Managed Agent：脑手分离
把思考和执行拆到不同进程，像操作系统一样虚拟化 Agent
本页解决的问题
先给结论「Managed Agent：脑手分离」要解决的关键问题是什么？
把思考和执行拆到不同进程，像操作系统一样虚拟化 Agent
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
容器挂了 = 会话丢失 = 无法调试 = 任务彻底失败。
就像养了一只宠物，挂了就完了，无法替代。
容器挂了 = 工具调用失败 = Claude 决定重试 = 新建容器继续。
就像牧场的牛，挂了重来一个，系统照常运行。
-
容器变成工具调用：
execute(name, input) -> string，对 Harness 来说就是一个普通函数 - 容器挂了 = 工具调用返回错误 = Claude 自行决定是否重试 = 自动新建容器继续工作
- Harness 可以在容器启动前就开始处理，不需要等容器 ready
TTFT = Time to First Token（首 Token 响应时间）
- 旧方案：Agent 生成的代码和 API 密钥在同一个容器里，Prompt Injection 可以直接偷密钥
- Git Token：在克隆仓库时注入容器环境变量，沙箱内可以用，但 Agent 看不到 token 值
- MCP OAuth Token：存在外部 vault 里，通过代理转发 MCP 调用，沙箱内无法直接访问 token
这意味着你可以让一个 Brain 同时操控多个 Sandbox（并行执行），也可以让同一个 Sandbox 在不同的 Brain 之间传递（接力执行）。组件之间完全解耦。
「类比：操作系统的虚拟化」如何改变一次回答
「TTFT = Time to First Token（首 Token 响应时间）」说明，模型处理的不是我们眼中的“字数”，而是一段段 Token。Token 的切分方式会影响输入长度、上下文能放下多少内容，以及一次请求要花多少计算。
长度、信息量和上下文不是一回事
当「这意味着你可以让一个 Brain 同时操控多个 Sandbox（并行执行），也可以让同一个 Sandbox 在不同的 Brain 之间传递（接力执行）。组件之间 完全解耦」变长时，先要分清三件事：文字被切成多少 Token、哪些内容真正参与当前判断、以及旧内容是否已经超出上下文窗口。删掉重复说明通常比单纯把窗口开得更大更有效。
- 容器变成 工具调用 ： execute(name, input) -> string ，对 Harness 来说就是一个普通函数
- 容器挂了 = 工具调用返回错误 = Claude 自行决定是否重试 = 自动新建容器继续工作
- Harness 可以在容器启动前就开始处理， 不需要等容器 ready
先保留会改变判断的内容
可以用「这意味着你可以让一个 Brain 同时操控多个 Sandbox（并行执行），也可以让同一个 Sandbox 在不同的 Brain 之间传递（接力执行）。组件之间 完全解耦」做一次对照：保留同样的问题，分别删掉重复背景、压缩格式和移除无关历史，比较答案质量、延迟与 Token 数量。
从「类比：操作系统的虚拟化」走到「三个核心组件」
「类比：操作系统的虚拟化」先把问题落在「操作系统虚拟化硬件 当你调用 read() 时，你不关心底层是 SSD、HDD 还是网络磁盘，操作系统帮你抽象了硬件细节。 Managed Agent 做同样的事 ：虚拟化 Agent 的各个组件，让脑不关心手是哪个容器，让手不关心脑用的是哪个模型」上；到了「三个核心组件」，讨论继续推进到「Session 会话日志 Append-only 的事件流，持久化存储。记录所有发生过的事情：用户输入、工具调用、模型输出。 Harness 脑 / 大脑 调用 Claude 并路由工具调用的循环。负责思考：决定下一步做什么、如何组织上下文。 Sandbox 手 / 沙箱 执行代码和编辑文件的容器环境。负责执行：运行命令、写文件、与外部系统交互」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
处理长文本时，先保留会改变结论的内容，再决定如何压缩格式和历史；上下文更长只有在新增信息真正有用时才值得付出代价。
- 「类比：操作系统的虚拟化」：操作系统虚拟化硬件 当你调用 read() 时，你不关心底层是 SSD、HDD 还是网络磁盘，操作系统帮你抽象了硬件细节。 Managed Agent 做同样的事 ：虚拟化 Agent 的各个组件，让脑不关心手是哪个容器，让手不关心脑用的是哪个模型
- 「三个核心组件」：Session 会话日志 Append-only 的事件流，持久化存储。记录所有发生过的事情：用户输入、工具调用、模型输出。 Harness 脑 / 大脑 调用 Claude 并路由工具调用的循环。负责思考：决定下一步做什么、如何组织上下文。 Sandbox 手 / 沙箱 执行代码和编辑文件的容器环境。负责执行：运行命令、写文件、与外部系统交互
- 「最后的要点」：Git Token ：在克隆仓库时注入容器环境变量，沙箱内可以用，但 Agent 看不到 token 值
最后的「最后的要点」把讨论落到「Git Token ：在克隆仓库时注入容器环境变量，沙箱内可以用，但 Agent 看不到 token 值」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。