详细解读 Claude Managed Agents
公众号名称：方圆AI分享
作者名称：方圆yo
发布时间：2026-04-14 20:19
Anthropic 在工程博客上发了一篇文章 Scaling Managed Agents: Decoupling the brain from the hands[1]，介绍了他们构建 Managed Agents 这个托管式 Agent 服务背后的系统设计思路。文章不长，但把 Agent 系统架构中一些看似老生常谈、实则很容易踩坑的问题讲得相当细。
Managed Agents 要解决的核心问题是：AI 模型的能力在快速进化，围绕它构建的系统架构应该怎么设计，才能不被模型能力的变化拖着走？Anthropic 给出的答案是，把 Agent 的各个组件拆开，让它们之间通过稳定的接口 交互，而不是绑死在一起。
这个思路听起来很朴素，但 Managed Agents 从问题发现到方案落地的整个过程，涉及的取舍和细节 值得仔细展开看看。
harness 的假设正在快速过期
Anthropic 工程博客之前写过好几篇关于如何构建 Agent harness 的文章，从怎么设计 Agent 循环，到怎么处理长时间运行的任务。贯穿这些文章的一个主题是，harness 本质上编码了一组关于模型能力边界 的假设。
比如他们之前发现，Claude Sonnet 4.5 在感知到上下文窗口快要用完的时候，会提前结束任务。这种行为被称为 context anxiety。为了解决这个问题，他们在 harness 里加了上下文重置机制。
但当他们把同一套 harness 用在 Claude Opus 4.5 上时，发现这个行为已经消失了。那些精心设计的重置逻辑 变成了多余的代码。
这个例子揭示了一个更深层的问题：harness 中编码的假设会随着模型能力的提升而失效。如果系统架构和这些假设紧密耦合，每次模型升级都可能带来一轮系统重构。
这就像 Rich Sutton 在 The Bitter Lesson 中说的那样，短期的工程优化往往会被长期的能力扩展所淘汰。（The Bitter Lesson 苦涩的教训(中英对照翻译)）
所以 Anthropic 要解决的根本问题是：如何设计一个系统，让它在 harness 的具体实现不断变化 的情况下，仍然保持稳定？
从操作系统的历史中借鉴思路
Anthropic 找到的灵感来自一个经典的计算机科学问题：如何为尚未被构思出来的程序设计系统。
几十年前，操作系统面对过同样的挑战。解决方案是把硬件虚拟化为抽象层。进程、文件这些概念足够通用，能够支撑当时还不存在的程序。这些抽象层的寿命远超了底层硬件。
一个 read() 调用，无论底下是 1970 年代的磁盘包还是现代的 SSD，接口都是一样的。上层的抽象保持稳定，下层的实现可以自由更换。
Managed Agents 遵循了同样的模式。他们把 Agent 的组件虚拟化为三个核心抽象：session（一个只追加的事件日志，记录了所有发生的事情），harness（调用 Claude 并将 Claude 的工具调用路由到相应基础设施的循环），sandbox（Claude 可以运行代码和编辑文件的执行环境）。
这样做的好处是，每个组件的实现都可以被独立替换，而不会影响其他组件。Anthropic 对这些接口的形状有明确的设计主张，但对接口背后运行什么并不做限定。
不要养宠物
Anthropic 最初的设计是把所有 Agent 组件放进一个容器里。session、harness、sandbox 共享同一个运行环境。这种方式有一些好处，比如文件编辑就是直接的系统调用，不需要设计服务边界。
但这种紧耦合的设计很快暴露了一个经典的基础设施问题：他们养了一只宠物。在 pets(宠物式) vs cattle(牲畜式) 这个经典的基础设施类比中，宠物是你精心命名、悉心照料、不能承受失去的个体，而牲畜是可以互换的。
在他们的场景里，服务器就成了那只宠物。如果容器出故障，session 就丢了。如果容器无响应，就必须想办法让它恢复。
修复容器意味着调试那些卡住的 session。他们唯一的观察窗口是 WebSocket 事件流，但事件流无法告诉他们故障究竟发生在哪里。
harness 中的 bug、事件流的丢包、容器离线，这三种完全不同的故障，呈现出来的表象是一样的。要搞清楚到底出了什么问题，工程师不得不进到容器内部开一个 shell，但因为容器里同时还存放着用户数据，这条路基本走不通。
还有一个问题是，harness 默认假定 Claude 要操作的所有东西都在同一个容器里。当客户希望让 Claude 连接到他们自己的虚拟私有云时，只能要么把他们的网络和 Anthropic 的网络做 peering，要么在客户自己的环境里跑 Anthropic 的 harness。
一个嵌入在 harness 中的假设，变成了连接不同基础设施时的阻碍。
把大脑和双手分开
Anthropic 最终找到的解决方案，是把他们所说的大脑（Claude 及其 harness）与双手（sandbox 和执行操作的工具）以及记忆（session 事件日志）彻底解耦。每一部分都变成一个独立的接口，对其他部分做出尽可能少的假设，每一部分都可以独立故障或被替换。
harness 离开了容器。解耦之后，harness 不再住在容器里面。它调用容器的方式，和调用其他任何工具完全一样：execute(name, input) → string。
容器从宠物变成了牛群。如果容器挂了，harness 会把故障作为一个工具调用错误捕获，然后传回给 Claude。如果 Claude 决定重试，就用一个标准化的配方初始化一个新容器：provision({resources})。再也不需要把挂掉的容器抢救回来了。
harness 本身也变成了牛群。因为 session 日志存在 harness 外部，harness 里没有任何状态需要在崩溃中存活。当一个 harness 失败时，新的 harness 可以通过 wake(sessionId) 启动，用 getSession(id) 拿回事件日志，然后从最后一个事件继续执行。
在 Agent 循环运行的过程中，harness 通过 emitEvent(id, event) 向 session 写入事件，保持一份持久化的记录。
这个设计的核心在于：把状态和逻辑分离。状态放在 session 这个持久化层里，逻辑放在 harness 这个无状态层里。任何一边出问题，都可以独立恢复，不会把另一边拖下水。
安全边界的结构性修复
在耦合设计中，Claude 生成的不受信任的代码，与凭证运行在同一个容器里。这意味着一次 prompt injection 攻击只需要说服 Claude 读取自己的运行环境变量就能得手。一旦攻击者拿到了 token，就可以创建新的、不受限制的 session，并把工作委派给它们。
缩小 token 的权限范围是一个显而易见的缓解措施，但这本身又编码了一个假设：认为 Claude 用一个受限的 token 做不了什么大事。而 Claude 正在变得越来越聪明。
结构性的修复方案是确保 token 从根本上无法从 sandbox 中被访问到。Anthropic 用了两种模式来实现这一点。
对于 Git，他们在 sandbox 初始化阶段就用仓库的访问令牌把代码 clone 下来，并把令牌配置到本地的 git remote 中。在 sandbox 内部，git push 和 pull 可以正常工作，但 Agent 本身从未接触过令牌。
对于自定义工具，他们支持 MCP 协议，并把 OAuth token 存放在 sandbox 外部的安全保险库中。Claude 通过一个专用代理调用 MCP 工具，代理接收与 session 关联的令牌，从保险库中取出相应的凭证，然后向外部服务发起调用。
harness 自始至终都不知道任何凭证的存在。
这种设计不依赖对模型能力的假设来保证安全，而是通过架构层面的隔离 来消除攻击面。
session 不等于上下文窗口
长时间运行的任务经常会超出 Claude 上下文窗口的容量，而处理这个问题的标准方法都涉及不可逆的决策：保留什么，丢弃什么。Anthropic 之前在上下文工程方面探索过多种技术，包括让 Claude 做上下文压缩、把记忆写入文件、选择性地移除旧的工具调用结果或思考过程。
但不可逆的上下文管理决策会导致失败。很难预知未来的对话轮次会需要哪些 token。如果消息被压缩步骤转换过了，被压缩的消息从 Claude 的上下文窗口中移除，只有在被额外存储的情况下才能恢复。
在 Managed Agents 中，session 承担了上下文存储的角色，它作为一个上下文对象存在于 Claude 的上下文窗口之外。与把上下文存在 sandbox 或 REPL 中不同，上下文被持久化存储在 session 日志中。
通过 getEvents() 接口，harness 可以按位置选取事件流的切片来查询上下文。这个接口使用起来很灵活，harness 可以从上次停止阅读的地方继续，可以回退到某个特定时刻之前的几个事件来查看前因后果，也可以在某个特定操作之前重新读取上下文。
获取到的事件还可以在传入 Claude 上下文窗口之前，在 harness 中做各种变换。这些变换可以是 harness 编码的任何逻辑，包括为了提高 prompt cache 命中率而做的上下文组织，以及各种上下文工程技巧。
Anthropic 把可恢复的上下文存储（在 session 中）和任意的上下文管理（在 harness 中）分成了两个关注点，因为他们无法预测未来的模型会需要什么样的上下文工程。接口只保证 session 是持久化的、可查询的，至于具体怎么管理上下文，留给 harness 去决定。
多个大脑，多双手
解耦大脑和双手还带来了一个直接的好处：解决了早期客户的一个核心诉求。
当团队希望让 Claude 操作他们自己 VPC 中的资源时，之前唯一的办法是把他们的网络和 Anthropic 的网络做直接建立网络互联，因为承载 harness 的容器假定所有资源都在它旁边。一旦 harness 不再住在容器里，这个假设就消失了。
同样的架构变更还带来了性能上的收益。当大脑在容器里的时候，每多一个大脑就需要多一个容器。每个大脑都要等容器完成配置才能开始推理，每个 session 都要预付完整的容器启动成本。
即使一个 session 根本不需要用到 sandbox，也得先 clone 代码仓库、启动进程、从服务器获取待处理的事件。
这些空转时间体现在 TTFT（time-to-first-token，首字时延）上，也就是从接受任务到产出第一个响应 token 之间的等待时间。TTFT 是用户感知最直接的延迟指标。
解耦之后，容器只在真正需要时才通过工具调用来配置。不需要容器的 session 就不用等容器。推理可以在编排层从 session 日志中拉取待处理事件后立即开始。
采用这个架构之后，Anthropic 的 p50 TTFT 下降了大约 60%，p95 下降超过 90%。扩展到多个大脑，只需要启动多个无状态的 harness，然后在需要时才把它们连接到双手上。
在多双手方面，他们还希望每个大脑能连接到多个执行环境。实际操作中，这意味着 Claude 必须能够推理多个执行环境，并决定把工作发送到哪里。这在认知上比在单个 shell 里操作要复杂得多。
他们最初把大脑放在单个容器里，正是因为早期的模型还不具备这种能力。随着模型智能的提升，单个容器反而成了瓶颈：当那个容器出故障时，大脑伸向的所有执行环境的状态都会丢失。
解耦之后，每个执行环境都变成了一个工具：execute(name, input) → string。一个名称和输入进去，一个字符串返回。这个接口可以支持任何自定义工具、任何 MCP 服务器，以及 Anthropic 自己的工具。
harness 不关心 sandbox 是一个容器、一台手机还是一个游戏模拟器。而且因为没有任何双手和任何大脑绑定在一起，大脑之间可以互相传递双手。
meta harness 的设计哲学
回过头来看，Anthropic 构建 Managed Agents 时面对的挑战，本质上是一个古老的系统设计问题：如何为尚未存在的程序构建基础设施。操作系统用了几十年来证明，把硬件虚拟化为足够通用的抽象层，是这个问题的有效解法。
Managed Agents 是一个 meta harness。它不对 Claude 未来需要什么样的具体 harness 做判断，而是提供一组通用的接口，让各种不同的 harness 都能在上面运行。
比如 Claude Code 是一个优秀的 harness，他们在很多任务中广泛使用。他们也展示过针对特定任务的 Agent harness 在垂直领域表现更好。Managed Agents 可以容纳所有这些方案，随着 Claude 智能水平的提升而匹配进化。
meta harness 的设计意味着对 Claude 周围的接口有明确的主张：Claude 需要操控状态的能力（通过 session），需要执行计算的能力（通过 sandbox），需要扩展到多个大脑和多双手的能力。
他们设计这些接口时，确保它们可以在长时间跨度内可靠、安全地运行。但他们不对 Claude 需要多少个大脑或多少双手做任何假设，也不假定它们会在哪里运行。
这种设计思路，对于所有正在构建 AI Agent 系统的团队都有参考价值。与其不断追着模型能力的变化去重构系统，不如从一开始就把系统设计成对模型能力假设最少的形态。把容易变的部分和不容易变的部分分开，让接口稳定，让实现自由演化。
(完)
我是方圆，持续分享AI干货，下期再见～
往期推********荐
我给 Claude Code 源码加了宠物成长系统，人人都能拥有金色传说
五位大佬聊了两小时，终于把 Harness Engineering 讲明白了
添加微信，加入AI交流群，获取AI干货分享👇
如果这篇文章对你有帮助，欢迎顺手点个赞、点个在看，再转发给更多需要的人
也欢迎给公众号加个星标⭐，这样以后更新就能第一时间看到
你的每一次支持，都是我持续输出的动力，谢谢你～
引用链接
[1] Scaling Managed Agents: Decoupling the brain from the hands: https://www.anthropic.com/engineering/managed-agents
Original 方圆yo 方圆AI分享