Anthropic《Scaling Managed Agents: Decoupling the brain from the hands》深度解读¶

这篇文章到底在讲什么¶

一句话先说结论：

Anthropic 这篇文章表面上是在介绍 Claude Managed Agents 的工程设计，但更深层其实是在回答一个更通用的问题：

当模型能力持续变强时，Agent 系统应该把什么设计成稳定层，什么设计成可替换层？

Anthropic 给出的答案是：

• 不要把某一代模型的“补丁式 harness 技巧”当成长期架构；
• 要把 session、harness、sandbox/tools 之间的接口设计成更稳定的一层；
• 用“接口稳定、内部可替换”的方式，让系统能随着模型能力变化而持续演进。

所以，这不是一篇单纯的产品介绍文，而是一篇非常典型的“Agent 平台架构方法论”文章。

先建立一个总心智模型¶

Anthropic 在文中把一个 Agent 系统拆成了三块：

1. Brain（脑）
   - Claude + harness
   - 负责推理、规划、决定下一步做什么、把工具调用路由出去

2. Hands（手）
   - sandbox、tools、MCP、执行环境
   - 负责真正去运行命令、读写文件、访问外部服务

3. Session（会话）
   - append-only 的事件日志
   - 负责持久化记录整个任务发生过什么，以支持恢复、审计、回放、异步执行

文章核心就是一句：

把脑、手、会话彻底解耦。

为什么 Anthropic 认为旧设计有问题¶

他们最开始把 session、harness、sandbox 都放进同一个容器里。

这看起来很自然，因为：

• 文件编辑是本地 syscall，简单；
• 没有额外服务边界，开发快；
• 所有东西都在一起，似乎更“顺手”。

但它很快带来了三个结构性问题。

1）容器变成了“pet”，不是“cattle”¶

文章用了经典的基础设施比喻：pet vs cattle。

• pet：一个不能丢、要人工照料的个体
• cattle：可替换、坏了就丢、重新拉起即可

旧设计的问题是：

• 容器一挂，session 也跟着丢；
• 容器卡住时，必须人工排查；
• 整个系统依赖某个具体容器还活着。

也就是说，原本应该是“可替换执行环境”的容器，被设计成了承载关键状态的单点。

这不是小 bug，而是状态边界放错了位置。

2）故障定位非常差¶

他们说自己的主要观察窗口只有 WebSocket 事件流。

但问题在于：

• harness 出 bug，
• 网络掉包，
• 容器离线，

这些在事件流上看起来都很像。

于是工程师为了定位问题，只能进入容器排查。但容器里往往又有用户数据，这在安全与运维上都非常别扭。

所以旧架构不仅脆，而且难 debug。

3）harness 默认假设资源和自己在一起¶

这是文章里特别重要但很容易被忽略的一点。

旧 harness 隐含了一个假设：Claude 要操作的东西就在当前容器里。

这个假设在内部玩 demo 时没问题，但一旦客户说：

“我的资源在自己的 VPC 里，你来接入吧。”

问题就来了。

于是客户只能：

• 和 Anthropic 网络打通，或者
• 直接在自己的环境里跑 Anthropic 的 harness

这说明一个很深的问题：

系统把“执行资源的位置”写死进了 harness 设计里。

一旦要跨网络边界、跨安全域，这种耦合就会变成产品扩展障碍。

新架构的核心思想：把脑从手里拆出来¶

Anthropic 最关键的决策是：

让 harness 不再住在容器里，而是把容器也看成工具的一种。

也就是：

• Brain 负责思考和编排；
• Hands 负责执行；
• Session 负责记录。

它们三者之间通过小而稳定的接口协作。

Hands 的统一抽象：execute(name, input) -> string¶

这是全篇最重要的抽象之一。

Anthropic 的意思不是“容器是特殊东西”，而是：

容器、工具、MCP 服务、本地执行环境，本质上都可以被视作一种 hand。

只要接口统一成：

execute(name, input) -> string

那么 Brain 就不需要知道对面到底是什么：

• 一个 Linux 容器，
• 一个 MCP server，
• 一个客户 VPC 里的服务，
• 甚至未来别的执行环境。

这背后的工程价值非常大：

1. 能力接入方式统一；
2. 底层实现可替换；
3. 扩展新 hand 的成本低；
4. Brain 的编排逻辑不会被基础设施细节污染。

