内容分享——Scaling Managed Agents: Decoupling the brain from the hands

原文Scaling Managed Agents: Decoupling the brain from the hands来源Anthropic Engineering Blog作者Lance Martin, Gabe Cemaj, Michael Cohen核心命题HarnessAgent 运行框架会过时但接口应该永存。随着模型能力的快速提升今天为弥补模型不足而设计的 harness 明天可能就成为死重。Anthropic 通过 Managed Agents 解决了一个经典计算机科学问题如何为尚未想到的应用程序设计系统。一、问题背景Harness 的过时问题1.1 一个具体案例Context Anxiety在 Claude Sonnet 4.5 时代团队发现模型会在感知到上下文限制接近时过早地结束任务——这种行为被称为上下文焦虑。当时的解决方案是在 harness 中加入**上下文重置context resets**机制。然而当同样的 harness 应用到 Claude Opus 4.5 时发现这个行为已经消失了。模型变得更聪明了不再需要这种干预。但上下文重置的代码仍然在那里成为死重dead weight。1.2 核心洞察“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.”Harness 编码了关于 Claude 自身无法做什么的假设。但这些假设需要经常被质疑因为随着模型改进它们可能会过时。这引用了 Rich Sutton 的《The Bitter Lesson》试图将人类知识编码到系统中的方法最终会被利用计算能力的通用方法所超越。二、解决方案操作系统式的抽象2.1 类比操作系统虚拟化硬件几十年前操作系统通过将硬件虚拟化为**进程process和文件file**等抽象来解决同样的问题。这些抽象足够通用可以支持当时还不存在的应用程序。关键洞察read()命令不关心它访问的是 1970 年代的磁盘组还是现代 SSD上层的抽象保持稳定而底层实现可以自由变化2.2 Managed Agents 的三层虚拟化Managed Agents 遵循同样的模式将 Agent 组件虚拟化为三个核心抽象组件类比功能Session文件系统只追加日志记录发生的一切Harness进程调度器调用 Claude 并将工具调用路由到相应基础设施的循环Sandbox执行单元Claude 可以运行代码和编辑文件的执行环境这种设计允许每个组件的实现被替换而不会干扰其他组件。三、架构演进从宠物到牲畜3.1 第一代架构紧耦合的宠物初始设计所有 Agent 组件放在单个容器中Session、Agent Harness、Sandbox 共享一个环境好处文件编辑是直接系统调用无需设计服务边界问题采用了宠物pet模式在宠物 vs 牲畜pets-vs-cattle的类比中宠物有名字的、手工维护的个体你无法承受失去它牲畜可互换的、批量管理的实例在这个类比中服务器变成了宠物——如果容器失败session 就丢失了如果容器无响应必须手工 nursed 恢复健康。3.2 调试噩梦紧耦合带来的具体问题故障定位困难唯一的观察窗口是 WebSocket 事件流无法区分是 harness bug、事件流丢包还是容器离线工程师必须进入容器内部调试但容器通常包含用户数据实际上缺乏调试能力网络假设固化Harness 假设 Claude 操作的所有资源都在同一个容器内当客户要求连接到他们的 VPC 时必须将他们的网络与 Anthropic 的网络对等连接或者在客户自己的环境中运行 harness一个 baked into harness 的假设成为了连接不同基础设施的障碍四、解耦架构大脑与手分离4.1 核心设计原则将大脑Brain与手Hands以及会话Session解耦。每个组件成为对接口做很少假设的独立单元可以独立失败或被替换。4.2 Harness 离开容器变化Harness 不再生活在容器内部。新的调用方式execute(name, input) → stringHarness 像调用任何其他工具一样调用容器。结果容器变成了牲畜cattle如果容器死亡harness 将其作为工具调用错误捕获并返回给 Claude如果 Claude 决定重试可以用标准配方provision({resources})重新初始化新容器不再需要 nursed 失败的容器恢复健康4.3 Harness 故障恢复关键设计Session log 位于 harness 外部。这意味着Harness 内部没有任何需要在崩溃后存活的东西当 harness 失败时可以用wake(sessionId)重启新的 harness使用getSession(id)恢复事件日志从最后一个事件恢复执行持久化机制emitEvent(id, event) // 在 agent 循环中写入 session保持事件的持久记录4.4 安全边界紧耦合设计的安全问题Claude 生成的任何不受信任的代码在与凭证相同的容器中运行提示注入只需要说服 Claude 读取自己的环境一旦攻击者获得令牌可以生成新的无限制 session解耦后的安全改进Git 认证模式使用每个仓库的访问令牌在 sandbox 初始化期间克隆仓库将令牌接入本地 git remoteGit push/pull 在 sandbox 内工作但 agent从不直接处理令牌MCP 工具认证模式OAuth 令牌存储在安全 vault 中Claude 通过专用代理调用 MCP 工具代理接收与 session 关联的令牌代理从 vault 获取凭证并调用外部服务Harness 永远不会知道任何凭证五、Session超越 Claude 的上下文窗口5.1 长程任务的上下文挑战长程任务通常超过 Claude 的上下文窗口长度。标准解决方案都涉及不可逆的决策技术描述问题CompactionClaude 保存上下文窗口的摘要原始信息丢失Memory ToolClaude 将上下文写入文件需要显式管理Context Trimming选择性移除旧工具结果或思考块可能删除未来需要的信息核心问题很难知道未来的 turn 需要哪些 token。5.2 Session 作为上下文对象Managed Agents 中session 作为位于 Claude 上下文窗口之外的上下文对象。接口设计getEvents() // 允许大脑通过选择事件流的位置切片来查询上下文使用方式从上次停止读取的位置继续回退到特定时刻前的几个事件查看前因在特定动作前重新读取上下文5.3 关注点分离Session负责可恢复的上下文存储持久化、可靠Harness负责任意的上下文管理组织、缓存优化、上下文工程这种分离的原因是无法预测未来模型需要什么样的特定上下文工程。六、性能优化多大脑、多手6.1 解耦前的性能瓶颈问题每个大脑需要同样多的容器每个 session 必须预先支付完整的容器设置成本即使永远不会 touch sandbox 的 session也必须克隆仓库、启动进程、获取待处理事件指标Time-to-first-token (TTFT)衡量 session 从接受工作到产生第一个响应 token 的等待时间这是用户最能感受到的延迟6.2 解耦后的性能提升变化容器仅在需要时由大脑通过工具调用execute(name, input) → string配置。结果不需要立即使用容器的 session 不需要等待容器推理可以在编排层从 session log 拉取待处理事件后立即开始性能数据p50 TTFT 下降约 60%p95 TTFT 下降超过 90%扩展到多个大脑只需启动多个无状态 harness仅在需要时连接手。6.3 多手的认知挑战目标让每个大脑能够连接到多个手执行环境。挑战Claude 必须推理多个执行环境并决定向哪里发送工作——这比在单个 shell 中操作是更难的认知任务。解耦后的能力每个手成为一个工具execute(name, input) → string输入名称和输入返回字符串支持任何自定义工具、任何 MCP 服务器、Anthropic 自己的工具Harness 不知道 sandbox 是容器、手机还是 Pokémon 模拟器因为没有任何手与任何大脑耦合大脑可以相互传递手七、Meta-Harness 设计哲学7.1 核心思想Managed Agents 是一个meta-harness元框架“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.”不对 Claude 未来需要的特定 harness 持意见。相反它是一个具有通用接口的系统允许多种不同的 harness。7.2 设计原则有意见的OpinionatedClaude 需要操作状态的能力sessionClaude 需要执行计算的能力sandboxClaude 需要扩展到多个大脑和多个手的能力这些接口应该支持在长周期内可靠、安全地运行无意见的Unopinionated大脑和手的数量和位置特定的 harness 实现特定的 sandbox 类型7.3 与现有 Harness 的关系Claude Code优秀的通用 harness在 Anthropic 内部广泛使用任务特定 harness在狭窄领域表现出色Managed Agents可以容纳以上任何一种随时间匹配 Claude 的智能水平八、关键工程洞察总结8.1 架构设计原则接口稳定性 实现稳定性设计持久的接口允许实现自由变化借鉴操作系统虚拟化硬件的经验牲畜 宠物组件应该是可互换的而不是手工维护的故障应该导致替换而不是修复解耦 紧耦合大脑、手、session 应该独立失败和扩展通过最小化假设实现灵活性8.2 安全设计原则凭证隔离执行环境不应该能够访问凭证使用代理模式间接访问敏感资源最小权限每个组件只获得其功能所需的最小权限避免一旦攻破全部失守的单点故障8.3 性能设计原则延迟优化识别用户最能感受到的延迟TTFT按需配置资源避免预热的固定成本水平扩展无状态组件易于水平扩展状态集中在专门的持久化层九、对开发者的启示9.1 设计 Agent 系统的建议质疑你的假设今天为弥补模型不足而添加的代码明天可能成为死重定期评估 harness 中的假设是否仍然有效设计持久接口投资于接口设计而非具体实现考虑尚未想到的应用程序拥抱解耦将认知大脑与执行手分离将状态session与逻辑harness分离9.2 使用 Managed Agents 的最佳实践利用接口灵活性通过getEvents()灵活地管理上下文利用 session 的持久化特性实现容错设计可恢复的执行假设任何组件都可能失败利用 harness 的故障恢复机制安全地管理凭证使用 vault 存储敏感信息避免将凭证暴露给执行环境参考链接Building effective agentsEffective harnesses for long-running agentsHarness design for long-running applicationsEffective context engineering for AI agentsThe Bitter Lesson - Rich SuttonThe Art of Unix Programming - Chapter 3 - Eric S. RaymondPets vs Cattle - Cloud Scaling