跳转至

扩展托管智能体：解耦大脑与双手的操作系统级架构演进

Scaling Managed Agents: Decoupling the Brain from the Hands

想要快速上手 Claude Managed Agents，请参阅我们的 官方文档。

Get started with Claude Managed Agents by following our docs.

文章背景与核心概要

Anthropic 研发团队在长期构建 AI 智能体 (AI Agent) 的工程实践中发现，传统的单容器架构将提示词调度回路、代码执行沙盒与会话状态紧密耦合，导致基础设施不仅脆弱如“专属宠物 (Pets)”，而且频繁受到模型能力演进的冲击与安全漏洞的威胁。为了打破这一瓶颈，Anthropic 正式推出了云端托管服务 Managed Agents，借鉴经典现代操作系统的虚拟化设计哲学，将智能体抽象为会话 (Sessions)、底座回路 (Harnesses) 与执行沙盒 (Sandboxes) 三大核心接口。通过将负责思考决策的“大脑”与负责落地操作的“双手”彻底解耦，系统彻底消除了对脆弱单一容器的运维依赖，更将首字元生成延迟 (TTFT) 的 p50 降低约 60%、p95 骤降逾 90%。这一操作系统级的架构演进不仅筑牢了凭证隔离的安全边界，更为未来支持多大脑并行决策与多环境跨端协作铺平了道路。

📌 执行摘要

📌 Executive Summary

在构建能够长期自主执行任务的 AI 智能体 (AI Agent) 时，工程师通常需要设计一套调度底座 (Harness)。然而，这些底座往往暗含了当下对模型“能做什么、不能做什么”的临时假设——而随着大语言模型 (Large Language Model, LLM) 能力的飞速进化，这些硬编码的假设往往很快就会落后失效。为了打造真正面向未来的智能体架构，Anthropic 推出了托管服务 Managed Agents，旨在通过一套标准化、模块化的接口来稳健调度并运行长周期智能体任务。

Building long-running AI agents often requires harnesses that encode temporary assumptions about what models can or cannot do on their own—assumptions that quickly go stale as models improve. To future-proof agent architecture, Anthropic introduced Managed Agents, a hosted service designed to run long-horizon agents through modular interfaces.

团队从经典操作系统的演进历程中汲取灵感，将智能体的核心组件虚拟化为三层稳定的抽象原语——会话 (Sessions，持久化日志)、底座 (Harnesses，编排循环回路) 以及 沙盒 (Sandboxes，代码与文件执行环境)，成功实现了将负责决策的“大脑”与负责落地的“双手”彻底解耦。这一架构转型彻底消除了脆弱的基础设施运维负担 (告别“专属宠物 (Pets)”模式)，大幅削减了首字元生成延迟 (Time-To-First-Token, TTFT)，构筑了更严密的安全防御边界，并支持极具扩展性的“多大脑、多双手”协同工作流，使整体架构能够跨越任何单一模型与底座的具体实现，实现持久生命力。

By taking inspiration from traditional operating systems and virtualizing agent components into stable abstractions—sessions (durable logs), harnesses (the orchestration loops), and sandboxes (execution environments)—the system successfully decouples the "brain" from the "hands." This architectural shift eliminates brittle infrastructure ("pets"), significantly drops time-to-first-token (TTFT) latency, enhances security, and enables scalable, multi-brain and multi-hand workflows that can outlast any specific implementation.

架构背景与引言

Introduction

在 Anthropic 工程博客中，如何构建高效智能体以及如何为长时间运行的任务设计调度底座一直是一个核心话题。贯穿这些实践的一个共同主线在于：我们所设计的调度底座 (Harness)，本质上都在针对“Claude 自身尚不具备哪些能力”进行硬编码式的前提假设。然而，我们必须时刻审视并质疑这些假设，因为正如“苦涩的教训 (The Bitter Lesson)”所指出的那样，伴随底层模型智能的跃迁，这些既有假设往往很快就会陈旧过时。

A running topic on the Engineering Blog is how to build effective agents and design harnesses for long-running work. A common thread across this work is that harnesses encode assumptions about what Claude can’t do on its own. However, those assumptions need to be frequently questioned because they can go stale as models improve.

