Anthropic 发布 Claude Managed Agents：将大脑与双手解耦的长时程智能体托管服务

按照我们的文档开始使用 Claude Managed Agents。

工程博客上持续讨论的一个主题是如何构建高效的智能体，以及为长时间运行的任务设计 harness。这项工作中的一个共同点是，harness 编码了关于 Claude 自身无法完成哪些事情的假设。然而，这些假设需要被频繁质疑，因为随着模型改进，它们可能会过时。

仅举一例，在先前的工作中我们发现，Claude Sonnet 4.5 在感知到上下文限制临近时会过早地结束任务——这种行为有时被称为“上下文焦虑”。我们通过在 harness 中加入上下文重置来解决这个问题。但当我们在 Claude Opus 4.5 上使用相同的 harness 时，发现该行为已经消失。这些重置成了累赘。

我们预计 harness 会持续演进。因此我们构建了 Managed Agents：Claude Platform 中的一项托管服务，通过一小组旨在比任何特定实现（包括我们今天运行的实现）更持久的接口，代表你运行长周期智能体。

构建 Managed Agents 意味着解决计算领域的一个老问题：如何为“尚未被想到的程序”设计系统。几十年前，操作系统通过将硬件虚拟化为抽象——进程、文件——来解决这个问题，这些抽象足够通用，可以容纳尚不存在的程序。这些抽象比硬件更持久。read() 命令并不关心它访问的是 1970 年代的磁盘组还是现代 SSD。上层的抽象保持稳定，而下层的实现可以自由变化。

Managed Agents 遵循同样的模式。我们将智能体的各个组件虚拟化：会话（记录一切已发生事件、仅追加的日志）、harness（调用 Claude 并将 Claude 的工具调用路由到相关基础设施的循环）以及沙箱（Claude 可以在其中运行代码和编辑文件的执行环境）。这使得每个组件的实现都可以在不干扰其他组件的情况下被替换。我们对这些接口的形态有明确主张，但对它们背后运行什么并不在意。

不要收养宠物

我们一开始将所有智能体组件放入单个容器，这意味着会话、智能体 harness 和沙箱共享同一个环境。这种方法有好处，包括文件编辑是直接的系统调用，而且无需设计服务边界。

但通过将所有内容耦合到一个容器中，我们遇到了一个老的基础设施问题：我们收养了一只宠物。在宠物与牲畜的类比中，宠物是一个有名字、需要亲手照料、你承受不起失去的个体，而牲畜则是可互换的。在我们的案例中，服务器成了那只宠物；如果容器发生故障，会话就会丢失。如果容器无响应，我们必须把它护理回健康状态。

护理容器意味着调试无响应的卡住会话。我们唯一的观察窗口是 WebSocket 事件流，但它无法告诉我们故障发生在哪里，这意味着 harness 中的 bug、事件流中的数据包丢失，或容器离线，看起来都一模一样。为了弄清出了什么问题，工程师必须在容器内打开一个 shell，但由于该容器通常也持有用户数据，这种做法本质上意味着我们缺乏调试能力。

第二个问题是，harness 假设 Claude 所处理的一切都与其位于同一容器中。当客户要求我们将 Claude 连接到他们的虚拟私有云时，他们要么必须将自己的网络与我们的网络对等互联，要么在他们自己的环境中运行我们的 harness。当我们需要将 harness 连接到不同的基础设施时，这个内嵌于 harness 中的假设就成了问题。

我们最终采用的解决方案是将我们视为“大脑”的部分（Claude 及其 harness）与“手”（执行操作的沙箱和工具）以及“会话”（会话事件日志）解耦。每一部分都成为一个对其他部分几乎不做假设的接口，并且每一部分都可以独立失败或被替换。

harness 离开容器。将大脑与手解耦意味着 harness 不再位于容器内部。它像调用任何其他工具一样调用容器：execute(name, input) → string。容器变成了“牲口”。如果容器死亡，harness 会将失败捕获为工具调用错误，并将其传回给 Claude。如果 Claude 决定重试，可以用标准配方重新初始化一个新容器：provision({resources})。我们不再需要将失败的容器“护理”回健康状态。

从 harness 故障中恢复。harness 也变成了“牲口”。由于会话日志位于 harness 之外，harness 中没有任何内容需要在崩溃后存活。当某个 harness 失败时，可以用 wake(sessionId) 重启一个新的 harness，使用 getSession(id) 取回事件日志，并从最后一个事件恢复。在智能体循环期间，harness 使用 emitEvent(id, event) 写入会话，以保留事件的持久记录。

安全边界。在耦合设计中，Claude 生成的任何不可信代码都与凭据运行在同一个容器中——因此，提示注入只需说服 Claude 读取自己的环境即可。一旦攻击者获得了这些令牌，他们就可以生成新的、不受限制的会话，并将工作委派给它们。缩小作用域是一种显而易见的缓解措施，但这隐含了一个关于 Claude 用受限令牌不能做什么的假设——而 Claude 正变得越来越聪明。结构性的修复是确保令牌永远无法从 Claude 生成代码所运行的沙箱中访问到。

我们使用两种模式来确保这一点。认证信息可以与资源捆绑在一起，也可以保存在沙箱之外的保险库中。对于 Git，我们在沙箱初始化期间使用每个仓库的访问令牌克隆仓库，并将其接入本地 git remote。Git push 和 pull 可以在沙箱内部工作，而智能体无需亲自处理令牌。对于自定义工具，我们支持 MCP，并将 OAuth 令牌存储在安全的保险库中。Claude 通过专用代理调用 MCP 工具；该代理接收与会话关联的令牌。然后，代理可以从保险库中获取相应的凭据，并向外部服务发起调用。harness 始终不会知晓任何凭据。

