Agent 的「大脑」不需要带着「双手」一起死：Anthropic 解耦 brain/hand 后启动延迟降 60%，但跨组织协作才是更难的问题

大多数团队第一次搭 agent 系统，是把所有东西塞进一个容器 — — 模型、工具调用循环、执行环境、凭证、日志。运行起来没问题。直到容器挂了，你发现 session 没了、状态丢了、整个 agent 和它踩过的所有坑一起蒸发了。

Anthropic 把这三个东西拆开之后，p50 首 token 延迟降了 60%，p95 降了 90% 以上。但拆开的是一个 agent 的内部组件 — — 跨组织协作，他们没动。

你第一次把一个 agent 接进生产系统的时候，大概率经历过这件事：容器卡死了。你看不到里面发生了什么，唯一的窗口是 WebSocket 事件流 — — 但它不能告诉你故障出在 harness、沙箱、还是网络。你想进容器 debug，但容器里存着用户数据，你不敢动。你的 agent 不是一台服务器，它是一只宠物 — — 生病了你得端着药去哄它。

而当你终于把它救活，发现它只是网络断了一秒 — — 你花了 40 分钟去诊断一个 1 秒的问题。这种无力感不只你有。Anthropic 的工程师在 2026 年 4 月的文章里用了一个精准的比喻：“我们养了一只宠物，不是牧场的牛。”

宠物 vs 牛（pets vs cattle）是 SRE 领域的老类比了。一只宠物有自己的名字，生病了有人治，死了有人心疼。牧场的牛没有名字，死了就换一头。Anthropic 的 Managed Agents 架构，核心工作就是把 agent 从宠物变成牛 — — 每个组件可以独立死亡、独立替换、独立恢复。

真正有意思的是：这个架构把 agent 内部拆清楚了，但跨 agent、跨组织的协作问题，它没碰。而跨组织协作需要的架构思维，和 Anthropic 拆 agent 内部组件时用的东西，是同一个东西 — — 标准化接口替代硬编码耦合，cattle 替代 pet。

适合谁读？ 正在搭 agent 基础设施的平台工程师和架构师；从单 agent 转向多 agent、发现”agent 内部架构”和”agent 间架构”是两个完全不同问题的团队；对「agent 的操作系统」这个类比感兴趣、想理解它在不同层级上分别意味着什么的人。

读完这篇，你应该能回答三个问题：

1. Anthropic 把 agent 拆成 Session / Harness / Sandbox 三个接口后，TTFT 降 60% 靠的是什么机制？
   不是模型变快——是把"启动容器"从"启动推理"的路径上拿掉了。
2. 这套解耦方案在单 agent 内部很完整，但跨组织协作少了哪四块？
   发现、跨集群传递、能力变化可见、任务级编排。
3. BeeOS 的 OpenAPI + A2A 怎么把 cattle 模式从"一个 agent 内部"扩展到"全网络 agent 可替换"？
   三入口分工——OpenAPI 管生死，A2A 管对话，MCP 管边界。

零、先把事实说清楚

Anthropic 在 2026 年 4 月 8 日发布的工程博客《Scaling Managed Agents: Decoupling the brain from the hands》，详细记录了他们的 hosted agent 服务在生产中遇到的瓶颈和架构重构。

• 指标: p50 TTFT（首 token 延迟） — 旧架构（耦合容器）: 基线 — 新架构（解耦 brain/hand/session）: 降约 60%
• 指标: p95 TTFT — 旧架构（耦合容器）: 基线 — 新架构（解耦 brain/hand/session）: 降超 90%
• 指标: 容器故障恢复 — 旧架构（耦合容器）: 人工进入容器 debug，session 可能丢失 — 新架构（解耦 brain/hand/session）: harness 崩溃后 wake(sessionId) 自动恢复
• 指标: 安全边界 — 旧架构（耦合容器）: 凭证和 untrusted code 在同一容器 — 新架构（解耦 brain/hand/session）: Git token 注入 remote，MCP OAuth 走 vault proxy
• 指标: brain-to-hand 关系 — 旧架构（耦合容器）: 1:1（一个 brain 绑一个 sandbox） — 新架构（解耦 brain/hand/session）: M:N（多个 brain 可操作多个 sandbox，brain 间可传递 hand）
• 指标: 上下文持久化 — 旧架构（耦合容器）: 内存内，容器死 = 上下文丢 — 新架构（解耦 brain/hand/session）: session 独立 append-only 日志，harness 可任意时间回读

核心机制：Session（append-only 事件日志）、Harness（无状态决策循环，wake(sessionId) 即恢复）、Sandbox（provision({resources}) 标准化创建，死了直接重建）——三个独立接口，各自可替换。