举一个真实的例子：在我们之前的工程研究中曾发现，Claude Sonnet 4.5 一旦感知到自身上下文长度即将触及上限，就会草率地提前结束任务——这种现象有时被称为“上下文焦虑 (Context Anxiety)”。当时，我们在调度底座中引入了“上下文自动重置”机制来解决这个问题。然而，当我们把完全相同的底座逻辑应用到更强大的 Claude Opus 4.5 上时，却发现这一焦虑行为早已不复存在，先前精心设计的上下文重置逻辑反倒变成了冗余的累赘 (Dead Weight)。

As just one example, in prior work we found that Claude Sonnet 4.5 would wrap up tasks prematurely as it sensed its context limit approaching—a behavior sometimes called “context anxiety.” We addressed this by adding context resets to the harness. But when we used the same harness on Claude Opus 4.5, we found that the behavior was gone. The resets had become dead weight.

我们深知，调度底座在未来必然会持续迭代演进。为此，我们在 Claude Platform 中构建了 Managed Agents：一项云端托管服务，它通过一组精简且高度抽象的标准化接口代你运行长周期智能体。这套接口的设计初衷，就是为了跨越并超越任何具体的底层实现——包括我们今天所运行的版本。

We expect harnesses to continue evolving. So we built Managed Agents: a hosted service in the Claude Platform that runs long-horizon agents on your behalf through a small set of interfaces meant to outlast any particular implementation—including the ones we run today.

构建 Managed Agents，实际上是在解决计算机科学史上的一个经典老难题：如何为一个系统进行架构设计，使其能够从容承载“尚未构想出的未来程序”。几十年前，传统操作系统通过将物理硬件虚拟化为诸如“进程 (process)”与“文件 (file)”等高度通用的抽象概念，完美化解了这一困境。这些抽象概念的生命力远远超越了硬件本身——无论底层访问的是 20 世纪 70 年代的古老磁盘组，还是当今尖端的固态硬盘 (SSD)，一个标准的 read() 系统调用都完全感知不到硬件差异。顶层的抽象契约坚如磐石，而底层的具体实现则可自由迭代。

Building Managed Agents meant solving an old problem in computing: how to design a system for “programs as yet unthought of.” Decades ago, operating systems solved this problem by virtualizing hardware into abstractions—process, file—general enough for programs that didn't exist yet. The abstractions outlasted the hardware. The read() command is agnostic as to whether it’s accessing a disk pack from the 1970s or a modern SSD. The abstractions on top stayed stable while the implementations underneath changed freely.

Managed Agents 延续了完全相同的设计哲学。我们将智能体的核心组成部分进行了全方位的虚拟化：会话 (Session)，记录所有已发生交互与历史的仅追加日志 (Append-only Log)；底座 (Harness)，负责调用 Claude 并将模型的工具调用精准路由至关联基础设施的循环编排回路；以及 沙盒 (Sandbox)，供 Claude 安全运行代码和编辑文件的隔离执行环境。这使得任意组件的底层实现都可以被随时无缝替换，而丝毫不影响其他组件的正常运转。我们对这些“接口的设计范式”有极其明确的技术主张，但对“接口背后运行的具体实现”则保持完全的开放与中立。

Managed Agents follow the same pattern. We virtualized the components of an agent: a session (the append-only log of everything that happened), a harness (the loop that calls Claude and routes Claude’s tool calls to the relevant infrastructure), and a sandbox (an execution environment where Claude can run code and edit files). This allows the implementation of each to be swapped without disturbing the others. We're opinionated about the shape of these interfaces, not about what runs behind them.

摆脱“宠物式”基础设施的运维泥潭

Don’t Adopt a Pet

在最初的探索阶段，我们将智能体的所有组件统统塞进了一个单一的容器中，这意味着会话管理、智能体底座与代码沙盒共享同一个运行环境。这种“一体化”做法在初期确实有一些便利——例如文件编辑可以直接发起系统调用 (syscall)，而且开发者完全无需花费精力去设计跨服务的网络与鉴权边界。

We started by placing all agent components into a single container, which meant the session, agent harness, and sandbox all shared an environment. There were benefits to this approach, including that file edits are direct syscalls, and there were no service boundaries to design.

