第四章：多智能体协作与编排

第四章：多智能体协作与编排

本章要回答的三个问题

1. 两个 Agent 以上的协作，有哪几种对话拓扑，各自代价如何？
2. GroupChat 怎么让一群 Agent 自己决定谁先说、谁后说？
3. 对话什么时候该停，停了之后怎么拿到像样的结果？

为什么有这一章

前三章你有了会干活的单个 Agent，但多智能体的真正价值在"协作"。一个写代码的、一个审稿的、一个测错的，三个角色来回挑刺改稿，比一个全能 Agent 闷头写要稳得多——因为挑刺的人不需要自己写，写的人也知道有人兜底，职责分离带来的是整体质量的提升。这一章是全书枢纽，我们讲清顺序对话、自由对话、GroupChat 三种模式的取舍，以及终止条件这种容易被忽略却最常出 bug 的地方。模式选错，系统要么失控要么僵死；终止条件不设，两个 Agent 能聊到账单爆炸。可以说，前面三章都是在为这一章的"让多个角色真正协作"做准备：第二章让你懂 Agent 内部，第三章让你造出能干的成员，这一章把它们组织成一支真正配合的队伍。我们特别强调，群聊的坑九成在终止条件和发言选择策略——很多 demo 跑得欢，一上生产就因为没收敛而烧钱，根因都在这一章覆盖的内容。所以这一章不是"多个 Agent 一起聊天"那么轻松，它是把分布式协调的那套老难题（谁先说、意见不合怎么办、何时收工）用对话形式重新讲一遍。

读完能解决什么

读完这一章，你能拿到几项组装系统的关键能力：第一，你能根据任务特征选对对话模式——固定流水线用顺序、探索原型用自由、多角色轮转用 GroupChat，不再凭感觉；第二，你能搭一个 GroupChat 并配置 speaker_selection_method，让两个 Agent 轮转改稿而不是抢话；第三，你能设置 is_termination_msg 和 max_round，在恰当时机停下拉住成本；第四，你能解释 GroupChatManager 和 GroupChat 的关系，知道 Manager 只决定"谁说"、不保证"聊出结果"，从而主动设计收敛逻辑；第五，你能处理"意见不合"——用明确的牵头角色或投票策略替代自由发散。这是把前几章零件组装成系统的关键一步。我们特别强调：群聊的坑九成在终止条件，这一章会花最多篇幅讲它，因为这里省下的每一分钟都会在生产账单上加倍奉还。

各节分工表

先决条件

• 第三章已读，手里已有能挂工具的 Agent。
• 理解"一轮对话"指一次消息往返，便于理解 max_round。
• 准备接受"群聊不一定收敛"的现实，本章会教你怎么收。

知识点清单（可考核）

• 能写出一个 GroupChat 并让两个 Agent 轮转发言。
• 能设置 is_termination_msg 让某个关键词出现时停。
• 能解释 GroupChatManager 和 GroupChat 的关系。
• 能说清 speaker_selection_method 几种策略的差异。
• 能在终止后从最后一条消息提取结果。

一个必须建立的直觉

群聊不是"几个 Agent 开会讨论出最优解"的魔法，它更像一个没有主持人的圆桌——如果没人负责收敛，它会一直聊。Manager 只决定"谁说"，不保证"聊出结果"。所以你作为设计者，必须同时设计"怎么停"（4.4）和"人何时介入"（4.5）。忽略这两点，群聊要么烧钱要么无果。

本章常见误区

这一章的坑几乎都和"以为群聊会自动变好"有关。误区一：认为 GroupChat 像开会，几个 Agent 讨论着就能出最优解。它不是魔法，更像没有主持人的圆桌——没人负责收敛就会一直聊，Manager 只决定谁说，不保证聊出结果。误区二：忘记设终止条件，觉得"聊差不多自然停"。模型没有"差不多"的概念，不设 max_round 或终止消息，它就真能聊到上下文溢出。误区三：自由对话直接上生产，理由是"灵活"。自由对话难复现、难调试，只适合原型期，定型后应收成顺序或群聊。

与前面章的边界

第四章只解决"多个 Agent 怎么协作、何时停、人何时介入"，不进入生产化加固（第五章）、不碰具体业务落地（第六章）、不接社区与生态（第七章）。如果你在读本章时已经在设计监控指标或部署流水线，那是第五章和第六章的范畴，先把协作跑顺。

往下走到哪

能跑通协作后，第五章把它推向生产：性能、扩展、安全、调试。详见第五章。