上一章我们讲了给一个智能体用 MCP 接入外部工具的方法。到此为止，一个具备"头·工具·记忆·循环"的自主智能体已经能跑起来。可一旦活儿变大，把一切都塞进一个智能体的设计，总会在某处崩掉。本章要在不依赖具体框架的概念层面，梳理把角色分开、用多个智能体来解的"多智能体设计"，以及它协作的思路（A2A：Agent-to-Agent）。
目标是能判断"何时·如何分，才会变强"
一个智能体不够用的时候
一个智能体，简单、通透、行为也好追——正因如此，先用一个来做才是正解。问题出在往里不断加角色的时候。"调查、撰写、复查、翻译、还要发布……"把一堆职责塞进一条提示词，过了某个临界点，精度会突然开始下滑。
原因主要有 3 个。①指令变长、变含糊（写得越是这个那个，模型越拿不准该优先哪个）。②上下文膨胀（连无关信息也一并抱着，关键指令被稀释）。③工具太多（选项越多，越容易选错工具）。塞得过满的一个智能体，就好比"让一个人身兼数职、忙到打结的职场"。
💡 换个思路。 不再一味把一个智能体做聪明，而是切换到"让多个各自专注单一角色的小智能体协同"。这是多智能体设计的出发点。与人类组织里分工做事同理，把各自的职责划得越窄越明确，整体就越稳定。
不过——分了未必就一定更好。分工总伴随协调的成本。所以本章的真正主题，不只是"怎么分"，更在于"到底该不该分"的判断。先看过代表性的 3 种形态，再进入判断标准。
3 种基本模式
多智能体的构成可以画出无数种，但实务中反复出现的骨架，可归结为3 种。把这 3 种组合起来，多数构成都能说明清楚。先逐个抓住各自的角色与适用·不适用。
父方（编排者）制定整体计划，把任务分派给子方（工作者）执行，再汇集结果整合。子方彼此不相识，只看父方。中央集权、易于控制是其长处。
适合场景：任务可拆分、想并行跑的时候。
把工序排成一列，把前一个智能体的输出，作为下一个智能体的输入依次传递。比如"调查 → 撰写 → 校对"。每一段只担一道工序，职责清晰、也便于验证。
适合场景：步骤线性、阶段已定的时候。
像"调查担当""代码担当""复查担当"那样，备好各有专长的专家智能体，视情况点名调用。各自的指令与工具都能收窄，专业度随之提升。
适合场景：所需能力按领域差异很大的时候。
这 3 种并不互斥。真实系统里，常会出现"编排者统领一群专家型工作者，其中一个又是流水线"这样的嵌套结构。先定好最外层的一个骨架，只在需要的地方于内层换用另一种模式——这种垒法最好驾驭。
📊 拿不准就从①开始。 3 种里最通用的是编排者＋工作者。父方在中央握着规划与整合，易于控制，是许多多智能体构成的基本形。模式整体的梳理可参考《什么是多智能体》，作为系统的理解则看《什么是多智能体系统》。
该分的时候／不该分的时候
了解了模式，就容易见什么都想分。可分工总要付"协调的成本"——智能体之间传信息、对接、等待的功夫。只有分了得到的收益超过这份协调成本时，多智能体才是正解。先把两边并排看看。
- 能并行：让独立的子任务同时跑，缩短时间
- 需要专业：按领域收窄指令·工具，精度提升
- 探索面广：想分头去找多个视角或候选
- 想隔离上下文：按角色切开语境，防止串扰
- 本就简单：一个能搞定的处理，被平白复杂化
- 成本增加：智能体越多，LLM 调用·令牌越堆越高
- 协调沉重：交接与等待的功夫，吃掉分工的收益
- 强顺序依赖：强烈依赖前一步的结果，几乎没有并行余地
⚠️ 先问"一个够不够"。 多智能体很强大，但不是开局就选的东西。一个 → 打磨提示词 → 加工具 → 还不够再拆分，逐级升级是铁则。复杂度，等确认过"眼下这一个是不是真到了极限"再加。拆分随时事后都能做。
一个实务上的标尺："把这个角色讲给人类同事听时，能不能自然地写进一份人的职务说明书"，可以想象一下。若一个头衔就能写下，那还够用一个。当你想把"这是调查的人、这是撰写的人"分成不同的人时，就是该考虑拆分的时机。判断的全貌也可一并参考《多智能体系统的做法》。
智能体间的协作（A2A）
决定要分之后，下一个设计课题是"智能体彼此如何交换信息"。放到人类团队里，相当于定好交接文档的格式与汇报的规则。这里一含糊，个体再优秀，整体也咬合不上。协作要抓的点主要有 2 个。
定好传什么、以什么格式。把"任务的指令·所需的输入·期望的输出格式"做成明确的约定，接收方就不迷茫。比起自由文的甩锅，结构化的交接更稳定。
把多份输出汇成一份的工序。定好由谁负最终责任来整合。返回结果相互矛盾时的优先级，以及汇总方式（摘要·比对·多数决），也要纳入设计。
把"智能体彼此分担角色、协同"这一思路，更加标准化地去处理的动向，就是A2A（Agent-to-Agent）。上一章的 MCP 是连接"智能体↔工具／数据"的约定，与之相对，A2A 是连接"智能体↔智能体"的约定——请把它理解为一套通用作法：了解对方智能体能做什么、向其委托任务、接收结果。
💡 MCP 与 A2A 对照着记。 粗略地说，MCP＝给智能体接上"手"，A2A＝把智能体彼此"连起来"。前者是工具·数据连接，后者是协作的作法。先作为概念抓住就够，具体协议在后续章节也会触及。更详细的可看《什么是 A2A 协议》。与上一章的《MCP 与工具连接》对读，区别会更清楚。
重要的不是记住协议的名字，而是"协作需要明确的约定"这一设计姿态。谁持有哪个任务、以什么输入开始、返回什么、失败了退给谁——先把这些约定定好，才是规模变大也不崩的系统地基。
上下文与成本的管理
多智能体最大的实务风险，是上下文与成本的膨胀。智能体越多、彼此传信息越频繁，各智能体所抱的上下文就越胖，LLM 的调用次数与令牌量也越堆越高。放任不管，系统就容易变慢·变贵·变不稳。在设计阶段就把缰绳握好。
给子方只传这项任务所需的量。别把全历史原样灌进去。无关的语境也会拉低精度。
长结果先摘成要点再往下传。递交的是"结论与依据"，而非原始日志。
给同时跑的子方数量设上限。无限增多，会被成本与速率限制拖垮。
重推理的父方与简单作业的子方，用不同规模的模型。别全都上最高档模型。
其中"收窄要传的信息"是效果尤大的设计判断。若是编排者＋工作者型，父方持有全局，但只把切出来的任务与最小限度的输入传给子方。子方所抱的上下文越小，精度越高、成本越低。请把它理解为，前几章提到的上下文工程思路，被扩展到了多个智能体上。
⚠️ 成本按"体数 × 步数"起作用。 每多一个智能体，那一份的调用就按循环圈数叠加上去。体数越多，每一体的浪费在整体上就翻好几倍，要留意。并行数的上限，与各智能体的步数上限（该停之处），都要一开始就定好。这套"用了多少"的度量，衔接到下一章的可观测性。
坑与在设计上的防法
多智能体有单体不会出现的特有失败。它们都不该靠运行时碰运气，而要靠设计事先防住。把代表性的 3 个及其对策抓一抓。
多个智能体重复干同一件事；或"归谁管"含糊，谁都不干。
防法：把各智能体的职责不重叠·不遗漏地切开，做到边界能用一句话说死。
A 推给 B、B 又推给 A……互相把活儿甩来甩去，迟迟不完·反复同样的往来。
防法：务必设终止条件与往返·步数的上限。让中央（父方）握最终判断，就不易失控。
一个智能体的失败或错误输出，原样流向下一个，拖停整体·造出错误的成果。
防法：交接前验证输出，并定好失败时的兜底（重试·替代·上报人工）。
3 个共通的教训是，"边界·终止条件·验证"要在写代码之前先定好。谁负责什么（边界）、何时停下（终止条件）、交出去前确认什么（验证）。把这 3 点织进设计，多智能体特有的麻烦，大半就能防于未然。
📊 "看不见就修不了"。 这些失败，只有在"哪个智能体做了什么"事后可追的状态下，才第一次察觉得到。多个智能体一掺和，"何处发生了什么"比单体更难看清——正因如此，下一章的评估与可观测性，在多智能体里更加重要一层。
- 塞得过满会掉精度。用把角色划窄的小智能体协同来解。
- 基本模式有 3 种 ― 编排者＋工作者·流水线·角色分工，可嵌套。
- 需要并行·专业·广探索时才分。简单就保持一个。先问"一个够不够"。
- 协作用明确的约定（A2A＝连接智能体彼此的作法）。上下文与成本要收窄管理。
- 特有陷阱（重叠·互推·连锁失败）靠边界·终止条件·验证在设计上先定好来防。
多个智能体一动起来，接下来需要的是"度量它是不是真的跑得好，并把运行过程可视化"。下一章《评估与可观测性》里，我们来学度量智能体质量、让内部动作可追的方法。