以上数据来自 Anthropic 工程博客《Scaling Managed Agents: Decoupling the brain from the hands》（2026–04–08），作者 Lance Martin、Gabe Cemaj、Michael Cohen。

一、从宠物到牛：为什么「全塞一个容器」是条死路

Anthropic 的工程师说了句大实话：旧架构把 session、harness、sandbox 全塞进一个容器里的时候 — — 他们养了一只宠物，不是牧场的牛。

这句话代表的意思是：当你的 agent 是一个不可替换的个体，每一个故障都变成了急诊。不是监控告警、自动重启、事后复盘这种正常运维 — — 是急诊。而且是那种你看不到病因、手里却捏着用户数据的急诊。

旧架构的状态：

┌──────────────────────────────┐
│         一个容器              │
│  ┌────────┐  ┌────────────┐  │
│  │Harness │  │  Sandbox   │  │
│  │(决策)  │  │  (执行)    │  │
│  └────────┘  └────────────┘  │
│  ┌──────────────────────┐   │
│  │     Session (日志)    │   │
│  └──────────────────────┘   │
│  ┌──────────────────────┐   │
│  │     凭证 + 密钥       │   │
│  └──────────────────────┘   │
└──────────────────────────────┘

三个问题从这里长出来，每一个都值得单独展开。

第一，容器死亡 = session 死亡。 日志和 agent 绑在同一个进程空间。容器一挂，你连 agent 最后做了什么都不知道。Anthropic 的工程师唯一的办法是进容器 debug — — 但容器里有用户数据，开 shell debug 本身就踩在安全红线上。更要命的是：三种完全不同的故障 — — harness 里的 bug、WebSocket 丢包、容器离线 — — 在运营端看起来一模一样。你分不清是谁的锅，只知道”它不动了”。

第二，每个 session 都付容器的启动成本，即使它根本不需要容器。 这是最容易被人忽略的一个成本来源。在旧架构里，任何 session — — 包括纯文本对话、纯规划任务 — — 都要等容器完全就绪才能开始推理。克隆 repo、拉取依赖、启动进程、拉取 pending events — — 这些操作跟推理无关，但它们站在推理前面排队。解耦后的架构把容器变成 brain 发 execute() 按需调用，不需要 sandbox 的 session 直接跳过这些步骤开始推理。这就是 p50 TTFT 降 60% 的核心：不是推理变快了，是排队消失了。

第三，凭证和 untrusted code 同处一室。 Claude 生成的代码在 sandbox 里跑，sandbox 和凭证在同一个容器里。prompt injection 只需要说服 Claude 读一下环境变量 — — 不需要绕过什么复杂的安全机制。传统的缓解方案是给 token 窄 scope，但这本质上是在赌”Claude 不知道窄 scope token 还能做什么”。而 Claude 正在变聪明 — — 赌模型的无知，不是安全策略，是时间炸弹。

新架构做的事，本质上是一次操作系统式的虚拟化 — — 对上面的 agent 暴露统一接口，把下面随时变的东西藏起来：

┌──────────┐    ┌──────────┐    ┌──────────┐
│ Session  │    │ Harness  │    │ Sandbox  │
│(独立存储)│    │(无状态)  │    │(标准化创建)│
│          │    │          │    │          │
│ append   │◄───│ wake(id) │───►│provision │
│ only log │    │ emitEvent│    │({res})   │
│          │    │          │    │          │
│ 活着就行 │    │崩了重启  │    │死了重建  │
└──────────┘    └──────────┘    └──────────┘
      │               │                │
      │               │    ┌───────────┴──────┐
      │               └───►│  Vault Proxy     │
      │                    │  (凭证隔离)      │
      └────────────────────┤                  │
                           │  Git remote:     │
                           │  token 注入后    │
                           │  agent 不可见    │
                           │                  │
                           │  MCP:            │
                           │  OAuth 进 vault  │
                           │  proxy 代发请求  │
                           └──────────────────┘

Session 是 append-only 日志 — — harness 崩了以后用 wake(sessionId) 从最后一个事件恢复。Sandbox 死了用 provision({resources}) 重建一个规格化的——不心疼。Harness 本身也是无状态的——崩溃了启动一个新的，调用 wake(sessionId)，从 session 日志里读到自己的上一段生命，继续往下走。

这不是简单的拆服务。这是重新定义了 agent 的故障域 — — 每个组件可以独立失败，不影响整体恢复。就像操作系统里一个进程崩了不会让内核 panic。

二、多 brain 多 hand：解耦的经济学

解耦不光解决了可靠性问题，还解开了一个旧架构里的硬绑定：brain 和 hand 必须一比一。

