前面 8 篇讲的是「一个 Agent 怎么用图跑起来」。这一篇进阶——多个 Agent 怎么协作。
单个 Agent 能做的事有限。复杂任务（比如「帮我调研一个技术方案并写报告」）涉及调研、分析、写作多个环节，一个 Agent 既要做调研又要写作，prompt 会臃肿、容易顾此失彼。多 Agent 协作的核心思路是分工：让每个 Agent 专精一件事，组合起来完成复杂任务。
为什么需要多 Agent
单 Agent 处理复杂任务的痛点：
- prompt 臃肿：一个 Agent 又要调研又要写作，prompt 里塞满各种规则，模型容易抓不住重点
- 上下文污染：调研产生的大量中间信息，和写作需要的，混在一个 context 里，互相干扰
- 难调试：出了问题，不知道是调研环节错还是写作环节错
多 Agent 解法：把任务拆成子任务，每个 Agent 专精一类，各自维护自己的上下文。
这和软件工程里「单一职责」一个道理：一个函数干太多事就拆成多个函数，一个 Agent 干太多事就拆成多个 Agent。
两种主流拓扑
多 Agent 怎么组织？LangGraph 里两种最主流的拓扑：
Supervisor（主管型）
一个「主管 Agent」负责分配和汇总，多个「工人 Agent」各干各的。任务来了，主管判断该给谁做，分下去；工人做完，结果回到主管；主管决定继续分还是收尾。
像公司里的「经理-员工」结构：经理不亲自干活，但决定谁干、汇总结果。适合有明确编排逻辑的任务——主管知道整个流程该怎么走。
Swarm（群组型）
没有固定主管，Agent 之间直接传递控制权。一个 Agent 做到一定程度，判断「该交接了」，就把控制权（和当前 state）交给下一个合适的 Agent。
像接力赛：每个 Agent 跑自己那一棒，跑完把接力棒交给下一个人。适合流程是涌现的——谁接手由当前情况决定，而不是预设的。
两种拓扑怎么选
| 维度 | Supervisor 主管型 | Swarm 群组型 |
|---|---|---|
| 控制方式 | 中心化，主管调度 | 去中心化，Agent 互相交接 |
| 适合 | 编排逻辑明确、可预设 | 流程涌现、动态决定下一步 |
| 调试 | 主管处集中看，好排查 | 分散，追踪靠 state 流转 |
| 典型场景 | 客服分流、报告生成 | 多步探索、开放任务 |
一个简单判断：如果你能在脑子里画出整个流程图（谁先谁后），用 Supervisor；如果流程要靠 Agent 自己临场决定，用 Swarm。
共享 State：协作的媒介
无论哪种拓扑，多 Agent 协作的底层都是共享 state。所有 Agent 读写同一个 state（上一篇 Reducer 讲的合并规则在这里至关重要），通过 state 传递信息。
这就是为什么第 10 篇强调「state 是公共黑板」、第 13 篇强调「reducer 决定合并」——这两个在单 Agent 里显得抽象的概念，在多 Agent 协作里直接决定能不能正确协作。多个 Agent 并发写同字段，没有清晰的 reducer，结果就乱了。
子图：把复杂图模块化
当 Agent 数量多了，整张图会变得很大、很难维护。LangGraph 支持子图（subgraph）：把一组相关的 Agent 和节点封装成一个子图，对外暴露统一接口。
这就像代码里的「函数封装」——把一组相关逻辑包成函数，主流程只调用函数，不用关心内部。多 Agent 系统里，可以把「调研」封装成一个子图（内部可能有检索 Agent、总结 Agent），主图里只看到一个「调研模块」。
收束：多 Agent 是单 Agent 的自然延伸
这一篇讲了多 Agent 协作：
- 单 Agent 处理复杂任务有 prompt 臃肿、上下文污染、难调试的痛点
- 两种主流拓扑：Supervisor（主管调度）和 Swarm（互相交接）
- 底层都靠共享 state 协作，reducer 是正确性的保障
- 子图可以把复杂的多 Agent 系统模块化
到这里，Phase 2（LangGraph 状态机）接近尾声。下一篇做一个 Phase 2 的实战收束——把这些概念串成一个完整的 Agent 例子，作为 Phase 2 的句号，并衔接 Phase 3 的 Agent 应用层。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
