Managed Agents：让 Agent 长时运行的接口，比具体 Harness 更重要

Anthropic 在这篇工程文章里解释了一个核心观点：harness 会随着模型能力提升而过时，但围绕 agent 的稳定接口应该尽量持久。他们推出的 Managed Agents，本质上就是一个为长周期 agent 工作设计的托管服务，它试图用一组更稳定的抽象，去承接未来不断变化的 Claude harness、sandbox 和执行环境。

原文链接：https://www.anthropic.com/engineering/managed-agents

这篇文章在讲什么

Anthropic 认为，很多 agent 系统的问题，不在于模型不够强，而在于外围 harness 写死了太多“模型现在做不到什么”的假设。随着模型变强，这些假设会迅速过时，原本有效的工程补丁也会变成累赘。

他们举了一个例子。此前在 Claude Sonnet 4.5 上，他们发现模型在接近上下文上限时，容易提前草草结束任务，也就是所谓的“context anxiety”。于是，他们在 harness 里加入了 context reset 机制来缓解这个问题。但当同样的 harness 用在 Claude Opus 4.5 上时，这种行为已经消失了，原本的 reset 逻辑反而变成了多余负担。

所以，Anthropic 的判断是：harness 必然持续演化。与其围绕某一代模型能力写死系统，不如设计一套能长期存在的接口，让 harness 可以自由替换，而不影响整个 agent 系统。

Managed Agents 的核心抽象

Anthropic 借鉴了操作系统的设计思路。就像操作系统把不断变化的底层硬件抽象成稳定的 process、file 等接口一样，Managed Agents 也把 agent 系统拆成几个彼此解耦的组成部分：

• Session：记录一切发生过事情的追加式事件日志
• Harness：调用 Claude、分发工具调用、驱动 agent 循环的控制层
• Sandbox：Claude 可执行代码、编辑文件、运行任务的执行环境

这种拆分的重点，不是规定底层必须怎么实现，而是只规定这些组件之间怎样通过稳定接口协作。

Anthropic 的立场很明确：他们不执着于今天具体使用哪种 harness，而是更在意 Claude 周围接口的形状是否足够通用，能不能兼容未来不同类型的执行器、工具系统和任务编排方式。

为什么一体化容器方案不够好

他们一开始也尝试过把 session、harness、sandbox 都放进同一个容器里。这样做看起来很直接，文件操作是本地系统调用，也不用设计复杂的服务边界。

但问题很快出现了。

1. 容器变成了“宠物”

一旦所有关键状态都绑在同一个容器上，这个容器就不再是可替换的 cattle，而变成了必须小心照料的 pet。

• 容器挂掉，session 就丢了
• 容器无响应，需要工程师手动抢救
• 故障定位困难，只能从 WebSocket 事件流侧面猜测问题
• 真要调试，还得进容器开 shell，而容器里往往又带着用户数据，调试能力受到很大限制

2. Harness 假设资源必须和它在一起

这种设计还默认 Claude 要操作的代码仓库、工具和资源都在同一个容器环境里。可一旦客户想让 Claude 访问他们自己 VPC 里的资源，这个假设就立刻成了阻碍。

客户要么得跟 Anthropic 的网络打通，要么就得自己部署整套 harness。也就是说，原本只是工程实现细节的一个假设，最后变成了产品能力的边界。

关键架构思路：脑、手、会话分离

Anthropic 最终采用的方案，是把 agent 系统里的三类职责拆开：

• Brain（脑）：Claude 加上 harness
• Hands（手）：沙箱、外部工具、执行环境
• Session（会话）：持久化事件日志

拆开之后，每一层都可以单独失败、替换、恢复，而不用把整个 agent 一起拖垮。

Harness 不再住在容器里

harness 不再和 sandbox 绑死，而是把 sandbox 当作普通工具来调用，例如：

execute(name, input) -> string

这样一来，sandbox 容器如果崩了，harness 只会把它当成一次工具调用失败，交还给 Claude 处理。Claude 可以决定是否重试，而新的容器可以按标准流程重新 provision。

这让 sandbox 从“需要人工照料的宠物”变成了真正可替换的执行单元。

Harness 自己也变成可替换组件

因为 session 日志被移到了 harness 外部，即使 harness 崩溃，关键状态也不会丢失。新实例只需要：

• wake(sessionId)
• getSession(id) 取回事件日志
• 从最后一个事件继续恢复执行

在 agent loop 过程中，harness 持续通过 emitEvent(id, event) 写入 durable session log。这样恢复就不依赖某个具体进程还活着。

安全边界为什么更强

Anthropic 也强调了一个很现实的问题：如果 Claude 生成的不可信代码，与凭证处在同一个容器环境里，那么 prompt injection 的攻击路径会非常短。

攻击者只需要诱导 Claude 去读取它自己运行环境里的凭证，就可能拿到 token。拿到 token 后，攻击者甚至可以启动新的 session，继续放大攻击面。

他们认为，单纯依靠缩小 token 权限范围并不稳妥，因为这依然建立在“模型暂时还做不到什么”的假设上。而模型能力是在持续提升的。

