扩展托管智能体：将大脑与双手分离 \ Anthropic

来源: https://www.anthropic.com/engineering/managed-agents 抓取时间: 2026-07-21 16:20:25

按照我们的文档开始使用 Claude 托管智能体。

工程博客上的一个持续主题是如何构建有效的智能体和为长期运行的工作设计支架。这项工作的一个共同线索是，支架编码了关于 Claude 不能独立做什么的假设。然而，这些假设需要经常受到质疑，因为随着模型的改进，它们可能会过时。

举一个例子，在之前的工作中，我们发现 Claude Sonnet 4.5 在感知到其上下文限制即将到来时会提前结束任务——这种行为有时被称为"上下文焦虑"。我们通过向支架添加上下文重置来解决这个问题。但是当我们在 Claude Opus 4.5 上使用相同的支架时，我们发现这种行为已经消失了。这些重置变成了无用的负担。

我们预计支架将继续演进。因此，我们构建了托管智能体：Claude 平台中的一项托管服务，它通过一组旨在超越任何特定实现（包括我们今天运行的实现）的接口，代表您运行长期智能体。

构建托管智能体意味着解决计算中的一个老问题：如何为"尚未想到的程序"设计一个系统。几十年前，操作系统通过将硬件虚拟化为抽象——进程、文件——解决了这个问题，这些抽象足够通用，适用于尚不存在的程序。这些抽象超越了硬件。read() 命令对于它是访问 1970 年代的磁盘组还是现代 SSD 是不可知的。顶层的抽象保持稳定，而底层的实现可以自由更改。

托管智能体遵循相同的模式。我们虚拟化了智能体的组件：会话（所有发生的事情的仅追加日志）、支架（调用 Claude 并将 Claude 的工具调用路由到相关基础设施的循环）和沙箱（Claude 可以运行代码和编辑文件的执行环境）。这允许每个组件的实现被交换，而不会干扰其他组件。我们对这些接口的形状有明确主张，但对它们背后运行的内容没有主张。

不要养宠物

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

但是通过将所有东西耦合到一个容器中，我们遇到了一个古老的基础设施问题：我们已经收养了一个宠物。在宠物与牛的类比中，宠物是一个有名字、人工照料的个体，你不能失去它，而牛是可以互换的。在我们的案例中，服务器变成了那只宠物；如果容器失败，会话就丢失了。如果容器没有响应，我们必须护理它恢复健康。

护理容器意味着调试无响应的卡住会话。我们唯一的窗口是 WebSocket 事件流，但这不能告诉我们_哪里_出现了故障，这意味着支架中的错误、事件流中的丢包或容器脱机都表现相同。为了找出哪里出了问题，工程师必须在容器内打开一个 shell，但由于该容器通常也包含用户数据，这种方法实际上意味着我们缺乏调试能力。

第二个问题是，支架假设 Claude 处理的任何东西都与它一起生活在容器中。当客户要求我们将 Claude 连接到他们的虚拟私有云时，他们必须要么将他们的网络与我们的网络对等，要么在他们自己的环境中运行我们的支架。当我们想要将其连接到不同的基础设施时，支架中内置的一个假设变成了一个问题。

将大脑与双手分离

我们找到的解决方案是将我们认为的"大脑"（Claude 及其支架）从"双手"（执行动作的沙箱和工具）和"会话"（会话事件日志）中分离出来。每个都变成了一个接口，对其他接口做出很少的假设，并且每个都可以独立失败或被替换。

支架离开容器。 将大脑与双手分离意味着支架不再生活在容器内。它像调用任何其他工具一样调用容器：execute(name, input) → string。容器变成了牛。如果容器死亡，支架将故障作为工具调用错误捕获并传递回 Claude。如果 Claude 决定重试，可以使用标准配方provision({resources})重新初始化一个新容器。我们不再需要护理失败的容器恢复健康。

