第五章 多智能体协作：单体的天花板与团队解法

第五章 · 多智能体协作：单体的天花板与团队解法

本章要回答的三个问题：一个智能体配齐了工具、记忆、规划，还有什么办不成的事？多个智能体之间靠什么把话说清楚、不出误会？LangGraph、AutoGen、CrewAI 这些框架各自主张什么，什么时候该借谁的力？

为什么会有这一章

前四章的组件齐备之后，最常见的错觉是"万事俱备"。真实项目里很快会撞上新天花板：工具注册到二十个，模型开始选错；一份任务里既有写代码又有查资料又有审风格，单一角色的系统提示词臃肿到互相打架；长链任务的误差在同一个上下文里滚雪球。这些症状指向同一个方向——上下文与角色的过载。多智能体不是更高级的玩具，而是把"一个人干所有活"拆成"一支分工明确的队伍"的工程手段。

同时要泼一盆冷水：多智能体的通信成本、误差放大与调试复杂度都是实打实的税。本章一半篇幅在讲怎么组队，另一半在讲什么时候坚决不组——后者往往更有价值。

本章全景

图：协作拓扑三形态——主管型、流水线、辩论型

读完能解决什么

• 拿到一个任务能判断"单体够用还是需要组队"，并说出判断依据，而不是"显得高级就上多智能体"。
• 能为一支智能体队伍定消息协议：信封字段、任务派发格式、结果回传格式、轮次与终止规则。
• 能对照 ReAct、Reflexion、AutoGPT 式、多智能体四类架构模式，说清各自的解决问题与代价。
• 能在 LangGraph、AutoGen、CrewAI 之间做出有依据的选型，或决定干脆不用框架。

各节怎么分工

先决条件

• 读完第 2 章与第 4 章：每个智能体本质上都是"循环 + 工具 + 规划"的一个实例，本章把它们并联起来。
• 5.2 节的协议代码用到基本的数据类概念，其他无额外前置。

往下走到哪

队伍能协作之后，第六章解决"见识"问题：RAG 让整支队伍共享同一份最新事实，工具生态则让每个人都能调用现成的能力，不必从零造轮子。

一条实用的小队起步路径

如果决定组队，建议从"两员编制"起步：一个执行者加一个评审者。这个最小配置能验证协议、总线、交接的全部机制，成本却只有大型编队的零头。跑顺之后再按需扩编——扩编的次序也有讲究：先加"专业分工"（新增一个领域的执行者），后加"流程岗位"（增加审校、质检环节），最后才考虑辩论这类重型机制。反过来从大编队往回砍的调整，几乎总伴随着协议重构，代价高得多。

另外提醒一句调试心态：多智能体系统的初期故障里，大头不是"哪个智能体不聪明"，而是"消息在谁那里丢了字段、谁读错了谁的产出"。5.2 节的协议纪律就是为了把这些机械故障一次性消灭——先让队伍把话说清楚，再去苛求它说得聪明。

本章与相邻章节的关系

多智能体不是孤立的章节，它站在前面几章的地基上，也向后面两章输出需求。向前看：每个队员本质是一个第 2 章的循环实例，队员之间的任务书就是 4.1 节计划结构的跨实体版本——派发协议写得好的团队，几乎都是先在单体里把计划结构写清楚了。向后看：协作带来两个新需求，一是整支队伍需要共享同一份事实源（否则各队员对世界的认知会分叉），这正是第 6 章 RAG 的事；二是队伍的动作面变大，越权与误伤的组合风险上升，第 7 章的护栏在多智能体场景要按"队内传播"重新评估覆盖面。带着这张关系图读本章，很多设计取舍会自然浮现：协议为可追溯服务，拓扑为控制流服务，而所有设计最终都为第 7 章的可治理性服务。