Anthropic 的Managed Agents：把“大脑”与“双手”解耦

Anthropic 为什么要做 Managed Agents

Anthropic 最近介绍了他们在 Claude 平台上推出的一项能力：Managed Agents。如果用一句话概括，这套系统的目标是：把长时运行 Agent 的“大脑”、执行动作的“双手”，以及完整会话记录彻底拆开，让它们可以独立扩展、独立恢复、独立替换。

这不是一篇单纯讲新产品功能的文章，它更像是在解释一个更底层的问题：为什么长期运行的 AI Agent，不能继续靠把所有东西塞进一个容器里来完成。

对正在做 Agent、工作流、工具调用和长任务编排的人来说，这篇文章很值得看，因为它讨论的不是“再加一个 prompt”或者“再多接几个工具”，而是更长期的系统设计问题。

一句话看核心结论

Anthropic 的判断可以概括为三点：

•Agent 的核心部件应该被虚拟化，而不是硬耦合在一起

•Session 不能等同于模型上下文窗口

•未来的 Agent 系统，必须支持 many brains、many hands 的形态

他们把 Agent 系统拆成了三个可替换的接口：

•Session：记录所有事件的追加式日志

•Harness：负责调用 Claude、路由工具调用的编排层

•Sandbox：执行代码、编辑文件、接入外部资源的环境

这套设计的重点不在于今天内部到底怎么实现，而在于：无论未来底层实现怎么变，上层接口尽量稳定。

一、为什么要重新设计 Agent 基础设施？

Anthropic 先给出了一个很有代表性的背景：随着模型能力变化，很多早期在 harness 里写死的假设，都会慢慢失效。

例如，他们之前发现 Claude Sonnet 4.5 在上下文快满时，容易提前结束任务，出现一种类似“上下文焦虑”的行为。为了解决这个问题，他们在 harness 里加入了 context reset。结果后来把同样的 harness 用到 Claude Opus 4.5 上时，这个问题已经消失了，原来的 reset 机制反而成了额外负担。

这件事说明：

很多 harness 的设计，本质上都是对“当前模型还做不到什么”的补丁。

而一旦模型进步，这些补丁就可能从“必要机制”变成“历史包袱”。

因此，Anthropic 希望做一套更稳定的 Agent 运行方式：即使未来 harness 变了、sandbox 变了、上下文管理策略变了，系统也不需要推倒重来。

他们借用了操作系统的思路：像“进程”“文件”这样的抽象之所以能长期存在，不是因为底层硬件没变，而是因为接口足够稳定、足够通用。

Managed Agents 也是同样的想法：抽象 Agent 的关键组件，让具体实现可以自由演进。

二、从“一只难伺候的宠物”到“可替换的牛群”

Anthropic 早期的做法，是把 session、agent harness、sandbox 全都放进同一个容器里。

这种方式的好处很直接：

•文件编辑就是容器内直接 syscall

•没有明显的服务边界需要设计

•一开始实现起来比较顺手

但很快，他们撞上了经典的基础设施问题：你不是在管理一群可以替换的实例，而是在照料一只不能出事的宠物。

在“pet vs cattle”这个经典比喻里：

•pet（宠物）：有名字、需要人工照料、不能轻易挂

•cattle（牛群）：节点是可替换的，坏了就换

当所有东西都耦合在一个容器里时，这个容器就成了“宠物”：

•容器一挂，session 可能一起丢

•容器失去响应，就得人工进去救火

•出问题时，外部往往只能看到 WebSocket 事件流，很难分清到底是 harness bug、网络丢包，还是容器离线

•真要查问题，工程师就得 shell 进容器，但容器里可能还带着用户数据，这又带来新的调试和安全问题

更麻烦的是，这种设计默认 Claude 操作的一切资源都跟自己住在同一个容器里。客户如果想让 Claude 访问自己 VPC 里的资源，要么跟 Anthropic 网络打通，要么把 Anthropic 的 harness 直接跑进自己的环境里。一个写死在架构里的假设，变成了系统扩展的障碍。

所以他们最终做出的调整是：

•大脑（Claude + harness）拆出来

•双手（sandbox 与各种工具）拆出来

•会话记录（session log）也拆出来

三者之间只通过清晰接口协作，而不是共享一个命运共同体。

三、把“大脑”与“双手”分开，系统会发生什么变化？

1）容器不再是必须被救活的对象

在新设计下，harness 不再住在容器里，而是把容器当成普通工具来调用：

execute(name, input) → string

这意味着：

•容器挂了，不再等于整个 session 挂了

•harness 可以把失败当作一次工具调用错误回传给 Claude