所以更稳健的做法是结构性隔离：让 sandbox 根本接触不到这些凭证。

他们采用了两种模式：

• Git 凭证与资源绑定：初始化 sandbox 时，用仓库 token 完成 clone，并把认证能力接到本地 remote 上。Claude 在 sandbox 内可以正常 pull/push，但看不到 token 本身。
• 外部工具走 MCP + vault：OAuth 凭证保存在安全 vault 里，Claude 调用 MCP 工具时，先经过代理层，代理层拿 session 关联 token 去 vault 取凭证，再代表 Claude 调外部服务。

结果是，harness 本身也不会直接接触这些敏感凭证。

Session 不等于上下文窗口

长周期任务几乎必然会超出模型的上下文窗口。常见做法比如摘要压缩、记忆写文件、裁剪旧消息，都带有一个共同问题：它们会做不可逆的信息取舍。

问题在于，你很难提前知道未来哪些 token 还会有用。

Anthropic 在 Managed Agents 里把 session 设计成一个独立于 Claude context window 的“可恢复上下文对象”。也就是说：

• Claude 当前上下文窗口里放什么，由 harness 决定
• 全量历史则安全地存放在 session log 中
• Claude 或 harness 可以通过 getEvents() 按位置切片读取历史事件

这种设计的好处是：

• 可以从上次读取的位置继续往后读
• 可以为某个动作回退几条事件，查看上下文前因后果
• 可以在需要时重新读取早先历史，而不是依赖之前被压缩后的摘要

同时，harness 仍然可以对取回来的事件做任意转换，比如为了 prompt cache 命中率重新组织上下文，或做专门的 context engineering。

Anthropic 刻意把“可恢复的历史存储”与“当前上下文管理策略”拆开，因为他们认为后者未来还会不断演化，不该被过早固化。

Many brains, many hands

这篇文章另一个很重要的点，是 Managed Agents 天然支持“多个脑”和“多个手”。

Many brains

当 brain 和 hands 解耦后，不是每个 session 一开始都必须先起一个完整容器。只有真的需要 sandbox 时，brain 才通过工具调用去 provision 对应执行环境。

这带来了直接收益：

• 不需要 sandbox 的任务，不必为容器冷启动付出代价
• session 可以更快开始推理
• 整体首 token 时间（TTFT）显著下降

Anthropic 给出的数据是：

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

对于用户来说，这就是非常直接的体感优化。

Many hands

另一面是，一个 brain 可以连接多个 hand，也就是多个执行环境、工具系统、MCP 服务或其他设备。

Anthropic 承认，这会增加 Claude 的推理负担，因为它必须理解不同执行环境并决定把任务发往哪里。但随着模型能力提升，这种多 hand 协同逐渐变得可行。

一旦 hands 被统一抽象成 execute(name, input) -> string 这样的工具接口，底层可以是：

• 容器
• MCP server
• 手机
• 甚至 Pokémon 模拟器

而且 hands 不再绑定某一个 brain，因此不同 brain 之间还可以互相传递、共享这些 hands。

我的理解：这篇文章最值得记住的是什么

如果只提炼一个结论，我会认为是这一句：

不要把 agent 系统设计成围绕当前模型短板打补丁的工具堆，而要把它设计成一组能适配未来模型能力的稳定接口。

Anthropic 在这里其实不是单纯分享“Claude Managed Agents 的实现细节”，而是在给出一种更长期有效的 agent infra 思路：

1. 把状态持久化从执行进程里拿出来，避免某个实例挂掉就失忆
2. 把执行环境当作可替换工具，而不是 agent 本体的一部分
3. 把安全边界建立在结构隔离上，而不是建立在模型暂时做不到某事上
4. 把 session 视为可恢复的完整历史，而不是仅仅等于当前 prompt
5. 把未来 harness 的变化当成必然事件来设计系统

这套思路对于所有在做 agent orchestration、long-running tasks、tool-using agents、MCP-based systems 的团队都很有参考价值。

适合谁读

如果你正在关心这些问题，这篇文章很值得细读：

• 怎么设计长时间运行的 agent 系统
• agent 崩溃后怎样恢复，而不是从头来过
• 如何处理 context window 不够长的问题
• 怎样把 tool use、sandbox、session、凭证管理拆开
• 怎么让 agent infra 不被某一代模型特性绑死

对于做 agent 产品、AI infra、自动化编排平台的人来说，这篇文章的价值，不只是“Anthropic 怎么做”，而是它提供了一套很清晰的系统抽象框架。

总结

Managed Agents 的本质，不是又一个新的 Claude harness，而是一个 meta-harness。

它不试图押注未来 Claude 只会需要某一种固定执行方式，而是预设未来会出现更多 harness、更多 sandbox、更多执行环境，以及更多脑和手的协作场景。

Anthropic 的结论很克制，也很重要：

• 要对 Claude 周围的接口形状保持明确主张
• 但不要对未来 Claude 具体会怎么工作做过度假设

这其实就是这篇文章最核心的工程哲学。