这是典型的平台抽象思路：

上层稳定的是“能力接口”，不是具体实现。

容器也变成 cattle¶

因为容器不再承载核心 session 状态，所以容器挂了不再是灾难。

Brain 只会把它看成一次 tool-call failure。

如果 Claude 认为值得重试，就重新：

provision({resources})

拉起一个新容器即可。

这非常像云原生里“无状态工作节点 + 外部状态存储”的思路。

真正重要的状态不在容器本地，而在系统外部的 durable layer。

文章最深的一层：Session 不是 Claude 的上下文窗口¶

这是我认为最值得反复理解的一句。

在很多 Agent 系统里，大家会不自觉把“session”理解成：

• 当前 messages 列表
• 当前 prompt history
• 当前上下文窗口里那堆 token

Anthropic 说：不是。

他们把 session 定义成 append-only durable log¶

也就是：

• 所有事件都写入 session；
• session 持久化存在于 harness 外部；
• Claude 的上下文窗口只是“读取 session 的一个临时视图”。

这意味着：

1. 完整历史不受 context window 限制；
2. harness 崩了也不丢任务过程；
3. 可以回放、审计、重建现场；
4. 可以针对需要只取一部分历史重新喂给模型。

getEvents() 的意义¶

文章里说 Brain 可以通过 getEvents() 读取 session 中的事件切片。

这很关键，因为它把 context 从“直接塞满 prompt”升级成了“可检索对象”。

你可以：

• 从上次读到的位置继续读；
• 回退几个事件看前因后果；
• 在某个动作前重读上下文；
• 只取相关片段，而不是把全部历史再喂一遍。

这本质上是在说：

Session 是系统级状态；Context window 只是消费 Session 的一种方式。

这个抽象带来的好处远不止节省 token，而是让系统具备真正的长时程可恢复能力。

为什么文章反复强调“harness 假设会过时”¶

这篇文章的思想起点，其实来自 Anthropic 在过去 Agent 工程里的一个经验：

很多 harness 技巧，本质上是针对当前模型缺点打的工程补丁。模型变强后，它们会过时。

他们举的例子是“context anxiety”。

什么是 context anxiety¶

在之前的文章《Harness design for long-running application development》里，Anthropic 发现：

• Claude Sonnet 4.5 在上下文快满时，会出现一种“想赶紧收尾”的倾向；
• 为了缓解这个问题，他们设计了 context resets；
• 即清空上下文窗口，用结构化 handoff 让新 agent 接着干。

但到了 Claude Opus 4.5，他们发现这个问题基本消失了。

于是原来的 context resets 反而变成了：

• 额外 orchestration 复杂度
• 额外 token 开销
• 额外 latency
• 额外系统负担

也就是文章中的那个词：dead weight。

这件事真正说明了什么¶

说明你不能把“为了弥补某代模型弱点而加入的工程技巧”直接写死进系统主干。

否则模型能力一变，这些技巧就会从优化，变成包袱。

所以 Anthropic 的方法是：

• 允许 harness 持续变化；
• 但要让 session / sandbox / tool interface 这些更外层抽象尽量稳定。

一句话：

把易腐烂的东西放在可替换层，把长寿命的东西做成接口层。

这是这篇文章最强的方法论价值。

Harness 如何变成“可恢复的 cattle”¶

旧设计里，如果 harness 出问题，整个 agent 很难恢复。

新设计里，Anthropic 让 harness 也变成了可替换组件。

因为：

• session log 在 harness 外部；
• harness 不再需要自己保存完整状态；
• 只要用 wake(sessionId)、getSession(id) 读回事件流，就能从上次位置继续执行；
• 运行中持续 emitEvent(id, event)，确保整个过程有 durable record。

这相当于把 harness 从“有记忆的脆弱进程”改造成了“无状态编排器”。

这很像分布式系统里的一个成熟思想：

• 不追求组件永不失败；
• 追求组件失败后，能以低成本恢复语义连续性。

对于长任务 Agent，这比“尽量别挂”更重要。

安全设计：真正的边界不是容器，而是凭证位置¶

文章里还有一个非常强的工程点：

如果 Claude 生成的不可信代码和凭证在同一个执行环境里，那么 prompt injection 的后果会非常严重。

因为一旦攻击者诱导 Claude 读取环境变量，拿到 token，就可能：

