为什么搞懂 Agent，要先把它拆成五层来看
Agent 的能力与故障都长在 Loop / Tool / Planning / Memory / Multi-Agent 这五层地基上。
立靶：不分层，你会在错的层上使错的劲
很多人第一次接触 Agent，会被一堆名词砸晕：Loop、工具调用、ReAct、记忆、多智能体、MCP……于是要么把它当成「会聊天的机器人」，要么当成「一个超大 prompt」。这两种理解都会在做产品时反噬你。
不懂分层，会怎样？你会把一个本属于「模型规划能力不够」的问题，错当成「prompt 没写好」，于是无止境地改提示词；你会把「工具描述写得烂导致模型不会调」误判成「模型太笨」，转头去换更贵的模型；你会在一个根本不需要协作的任务上硬上多智能体，徒增通信失真和成本。更危险的是，当线上 Agent 出故障时，你定位不到是哪一层塌了——是循环里错误级联了，还是工具调错了，还是记忆把不该记的记住了。
把 Agent 拆成五层，本质是给你一张故障定位图和一张能力地图。每一层解决一个明确的问题，每一层有自己典型的失败表现。看懂了这张图，你和工程师对话时能说到点子上，做技术选型时知道该在哪一层下注，排查事故时能直接锁定塌掉的那一层。这是 Module A 的底座——后面所有关于失败节点、错误恢复、透明度、边界行为的讨论，都站在这五层之上。
框架：五层地基一张表
自下而上，五层逐级叠加。下层不稳，上层全废——没有可靠的 Loop，再精巧的规划也跑不起来；没有靠谱的工具调用，规划只是空想。
| 层 | 解决什么问题 | 典型能力 | 失败表现 |
|---|---|---|---|
| L1 Agent Loop | 让模型能「持续行动」而非一次性回答 | 思考→行动→观察的循环；stop_reason==tool_use 时继续，否则收尾 | 错误在循环里级联放大；陷入死循环或提前终止 |
| L2 Tool Use | 让模型能调用外部世界的能力 | name / description / inputSchema 三要素；并行工具调用；Computer Use | 模型不调、调错、参数填错；description 含糊导致调用成功率低 |
| L3 Planning | 让模型把复杂任务拆解、编排 | Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Supervisor-Workers 五种工作流 | 任务拆解混乱、步骤遗漏；用错编排模式 |
| L4 长期记忆 | 让 Agent 跨会话记住该记的 | 滚动窗口 / 摘要压缩 / 关键信息提取；显式偏好 vs 隐式偏好 | 该记的漏掉（Recall 差）；不该想起的乱想起（Precision 差） |
| L5 Multi-Agent | 让多个 Agent 协作完成单体装不下的任务 | 通信协议防失真；子任务错误三级处理：重试→降级→上报 | 智能体间信息失真；错误无人兜底；过度拆分徒增成本 |
关键认知：Agency（自主性）来自模型训练本身，不来自编排框架。hardcoded 的节点式 workflow 天花板很低，处理不了预设之外的路径。框架只是脚手架，决定模型能发挥多少，但发挥的上限由模型决定。
横切五层的还有一个 MCP（Model Context Protocol）。它不属于任何单独一层，而是 L2 工具接入的标准化协议——可以理解成「工具接入的 USB-C 标准」。三个角色：Host / Client / Server；三种能力：Tools（最重要）/ Resources / Prompts；两种传输：stdio（本地）/ SSE（远程）。它的价值是让工具的接入方式标准化，不必为每个 Agent 重写一遍胶水代码。
数据 / case：五层在真实产品里长什么样
下面都是脱敏后的真实场景，每个对应一层的「成败手感」：
- L1 Loop 的级联放大（某语音招聘 Agent）：实时语音场景里，一句识别错误会被带进下一轮推理，越滚越偏，最后整通对话跑题。教训是循环里必须有纠偏机制，不能让错误无衰减地往下传。
- L2 Tool description 决定成败（某合同审查 Agent）：同一个「提取条款」工具，description 从一句话改写成带使用边界和示例的清晰说明后，模型调用成功率显著提升。模型没变，工具描述变了，效果就变了——这印证了「description 质量是 L2 最重要的变量」。
- L3 编排模式错配（某深度研究 Agent）：把一个需要动态分配子任务的研究流程，硬套成线性的 Prompt Chaining，结果遇到分支就卡死。换成 Orchestrator-Workers（编排者动态派发子任务）后才跑顺。选对工作流模式，比堆 prompt 重要。
- L4 Precision vs Recall 的权衡（某长期助理 Agent）：用滚动窗口省事但丢早期信息（Recall 差）；用关键信息提取精准但要先定义「什么算重要」。还要区分显式偏好（用户明说的）和隐式偏好（从行为推断的）——把推断错的隐式偏好当成事实记下来，就是典型的 Precision 故障。
- L5 何时该上多智能体（某话术合规场景）：实时合规检查用 Supervisor-Workers 模式，一个 Agent 干活、一个 Agent 实时盯合规。但要记住：只有「任务可并行 / 需要独立验证 / 单 context 装不下」时才值得上 L5，否则通信失真和成本不划算。
可操作做法：怎么把这套分层用起来
PM 视角——用它做判断和沟通：
- 拿到一个 Agent 需求，先问「这事卡在哪一层」，而不是直接想 prompt 怎么写。
- 评估方向时，按层定位下注点：是该优化工具描述（L2），还是该换编排模式（L3），还是该补记忆方案（L4）。
- 警惕「过度协作」冲动——能用单 Agent + 好工具解决的，别轻易上 L5；多一层就多一份通信失真和成本。
- 故障复盘时，对照「失败表现」那一列逐层排查，把模糊的「Agent 不好用」翻译成具体哪一层塌了。
- 和工程师对齐时用层号说话：「这是 L4 的 Precision 问题」比「它老是记错事」高效得多。
工程视角——用它做架构决策：
- L1 先稳住循环骨架：明确停止条件、防死循环、给错误纠偏的余地，别让错误无衰减级联。
- L2 把 description 当一等公民来打磨，给清晰边界和示例；独立子任务上并行工具调用。工具接入优先走 MCP，避免重复造胶水。
- L3 按任务形态选工作流：线性选 Prompt Chaining，输入多样选 Routing，独立子任务选 Parallelization，动态分配选 Orchestrator-Workers，实时校验选 Supervisor-Workers。
- L4 按场景选记忆方案，并显式定义「什么值得记」；分清显式与隐式偏好，隐式推断要保守，宁可漏记不可错记。
- L5 上多智能体前先确认通信协议和错误三级处理（重试→降级→上报）；先证明单体真的装不下，再拆。
收口
五层不是五个零件，是一张故障定位图：下层不稳，上层全废；定位问题先问「塌的是哪一层」，再决定改 prompt、改工具、还是改架构。