但把所有功能强行耦合进单个容器的代价是致命的，我们很快撞上了云计算领域的经典顽疾：我们不自觉地养了一只“宠物 (Pet)”。在基础设施著名的“宠物 vs. 牛群 (Pets vs. Cattle)”比喻中，“宠物”指的是那些拥有专属名称、需要人工悉心照料且一旦死掉便代价惨重的个体，而“牛群”则是完全无状态、可随时替换的消耗品。在我们的早期架构中，运行容器成了这样一只脆弱的“宠物”：一旦容器崩溃挂掉，整个会话的所有状态与进度就荡然无存；一旦容器失去响应，运维工程师就不得不像兽医一样介入，费尽心机去“抢救”它。

But by coupling everything into one container, we ran into an old infrastructure problem: we’d adopted a pet. In the pets-vs-cattle analogy, a pet is a named, hand-tended individual you can’t afford to lose, while cattle are interchangeable. In our case, the server became that pet; if a container failed, the session was lost. If a container was unresponsive, we had to nurse it back to health.

这种对容器的“悉心照料”，本质上是在极其痛苦地调试那些无响应或陷入死锁的会话。当时我们窥探容器内部的唯一窗口就只有一条 WebSocket 事件流通道。然而，单纯的事件流根本无法告诉我们故障到底出在哪一个环节——究竟是底座逻辑存在 Bug、事件流遭遇了网络丢包，还是容器整机下线，在外部观测看来表现得完全一模一样。为了排查根因，工程师不得不通过 SSH 打开容器内部的 Shell 终端进行手动排查；但由于该容器同时驻留着敏感的用户私有数据，出于严格的数据隐私与合规限制，我们根本无法随意登入。这实际上意味着在生产环境中，我们几乎丧失了有效的调试能力。

Nursing containers meant debugging unresponsive stuck sessions. Our only window in was the WebSocket event stream, but that couldn’t tell us where failures arose, which meant that a bug in the harness, a packet drop in the event stream, or a container going offline all presented the same. To figure out what went wrong, an engineer had to open a shell inside the container, but because that container often also held user data, that approach essentially meant we lacked the ability to debug.

第二个核心痛点在于：调度底座默认假定“Claude 需要操作的所有资源都与它一同存放在同一个容器内”。当企业客户提出希望 Claude 直接访问他们私有的虚拟私有云 (Virtual Private Cloud, VPC) 资源时，客户要么必须将其 VPC 网络与我们的内部网络打通对等连接 (VPC Peering)，要么必须在客户自己的基础设施环境中自行部署并运行我们的底座。这种在设计初期硬编码进底座中的强假设，在我们试图将智能体对接多样化异构基础设施时，变成了难以逾越的工程障碍。

A second issue was that the harness assumed that whatever Claude worked on lived in the container with it. When customers asked us to connect Claude to their virtual private cloud, they had to either peer their network with ours, or run our harness in their own environment. An assumption baked into the harness became a problem when we wanted to connect it to different infrastructure.

核心解耦：将“大脑”与“双手”彻底分离

Decouple the Brain from the Hands

我们最终确立的破局方案是：将系统划分为三大部分并进行彻底解耦——负责思考与调度的“大脑” (Claude 及其 Harness 底座)、负责执行具体物理动作的“双手” (执行沙盒与各种工具)，以及记录会话轨迹的“会话” (Session 事件日志)。三者均被抽象为标准契约接口，彼此之间不作任何先验强假设；任何一部分发生故障或需要热替换，都可以独立完成而不波及其他组件。

