托管代理运行

本地跑 Agent 时常见的三个问题

把编码 Agent 当作一次性脚本在本机进程里跑，很快会遇到几类麻烦：其一，环境不可复现——代码库耦合在宿主机，依赖靠临时安装，另一台机器或新成员接手时又要重踩一遍坑；其二，无法作为长期服务稳定运行——网络抖动或进程重启都会打断任务，断点难以续上，离 7×24 持续工作很远；其三，多人协作冲突明显——几个同事同时改一个仓库，谁改了什么、合并前是否经过质量门，都缺乏清晰边界。

这套技能如何工作

该技能把运行环境从用户机器上剥离，Agent 被部署进远程沙箱，并要求输出结构化工件 HostedAgentSpec 与落地建议。四个关键能力对应上述问题：

• 镜像与数据卷解耦：Agent 运行在镜像注册表管理的预构建镜像中，修改镜像约需 30 分钟，因此把环境依赖固定在镜像里，把频繁变动的业务代码放进数据卷，避免每次都重打镜像。
• 预热池降低冷启动：预先启动一批空闲沙箱，新会话直接从池中分配，而不是临时拉起镜像，从而把冷启动延迟控制在可接受范围。
• 快照与恢复：对运行中的沙箱定期做内存加磁盘快照，会话中断或需要回放时，从快照继续执行，而不是从头跑一遍；需要事先明确快照粒度（全量或增量）与间隔，避免恢复点过旧。
• 会话隔离与多人协作：每个会话拥有独立的状态边界，工作目录、环境变量和密钥互不读取；跨会话共享只能通过显式交接文件。多人在同一仓库协作时，提交携带用户身份，合并前经过质量门，谁改了什么可审计。

适用边界与注意点

它并不适用于所有场景：纯本地、单轮就能结束的任务不必上沙箱；文件级上下文策略应交给 filesystem-context，工具契约设计应交给 tool-design，混用反而增加复杂度。此外，预热池大小、沙箱规模和自生成子沙箱的上限都需要按实际流量设置，否则要么冷启动排队，要么成本失控。