•如果 Claude 决定重试，可以重新按标准流程初始化一个新容器

这样一来，容器从“宠物”变回了“牛群”。坏了就换，不需要人工把旧实例硬救回来。

2）Harness 自己也变成可替换组件

过去如果 harness 崩了，系统恢复会很麻烦，因为很多状态都跟它绑在一起。

新设计里，session log 在 harness 之外单独存在，所以 harness 崩溃本身不再是致命问题。新的 harness 可以通过：

•wake(sessionId)

•getSession(id)

•emitEvent(id, event)

把会话历史重新读回来，再从上一个事件继续执行。

这相当于把“运行中的过程”变成“可恢复的事件流”。

3）安全边界更清楚了

这是整篇文章里非常关键的一点。

如果 Claude 生成的不可信代码，和系统凭证运行在同一个容器里，那么 prompt injection 一旦成功，攻击者可能只需要诱导 Claude 去读取自己的环境变量，就能把令牌拿出来。

而一旦令牌泄漏，对方就可以：

•开新 session

•扩大权限

•继续委派更多工作

这类问题当然可以靠“尽量把 token 权限缩小”去缓解，但 Anthropic 的观点是：这仍然建立在“模型暂时还做不到什么”的假设上。 随着模型更强，这种假设本身就不稳。

更根本的修复方式，是让这些凭证从结构上就不可被 sandbox 触达。

Anthropic 提到两类处理方式：

•把认证信息绑定在资源侧

•把认证信息保存在 sandbox 外部的安全 vault 中

例如 Git 场景里，他们会在 sandbox 初始化时，用仓库 token 完成 clone，并把认证能力接到本地 git remote 上。这样在 sandbox 里做 push / pull 是可以的，但 Agent 本身不需要直接接触 token。

对于自定义工具，他们支持 MCP，并把 OAuth token 存进安全 vault。Claude 调 MCP 工具时，通过专门的代理层完成调用；代理拿到与 session 绑定的 token，再去 vault 里取对应凭证访问外部服务。也就是说，harness 本身不需要知道任何真实凭证。

这不是“少给一点权限”的问题，而是“根本不给模型直接碰到凭证”的问题。

四、Session 不等于模型上下文窗口

这是另一个很值得反复咀嚼的观点。

很多长任务都会超过模型上下文窗口长度。常见做法通常是：

•压缩上下文

•做摘要

•trim 掉旧工具结果

•把部分记忆写进文件

Anthropic 之前也研究过这些做法，比如 compaction、memory tool、context trimming 等。

但问题在于：

无论你怎么压缩、裁剪、摘要，本质上都在做不可逆取舍。

你很难提前知道，未来某一步到底会需要哪一段上下文。

如果被压缩掉的消息没有持久化保存，那么未来就拿不回来了。

因此，Managed Agents 的一个关键思路是：把 session 当成一个存在于上下文窗口之外、但可以被持续查询的上下文对象。

在他们的设计里：

•完整事件流 durable 地保存在 session log 中

•大脑可以通过 getEvents() 按位置切片读取事件

•可以从上次读到的位置继续往后读

•也可以回退几步，重新查看某个动作发生前后的上下文

更重要的是：取出来的事件，如何组织、如何变换、如何裁剪，再交给 Claude，这件事交给 harness 自己决定。

也就是说，他们把两件事明确分开了：

•Session 负责可恢复、可追问、可持久化的上下文存储

•Harness 负责具体的上下文工程策略

这背后的逻辑很清楚：未来模型会变，context engineering 的做法也会变，所以不要把今天的上下文策略写死成系统底层不可动的规则。

五、为什么要支持 many brains、many hands？

Anthropic 认为，未来 Agent 不会只是一颗脑袋加一双手，而会走向更复杂的编排形态。

Many brains：多“大脑”并行

早期如果把 brain 放在容器里，那么每多一个 brain，就得多起一个容器。结果就是：

•容器要先 provision

•仓库要先 clone

•进程要先启动

•事件要先从服务端拉下来

这些准备动作都会拖慢真正的推理开始时间。

Anthropic 用 TTFT（time-to-first-token） 来衡量这种延迟，也就是：从任务进入系统，到用户收到第一个 token 之间的时间。

这是用户体感最明显的延迟指标之一。

当 brain 从 container 中解耦出来后，container 只有在真的需要时，才通过工具调用被 provision。这样如果某个 session 一开始并不需要 sandbox，就不会先为它付出整套容器启动成本。

他们给出的结果是：

•p50 TTFT 下降约 60%

•p95 TTFT 下降超过 90%

这说明架构调整不只是“更优雅”，而是真实改善了用户体验。