• 启动新的 session；
• 扩大调用范围；
• 对外部系统做更深的操作。

Anthropic 的做法不是简单说“缩小 token 权限”，而是做了结构性隔离：

1）Git 凭证不暴露给 Agent¶

他们把 repo token 用在 sandbox 初始化时：

• clone 仓库；
• 配置 git remote；

这样 agent 在 sandbox 里可以正常 git pull / git push，
但并不会直接拿到底层 token。

2）MCP / OAuth 凭证放进 vault¶

对于自定义工具：

• Claude 调 MCP 工具时，先经过 proxy；
• proxy 拿 session token 去 vault 取对应凭证；
• 再代替 Agent 调外部服务；
• harness 本身也不直接看到凭证。

这层设计真正想说明什么¶

Agent 系统里最危险的不是“模型会不会胡说”，而是：

执行面是否能直接摸到原始秘密。

Anthropic 的答案是：

• 执行环境尽量无凭证；
• 凭证放在更外层的受控代理里；
• 给 Agent 的不是秘密本身，而是受限能力。

这是非常值得借鉴的安全思路。

性能收益为什么这么大：不是模型更快，而是架构更对¶

文章里给了一个很亮眼的数据：

• p50 TTFT 下降约 60%
• p95 TTFT 下降超过 90%

这里的 TTFT 指的是：从任务开始，到产出第一个 token 的时间。

为什么旧设计慢¶

因为旧设计相当于：

• 每个 session 一上来就得准备容器；
• clone repo；
• 拉取待处理事件；
• 启动整个执行环境；
• 哪怕它此时只是想先思考一下。

这等于把“可能之后才需要的资源”提前绑定到了启动路径上。

为什么新设计快¶

新架构把容器推迟成“按需 provision”。

所以：

• 不需要 hand 的 session，不用等容器；
• Brain 可以先开始推理；
• 只有真的要执行时，才去拉起 hand。

这说明很多 Agent 系统的性能问题，不是模型慢，而是生命周期设计错了。

一句话总结这部分：

最有效的性能优化，常常来自资源延迟绑定，而不是局部微调。

Many brains, many hands：这不是扩容，而是系统级升级¶

Anthropic 最后提出两个方向：

1）Many brains¶

当 harness 变成 stateless 组件后：

• 你可以更容易横向扩展多个 brain；
• 一个任务不再强绑定到某个具体容器；
• 更容易恢复、接力、扩缩容。

2）Many hands¶

当 hand 被统一抽象成工具后：

• 一个 brain 可以调多个执行环境；
• Claude 不必局限在一个 shell 里工作；
• 不同 hand 可以来自不同网络、不同安全域、不同类型的工具系统；
• 甚至 brains 之间还能传递 hands。

这一点非常重要。

因为它意味着 Agent 平台不再是“一个模型 + 一个终端”的设计，而是逐渐变成：

• 多 brain 协作
• 多 hand 执行
• session 作为共享事实底座

这更接近未来真正的 Agent 平台形态。

把产品文档和工程文章对起来看¶

Anthropic 的官方文档里把 Claude Managed Agents 定义为：

• pre-built, configurable agent harness
• 运行在 managed infrastructure 上
• 适合 long-running tasks 和 asynchronous work
• 核心概念包括：agent、environment、session、events

如果只看文档，你会觉得它主要是在卖一个“托管 Agent 运行时产品”。

但结合工程文章去看，会发现文档里的对象其实就是架构抽象的产品化映射：

• agent：Brain 的定义边界（模型、system prompt、tools、skills）
• environment：Hands 的运行模板（容器、网络、预装包）
• session：持久任务实例
• events：对外暴露的过程流

也就是说：

产品对象模型，正是工程抽象的 API 化结果。

这说明 Anthropic 不是先有一堆功能再包装成 API，而是先想清楚哪些对象该成为系统的一等公民。

普通软件工程师真正该学到什么¶

如果你不是要复刻 Anthropic 的平台，而是想做自己的 Agent 系统，这篇文章最值得带走的是下面 6 条。

1）先设计状态边界，再设计 prompt 技巧¶

不要一上来就沉迷：

• prompt 怎么写
• tool description 怎么调
• planner 怎么 hack

更应该先定义：

• session 存什么
• event 怎么记
• 失败怎么恢复
• 执行环境怎么隔离
• 哪些东西是 durable state

