很多 AI agent 的第一版架构都很像：模型、harness、workspace、工具调用、文件编辑和凭证，全都在一个容器里。这样做的好处非常现实，开发快、调用近、文件改动就是本地 syscall，看上去几乎没有分布式复杂度。
问题在于，这种简化通常只在“单人实验 + 短任务”里成立。一旦进入真实系统，单容器设计会把三个本应独立失败的东西绑死在一起：大脑、手和会话。容器一挂，你既不知道状态还在不在，也不知道 side effect 做到哪，更不知道凭证有没有被暴露给生成代码。
这就是为什么 orchestrator 与 sandbox 的解耦，不是架构洁癖，而是让 agent 能长时间、跨环境可靠运行的基础。建议先结合 AI agent Sandbox 环境设计、AI agent Session Store 设计、AI agent Worker Lease 与心跳机制 和 AI agent 凭证委托与 Token Vault Proxy 一起看。
当“大脑”和“手”绑在一起，故障会被放大
单容器架构最常见的问题有 4 类：
| 问题 | 为什么会被放大 |
|---|---|
| 容器故障 | 推理状态、文件状态和工具状态同时丢失 |
| 调试困难 | 你分不清是 harness 卡了，还是 sandbox 卡了 |
| 安全边界模糊 | 生成代码可能直接接触环境变量和凭证 |
| 资源浪费 | 每次会话一开始就得完整 provision 一个重量级环境 |
这类设计真正的问题，不是“太简单”，而是把本来应该分开的失效域混成了一个整体。
更稳的模型：orchestrator 负责推理和调度，sandbox 只负责执行
解耦后的最小职责边界通常长这样：
- orchestrator 负责 session 读取、上下文组织、模型调用、工具路由和策略判断
- sandbox 负责执行代码、访问文件、运行受控命令和返回结果
- session store 负责保存 durable 事件和恢复事实
从接口上看，关键不是“调用远程容器”，而是把执行环境变成一个普通工具：
execute(environmentId, input) -> result
一旦变成这个形态，sandbox 就不再是系统的“宿主”，而只是被 orchestrator 调用的一只手。手断了，可以换新的；大脑挂了，可以从 session 再醒。
失败案例：容器卡死后，团队既不能恢复，也不敢进去排查
某团队把 agent 的 workspace 和凭证都放在同一个容器里。一次任务执行中，容器长时间无输出。值班同学想进去查看，但又担心容器里同时装着用户代码和敏感 token；强杀容器又怕丢状态。
最后的局面很典型：
- 调试路径不清晰
- 恢复路径不存在
- 安全边界不敢碰
这不是单个 bug，而是架构层的失败模式。解法也不是“再写一个心跳”，而是把状态放到 session、把凭证放到 vault、把执行放到 sandbox，让每一层都能独立失败、独立更换。
解耦以后，TTFT 和隔离通常都会一起变好
很多人担心解耦会增加调用链，导致首 token 更慢。现实里，恰恰相反。因为当 orchestrator 不再默认为每个会话提前 provision 完整 sandbox 时，很多纯读任务或轻任务可以先推理、后执行，甚至根本不需要启动重型环境。
这会直接带来两个收益：
- 只有真的需要“手”的任务才去 provision 手
- 纯规划和轻查询任务不再被环境初始化阻塞
也就是说，解耦不仅改善故障边界，还给了系统延迟优化的空间。
解耦设计 Checklist
- orchestrator、sandbox 和 session store 是否是三个独立职责面
- sandbox 是否被视作受控工具，而不是会话宿主
- 会话状态是否离开容器，成为 durable session 事实
- 生成代码是否无法直接读取真实凭证
- sandbox 失效后是否可以替换新环境而不丢全局会话
- 纯规划型任务是否可以在不 provision 重型环境的情况下先响应
最值得坚持的一条边界
真正可靠的 agent 系统，不是“容器足够稳”，而是即使某个 sandbox 坏掉，系统仍知道任务进行到了哪、下一步该怎么办、哪些 side effect 已经提交。只要你仍把大脑和手绑在一起，这件事就会变得非常昂贵。
延伸阅读：