Many hands：多执行环境协作

另一边，他们也希望一个 brain 能同时连接多双“手”。

现实里，这意味着 Claude 可能需要同时协调多个执行环境，并判断把任务发到哪里去完成。这比只在单一 shell 里工作，对模型提出了更高要求。

Anthropic 直说：早期模型还做不到，所以一开始才把 brain 和单个 container 绑定在一起。但随着模型变强，单容器反而变成限制：

•一旦容器出问题，brain 正在操作的所有“手”都会一起受影响

•扩展到多个执行环境会更难

在解耦设计里，每一双手本质上都是一个统一接口的工具：

execute(name, input) → string

所以这双手可以是：

•一个容器

•一个 MCP server

•一部手机

•甚至一个 Pokémon 模拟器

Harness 不需要预先知道底层到底是什么。只要接口一致，就可以接进来。

更进一步，因为任何一双手都不再绑定某一颗脑袋，所以不同 brains 之间还可以传递 hands、共享 hands 或接力完成任务。

这会让 Agent 系统具备更像“分布式协作体”的能力，而不是一个被困在单环境里的线程。

六、这篇文章真正重要的，不是 Managed Agents，而是“元编排层”思路

如果只把这篇文章理解成“Anthropic 发布了一个托管 Agent 服务”，其实会低估它的价值。

更值得关注的是，它表达了一种越来越清晰的趋势：

未来真正有生命力的 Agent 平台，不是把某一版最强实践写死，而是提供一层足够稳定的元接口，让未来不同类型的 harness、sandbox 和上下文工程策略都能接进来。

Anthropic 甚至直接把 Managed Agents 描述成一种 meta-harness。

它不是在赌“未来 Claude 一定需要哪一种 harness”，而是在赌：

•Claude 仍然需要操纵状态

•Claude 仍然需要执行计算

•Claude 仍然需要在长时间跨度里稳定运行

•Claude 很可能需要 many brains、many hands 的扩展能力

因此，最值得被固定下来的，不是具体链路，而是围绕 Claude 的那些基础接口。

这其实和操作系统抽象层的思想非常接近：你不预测未来每个程序会长什么样，但你提前把那些最底层、最通用、最不容易过时的接口定义好。

七、对做 Agent 的人，有哪些直接启发？

这篇文章对外部开发者最实际的启发，我觉得至少有四个：

1. 不要把“当前模型的缺陷补丁”误当作长期架构

很多 workflow、loop、guardrail、上下文技巧，在今天可能很重要，但它们很可能只是阶段性补丁。架构上要给“未来删掉这些补丁”留空间。

2. Session 必须可恢复、可追问，而不是只存在于 prompt 里

如果你的 Agent 一旦压缩上下文就丢信息，一旦进程崩掉就失忆，那么系统的上限会非常低。长任务系统最终一定要把“完整可恢复事件流”单独抽出来。

3. 令牌安全最好靠结构隔离，不要只靠权限收缩

Prompt injection、工具滥用、环境变量泄漏，本质上都说明：只要模型能碰到敏感凭证，就迟早会变成风险点。 最稳的方式，是让模型触达不到它们。

4. 未来 Agent 基础设施会越来越像分布式系统，而不是单机脚本

当系统开始支持 many brains、many hands，很多设计思路会自然从“写一个更大的 agent loop”转向：

•如何定义稳定接口

•如何做故障恢复

•如何做状态持久化

•如何在不同执行环境之间路由动作

•如何保证安全边界始终清晰

这意味着，Agent 工程会越来越接近基础设施工程。

结语

Anthropic 这篇文章最有价值的地方，在于它没有把焦点只放在“模型更聪明了”，而是进一步讨论：当模型持续变强时，什么样的系统结构才不会很快过时。

Managed Agents 给出的答案是：

•用 session / harness / sandbox 这样的稳定接口做解耦

•让 上下文存储 与 上下文管理 分层

•把 brain 和 hands 分开

•让系统天然支持 恢复、替换、扩展与并行

从这个角度看，这篇文章其实不是在讲一个功能，而是在讲下一代 Agent 平台应该如何搭地基。

如果你正在做长时运行 Agent、工具调用编排、企业内执行环境接入，或者在思考 Agent 平台层应该怎么设计，这篇文章非常值得认真读一遍。

参考来源

•原文：https://www.anthropic.com/engineering/managed-agents[1]

声明

本文由山行整理自：https://www.anthropic.com/engineering/managed-agents ，如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～

参考链接

[1] https://www.anthropic.com/engineering/managed-agents: https://www.anthropic.com/engineering/managed-agents