2）把 session 设计成日志，而不是消息数组¶

如果 session 只是 messages list，那么：

• 恢复困难
• 审计困难
• 回放困难
• 长任务很容易被 context window 限制住

更好的方式是：

• 把 session 做成可切片、可回放、可外部存储的事件流。

3）把模型特定补丁放进易替换层¶

像：

• context reset
• compaction 策略
• tool forcing
• retry heuristic
• prompt hack

这些都可能随着模型进步而过时。

所以它们应该是 policy / middleware / adapter，而不是平台最稳定的核心层。

4）把控制面和执行面分开¶

控制面负责：

• 思考
• 规划
• 路由
• 决策

执行面负责：

• 跑命令
• 调 API
• 操作文件
• 接触外部环境

这会带来：

• 更清晰的权限边界
• 更容易的故障定位
• 更好的可替换性

5）把凭证设计成“代理能力”，而不是“裸露秘密”¶

如果 agent 所在环境直接拿到真实 token，那么 prompt injection 的上限会非常高。

更稳的方式是：

• sandbox 不直接持有秘密；
• 通过 vault / proxy / scoped capability 访问外部资源。

6）评估架构时问一句：模型变强后，这层会不会变成 dead weight？¶

这是这篇文章非常成熟的一个判断标准。

任何你今天为了弥补模型不足而加的工程技巧，都应该问：

• 明天模型更强时，这还值不值得保留？
• 如果不值得保留，移除成本高不高？

如果移除成本很高，说明你把短寿命策略写进了长寿命架构。

我对这篇文章的最终理解¶

如果只用一句话总结：

Anthropic 在做的不是一个“更会调工具的 Claude”，而是一个“让 Agent 系统能持续适应未来模型能力变化”的架构底座。

它真正解决的不是“怎么让模型去跑命令”，而是：

• 怎么让 session 持久可靠；
• 怎么让 harness 可替换、可恢复；
• 怎么让 hands 可自由扩展；
• 怎么让安全边界不随着 Agent 更强而崩掉；
• 怎么让今天的 harness 技巧不会绑死明天的系统演进。

所以这篇文章最值得学的，不是某几个 API 名字，而是它背后的设计顺序：

1. 先稳定接口；
2. 再允许内部演化；
3. 先把状态和执行边界分清；
4. 再去做 prompt / harness 优化；
5. 默认承认模型会变强，因此系统要为“旧补丁过期”留好空间。

这其实已经不是“小技巧”，而是很成熟的 Agent 平台工程观。

适合你记住的 5 句话¶

1. Session 不是上下文窗口，Session 是可恢复的外部事件日志。
2. Harness 会过时，接口比 Harness 更应该稳定。
3. Brain 负责思考，Hands 负责执行，二者不要绑死。
4. 真正的安全边界不只是容器隔离，而是凭证不要落到执行面。
5. 很多性能优化来自资源延迟绑定，而不是单纯让模型更快。

可继续延伸阅读的方向¶

如果你想把这篇文章吃得更透，建议继续串读这几类内容：

1. Anthropic 早期关于 harness / context engineering 的文章
   - 理解为什么他们会得出“补丁会过时”的结论

2. 事件溯源（event sourcing）和控制面/执行面分离
   - 能更好理解 session log 和 brain/hands 分层

3. 面向 Agent 的安全设计
   - prompt injection、vault、scoped capability、proxy execution

4. Many-brains / many-hands 的调度问题
   - 这会自然延伸到 multi-agent orchestration 的设计空间

参考来源¶

已直接查看的主要来源：

1. Anthropic Engineering
   - https://www.anthropic.com/engineering/managed-agents
   - 标题：Scaling Managed Agents: Decoupling the brain from the hands

2. Claude API Docs
   - https://platform.claude.com/docs/en/managed-agents/overview
   - 标题：Claude Managed Agents overview

3. Anthropic Engineering
   - https://www.anthropic.com/engineering/harness-design-long-running-apps
   - 标题：Harness design for long-running application development

最后一句¶

如果你把这篇文章只读成“Anthropic 推了个托管 Agent 产品”，那只看到了表层。

如果你把它读成：

在模型能力持续上升的前提下，Agent 平台该如何设计稳定接口、易腐策略层、状态边界与安全边界，

那就读到了它真正有价值的地方。