The solution we arrived at was to decouple what we thought of as the “brain” (Claude and its harness) from both the “hands” (sandboxes and tools that perform actions) and the “session” (the log of session events). Each became an interface that made few assumptions about the others, and each could fail or be replaced independently.

  • Harness 迁出容器： 解耦大脑与双手意味着调度底座不再驻留在容器内部。它调用执行容器的方式与调用任何其他外部工具毫无二致：通过统一接口 execute(name, input) → string。此时容器变成了随用随弃的“牛群”：若容器意外挂掉，底座只需将失败捕获为一次工具调用异常并回传给 Claude；若 Claude 决定重试，底座就能依照标准化配方快速初始化拉起一个全新的容器：provision({resources})。我们从此彻底告别了“抢救”坏死容器的运维噩梦。
  • 从 Harness 故障中自愈： 不仅执行容器变成了“牛群”，连调度底座本身也成为了无状态的“牛群”。由于会话日志完全独立保存在底座之外，底座崩溃时无需保留任何内存状态。一旦某个底座实例宕机，新的底座实例可以通过 wake(sessionId) 被唤醒，调用 getSession(id) 拉取完整的历史事件日志，并从上一个事件发生的位置无缝续接执行。在智能体主循环运行期间，底座只需通过 emitEvent(id, event) 持续向会话写入数据，即可确保持久化审计记录的绝对完备。

  • The harness leaves the container. Decoupling the brain from the hands meant the harness no longer lived inside the container. It called the container the way it called any other tool: execute(name, input) → string. The container became cattle. If the container died, the harness caught the failure as a tool-call error and passed it back to Claude. If Claude decided to retry, a new container could be reinitialized with a standard recipe: provision({resources}). We no longer had to nurse failed containers back to health.

  • Recovering from harness failure. The harness also became cattle. Because the session log sits outside the harness, nothing in the harness needs to survive a crash. When one fails, a new one can be rebooted with wake(sessionId), use getSession(id) to get back the event log, and resume from the last event. During the agent loop, the harness writes to the session with emitEvent(id, event) in order to keep a durable record of events.

  • 重构安全隔离边界： 在过去紧密耦合的设计中，Claude 生成的任何不受信代码都与各类系统凭证运行在同一个容器内——这意味着攻击者若实施提示词注入 (Prompt Injection)，只需诱导 Claude 读取自身所在容器的环境变量即可窃取凭证。一旦攻击者拿到这些访问 Token，就能凭空创建不受限制的全新会话并下发任意恶意任务。对权限范围进行细粒度收窄 (Narrow Scoping) 固然是一种常规防御手段，但这再次对“拥有受限 Token 的 Claude 做不到什么”进行了预设假设——而随着 Claude 越来越聪明，这种假设极其脆弱。根本性的结构化解决方案，是确保运行 Claude 生成代码的沙盒环境在物理上永远无法触达任何敏感 Token。
  • The security boundary. In the coupled design, any untrusted code that Claude generated was run in the same container as credentials—so a prompt injection only had to convince Claude to read its own environment. Once an attacker has those tokens, they can spawn fresh, unrestricted sessions and delegate work to them. Narrow scoping is an obvious mitigation, but this encodes an assumption about what Claude can't do with a limited token—and Claude is getting increasingly smart. The structural fix was to make sure the tokens are never reachable from the sandbox where Claude’s generated code runs.

为了落实这一铁律，我们采用了两种安全模式：将认证权限直接与资源绑定，或者存放在沙盒外部的安全凭证保险库 (Vault) 中。以 Git 操作为例，在沙盒初始化阶段，系统使用各代码仓库的访问 Token 克隆代码库，并将其配置注入本地 Git 远程源中。智能体在沙盒内部可以直接执行标准的 Git push 与 pull 命令，而其自身自始至终无法接触到任何 Token 字符串。对于自定义工具，我们原生支持模型上下文协议 (Model Context Protocol, MCP)，并将 OAuth 授权 Token 统一保存在外部加密保险库中。Claude 通过专属的安全代理 (Dedicated Proxy) 调用 MCP 工具：该代理仅接收与当前会话关联的临时标识，随后由代理从保险库中取出真实凭证代为向外部服务发起请求。在整个过程中，调度底座 Harness 同样对底层真实凭证一无所知。

We used two patterns to ensure this. Auth can be bundled with a resource or held in a vault outside the sandbox. For Git, we use each repository’s access token to clone the repo during sandbox initialization and wire it into the local git remote. Git push and pull work from inside the sandbox without the agent ever handling the token itself. For custom tools, we support MCP and store OAuth tokens in a secure vault. Claude calls MCP tools via a dedicated proxy; this proxy takes in a token associated with the session. The proxy can then fetch the corresponding credentials from the vault and make the call to the external service. The harness is never made aware of any credentials.

破除误区：会话 (Session) 绝不等同于 Claude 的上下文窗口

The Session is Not Claude’s Context Window

