Anthropic Managed Agents 解读：长任务 Agent 为什么要解耦 brain、hands 和 session

摘要：Anthropic Engineering 在 2026 年 4 月发布《Scaling Managed Agents: Decoupling the brain from the hands》，讲的是长任务 Agent 如何从“一个大容器里跑到底”演进为可恢复、可替换、可扩展的系统架构。它的核心启发是：Agent 不应该被设计成一个不能失败、不能迁移、不能调试的“宠物容器”，而应该拆成 brain、hands、session 三类稳定接口，让模型、工具、沙箱和状态日志可以独立演进。

背景：长任务 Agent 不是一次推理，而是一套运行时

很多团队做 Agent 时，最初会把所有东西放进同一个运行环境：模型循环、工具调用、文件系统、代码执行、会话状态都在一个容器里。这样做开发很快，因为文件修改是本地 syscall，工具接口也不用跨服务设计。

但一旦 Agent 开始处理长任务，这种架构就会暴露问题。任务可能运行几十分钟甚至更久，容器可能卡死，网络流可能中断，模型上下文可能耗尽，用户可能暂停后再回来。单容器架构在 demo 阶段很舒服，在生产阶段就会变成难维护的“宠物”。

Anthropic 的 Managed Agents 就是为了解决这个问题。它把长任务 Agent 拆成三类接口：brain、hands 和 session。brain 是 Claude 与 harness；hands 是沙箱、工具和外部执行环境；session 是可持久化的事件日志。

从宠物容器到可替换组件

Anthropic 文章里用了 pets vs cattle 的类比。宠物是有名字、需要照顾、不能轻易丢的个体；cattle 是可替换的资源。如果 Agent 的全部状态都在一个容器里，这个容器就成了宠物。

容器一旦失败，session 可能丢失；容器卡住，工程师不得不进容器调试；容器里如果还存着用户数据和凭据，调试本身又会变成安全问题。

Managed Agents 的做法是让 harness 离开容器。容器不再承载整个 Agent，而只是一个可以被调用的执行工具。brain 通过类似 execute(name, input) -> string 的接口调用 hand。如果 hand 死了，brain 收到的是工具错误，可以重新 provision 一个。

这带来一个关键变化：失败从灾难变成普通事件。系统不需要拯救某个坏掉的容器，而是把失败暴露给 Agent 或编排层，让它重试、换环境或请求人工介入。

Session 不等于上下文窗口

长任务 Agent 的另一个难题是上下文。很多人会把上下文问题理解为“模型上下文窗口不够长”，于是使用压缩、摘要、裁剪、memory 文件等策略。

这些方法有用，但都有不可逆风险。你今天丢掉的一段日志，可能正是明天排查失败需要的关键证据。

Anthropic 的思路是把 session 做成 Claude 上下文窗口之外的持久事件日志。harness 每次执行都写入事件，失败后新 harness 可以通过 wake(sessionId) 恢复，用 getSession 或 getEvents 获取历史，再从最后事件继续。

这相当于把“可恢复状态”和“当前提示词上下文”分开。Claude 当前上下文只放这一步需要的内容，完整历史则保存在 session 里，可以按需切片、回看、摘要或重组。

对研发团队来说，这个设计非常重要。不要把所有历史都塞进 prompt，也不要把状态只存在模型上下文里。长期 Agent 应该有自己的事件溯源系统。

Brain 和 hands 解耦后的性能收益

文章还提到一个很实际的性能收益：TTFT，也就是从接受任务到产生第一个响应 token 的时间。

在旧设计里，每个 brain 都绑定一个容器。即使任务一开始并不需要执行代码，也要先 provision 容器、克隆仓库、启动进程、取事件。用户会感觉启动很慢。

brain 和 hands 解耦后，推理可以先开始。只有当任务真正需要文件系统、shell 或其它执行环境时，brain 才通过工具调用去 provision hand。Anthropic 文章称，这让 p50 TTFT 下降约 60%，p95 下降超过 90%。

这个例子说明：Agent 性能优化不只是模型推理速度。架构是否把不必要的环境启动放在关键路径上，会直接影响用户体验。

安全边界：凭据不应出现在 sandbox 里

解耦还有一个安全收益。旧架构里，Claude 生成的代码可能和凭据在同一个容器中运行。如果 prompt injection 诱导 Claude 读取环境变量，token 就可能泄露。

Managed Agents 的结构性修复是：生成代码运行的 sandbox 不应能接触凭据。

Anthropic 使用两种模式：一种是把授权和资源绑定，比如 Git token 只在初始化 repo 时用于配置 remote，agent 不直接接触 token；另一种是把 OAuth token 放在 sandbox 外部的 vault，通过 MCP proxy 代为调用外部服务。harness 也不需要知道真实凭据。

这给企业 Agent 一个明确原则：工具权限要通过代理和 vault 管理，不要把凭据作为环境变量塞进执行容器。

多个 brain，多个 hands

一旦 brain、hands、session 都变成接口，系统就不再限制于一个模型操作一个容器。多个 brain 可以启动多个无状态 harness；一个 brain 可以连接多个 hands；不同 hands 可以是容器、MCP 工具、远程环境，甚至未来完全不同的执行设备。

这对企业场景很重要。客户可能希望 Agent 操作自己 VPC 内的资源，而不是把所有数据拉到服务商容器里。如果 harness 不再假设资源就在本地容器，集成远程环境会更自然。

未来 Agent 平台很可能会像分布式系统一样：一个协调 brain，多个执行 hand，一个 durable session log，再加上权限、审计、恢复和监控。

对研发团队的实践建议

第一，不要把长任务 Agent 做成单进程脚本。至少要拆出状态日志、工具执行环境和模型循环。

第二，所有关键事件都应 append-only 记录。模型输入、工具调用、输出、错误、人工反馈、文件改动都应该能回放。

第三，sandbox 要可替换。执行环境坏了可以重建，任务不应因此丢失。

第四，把凭据放在 vault 和 proxy 后面。Agent 可以请求能力，但不应该直接持有长期密钥。

第五，把 TTFT 纳入 Agent 体验指标。用户感知的不只是任务总时长，也包括任务是否能立刻开始推进。

风险与限制

这种架构会增加系统复杂度。接口边界、事件日志、远程 sandbox、MCP proxy、凭据 vault 和恢复逻辑都需要工程投入。对小型 demo 来说，单容器可能更快。

但一旦 Agent 要进入真实生产环境，可恢复性、安全边界和可观测性会比开发便利更重要。尤其是长任务、多人协作和企业权限环境下，单容器架构很快会成为负担。

结论

Anthropic Managed Agents 的核心启发是：长任务 Agent 应该像分布式系统，而不是像一次性脚本。

brain、hands、session 的解耦，让 Agent 能失败后恢复、能连接不同执行环境、能保护凭据、能降低启动延迟，也能随着模型能力提升替换 harness。对研发团队来说，建设 Agent 平台时最重要的不是先堆更多工具，而是先设计稳定接口和持久状态。只有这样，Agent 才能从一次性自动化，变成可长期运行的工程基础设施。

参考来源

• Anthropic Engineering：Scaling Managed Agents: Decoupling the brain from the hands，2026-04-08
  https://www.anthropic.com/engineering/managed-agents
• Anthropic Engineering Blog
  https://www.anthropic.com/engineering