Skip to content

扩展 Managed Agents:将"大脑"与"双手"解耦

发布日期: 2026年4月8日

作者: Lance Martin、Gabe Cemaj 和 Michael Cohen。感谢 Nodir Turakulov、Jeremy Fox、Agents API 团队和 Jake Eaton 的贡献。


Harness 编码了随模型进步而过时的假设。Managed Agents——一个用于长时间 Agent 工作的托管服务——围绕着在 Harness 变化时保持稳定的接口来构建。

Anthropic 工程博客中反复出现的主题是构建有效的 Agent 和设计长时间运行工作的 Harness。一个关键洞察是 Harness 编码了关于 Claude 局限性的假设,但这些假设需要定期重新评估,因为随着模型的进步它们可能会变得过时。

例如,Claude Sonnet 4.5 会在接近其 Context Window 限制时过早地结束任务——这种行为被称为"上下文焦虑"。团队通过在 Harness 中进行上下文重置来解决这个问题。然而,Claude Opus 4.5 在使用相同 Harness 时却没有表现出这种行为,使得上下文重置变成了多余的负担。

由于 Harness 会不断演进,Anthropic 构建了 Managed Agents:这是 Claude 平台上的一个托管服务,通过设计为超越任何特定实现的接口来运行长时间 Agent。

计算领域中的老问题

构建 Managed Agents 需要解决为"尚未设想的程序"设计系统的挑战。操作系统几十年前通过将硬件虚拟化为进程文件等抽象来解决了这个问题——这些抽象足够通用,能够适应未来的程序。无论访问的是1970年代的磁盘组还是现代 SSD,read() 命令都能正常工作。抽象保持稳定,而实现可以自由变化。

Managed Agents 遵循相同的模式,将 Agent 组件虚拟化:

  • Session:所有发生事件的仅追加日志
  • Harness:调用 Claude 并将工具调用路由到相关基础设施的循环
  • Sandbox:Claude 可以运行代码和编辑文件的执行环境

每个组件都可以在不影响其他组件的情况下被替换。系统对接口形态有明确要求,但对背后运行的内容不加限制。

不要养"宠物"

最初,所有 Agent 组件都被放置在单个容器中——Session、Harness 和 Sandbox 共享一个环境。好处包括可以直接通过系统调用编辑文件,以及不需要设计服务边界。

但将所有内容耦合到一个容器中造成了"宠物与牲畜"的基础设施问题。服务器变成了一个有名字的、需要精心照料的个体("宠物"),不能丢失。如果容器失败,Session 就会丢失。无响应的容器需要被"护理"恢复健康。

调试无响应的卡住 Session 尤其痛苦。WebSocket 事件流是唯一的调试窗口,但它无法揭示故障发生在哪里——Harness 中的 bug、数据包丢失或离线容器看起来都一样。工程师不得不在容器内部打开 shell,但由于该容器通常持有用户数据,这实际上意味着无法调试。

第二个问题是:Harness 假设 Claude 的工作在同一个容器中。当客户希望 Claude 连接到他们的 VPC 时,他们必须要么对等连接网络,要么在自己的环境中运行 Harness。一个内置于 Harness 的假设变成了连接不同基础设施的障碍。

将"大脑"与"双手"解耦

解决方案是将"大脑"(Claude 及其 Harness)与"双手"(执行操作的 Sandbox 和工具)以及"Session"(事件日志)解耦。每个都成为一个对其他组件假设最少的接口,每个都可以独立失败或被替换。

Harness 离开容器

解耦意味着 Harness 不再住在容器内部。它像调用任何其他工具一样调用容器:execute(name, input) → string。容器变成了"牲畜"。如果容器死了,Harness 将失败作为工具调用错误捕获并传回给 Claude。如果 Claude 决定重试,可以通过 provision({resources}) 重新初始化一个新容器。不再需要"护理"失败的容器。

从 Harness 故障中恢复

Harness 也变成了"牲畜"。由于 Session 日志位于 Harness 之外,Harness 中没有任何内容需要在崩溃后存活。当一个 Harness 失败时,新的 Harness 通过 wake(sessionId) 启动,通过 getSession(id) 检索事件日志,并从最后一个事件恢复。在 Agent 循环期间,Harness 通过 emitEvent(id, event) 写入 Session 以维护持久记录。

安全边界

在耦合设计中,Claude 生成的不可信代码与凭证运行在同一个容器中——Prompt Injection 只需要说服 Claude 读取自己的环境。有了这些 Token,攻击者就可以生成新的、不受限制的 Session。缩小范围是一个显而易见的缓解措施,但这编码了关于 Claude 无法用有限 Token 做什么的假设——而 Claude 一直在变得更聪明。