长周期的复杂任务往往会超出 Claude 自身的上下文窗口上限，而业界的传统处理手段几乎都涉及一系列“不可逆”的取舍决策——即决定保留什么、丢弃什么。我们在关于上下文工程的早期研究中曾深入探讨过这些技术手段。例如，上下文压缩 (Compaction) 允许 Claude 对窗口内容生成摘要保存，记忆工具 (Memory Tool) 允许 Claude 将重要上下文持久化写入文件以实现跨会话学习。这些策略还可以与上下文裁剪 (Context Trimming) 搭配使用，有选择地剔除久远的工具执行结果或思维链 (Chain-of-Thought, CoT) 思考块等无用 Token。

Long-horizon tasks often exceed the length of Claude’s context window, and the standard ways to address this all involve irreversible decisions about what to keep. We’ve explored these techniques in prior work on context engineering. For example, compaction lets Claude save a summary of its context window and the memory tool lets Claude write context to files, enabling learning across sessions. This can be paired with context trimming, which selectively removes tokens such as old tool results or thinking blocks.

然而，选择性保留或丢弃上下文的不可逆决定极易引发系统性失败。在多轮长程规划中，我们很难预先研判未来的决策轮次究竟会需要哪些历史 Token。一旦消息被执行了压缩归纳，调度底座就会将原始消息从 Claude 的活动上下文窗口中移除，除非这些原始消息被妥善存储，否则它们将永远无法追溯恢复。学术界先前的研究已经探索过解决方案：将上下文作为独立对象保存在上下文窗口外部。例如，在交互式解释器环境 (REPL) 中将上下文抽象为一个常驻对象，大语言模型 (LLM) 可以通过编写代码来可编程地对其进行过滤、切片与按需读取。

But irreversible decisions to selectively retain or discard context can lead to failures. It is difficult to know which tokens the future turns will need. If messages are transformed by a compaction step, the harness removes compacted messages from Claude’s context window, and these are recoverable only if they are stored. Prior work has explored ways to address this by storing context as an object that lives outside the context window. For example, context can be an object in a REPL that the LLM programmatically accesses by writing code to filter or slice it.

在 Managed Agents 中，“会话”正是扮演了这一外置上下文对象的角色，天然独立于 Claude 自身的有限窗口之外。更进一步的是，它没有将上下文直接置于沙盒或 REPL 中，而是以仅追加的持久化事件日志形式存储。通过标准化接口 getEvents()，作为“大脑”的模型可以自由查询上下文，根据位置索引灵活切片事件流。这一接口极其敏捷自由：大脑不仅可以随时从上次停读的位置继续往下读取，还能在关键决策前倒回若干步事件以回溯前因后果，或者在执行特定关键动作前精准重读先验细节。

In Managed Agents, the session provides this same benefit, serving as a context object that lives outside Claude’s context window. But rather than be stored within the sandbox or REPL, context is durably stored in the session log. The interface, getEvents(), allows the brain to interrogate context by selecting positional slices of the event stream. The interface can be used flexibly, allowing the brain to pick up from wherever it last stopped reading, rewinding a few events before a specific moment to see the lead up, or rereading context before a specific action.

拉取到的所有事件在真正输入 Claude 的上下文窗口之前，还可以在调度底座内部进行二次加工与动态转换。底座可以自由编码任何转换策略——包括组织上下文结构以最大化提示词缓存 (Prompt Cache) 命中率，以及实施各种精细的上下文工程。我们之所以将“会话层的可恢复持久化存储”与“底座层的任意动态上下文管理”进行关注点分离，是因为我们无法预测未来的新一代模型究竟需要怎样特定的上下文工程范式。标准化接口将复杂的上下文管理权交给调度底座自行掌控，而系统本身只向外界提供不可动摇的底线承诺：会话日志绝对持久可靠，并随时可供查询检索。

Any fetched events can also be transformed in the harness before being passed to Claude’s context window. These transformations can be whatever the harness encodes, including context organization to achieve a high prompt cache hit rate and context engineering. We separated the concerns of recoverable context storage in the session and arbitrary context management in the harness because we can’t predict what specific context engineering will be required in future models. The interfaces push that context management into the harness, and only guarantee that the session is durable and available for interrogation.

规模化演进：多大脑与多双手的协同生态

