扩展 Managed Agents：将“大脑”与“执行端”解耦
官方原文: https://www.anthropic.com/engineering/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 上限时可能会过早收尾，这种现象被称为“context anxiety”。团队曾在 Harness 中加入上下文重置来应对；但 Claude Opus 4.5 在相同 Harness 下并未出现该行为，于是这套重置机制反而成了额外负担。
由于 Harness 会持续演进，Anthropic 构建了 Claude Platform 上的 Managed Agents：它通过不绑定某一种具体实现的接口，运行长时任务 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 通过 wake(sessionId) 启动，调用 getSession(id) 读取事件日志，并从最后一个事件继续执行。在 Agent 循环中，Harness 通过 emitEvent(id, event) 持续写入 Session，形成持久记录。
安全边界
在耦合式设计中，Claude 生成的不可信代码与凭证同处一个容器。攻击者只要通过 Prompt Injection 诱导 Claude 读取自身环境，就可能拿到 Token，并用它创建新的、权限不受限的 Session。缩小 Token 权限当然能缓解风险，但那仍依赖于“Claude 拿到有限 Token 后做不了什么”的假设，而 Claude 的能力会持续增强。
结构性修复确保 Token 永远无法从 Claude 生成代码运行的 Sandbox 中访问，使用两种模式：
- Git：每个仓库的访问 Token 仅在 Sandbox 初始化时用于克隆仓库，并配置到本地 Git remote。Sandbox 内的 Git
push与pull均可正常工作，但 Agent 从不接触 Token 本身。 - 自定义工具：系统支持 MCP，OAuth Token 保存在安全凭证库中。Claude 通过专用代理调用 MCP 工具；该代理接收与 Session 关联的标识，从凭证库取出对应凭证后再发起外部调用。Harness 不会接触任何凭证。
Session 并不是 Claude 的 Context Window
长时任务通常会超过 Claude 的 Context Window。常见做法都要对哪些内容保留作出不可逆选择，例如 compaction（保存摘要）、memory tools（把上下文写入文件以支持跨 Session 学习）和 context trimming（选择性删除较早的工具结果或 thinking blocks）。
但不可逆的保留/丢弃决定可能导致失败，因为很难知道未来的轮次需要哪些 Token。先前的研究探索了将上下文存储为存在于 Context Window 之外的对象——例如，作为 REPL 中的对象，LLM 通过编写代码来过滤或切片它进行编程访问。
在 Managed Agents 中，Session 提供了这一能力，可作为 Claude Context Window 之外的上下文对象。上下文被持久化到 Session 日志。getEvents() 接口允许“大脑”按事件流的位置范围查询上下文：从上次读到的位置继续、回到某个时刻之前，或重新读取某次操作之前的上下文。
取回的事件可先在 Harness 中转换，再送入 Claude 的 Context Window，从而支持为提高 Prompt Cache 命中率而组织上下文，也支持其他 Context Engineering 策略。团队把可恢复的上下文存储（Session）与任意形式的上下文管理（Harness）分离开来，因为无法预知未来模型需要哪种 Context Engineering。接口只保证 Session 可持久保存、可被查询，而将上下文管理策略交给 Harness。
多个大脑，多个执行端
多个大脑
解耦解决了早期的一项客户痛点。需要让 Claude 操作自有 VPC 资源的团队，过去不得不进行网络对等连接，因为承载 Harness 的容器默认所有资源都在身边。Harness 离开容器后，这一假设也随之消失。
解耦也带来了性能收益。当“大脑”放在容器中时，增加多个“大脑”就等于增加多个容器。每个 Session 都要预先承担完整的容器准备成本；即使某个 Session 永远不用 Sandbox，也得先克隆仓库、启动进程并获取待处理事件。
这段无效等待会体现在首个 Token 耗时（TTFT）中，也是用户最直接感受到的延迟。解耦后，容器只在“大脑”通过工具调用确有需要时才配置；暂时不需要容器的 Session 无需等待。编排层从 Session 日志取得待处理事件后即可开始推理。采用该架构后，TTFT 的 p50 约降低 60%，p95 降低超过 90%。要扩展“大脑”数量，只需启动更多无状态 Harness，并在需要时再连接执行端。
多个执行端
团队还希望每个“大脑”能连接多个执行端。实际使用中，Claude 需要理解多个执行环境，并决定将工作发往何处；这比只操作一个 shell 更具挑战。最初选择单容器设计，是因为早期模型还无法处理这一复杂度。随着模型能力提升，单容器反而成了限制：它一旦故障，“大脑”正在操作的所有执行端状态都会丢失。
解耦后，每个执行端都可抽象为一个工具：execute(name, input) → string，即传入名称与输入，返回字符串。这个接口可以承载任意自定义工具、任意 MCP server 和 Anthropic 自有工具。Harness 无需知道 Sandbox 背后是容器、手机还是 Pokémon 模拟器。执行端不再绑定任何特定“大脑”，因此不同“大脑”也可以彼此交接执行端。
结论
挑战是一个古老的：为"尚未设想的程序"设计系统。操作系统通过将硬件虚拟化为通用抽象而持续了数十年。通过 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），并能扩展到多个“大脑”和多个执行端。接口旨在长期可靠、安全地运行；但不预设未来需要多少个“大脑”或执行端，也不预设它们位于何处。