旧架构里，一个 brain（harness + Claude）绑一个 sandbox。要 5 个 brain 就得起 5 个容器 — — 每个都要全量初始化。新架构里，brain 本身是无状态的决策循环，它通过 execute(name, input) → string 这个统一接口操作任何 hand。

这个设计释放了两个结构性的自由度：

brain 和 hand 可以 N:M。 一个 brain 可以同时操作多个 sandbox — — 比如同时在一个 sandbox 里跑数据分析代码、在另一个 sandbox 里编辑配置文件。反过来，多个 brain 也可以共享 hand — — brain A 把一个 sandbox 的控制权交给 brain B，传递的不是消息，是执行环境本身。

这在实际场景里非常具体：你有一个 brain 负责规划，它把一个 sandbox（里面有装好的依赖、代码、上下文）直接交给另一个 brain 去执行 — — handoff 不是复制状态，是指针传递。

按需启动。 不需要 sandbox 的 session — — 纯思考、纯规划、纯文本对话 — — 推理可以立即开始，不等任何东西。sandbox 变成工具调用的一部分，不是 agent 的前提条件。p50 TTFT 降 60%、p95 降 90% 的数据，不是来自什么优化技巧。来自把”启动容器”从”启动推理”的关键路径上完全移除。

Anthropic 的文章里有一段关于 context anxiety 的故事，值得单独提出来。他们在 Claude Sonnet 4.5 上观察到一个行为：模型感知到 context limit 即将达到时会提前结束任务。他们在 harness 里加了 context reset 来应对。但到了 Claude Opus 4.5，这个行为消失了 — — context reset 变成了死代码。

这就是”harness 编码了关于模型弱点的假设”的典型案例。这些假设会过期，而过期的代码应该能被替换掉而不影响系统其他部分。可替换的前提是解耦。 如果 harness 和 session 绑在一起，你就不能单独换 harness。

三、拆开了一个 agent，没拆开 agent 之间

到这里，Anthropic 的方案在单个 agent 的内部架构上已经非常完整。但它有一个结构性的空白：它没有定义 agent 与 agent 之间的接口。

具体看缺了什么：

一、没有 agent 发现机制。 Managed Agents 里，每个 brain 通过 execute() 操作自己的 hand。但如果你想让 Agent A 调用 Agent B——跨团队、跨组织、跨供应商的另一个 agent——怎么知道它的存在？怎么知道它的能力？Anthropic 的接口里没有任何”Agent Card”的概念。在一个平台内这不是问题——平台知道所有 agent。但在跨平台场景里，发现是第一道门。门都没有，谈不上协作。

二、没有跨集群 sandbox 传递协议。 brain 之间可以传递 hand，但前提是它们在同一套 Managed Agents 基础设施里。这个前提在跨组织场景里不成立 — — 你的 agent 在 Anthropic 平台，我的在 BeeOS，sandbox 怎么传递？没有跨平台的 handoff 协议，brain A 建好的 sandbox 对 brain B 来说就是不可见的。

三、session 记录事件，不记录能力变化。 session 只存”发生了什么”（event log），不存”agent 现在能做什么”。一个 agent 在运行过程中获得了新的工具权限、接入了新的外部服务 — — 这些动态能力变化对它自己的 harness 是已知的，但对另一个想调用它的 agent 来说完全不可见。没有能力变化通知机制，agent 之间永远只能在静态假设上协作。

四、没有任务级编排。 execute(name, input) → string 是一个同步的工具调用接口。它没有 task ID、没有状态跟踪、没有异步流式反馈。一个 agent 发给另一个 agent 的长时间任务——比如”跑这个数据分析，可能需要 5 分钟，有进展告诉我”——在这套接口里传不了。Anthropic 给单 agent 内部建了 session 做 durable log，但 agent 之间没有等效物。

这四个缺失画在一起：

单 agent 内部（Anthropic 已解决）：
  ✅ Session / Harness / Sandbox 解耦
  ✅ brain-hand N:M 关系
  ✅ 凭证隔离（vault proxy + token injection）
  ✅ 故障恢复（wake + provision）
  ✅ harness 可替换（死代码不拖累系统）

agent 之间（Anthropic 没碰）：
  ❌ agent 发现——"现在有哪些 agent 可以合作？"
  ❌ task 跨组织传递——"我把这个任务交给你，怎么交？怎么跟踪？"
  ❌ sandbox 跨集群传递——"我在我的环境里建好了，你能接手吗？"
  ❌ 能力变化可见——"我刚接了一个新的数据分析 API，你该知道"

