Appearance
该文章暴露出一个趋势，Agent工程的重心，正从prompt/harness逐步转向runtime/platform，换句话说，问题已经不再是如何让模型更会想，而是怎么让模型在真实世界里稳定运行、可恢复、可治理、并且把上下文和动作管理好
Anthropic 用一个很直白的表达来概括这件事：Decoupling the brain from the hands。把“大脑”和“手”解耦。这个说法表面上像比喻，实际上对应的是一个很具体的工程判断：不要再把推理、规划、状态维护、工具调用、权限控制、错误恢复、异步任务管理全部堆在同一个 Agent prompt 和 harness 里。
一、Anthropic真正在解决什么问题
如果这两年做过agent，很容易经历一个相似过程
一开始大家都是“模型+工具调用”，给模型几个tool，加一点system prompt，加一点循环，让他自己决定什么时候搜索、代码执行， 这个阶段就是证明模型不只是聊天，它还能做事
但是只要任务一变长，工具一变多，执行链变得复杂，问题就很容易暴露出来
- 上下文越来越长，模型开始遗忘或者提前收尾
- 工具调用细节越来越多
- 一旦中断，很难恢复到中间的状态继续执行
- 失败重试、异步轮询、权限边界等问题
- 评估和审计很难做，因为系统状态散落在prompt、日志和工具结果里
这类问题的共同点是：它们已经不是模型推理能力本身的问题，而是运行时设计的问题。
Anthropic 这篇文章回应的，正是这个阶段变化。随着模型能力提升，瓶颈从“模型能不能推理”逐渐转移到了“系统怎么承接模型的推理结果，让它稳定落地执行”。
所以文章里提出的 managed agents，本质上不是一个简单的 API 包装，而是一种更偏平台化的 Agent 运行思路。
二、什么叫大脑和手解耦
Anthropic 这句话如果翻成工程语言，大概可以拆成三层。
第一层，决策和执行解耦。模型负责理解目标、制定策略、识别异常、决定下一步做什么；而具体怎么调工具、怎么轮询异步任务、怎么做重试、怎么 checkpoint、怎么恢复，这些不应该都让模型用自然语言硬扛。模型说“要做什么”，运行时负责“怎么可靠地做完”。
第二层，推理状态和执行状态解耦。Agent 运行时里其实有两类完全不同的状态。一类是推理状态，比如当前目标、子任务、计划、判断依据；另一类是执行状态，比如 job id、工具调用历史、重试次数、权限票据、异步任务进度。如果把这两类状态都塞进模型上下文，模型很快就会沦为一个在读执行日志的解释器，而不是一个做高价值判断的决策器。Managed agents 的方向，是把大量执行状态从 prompt 里剥离出去，存放在托管运行时中，只把当前决策真正需要的摘要反馈给模型。
第三层，高层动作和低层工具细节解耦。这点尤其关键。一个成熟 Agent 不该让模型永远盯着 HTTP 参数、分页、认证头、轮询逻辑这些低层实现，而应该尽量面向更高层的 action abstraction 工作。比如“研究一个主题”“准备一个 PR”“总结客服线程”“运行一批评测”，而不是每一步都在跟 API JSON 搏斗。
所以这里的“brain”和“hands”并不是说模型不执行了，而是说：模型不应该被迫亲自管理所有执行细节。
三、文章的主题
过去很多 Agent 工程讨论，默认中心是 prompt 或 harness。也就是说，大家潜意识里还在把 Agent 视为“一个更复杂的 prompt system”。模型是核心，其他部分只是辅助胶水。
但 Anthropic 这篇文章其实在说：Agent 不应再只被理解成 prompt 驱动的工具调用器，而应该被理解成运行在一个托管执行系统上的智能控制层。
这会带来几个很直接的后果。
1. Agent 的核心竞争点正在从“更会想”转向“更会执行”
现在看 Agent，真正拉开差距的往往不是模型能不能规划三步五步，而是这些更“土”的问题：
- 长任务会不会中途崩
- 工具调用会不会乱
- 状态能不能恢复
- 权限会不会越界
- 成本会不会失控
- 是否能追踪、回放、审计
这类问题在传统软件工程里不新鲜，但在 Agent 时代，它们变成了决定系统能不能上线的核心因素。Anthropic 文章里的 managed agents，本质上就是在把这些能力产品化、平台化。
2. Harness 不再是最终答案
Anthropic 在其他文章里也反复透露一个现实：很多 harness 设计，编码的是“模型当前做不到什么”的假设。但模型能力在变化，这些假设会过时。
比如某一代模型需要你显式写死任务拆解模板、写死上下文切分策略、写死一套错误恢复话术；下一代模型可能自己就能做得更好，结果你那些旧规则反而成了束缚。
所以更合理的系统边界应该是：把稳定且不依赖模型能力变化的逻辑，尽量沉到 runtime；把会随着模型变强而变化的策略，保持轻量和可演化。
换句话说，prompt 要薄，runtime 要厚。
3. 上下文管理不能只靠上下文本身解决
这点和长短记忆设计直接相关。很多系统一遇到上下文压力，就开始做截断、压缩、摘要，像是在 token 层做救火。但这篇 managed agents 隐含传达的更深一层判断是：很多东西压根就不该待在上下文里。
比如工具执行轨迹、异步任务状态、权限令牌、重试元信息，这些本质上属于 runtime state，而不是给模型持续展开的 reasoning context。如果这些信息不被剥离出去，模型再强也会被执行噪声拖垮。
所以这篇文章其实也在提醒我们：Agent 的上下文工程，最终会收敛到“把什么从上下文里拿出去”，而不只是“怎么往上下文里塞更多”。
四、这篇文章对 Agent 架构设计的真正启发
如果把 Anthropic 这篇文章转成一个更可实现的系统设计视角，我觉得至少可以提炼出下面这套结构。
第一层：Reasoning Layer
这一层由模型承担，负责：
- 理解用户意图
- 做高层任务拆解
- 判断当前步骤成功与否
- 在异常分叉时做策略调整
- 生成中间结论和最终输出
这一层不适合承载太多低层执行逻辑，否则模型会被工具细节和流程噪声稀释。
第二层：Execution Runtime
这一层是 managed agents 的核心。它负责：
- 工具调用编排
- 状态持久化
- checkpoint 与 resume
- timeout 与 retry
- 权限和审计
- 异步作业管理
- 长任务生命周期控制
从软件系统的角度看，这层更像是 Agent 的操作系统，而不是一个简单中间件。
第三层：Capability Interface
这一层负责把底层工具和环境能力以更稳定的形式暴露给 Agent。它可能包括：
- MCP 一类标准化工具接入协议
- 更高层封装过的 skills / actions
- 浏览器、代码执行、企业系统等外部环境
这里最重要的不是工具数量，而是抽象粒度。如果粒度太低，模型负担过重；如果粒度过高，又可能失去必要控制。
第四层：Memory and Evaluation
这篇文章虽然不是专讲 memory 和 eval，但它背后的运行时思路会直接影响两者设计。
memory 方面，要把长期语义记忆和运行时执行状态分开。稳定偏好、可复用知识、重要项目事实可以进长记忆；而 job 进度、轮询状态、临时日志这种内容，不应该伪装成“长期记忆”。
evaluation 方面，runtime 平台化以后，评测也更容易从“看最终答案好不好”升级为“看整个任务执行过程是否稳定、是否可恢复、是否资源合理”。
一个需要警惕的点是，平台托管往往伴随抽象泄漏。对于简单到中等复杂度任务，managed runtime 可以明显减轻工程负担；但一旦进入高度定制场景，比如强监管流程、复杂业务状态机、企业内网工具链深度耦合，你迟早还是要面对底层执行模型。
另一个边界是，解耦不等于隔离。模型虽然不该背全部执行细节，但它仍然需要拿到足够的执行反馈，否则就会变成脱离现场的“高层瞎指挥”。所以真正成熟的系统，不是简单把手剁掉交给平台，而是建立一套更干净的反馈接口：给模型必要反馈，但不让它被低层噪声淹没。