开篇

前几天，Anthropic 官方工程团队发布了一篇技术博客《Scaling Managed Agents: Decoupling the brain from the hands》。

刚好最近在学习拆解 Claude Code 的底层技术架构，初读这篇博客时，脑子里冒出了不少问号：这个 Managed Agents 是一个新的协议吗？为什么原本用来包裹模型的 Harness 被剥离出来变成了大脑？ 

带着这些疑问反复推敲，原来我的认知卡点，在于一直带着「本地单体应用」的思维，去看待「云端托管平台」的架构。

这篇文章就是我将 Claude Code 底层代码复现工程，与 Anthropic 这篇最新架构反思放在一起对读后，做的一次从「本地单体应用」到「云端多智能体托管」的架构演进梳理。

一共会分为以下三个部分～

• Claude Code 底层的单体 Agent 架构

• 单体 Agent 的困境与「宠物」隐喻

• Managed Agents 「脑、手与会话」的解耦

希望这次从底层代码到宏观架构的梳理，能对你理解真正可落地的 Agent 业务架构有一点点启发～😊

文章地址：https://www.anthropic.com/engineering/managed-agents

Claude Code (cc) 的单体架构

当我们打开 cc 的终端界面，敲下一句"帮我写一个贪吃蛇游戏"后，背后会发生什么呢？😯

可以把它大致拆解为以下三个核心组件：

1、核心状态机（The Harness / Query Loop）

这是整个 Agent 最核心的部分。在 cc 中，它被具象化为一个名为

query_loop 的 while(True) 循环。这个循环定义了 Agent 思考和行动的节奏：

Phase 1（准备）：系统把你的要求、当前的文件目录、之前的对话等等，打包成一长串消息流（Transcript）。

Phase 2（调用与流式执行）：把这串长长的文本发送给模型。此时模型开始吐出结果。如果模型决定调用工具（比如Bash跑命令），系统可以不等模型把话全说完，立刻并发启动工具。

Phase 3（执行与拼装）：工具在你的本地电脑上真实地运行（比如创建了一个 game.py ），然后系统把成功或失败的结果再次拼装回消息流中。

Phase 4（循环）：系统拿着带有工具执行结果的新消息流，再次去调用模型，直到模型说：“任务完成（end_turn）”。

👉 这个把模型包裹起来、给它提供上下文、并负责把模型的意图翻译成真实世界动作的脚手架代码，被称为Harness。

2、双手（The Hands / Tools）

模型本身是没有实体的。在 cc 中，「手」就是那 20 多个预先写好的 Python 脚本（比如 FileEditTool , BashTool , GlobTool 等）。

当模型输出一段特定的JSON说：{"tool": "bash", "command": "ls -la"}时，Harness 就会在当前的操作系统环境下拉起一个子进程去执行它。

3、记忆与上下文（The Session）

在 cc 这类 harness 中，运行时上下文高度依赖信息流（transcript），并通过 compact 与 memory 机制来缓解窗口限制。但它不等同于 Managed Agents 所强调的外置、耐久、可按需回放的 session log。（这个下面会写到～）

简单总结一下 cc 的单体架构：

cc 本地终端就是一个大容器。在这个容器里，住着大脑（Harness+模型接口）、双手（执行工具的环境）和记忆（不断被裁剪的上下文）。它们紧紧抱在一起，共享着电脑的CPU、内存和最高权限。

这在本地用起来的确很厉害，但如果要把这个模式搬到云端，卖给成千上万的企业呢？这时问题就出现了。👇

单体Agent的困境：不要把服务器当宠物养

在 Anthropic 的博客中，他们指出了这种紧耦合架构在面临大规模扩展时的三大痛点。

痛点一：脆弱的宠物

宠物是主人精心起名字且无法承受失去的个体，它要是病了（死机），主人就会半夜爬起来去抢救它；而牛是牧场里打着编号的家畜，死了一只，直接换下一只。

在这个旧架构里，Agent 就变成了一只娇贵的宠物。🐈‍⬛

因为大脑（Harness）、手（代码沙盒）和会话日志（Session）都在同一个容器里。如果代码沙盒里跑了一个死循环导致内存溢出，整个容器崩溃了，那么：

• Harness 挂了，大脑断线。

• Session 丢了，刚才聊了几十轮的进度全都灰飞烟灭。

工程师们只能被迫去抢救这些容器，而因为容器里有用户的私有代码，为了隐私安全，工程师甚至无法登进去 Debug。

痛点二：上下文焦虑症

随着模型变得越来越聪明，Harness 里的很多补丁代码会变得很可笑。👇

Anthropic 发现了一个有趣的现象：早期的 Claude 3.5 Sonnet 模型，在做长周期任务时，如果感觉到 token 快到上限了，它会产生「上下文焦虑」，开始草草结案。

为了解决这个问题，工程师在 Harness 里加了强制的上下文压缩（也就是cc/compact）。