这不是 Anthropic 做错了。Managed Agents 是一个平台内的产品 — — 在一个平台里解耦 brain/hand 已经解决了它要解决的问题。但 agent 经济的走向是跨平台协作的 — — 你的代码 agent 要调我的数据分析 agent，我的要调第三方的报告生成 agent。这个场景需要的不是平台内的接口，是平台间的协议。

四、BeeOS 的补位：把 cattle 模式从「单 agent 内部」扩展到「全网络」

BeeOS 做的事不是给已有的 agent 内部架构再加一层包装。它做的事是：把 Anthropic 给单 agent 内部建的 cattle 思维 — — 每个组件可替换、可独立恢复 — — 扩展到 agent 之间的协作层。

通过三种入口分工实现，每种解决一个层级的问题。

OpenAPI：agent 实例级的 cattle 生命周期

Anthropic 的 provision({resources}) 是 sandbox 的标准化生命周期。BeeOS 的 OpenAPI 把同样的逻辑用在了 agent 实例上：

POST /openapi/v1/agents/{agentId}/deploy     → 启动实例
POST /openapi/v1/agents/{agentId}/invoke     → 调用实例
POST /openapi/v1/agents/{agentId}/terminate  → 销毁实例

每个 agent 实例有独立生命周期。挂了就 terminate，重新 deploy。和 Anthropic 的 sandbox 一样——不是宠物，是牛。区别在于 Anthropic 管的是 sandbox 的生和死，BeeOS 管的是 agent 实例的生和死。一个层级往上移了一格。

A2A：补上 agent 发现、task 传递、流式反馈

这是 Anthropic 方案里完全缺失的三块。A2A（Agent-to-Agent）协议提供了三个标准化的跨组织协作接口：

Agent Card — — 每个 agent 的能力自描述。不是硬编码的 URL 列表或中心化注册中心。是 agent 自己发布的、可发现的元数据：

{
  "name": "CodeSandbox",
  "description": "执行代码并返回结果的沙箱 agent",
  "url": "https://a2a.beeos.ai/codesandbox",
  "skills": [
    {"id": "exec_python", "description": "Python 代码执行"},
    {"id": "exec_shell", "description": "Shell 命令执行"}
  ],
  "defaultInputModes": ["text", "application/json"],
  "defaultOutputModes": ["text", "application/json"]
}

JSON-RPC task — — 跨组织任务传递的标准格式。不是 Anthropic 私有的 execute()，而是带着 task ID、结构化输入、预期输出的标准化 RPC：

{
  "jsonrpc": "2.0",
  "method": "tasks/send",
  "params": {
    "id": "task_abc123",
    "message": {
      "role": "user",
      "parts": [
        {"type": "text", "text": "在沙箱中运行 data_analysis.py 并返回输出"}
      ]
    }
  }
}

SSE streaming — — 实时任务进度推送。execute(name, input) → string 是同步的，Orchestrator 在等待结果期间是瞎的。SSE 把每一步进度实时推回：

event: taskArtifactUpdate
data: {"taskId":"task_abc123","artifact":{"parts":[{"type":"text","text":"正在安装 pandas..."}]}}

event: statusUpdate  
data: {"taskId":"task_abc123","status":{"state":"completed"}}

三入口的分工逻辑

OpenAPI ── 管理 agent 实例的「生和死」
  ├── deploy / invoke / terminate
  └── 每个实例是 cattle，挂了就重建

A2A ── 管理 agent 之间的「对话」
  ├── Agent Card：发现（"谁存在、能做什么"）
  ├── JSON-RPC task：传递（"把这个任务交给你"）
  └── SSE streaming：反馈（"进行到哪一步了"）

MCP ── 管理 agent 的「权限边界」
  ├── bak_ 凭证体系：每个 agent 只能碰自己权限内的资源
  └── 和 Anthropic 的 vault proxy 逻辑一致——凭证不进 sandbox

Anthropic 解决了”一个 agent 内部怎么变牛” — — brain、hand、session 各自可替换。BeeOS 解决的是”多个 agent 之间怎么变牛” — — 当你的 Orchestrator 需要调用另一个组织维护的 agent 时，你不需要知道它的容器架构、harness 实现、凭证策略。你只需要它的 Agent Card 和 task 接口。

这就是 Anthropic 自己的设计哲学 — — “对接口有意见，对接口后面的实现没意见” — — 应用到 agent 之间的协作层。

五、最小可复用实现：三个组件跑通全链路

这套逻辑不需要黑科技。三个最小组件就能验证：