结构性修复确保 Token 永远无法从 Claude 生成代码运行的 Sandbox 中访问,使用两种模式:

  • 对于 Git:每个仓库的访问 Token 在 Sandbox 初始化期间克隆仓库并将其连接到本地 Git 远程。Git pushpull 可以在 Sandbox 内部工作,Agent 永远不需要处理 Token 本身。
  • 对于自定义工具:支持 MCP,OAuth Token 存储在安全保险库中。Claude 通过专用代理调用 MCP 工具,该代理接收与 Session 关联的 Token,从保险库获取相应的凭证,并进行外部调用。Harness 永远不会知道任何凭证。

Session 不是 Claude 的 Context Window

长时间任务通常会超出 Claude 的 Context Window。标准方法涉及对保留内容做出不可逆的决定——压缩(保存摘要)、记忆工具(将上下文写入文件以供跨 Session 学习)和上下文修剪(选择性地移除旧的工具结果或思考块)。

但不可逆的保留/丢弃决定可能导致失败,因为很难知道未来的轮次需要哪些 Token。先前的研究探索了将上下文存储为存在于 Context Window 之外的对象——例如,作为 REPL 中的对象,LLM 通过编写代码来过滤或切片它进行编程访问。

在 Managed Agents 中,Session 提供了这个好处,作为 Claude Context Window 之外的上下文对象。上下文持久存储在 Session 日志中。getEvents() 接口让"大脑"通过选择事件流的位置切片来查询上下文——从上次停止阅读的地方继续,在特定时刻之前回退,或在操作之前重新阅读上下文。

获取的事件可以在传递给 Claude 的 Context Window 之前在 Harness 中进行转换——从而实现上下文组织以获得高 Prompt Cache 命中率和上下文工程。可恢复的上下文存储(在 Session 中)和任意上下文管理(在 Harness 中)的关注点是分离的,因为团队无法预测未来的模型将需要什么样的上下文工程。接口将上下文管理推入 Harness,只保证 Session 是持久的且可供查询。

多个大脑,多双手

多个大脑

解耦解决了最早的客户投诉之一。希望 Claude 在自己的 VPC 中的资源上工作的团队以前必须对等连接网络,因为持有 Harness 的容器假设每个资源都在它旁边。一旦 Harness 离开容器,这个假设就消失了。

还有性能上的收益。当"大脑"在容器中时,多个"大脑"需要多个容器。每个 Session 都预先支付完整的容器设置成本——即使是永远不会触及 Sandbox 的 Session 也必须克隆仓库、启动进程并获取待处理事件。

这种空闲时间出现在首 Token 时间(TTFT)中——用户最直观感受到的延迟。解耦意味着容器仅在需要时由"大脑"通过工具调用进行配置。不需要容器的 Session 不会等待容器。一旦编排层从 Session 日志中拉取待处理事件,推理就开始了。使用这种架构,p50 TTFT 下降了约60%,p95 下降了超过90%。扩展到多个"大脑"意味着启动多个无状态的 Harness,仅在需要时将它们连接到"双手"。

多双手

团队还希望每个"大脑"连接到多双"双手"。在实践中,Claude 必须推理多个执行环境并决定将工作发送到哪里——这比在单个 shell 中操作更具认知挑战性。最初选择单容器设计是因为早期的模型无法处理这种情况。随着智能的提升,单容器成为了限制:当它失败时,"大脑"正在触及的每双"双手"的状态都会丢失。

解耦使每双"双手"成为一个工具:execute(name, input) → string——名称和输入进去,字符串出来。该接口支持任何自定义工具、任何 MCP 服务器和 Anthropic 自己的工具。Harness 不知道 Sandbox 是容器、手机还是 Pokemon 模拟器。因为没有"双手"与任何"大脑"耦合,"大脑"可以将"双手"相互传递。

结论

挑战是一个古老的:为"尚未设想的程序"设计系统。操作系统通过将硬件虚拟化为通用抽象而持续了数十年。通过 Managed Agents,Anthropic 旨在设计一个围绕 Claude 适应未来 Harness、Sandbox 或其他组件的系统。

Managed Agents 是一个元 Harness,对 Claude 未来需要的具体 Harness 不持立场——一个具有通用接口的系统,允许多种不同的 Harness。例如,Claude Code 是一个出色的 Harness,广泛用于各种任务,而特定任务的 Agent Harness 在狭窄领域表现出色。Managed Agents 可以容纳任何这些,随着时间的推移匹配 Claude 的智能。

元 Harness 设计意味着对围绕 Claude 的接口有明确立场:Claude 将需要操作状态(Session)和执行计算(Sandbox)的能力,并需要扩展到多个"大脑"和多双"双手"的能力。接口被设计为在长时间范围内可靠且安全地运行。但不对 Claude 将需要的"大脑"或"双手"的数量或位置做任何假设。

AI 落地咨询
艾维禾砺数字科技

企业 AI 落地全链路服务

Agent 开发工作流搭建Claude Code 集成
微信咨询
d187l8801b6124
访问官网 ivheli.com