# 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 平台该如何设计稳定接口、易腐策略层、状态边界与安全边界**，

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