Many Brains, Many Hands

  • 多大脑架构 (Many Brains)： 将大脑与双手解耦，彻底解决了早期企业客户普遍反馈的技术痛点。此前，当团队希望 Claude 访问其自身 VPC 内部的专有资源时，唯一的方法就是与我们的网络建立复杂的网络对等连接 (VPC Peering)，因为装载调度底座的容器固执地假定所有资源都与其紧挨在一起。一旦 Harness 迁出容器，这一束缚荡然无存。这项重构不仅带来了架构解耦，更带来了巨大的性能红利：在旧架构下，将大脑硬塞进容器意味着“有多少个大脑就必须冷启动多少个独立容器”。对于每一个大脑而言，在容器完全完成资源编排就绪之前，根本无法启动任何模型推理；每一个会话都在一开始就背负了高昂的容器初始化耗时。哪怕是一个完全不需要接触沙盒的纯推理会话，也不得不完整经历克隆代码库、启动守护进程、从服务端拉取待处理事件等漫长步骤。
  • Many brains. Decoupling the brain from the hands solved one of our earliest customer complaints. When teams wanted Claude to work against resources in their own VPC, the only path was to peer their network with ours, because the container holding the harness assumed every resource sat next to it. Once the harness was no longer in the container, that assumption went away. The same change had a performance payoff. When we initially put the brain in a container, it meant that many brains required as many containers. For each brain, no inference could happen until that container was provisioned; every session paid the full container setup cost up front. Every session, even ones that would never touch the sandbox, had to clone the repo, boot the process, fetch pending events from our servers.

这种因容器冷启动产生的无效等待时间直接体现在首字元生成延迟 (Time-To-First-Token, TTFT) 上，它衡量的是会话从接收任务到吐出第一个响应 Token 之间的时间跨度。而 TTFT 正是终端用户感知最为敏锐与痛切的核心性能瓶颈。

That dead time is expressed in time-to-first-token (TTFT), which measures how long a session waits between accepting work and producing its first response token. TTFT is the latency the user most acutely feels.

在解耦设计下，执行容器仅在确实需要时，才由大脑通过统一工具调用接口 (execute(name, input) → string) 按需按量动态拉起。因此，一个暂时不需要沙盒的会话完全无需经历漫长的容器等待；只要编排层从会话日志中拉取到待处理事件，大模型推理即可瞬间触发。采用这一现代化架构后，我们的 p50 TTFT 延迟直降约 60%，p95 极端延迟更是骤降超过 90%。此时，横向扩展至海量“大脑”，仅仅意味着启动大量轻量级的无状态底座实例，并且仅在必要时才将它们挂载连接至对应的“双手”。

Decoupling the brain from the hands means that containers are provisioned by the brain via a tool call (execute(name, input) → string) only if they are needed. So a session that didn't need a container right away didn't wait for one. Inference could start as soon as the orchestration layer pulled pending events from the session log. Using this architecture, our p50 TTFT dropped roughly 60% and p95 dropped over 90%. Scaling to many brains just meant starting many stateless harnesses, and connecting them to hands only if needed.

  • 多双手架构 (Many Hands)： 与此同时，我们也希望赋予每一个大脑同时联动多副“双手”的能力。在生产实战中，这意味着 Claude 必须具备同时理解并规划多个执行环境的能力，并自主决策将不同的任务派发至何处——这显然比在单一固定 Shell 终端中敲命令具有高得多的认知复杂度。我们早期之所以把大脑限制在单一容器内，主要是因为初代模型的推理与规划能力尚不足以胜任多环境调度；但随着模型智能水平的指数级跃升，单一容器反倒成了制约模型潜力的死穴：一旦该容器崩溃，大脑正在触达操作的每副“双手”所关联的所有状态都将全盘覆灭。
  • Many hands. We also wanted the ability to connect each brain to many hands. In practice, this means Claude must reason about many execution environments and decide where to send work—a harder cognitive task than operating in a single shell. We started with the brain in a single container because earlier models weren't capable of this. As intelligence scaled, the single container became the limitation instead: when that container failed, we lost state for every hand that the brain was reaching into.

