摘要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 与 harnesshands 是沙箱、工具和外部执行环境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 时用于配置 remoteagent 不直接接触 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 EngineeringScaling Managed Agents: Decoupling the brain from the hands2026-04-08https://www.anthropic.com/engineering/managed-agentsAnthropic Engineering Bloghttps://www.anthropic.com/engineering