但这是一种不可逆的破坏。因为这样强行抹掉了前期的代码报错细节，等到模型后续需要复盘时，线索已经断了。并且，当模型升级到 Opus 4.5 时，模型本身已经没有焦虑症了，Harness 里那段强制压缩的代码，反而成了枷锁。

痛点三：可怕的安全边界

在大脑和手不分家的架构里，模型生成的代码和系统的核心凭证（比如 GitHub Token）都在同一个盒子里。

如果模型遭遇了用户的「提示词注入攻击」，它完全可以悄悄写一段代码，读取当前环境变量里的私钥，然后发送到黑客的服务器上。因为在这个容器里，模型的手能摸到一切。🥷

Managed Agents：彻底的「脑手分离」

面对上述痛点，Anthropic 意识到：修修补补是没用的，必须在架构层面进行肢解。这就是面向长周期复杂任务的云端托管方案：Managed Agents（托管智能体）。

Managed Agents 的核心哲学可以用一句话概括：定义永恒的接口，让大脑、双手和记忆彻底解耦。👇

解耦一：大脑（Brain）离开容器，双手（Hands）变成「牛」

在这个架构中，Harness（包含 query_loop 的大脑层）被彻底从执行代码的容器（沙盒）中抽离了出来。

Harness 变成了「无状态的调度器」：它不再自己跑代码，当它需要执行命令时，它通过一个标准的接口 execute(name, input) -> string 呼叫远端的沙盒。

沙盒变成了「牛」：沙盒只是一个用来干脏活累活的隔离环境。如果在编译代码时沙盒崩溃了，没关系～由于大脑在外面，大脑不会死。🙂‍↔️大脑只会收到一个报错：“工具执行超时/失败”。然后大脑可以冷静地决定：调用

 provision({resources}) 接口，重新拉起一个新的沙盒，继续干活。

这种「自杀与重生」的机制，呼应了之前在《Agent = Model + Harness：一切皆是一个拉尔夫循环》中提到的理念：真正的鲁棒性，来自于系统的随时可抛弃。

解耦二：Session（对话日志）独立于上下文窗口

👉 这是用来解决「上下文焦虑症」问题的。

在 Managed Agents 中，对话日志不再局限于随时会被挤爆的上下文窗口。Anthropic 引入了一个独立存在、只追加不修改的Session（事件日志流）。

这就像给 Agent 外挂了一个行车记录仪：从第一条用户指令，到中间每一次工具调用的输入输出，全部被永久地、安全地记录在这个外部的 Session 数据库里。

按需检索：当 Harness 发现上下文太长需要清理时，它可以放心地清理。因为只要模型需要，它随时可以通过getEvents()接口，像查监控录像一样，倒回前天下午的 3 点 15 分，重新读取那一次特定的代码报错日志。

上下文不等于记忆（正如之前的文章所写）。在这个架构下，短期的上下文窗口只负责当前的思考推理，而外置的 Session 才是 Agent 真正的长期记忆库。如果 Harness 崩溃重启了，它只需要调用 wake(sessionId)，就能从日志中完美恢复上一秒的状态。

解耦三：安全边界的物理隔离

👉 因为「脑手分离」，鉴权问题迎刃而解。

当 Agent 需要拉取 GitHub 仓库时，存放 Token 的保险库绝不会把 Token 告诉模型，也不会把 Token 塞进跑代码的沙盒里。

系统通过外部的 MCP 代理服务：代理服务拿着 Session ID 去金库验证权限，通过后，由代理服务把代码拉下来，再挂载进沙盒。

Agent 永远都不会知道密码是什么，它只负责干活。即使它被注入了恶意指令，它在四面环壁的沙盒里，也偷不走任何东西。😎

解耦四：多脑多手，极速启动（TTFT优化）

👉 当一切都被解耦为标准接口后，一个商业优势出现了：极致的性能体验。

在旧架构下，用户说一句话，后台要花几十秒去启动一个包含完整环境的臃肿容器，导致首字返回时间极长。

现在，Harness（大脑）是极其轻量的代码，立刻就能启动。只有当模型思考完毕，决定真的需要写代码时，后台才会去动态拉起一个沙盒。

更进一步的，这种接口设计天然支持「多脑多手」。一个大脑可以同时操作多个不同的沙盒（比如一个跑前端代码，一个跑 Python 后端）；或者大脑遇到处理不了的专业问题，可以直接把手的控制权移交给另一个拥有专门 Prompt 的子大脑。

这套接口设计为「many brains，many hands」提供了更自然的系统基础，也让多执行环境、多 harness 以及多智能体式协作更容易成立。

最后

从本地的一段 query_loop 循环，到云端的 Managed Agents 解耦架构，正如 Anthropic 博客中写道的： 

挑战其实是一个古老的问题：如何为“尚未被构想出来的程序”设计系统。 

所以，Agent 不是一个更复杂的Chatbot，它是一套全新的计算范式。💻