TaskOrchestrator        CodeSandbox            SandboxRegistry
    │                       │                       │
    │   A2A task/send       │                       │
    │──────────────────────►│                       │
    │                       │   register sandbox    │
    │                       │──────────────────────►│
    │                       │                       │
    │   SSE artifact        │                       │
    │◄──────────────────────│                       │
    │   SSE statusUpdate    │                       │
    │◄──────────────────────│                       │

• TaskOrchestrator：通过 A2A 发现下游 agent 的 Agent Card，构造 task 并发送。不关心下游 agent 的内部架构 — — 不管是 Anthropic Managed Agents 驱动的 sandbox 还是自己实现的隔离环境，只要实现了 Agent Card + JSON-RPC task 就能接入。统一接口，内部实现自由。
• CodeSandbox：一个实现了 A2A 协议的 agent，接收 task、执行代码、SSE 流式返回结果。内部可以用 Anthropic 的 provision({resources}) 造 sandbox，也可以用自己的 Docker/K8s 隔离环境——对外接口不变。
• SandboxRegistry：记录所有可用 sandbox 的能力和状态。不是 agent 注册中心（Agent Card 已经解决了发现），而是 sandbox 的运行态仓库 — — 哪些在用、哪些 idle 可以复用、哪些需要重建。配合 OpenAPI 的 deploy/terminate 做实例级 cattle 管理。

关键设计原则和对 Anthropic 文章的呼应：

• 解耦范围 — Anthropic Managed Agents: 单 agent 内部（brain/hand/session） — BeeOS A2A: agent 之间（发现、传递、反馈）
• 发现机制 — Anthropic Managed Agents: 无（平台内部自管理） — BeeOS A2A: Agent Card
• 任务传递 — Anthropic Managed Agents: 内部 execute() — BeeOS A2A: 跨组织 JSON-RPC task
• 进度可见 — Anthropic Managed Agents: 同步返回 — BeeOS A2A: SSE streaming
• 生命周期 — Anthropic Managed Agents: sandbox provision({resources}) — BeeOS A2A: agent 实例 deploy/invoke/terminate
• 凭证边界 — Anthropic Managed Agents: vault proxy + token injection — BeeOS A2A: MCP bak_ 权限体系
• 适用边界 — Anthropic Managed Agents: 一个平台内的 agent — BeeOS A2A: 跨平台、跨组织的 agent 网络

对内实现可以任意替换，对外接口是标准化的。 这句写在 Anthropic 文章里的设计原则，在单 agent 内部是对的，在 agent 之间同样是对的。只是文章没往下推这一步。

结尾

Anthropic 把”操作系统”的类比端到了 agent 架构的台面上 — — 这可能是文章最重要的贡献。OS 通过虚拟化硬件让 read() 不知道下面是磁盘、SSD、还是网络 socket。Managed Agents 通过 execute() 让 harness 不知道 hand 是容器、手机、还是未发明的计算单元。

但这个类比值得继续往下推：操作系统不只是管一个程序的内部组件，它管的是程序之间的通信、资源竞争、权限隔离。IPC、文件描述符传递、信号量 — — 这些不是进程内部的事，是进程之间的事。

agent 的操作系统，同样需要这一层。Anthropic 建了内核，没建 IPC。

三个问题留给你，不需要现在回答，但值得放在团队的架构文档里：

1. 你的 agent 系统里，brain 挂了能不能自动恢复？hand 挂了能不能重建？
   ——Anthropic 的 cattle 模式在你这里是实现的、计划的、还是没想过的？
2. 你的 agent 需要调用另一个团队维护的 agent 时，是硬编码接口还是运行时发现？
   ——硬编码是技术债的起点，不是技术债的终点。
3. 你的团队在跨 agent 协作上的瓶颈，是「模型不够智能」还是「协议没有标准化」？
   ——分不清这两个的人，会一直把协议问题当成模型问题去解决。

如果这三个问题里有两个没有清晰答案，你缺的不是更好的模型。你缺的是 agent 之间的一层标准化接口 — — 和 50 年前 OS 给进程之间加的那层一样基本的东西。

参考与延伸阅读

• 案例来源（事实基础）：Scaling Managed Agents: Decoupling the brain from the hands（Anthropic Engineering Blog, 2026–04–08）
• BeeOS：docs.beeos.ai · openapi.beeos.ai · a2a.beeos.ai · mcp.beeos.ai
• A2A 规范背景：A2A（Google）
• MCP 规范背景：Model Context Protocol
• Building Effective Agents（Anthropic, 2024）
• Effective Harnesses for Long-Running Agents（Anthropic）
• Harness Design for Long-Running Apps（Anthropic）

BeeOS： docs.beeos.ai · openapi.beeos.ai · a2a.beeos.ai · mcp.beeos.ai