【Managed Agent】资源池与调度：如何给Agent分配可执行资源

本文暂为大纲，正文待补充。

Swarm在这里不是要讨论Agent如何互相对话、如何生成子Agent，而是一个更现实的问题：当很多Agent同时需要Sandbox、CPU和Memory时，平台怎样决定谁能开始、谁要等待，以及资源怎样在异常后回到池中。

从单个Sandbox到资源池

单个Agent临时启动Sandbox时，资源看似足够；并发任务变多后，CPU、Memory、容器启动位和外部连接都会变成有限资源。
Swarm只作为多Agent并发提出资源需求的背景，不展开Agent间通信和编排协议。
资源池要把机器上可供调度的能力，转换为系统可以比较、预留和回收的资源单位。

资源模型：vCPU、Memory与执行槽位

怎样用vCPU和Memory描述一个任务的最低需求、目标需求与上限。
Sandbox、并发进程、连接和磁盘工作区是否也需要作为独立的资源维度。
请求值、限制值和实际使用量分别解决什么问题；哪些粒度应由平台统一规定。

申请、放置与调度

一次任务如何提出资源申请，并进入等待、已预留、已分配、执行中或已回收等状态。
调度器怎样从候选机器或资源池中选择放置位置：可用容量、亲和性、冷启动成本与公平性。
任务优先级、租户配额和应用限额怎样影响排队顺序。

Lease：资源不会被永久占住

分配资源时为什么要创建Lease，而不是只写一个“已占用”标记。
Worker、Sandbox与调度器分别怎样续租、观察到期和确认释放。
Worker宕机、容器异常或回执丢失时，怎样根据Lease安全判定资源可以回收。

扩缩容与超卖

为什么CPU、Memory和Sandbox槽位不能简单按照物理容量一比一分配。
超卖带来更高利用率，也会带来排队、抢占、OOM和延迟抖动风险。
扩容触发条件、预热容量、缩容时机，以及怎样避免频繁抖动。
在成本、启动速度、任务成功率和用户等待体验之间如何取舍。

异常与治理闭环

长时间无进展、资源未释放、重复调度失败和租约泄漏怎样被观测到。
如何保留任务现场后取消、重新调度或回收资源。
与《可观测性与任务治理》《Sandbox选型与生命周期》的职责边界。

从Kubernetes借来的思想，和没有照搬的部分

借鉴资源声明、调度、Lease与控制器式收敛的思路。
不照搬完整的Kubernetes对象体系，而是只保留Managed Agent所需的最小模型。