从支架故障中恢复。 支架也变成了牛。因为会话日志位于支架之外，所以支架中的任何东西都不需要在崩溃中幸存下来。当一个支架失败时，可以用wake(sessionId)重新启动一个新的支架，使用getSession(id)取回事件日志，并从最后一个事件恢复。在智能体循环期间，支架使用emitEvent(id, event)写入会话，以保持事件的持久记录。

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

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

会话不是 Claude 的上下文窗口

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

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

在托管智能体中，会话提供了相同的好处，作为生活在 Claude 上下文窗口之外的上下文对象。但是上下文不是存储在沙箱或 REPL 中，而是持久地存储在会话日志中。接口getEvents()允许大脑通过选择事件流的位置切片来查询上下文。该接口可以灵活使用，允许大脑从它最后停止读取的地方继续，在特定时刻之前回退几个事件以查看之前的情况，或在特定动作之前重新读取上下文。

任何获取的事件也可以在传递给 Claude 的上下文窗口之前在支架中进行转换。这些转换可以是支架编码的任何内容，包括实现高提示缓存命中率的上下文组织和上下文工程。我们将会话中可恢复的上下文存储和支架中的任意上下文管理分开，因为我们无法预测未来模型需要什么特定的上下文工程。这些接口将该上下文管理推送到支架中，并且只保证会话是持久的并且可用于查询。

许多大脑，许多双手

许多大脑。 将大脑与双手分离解决了我们最早的客户抱怨之一。当团队希望 Claude 处理他们自己 VPC 中的资源时，唯一的途径是将他们的网络与我们的网络对等，因为容纳支架的容器假设每个资源都在它旁边。一旦支架不再在容器中，这个假设就消失了。同样的变化也带来了性能回报。当我们最初将大脑放在容器中时，这意味着许多大脑需要同样多的容器。对于每个大脑，在该容器配置完成之前无法进行推理；每个会话都预先支付了完整的容器设置成本。每个会话，即使是永远不会接触沙箱的会话，都必须克隆存储库、启动进程、从我们的服务器获取待处理的事件。

这段死时间体现在首次令牌时间（TTFT）中，它衡量会话在接受工作和产生第一个响应令牌之间等待的时间。TTFT 是用户最敏锐地_感受到_的延迟。

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

许多双手。 我们还希望有能力将每个大脑连接到许多双手。在实践中，这意味着 Claude 必须推理许多执行环境并决定在哪里发送工作——这是一项比在单个 shell 中操作更难的认知任务。我们从将大脑放在单个容器中开始，因为早期的模型没有能力做到这一点。随着智能的扩展，单个容器反而成为限制：当那个容器失败时，我们失去了大脑正在接触的每一只手的状态。

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

结论

我们面临的挑战是一个古老的挑战：如何为"尚未想到的程序"设计一个系统。操作系统通过将硬件虚拟化为足够通用的抽象来持续了几十年，这些抽象适用于尚不存在的程序。通过托管智能体，我们旨在设计一个系统，以适应围绕 Claude 的未来支架、沙箱或其他组件。

托管智能体是一个遵循同样精神的元支架，对 Claude 未来需要的_特定_支架没有主张。相反，它是一个具有通用接口的系统，允许许多不同的支架。例如，Claude Code 是一个出色的支架，我们在各种任务中广泛使用。我们还表明，任务特定的智能体支架在狭窄领域表现出色。托管智能体可以适应其中任何一种，随着时间的推移匹配 Claude 的智能。

元支架设计意味着对 Claude 周围的接口有明确主张：我们期望 Claude 需要操纵状态（会话）和执行计算（沙箱）的能力。我们还期望 Claude 需要能够扩展到许多大脑和许多双手。我们设计了这些接口，以便这些可以在长时间范围内可靠和安全地运行。但我们对 Claude 需要的大脑或手的数量或位置没有做出任何假设。

致谢

由 Lance Martin、Gabe Cemaj 和 Michael Cohen 撰写。感谢 Nodir Turakulov 和 Jeremy Fox 就这些主题提供的有益对话。特别感谢 Agents API 团队和 Jake Eaton 的贡献。