会话不是 Claude 的上下文窗口

长周期任务通常会超出 Claude 上下文窗口的长度，而解决这一问题的标准方法都涉及关于保留哪些内容的不可逆决策。我们在上下文工程的先前工作中探索过这些技术。例如，压缩让 Claude 保存其上下文窗口的摘要，记忆工具让 Claude 将上下文写入文件，从而实现跨会话学习。这可以与上下文修剪配合使用，后者会选择性地移除令牌，例如旧的工具结果或思考块。

但选择性地保留或丢弃上下文的不可逆决策可能导致失败。很难知道未来的轮次会需要哪些 token。如果消息经过压缩步骤被转换，harness 会将已压缩的消息从 Claude 的上下文窗口中移除，而这些消息只有在被存储的情况下才可恢复。先前的工作已经探索了解决这一问题的方法，即将上下文存储为一个存在于上下文窗口之外的对象。例如，上下文可以是 REPL 中的一个对象，LLM 通过编写代码来过滤或切片，以编程方式访问它。

在 Managed Agents 中，会话提供了同样的好处，充当一个存在于 Claude 上下文窗口之外的上下文对象。但上下文并非存储在沙箱或 REPL 中，而是持久地存储在会话日志中。该接口 getEvents(), 允许大脑通过选择事件流的位置切片来查询上下文。该接口可以灵活使用，允许大脑从上次停止阅读的位置继续，回退到特定时刻之前的几个事件以查看前因，或在特定操作之前重读上下文。

任何获取的事件也可以在 harness 中经过转换后再传入 Claude 的上下文窗口。这些转换可以是 harness 所编码的任何内容，包括为实现高提示缓存命中率而进行的上下文组织以及上下文工程。我们将会话中可恢复的上下文存储与 harness 中任意的上下文管理这两个关注点分开，因为我们无法预测未来的模型将需要哪些具体的上下文工程。这些接口将上下文管理推给 harness，并且只保证会话是持久的且可供查询。

许多大脑，许多手

许多大脑。将大脑与手解耦，解决了我们最早期的客户投诉之一。当团队希望 Claude 针对其自有 VPC 中的资源工作时，唯一的途径是将其网络与我们的网络对等互联，因为承载 harness 的容器假定每个资源都位于其旁边。一旦 harness 不再位于容器中，这一假定就不复存在。同样的改变还带来了性能收益。当我们最初将大脑放入容器时，这意味着许多大脑需要同样多的容器。对于每个大脑，在该容器完成配置之前无法进行任何推理；每个会话都要预先支付完整的容器设置成本。每个会话，即使是永远不会接触沙箱的会话，都必须克隆仓库、启动进程、从我们的服务器获取待处理事件。

这段停滞时间体现在首 token 时间（TTFT）上，它衡量一个会话从接受工作到产生第一个响应 token 之间等待的时长。TTFT 是用户最强烈感受到的延迟。

将大脑与手解耦意味着容器仅在需要时由大脑通过工具调用 (execute(name, input) → string) 进行配置。因此，不需要立即使用容器的会话就不必等待容器。一旦编排层从会话日志中拉取到待处理事件，推理就可以开始。使用这种架构，我们的 p50 TTFT 下降了约 60%，p95 下降了超过 90%。扩展到许多大脑只需启动许多无状态的 harness，并且仅在需要时将它们连接到手。

多手。我们还希望具备将每个大脑连接到多只手的能力。在实践中，这意味着 Claude 必须对许多执行环境进行推理，并决定把工作发送到哪里——这比在单一 shell 中操作是更难的认知任务。我们最初把大脑放在单个容器中，是因为早期的模型不具备这种能力。随着智能水平的提升，单个容器反而成了限制：当那个容器发生故障时，大脑所触及的每一只手都会丢失状态。

将大脑与手解耦，使每只手都成为一个工具，execute(name, input) → string：输入一个名称和输入，返回一个字符串。该接口支持任何自定义工具、任何 MCP 服务器以及我们自己的工具。运行框架并不知道沙箱是容器、手机还是 Pokémon 模拟器。而且由于没有任何一只手与任何大脑耦合，大脑之间可以互相传递手。

结论

我们面临的挑战是一个老问题：如何为“尚未想到的程序”设计系统。操作系统通过将硬件虚拟化为足够通用的抽象，从而延续了数十年，足以容纳当时尚不存在的程序。借助 Managed Agents，我们旨在设计一个能够容纳未来围绕 Claude 的运行框架、沙箱或其他组件的系统。

Managed Agents 是同一理念下的元运行框架，对 Claude 未来所需的特定运行框架不持立场。相反，它是一个具有通用接口的系统，允许许多不同的运行框架。例如，Claude Code 是一个出色的运行框架，我们在各种任务中广泛使用它。我们还展示了针对特定任务的智能体运行框架在狭窄领域中表现出色。Managed Agents 可以容纳其中任何一种，并随时间匹配 Claude 的智能水平。

元运行框架的设计意味着要对 Claude 周围的接口持有明确立场：我们预计 Claude 将需要操作状态（会话）和执行计算（沙箱）的能力。我们还预计 Claude 将需要扩展到许多大脑和许多手的能力。我们设计这些接口，使它们能够在长时间跨度内可靠、安全地运行。但我们不对 Claude 将需要的大脑或手的数量或位置做任何假设。