如果团队已经在跑 Agent 系统，可以先做一个简单的实验：把工具调用日志中，因为工具返回错误导致推理错误的次数统计出来。如果这个比例超过 10%，就值得考虑分离。
如果你的 Agent 已经在生产环境跑了几个月，你一定遇到过这种情况：Agent 在一轮推理中生成了一大段思考，然后调用了一个工具，工具返回了错误，Agent 开始重新推理，但这次推理被之前那堆工具返回的原始数据淹没了，推理质量反而下降。
这不是个例。当 Agent 的推理逻辑和工具执行逻辑混在同一个上下文窗口里时，两个问题会同时出现：推理层被执行细节干扰，执行层被推理延迟拖累。而它们偏偏又绑在一起，没法独立优化。
一个被大多数人忽略的架构问题
大多数 Agent 框架的默认实现，是把推理和工具执行放在同一个循环里。模型先生成思考，然后调用工具，把工具结果追加到上下文，继续思考，再调用下一个工具。这个模式在演示时很流畅，但到了生产环境，问题就开始暴露。
第一个问题：上下文污染。工具返回的数据往往是原始格式------API 的完整 JSON 响应、数据库查询结果、文件内容片段。这些数据进入上下文后，当 Agent 进入下一轮推理时，模型必须从这些原始数据中"找到"自己需要的信息。如果工具返回的数据量很大（比如一次搜索返回了 20 条结果，每条包含完整摘要），推理的有效上下文窗口就被压缩了。
第二个问题：错误传播。工具执行失败时，错误信息直接进入推理上下文。如果 Agent 刚好用的是推理模型，它会花大量 Token 去"分析"这个错误，甚至过度解读------明明是网络超时，模型却可能认为是工具实现有问题。
第三个问题：无法独立扩展。推理需要高参数模型或者推理模型，执行需要低延迟、低成本。当两者耦合在一起时，你只能用同一个模型做两件事。为了推理质量选了强模型，工具调用成本居高不下；为了执行成本选了弱模型，推理能力又不够。
大脑-手分离：一个老概念的新落地
"解耦推理与执行"在软件工程里不是新概念。但在 Agent 系统里，这个分离有更具体的含义：推理层（大脑）负责规划、分解任务、判断结果；执行层（手）负责调用工具、执行操作、返回结构化结果。
Anthropic 在 2026 年 4 月的工程博客中正式描述了这种模式，并称之为"Scaling Managed Agents"。他们发现，在客户侧 Agent 系统中，效果最好的架构往往是分离的------大脑只管想，手只管做。
这个架构的核心模型很简单：
大脑层只有一个职责：决定下一步做什么。它接收用户请求，分解成任务，调用执行层，分析执行结果，决定是否继续、重试或结束。大脑不直接接触任何外部系统，它通过执行层提供的结构化接口获取信息。
执行层则相反：它不决策，只执行。它接收大脑的指令，调用对应的工具，把结果整理成结构化数据返回给大脑。执行层可以包含重试逻辑、超时控制、结果格式化，但这些都不需要大脑知道。
这个模式为什么影响 Agent 应用
大多数生产级 Agent 遇到的问题，根源都在于推理和执行的耦合。分离之后，问题变得可解了。
上下文管理变得可控。大脑只接收执行层处理过的结构化结果，而不是原始数据。执行层可以负责截断、摘要、格式转换------比如搜索返回了 20 条结果，执行层可以只返回前 5 条加上"还有 15 条未显示"的标记。大脑不需要处理原始数据，上下文窗口压力骤减。
错误处理变得清晰。执行层负责重试和降级。一次工具调用超时了，执行层可以自动重试三次，三次都失败再返回"该工具暂时不可用"给大脑。大脑不需要知道网络问题、认证问题或者限流问题------它只需要知道工具执行的结果或者失败状态。
成本优化有了新维度。大脑可以用推理模型（比如推理能力强但成本高的模型），执行层可以用更便宜的模型或者纯代码实现。有些执行任务甚至不需要 LLM 参与------比如格式化数据、调用 REST API、执行 SQL 查询------这些完全可以用常规代码实现，成本接近零。
工程落地怎么做
实现大脑-手分离不需要复杂的框架。核心是定义好两个接口。
大脑到执行层的接口通常是一个任务描述结构：
@dataclass
class Task:
tool: str # 要调用的工具名称
params: dict # 工具参数
context: str | None # 执行所需的上下文信息
max_retries: int = 3 # 执行层自行重试次数
timeout: float = 30.0 # 超时控制执行层到大脑的接口是一个结果结构：
@dataclass
class TaskResult:
tool: str
status: Literal["success", "retryable_error", "fatal_error"]
data: Any # 执行层处理过的结构化数据
summary: str # 面向大脑的简短摘要
raw_size: int # 原始数据大小，供大脑参考
duration_ms: float关键点在于 data 和 summary 的分离。data 是结构化数据，summary 是给大脑看的自然语言摘要。执行层负责把原始数据转换成这两者，大脑只消费 summary 和 data 中的关键字段。
大脑的循环逻辑可以保持简单：
async def brain_loop(task_queue, result_queue, max_steps=20):
for step in range(max_steps):
task = await decide_next_task(result_queue) # 根据上一步结果决定下一步
if task is None: # 任务完成
break
await task_queue.put(task)
result = await result_queue.get()
# 处理结果...执行层的实现更直接：
async def execute_task(task, tool_registry):
for attempt in range(task.max_retries):
try:
raw = await tool_registry.call(task.tool, task.params)
processed = await process_result(task.tool, raw)
return TaskResult(
tool=task.tool,
status="success",
data=processed["data"],
summary=processed["summary"],
raw_size=len(raw)
)
except RetryableError as e:
await asyncio.sleep(2 ** attempt) # 指数退避
except FatalError as e:
return TaskResult(tool=task.tool, status="fatal_error", ...)这个模式的边界在哪里
大脑-手分离不是银弹。它适用的场景有明确边界。
当 Agent 执行的任务链比较短（比如 3-5 步），且工具调用简单直接时，没有必要引入分离层。单循环的 Agent 在简单场景下更高效，代码也更少。引入分离反而增加了复杂度和延迟。
当工具调用之间高度依赖上下文时，分离可能会增加通信成本。如果一个工具的执行结果直接影响下一个工具的参数选择，大脑需要先等执行层返回结果，再决定下一步。这个往返开销在单循环模式中是不存在的。
当执行层需要复杂的决策能力时，把执行层做得太"薄"反而会限制其能力。如果某个工具调用需要根据输入数据动态决定如何执行，那执行层也需要一定的推理能力------这时候执行层就不再是纯粹的"手"了，而是另一个大脑。这意味着你的架构需要支持嵌套的大脑-手结构。
生产建议
如果团队已经在跑 Agent 系统，可以先做一个简单的实验：把工具调用日志中，因为工具返回错误导致推理错误的次数统计出来。如果这个比例超过 10%，就值得考虑分离。
分离的切入点不需要一步到位。可以先从最"脏"的工具开始------那些返回原始数据量大、错误率高的工具。让这些工具的执行结果经过执行层处理后再进入大脑的上下文，观察推理质量的变化。
成本方面，可以先对大脑角色使用推理模型，对执行层使用更便宜的模型或纯代码。如果执行层使用纯代码实现，成本可以降至接近零------这是分离模式最容易被忽视的收益。
最后，不要等到所有接口都设计完美了再上线。大脑-手之间的接口可以先从简单的 JSON 开始，随着业务复杂度增加再逐步完善。Agent 系统本身就在快速演化，架构设计应该留出调整空间，而不是一次性追求完美。