将大脑与双手彻底解耦后，每一副“双手”都化作了一个标准工具接口：execute(name, input) → string——输入工具名称与参数，返回执行结果字符串。这套极简接口天然兼容任意自定义工具、任何标准的 MCP 服务器以及 Anthropic 原生内置的各项工具。调度底座完全无需关心背后的沙盒究竟是一个普通的 Docker 容器、一部真实的智能手机，还是一个正在运行宝可梦游戏的模拟器。更为重要的是，由于没有任何一副双手与特定大脑产生物理死锁绑定，不同的大脑甚至可以在多智能体协作流程中彼此顺畅地传递并共享这副“双手”。

Decoupling the brain from the hands makes each hand a tool, execute(name, input) → string: a name and input go in, and a string is returned. That interface supports any custom tool, any MCP server, and our own tools. The harness doesn’t know whether the sandbox is a container, a phone, or a Pokémon emulator. And because no hand is coupled to any brain, brains can pass hands to one another.

总结与思考

Conclusion

我们所面临的工程挑战其实早已在计算机史上反复出现：如何为一个系统进行架构设计，使其能够从容容纳“尚未构想出的未来程序”。传统操作系统之所以能够历经数十年风雨依然生机勃勃，正是因为它成功将物理硬件抽象为普适的虚拟层，为当年尚不存在的应用程序提供了通用的运行土壤。而在 Managed Agents 的设计中，我们的目标同样如此：构建一个能够全面兼容并优雅承载围绕 Claude 演化出的未来各类全新底座、沙盒乃至各类外部组件的通用底座系统。

The challenge we faced is an old one: how to design a system for “programs as yet unthought of.” Operating systems have lasted decades by virtualizing the hardware into abstractions general enough for programs that didn't exist yet. With Managed Agents, we aimed to design a system that accommodates future harnesses, sandboxes, or other components around Claude.

秉持着这种哲学，Managed Agents 本质上是一套“元底座 (Meta-Harness)”——它对 Claude 未来究竟需要何种具体形态的调度回路不作任何死板设定。相反，它提供的是高度通用的开放抽象接口，允许接入各种截然不同的底座实现。例如，Claude Code 就是一个我们内部广泛用于各类复杂任务的优秀工程底座；同时我们此前的研究也表明，针对特定专业任务定制的专用底座在垂直领域表现极具优势。Managed Agents 能够无缝兼容上述所有范式，并随着 Claude 自身智能的不断进化而保持同步演进。

Managed Agents is a meta-harness in the same spirit, unopinionated about the specific harness that Claude will need in the future. Rather, it is a system with general interfaces that allow many different harnesses. For example, Claude Code is an excellent harness that we use widely across tasks. We’ve also shown that task-specific agent harnesses excel in narrow domains. Managed Agents can accommodate any of these, matching Claude’s intelligence over time.

元底座的设计精髓在于：紧紧锚定围绕 Claude 运转的核心接口契约。我们坚信 Claude 始终需要操作持久状态的能力 (体现为会话 Session) 以及安全执行代码计算的能力 (体现为沙盒 Sandbox)。我们同样预见到，Claude 必然需要横向扩展为多大脑与多双手的协同网络。我们精心定义了这些接口规范，确保它们能够在超长的时间跨度上高可靠、高安全地稳定运行。但与此同时，我们对 Claude 未来实际需要调用的“大脑”与“双手”的数量或物理网络拓扑，不做任何先入为主的预设。

Meta-harness design means being opinionated about the interfaces around Claude: we expect that Claude will need the ability to manipulate state (the session) and perform computation (the sandbox). We also expect that Claude will require the ability to scale to many brains and many hands. We designed the interfaces so that these can be run reliably and securely over long time horizons. But we make no assumptions about the number or location of brains or hands that Claude will need.

致谢

Acknowledgements

本文由 Lance Martin、Gabe Cemaj 与 Michael Cohen 共同撰写。感谢 Nodir Turakulov 和 Jeremy Fox 在相关技术议题上富有成效的交流与启发。特别鸣谢 Agents API 团队以及 Jake Eaton 为该项目所作出的杰出工程贡献。

Written by Lance Martin, Gabe Cemaj, and Michael Cohen. Thanks to Nodir Turakulov and Jeremy Fox for helpful conversations on these topics. Special thanks to the Agents API team and Jake Eaton for their contributions.