群聊式多智能体（Group Chat）是 2026 年最被高估也最容易翻车的协作形态。它看起来像一个团队，运行起来像一个凌晨三点所有人都在回复每条消息的 Slack 频道。一份针对真实生产系统的实测揭示了一个反直觉结论：**绝大多数多智能体质量回归并不来自模型本身，而来自"谁该发言"这个看似琐碎的决策**。FutureAGI 的生产级群聊追踪明确指出，speaker-selection 逻辑是质量回归的头号来源——财务智能体抢答了法律问题、reviewer 在工具执行者拉取证据之前就开口、同一个 agent 被连续点名三轮。本文以 AutoGen GroupChat、LangGraph Supervisor、OpenAI Swarm handoff 三类主流栈为载体，把"发言权"拆成五种可实测的范式，并用真实 token 与轮次数据告诉你哪一式该用、哪一式是灾难。 ## 一、五式总览：发言权范式多维度对比 | 范式 | 决策者 | 每轮路由成本 | 5 智能体平均收敛 | Token 量级 | 失效模式 | |------|--------|-------------|-----------------|-----------|---------| | 自由混战式（auto manager） | manager LLM 自由文本选人 | 1 次完整 LLM 调用 | 20–60 轮 | 80K+ | 死循环、漂移、爆预算 | | 轮流坐庄式（round-robin） | 固定顺序表 | 0（查表） | 取决于顺序设计 | 15–25K | 无关者发言、关键者靠后 | | 中心点名式（supervisor 确定性路由） | 结构化状态 + 路由函数 | 0（多数情况） | 5–9 轮 | 18K | 监督者瓶颈 | | 广播聚合式（broadcaster fan-out） | 无"轮次"概念，全员并行 | 0 | 1 轮 + 综合 | 6K（最低） | 无法深度迭代 | | 合同竞标式（contract net） | 智能体竞标 + 声誉裁决 | 1 轮竞标开销 | 3–6 轮 + 竞标 | 22K | 竞标博弈（过度承诺） | 这张表的左上角是大多数团队的起点，右下角是大多数团队永远到不了的终点。下面逐一深拆。 ## 二、自由混战式：AutoGen auto manager 的隐性灾难 这是 AutoGen GroupChat 的**默认配置**，也是 90% 群聊翻车案例的根源。机制很简单：每轮结束，框架把完整对话历史塞进一个 manager prompt，让 LLM 输出下一个发言者的名字。问题在于这个 prompt 会随轮次线性膨胀。实测数据显示，4 个智能体跑到第 30 轮时，manager prompt 已经超过 30K token，manager 开始**幻觉选人**——它记不清自己的选择策略，转而按"谁上一次说话最客气"来点人。 一个真实客户案例更具说服力：5 个智能体组成的研究小组，平均要跑 **41 轮**才收敛，其中 manager 有 **22% 的概率连续 3 轮点同一个智能体**。这是纯粹的浪费——被重复点名的智能体拿不出新东西，只会把上一轮的话换个说法再说一遍。对应的代码长这样： ```python from autogen import GroupChat, GroupChatManager gc = GroupChat( agents=[researcher, critic, writer, fact_checker], messages=[], max_round=20, # 唯一的救命稻草：硬上限 speaker_selection_method="auto", # ← 灾难源头：每轮一次 manager LLM 调用 ) ``` **变现评估**：这一式没有任何训练营价值，它的唯一作用是作为反面教材。如果你在卖"多智能体实战课"，把它放在第一节课当靶子打，能立刻建立专业可信度——因为学员自己跑出来的就是这副模样。优点的诚实版本：上手最快，demo 效果最唬人，所以它是绝大多数教程的默认起点，也是绝大多数生产事故的起点。 ## 三、轮流坐庄式：round-robin 的伪确定性陷阱 把 `speaker_selection_method` 改成 `"round_robin"`，灾难立刻消失一半——因为选人不再需要 LLM。顺序是固定的：A→B→C→D→A→B……每一轮谁发言完全可预测、可调试、零 token 开销。这一式看起来很美，直到你意识到它的致命假设：**所有智能体在任何时刻都有同等发言价值**。 现实是，研究任务的正确节奏是 researcher 连发三轮、writer 一轮不发、fact_checker 在 researcher 之后立刻补位。round-robin 强行让 writer 在 researcher 还没出结果时就开口，writer 只能编一段占位符；又强行让 fact_checker 在没有原始证据时"先质疑着"，于是批评变成了无的放矢。它的失效不是成本问题，而是**语义错配**——对的人在对的时机没拿到话筒。 ```python gc = GroupChat(agents=[...], speaker_selection_method="round_robin", max_round=12) ``` 这一式的真正用途是**闭环流水线**：当任务本身有天然的固定工序（intake→retrieval→review→synthesize），且每一步都依赖上一步输出时，round-robin 就是零成本的最优解。离开这个前提，它只是"看起来比 auto 更负责任"的安慰剂。**变现评估**：可作为"流水线型多智能体"教学单元的标准答案，但必须严格框定在有序工序场景内，否则就是在卖一个会错配话筒的方案。 ## 四、中心点名式：supervisor 确定性路由，O(N) 降到 O(1) 这是 LangGraph Supervisor 模式的思维内核，也是生产系统中最被低估的杠杆。它的核心动作不是"让 supervisor 用 LLM 选人"，而是**把选人逻辑从 prompt 里搬到代码里**。实测结论很直接：把发言选择从"manager 看完整 transcript 做自由文本决策"降级为"读结构化状态对象、跑一个 Python 函数返回名字"，能把 speaker-selection 问题从 O(N) 的 LLM 推理压缩到 O(1) 的字典查找。 关键细节大多数人会错过：**supervisor 的 prompt 永远不应该看到完整对话历史**。给它一个结构化状态对象——当前任务、已完成子任务、待处理认领、上一个 worker 输出摘要——并在轮次之间确定性地更新这个状态。supervisor LLM 只在"路由函数无法编码的推理"发生时才被调用。 ```python def deterministic_route(state) -> str: # 零 LLM 调用：纯状态驱动 if state["pending_subtasks"] and not state["retrieval_done"]: return "researcher" if state["retrieval_done"] and not state["fact_checked"]: return "fact_checker" if state["fact_checked"] and state["final_answer"] is None: return "writer" return "supervisor" # 兜底 ``` 这一式的缺点是**监督者瓶颈**：所有 worker-to-worker 通信被禁止，A 需要 B 的东西必须经 supervisor 中转，于是 supervisor 成了吞吐量天花板。实测中，supervisor 单次 LLM 调用若耗时 3 秒、20 个 worker 在排队，分解吞吐上限就锁死在约 6.7 任务/秒。**变现评估**：这是最值得做成训练营主推方案的一式——它有清晰的"前后对比"（auto vs 确定性路由的 token 账单差 5–8 倍）、有可量化的工程动作（状态对象设计、路由函数编写）、有明确的晋升路径（从确定性路由到 supervisor LLM 兜底）。企业客户最容易为这一式买单。 ## 五、广播聚合式：最便宜、最被低估的一式 当团队以为自己想要"群聊"时，80% 的情况他们真正想要的是 broadcaster。机制极简：一个控制器把同一个 prompt 并行发给 N 个 worker，每个返回一个候选答案，一个综合步骤（LLM 调用或确定性合并）选出或拼合最终结果。**没有一个 agent 会和另一个 agent 说话**。这是所有范式里最便宜、最快的：5 个 agent 的典型成本仅约 6K token，一轮就完成。 它最适合的场景是**观点多样性**：投票、陪审团、并行研究、假设生成。50 个研究 agent 可以并行探索 50 个假设，无需任何中央协调者规划搜索路径。它的硬限制同样明确：**子任务之间不能有依赖**。一旦 worker B 需要 worker A 的输出才能开始，broadcaster 就退化成串行流水线，失去全部并行优势。 ```python # 伪代码：broadcaster 的核心是一次性 fan-out candidates = await asyncio.gather(*[ worker.run(task) for worker in crew # 全员并行 ]) final = synthesize(candidates) # 综合步骤 ``` **变现评估**：这是被严重低估的"多智能体入门级产品"。许多 SaaS 包装的"AI 投票决策""多模型共识"本质就是 broadcaster 加一层 UI。它的训练营价值在于打破"多智能体=复杂协调"的迷思，让学员意识到 80% 的"群聊需求"用一个 gather 调用就能解决，省下的协调复杂度才是真正的护城河。 ## 六、合同竞标式：contract net 与声誉裁决 继承自 1980 年代分布式 AI 研究的合同网协议（Contract Net Protocol），是动态任务分配最干净的范式。流程是：supervisor 宣布一个任务，worker 们各自竞标（附带成本估算和能力声明），supervisor 把合同授予一个 worker，该 worker 完成后汇报。它优于固定 supervisor 的地方在于——**你不需要硬编码"哪个 agent 处理哪个子任务"**。新 agent 注册自己的能力后，自动开始接收相关任务。 代价是**竞标博弈（bid gaming）**：agent 会过度承诺以赢得自己交付不了的合同。生产级做法是引入一个随合同结果更新的声誉分数（reputation score），让历史交付差的 agent 在后续竞标中自然被压价。这一式的收敛表现是 3–6 轮加一轮竞标，token 量级约 22K，介于 supervisor 和 broadcaster 之间。 ```python def award_contract(task, bids, reputations): # 综合报价与声誉，避免纯低价中标 scored = [ (b.agent, b.cost / reputations.get(b.agent, 0.5)) for b in bids ] return min(scored, key=lambda x: x[1])[0] # 选性价比最高 ``` **变现评估**：这是面向"开放生态"场景的高级范式——当你想做一个 agent 可以即插即用注册的 marketplace 时（这正是 2026 年若干 Agent 交易平台的方向），contract net 是底层原语。它的训练营价值偏中高级，适合作为"动态多智能体调度"模块的核心，但需要配套声誉系统才完整，工程量较大。 ## 七、横切防线一：认领锁，消灭"静默重复劳动" 发言权解决"谁来说"，认领锁解决"谁在偷偷干同一件事"。这是 thread-transfer 实测中最被忽视的失效模式——**静默认领冲突**：两个 agent 都开始做同一个子任务却互不知情，你为重复工作付两次钱，再付第三次钱请一个仲裁 agent 选出赢家。认领锁把数据库行锁的模式搬到了 agent 工作上：agent 开始子任务前，先对一个具名资源上锁；锁被占就等待或请求 supervisor 重新分配。 ```python import redis r = redis.Redis() TTL = 300 # 2× 预期任务时长，崩溃 agent 不留永久锁 def acquire(agent_id, resource): return r.set(f"lock:{resource}", agent_id, nx=True, ex=TTL) def work(agent_id, resource): if not acquire(agent_id, resource): return ask_supervisor_reassign() # 锁被占，不自作主张 try: return do_task(resource) finally: r.delete(f"lock:{resource}") ``` 实现极轻：一个键值存储（Redis，或单进程里的 dict）映射资源 ID 到 agent ID，带 TTL。TTL 设为预期任务时长的 2 倍，确保崩溃的 agent 不会留下永久锁。这条防线与发言权范式正交，五式中任何一式都应叠加它。 ## 八、横切防线二：三层终止与循环检测 每个多智能体系统在运行前必须回答一个问题：**它什么时候停？** Demo 几乎从不回答；生产系统必须回答。实测经验值很硬：**90% 设计良好的多智能体任务在 10 轮内收敛，如果你跑到第 15 轮，你就已经在循环里了**。三层终止缺一不可： - **第一层 语义完成**：结构化检查——状态对象的 `final_answer` 字段是否非空？所有 worker 是否都返回了？永远不要把"LLM 自我宣告我觉得做完了"作为唯一停止条件。 - **第二层 轮次/Token 硬上限**：最多 20 轮、最多 50K token。命中任一即停，返回部分输出或显式失败。这道闸能挡住那张 200 美元的失控账单。 - **第三层 循环检测**：哈希最近 N 个 agent 输出，相同哈希出现 2 次以上、或嵌入向量余弦相似度 > 0.92 的近重复出现，即判定循环，强制换人或注入"综合并决策"指令。 ```python from sklearn.metrics.pairwise import cosine_similarity recent = state["outputs"][-5:] sim = cosine_similarity(embed(recent)) if (sim > 0.92).sum() > len(recent): # 近重复 → 在循环 inject_synthesize_instruction() # 强制综合或中断 ``` 循环检测只需约 20 行代码，但它在第一次触发时就回本。太多团队跳过它，理由是"我们的 prompt 不会循环"——结果它们循环了。 ## 九、横切防线三：角色契约，从提示工程到接口设计 这是可靠性领域最大的单一杠杆。冲突的根源不是分歧，而是**职责重叠**。给每个 agent 一份"契约"而非一段 system prompt，契约写明四件事：**Scope**（这个 agent 允许碰什么问题——"研究 agent"不是 scope，"为当前研究任务抓取并总结网络来源；绝不写最终输出；绝不批评其他 agent"才是）；**Inputs**（期望的 schema，离谱输入直接拒绝而非瞎猜）；**Outputs**（严格 JSON 形状，不准散文、不准思考过程、不准"这是我做的"——纯数据）；**Termination**（什么条件下报告 DONE 并停止）。 契约由 orchestrator 强制执行：agent 返回的 JSON 若不合 schema，orchestrator 直接拒绝并重试或升级，下游 agent 永远看不到畸形输出。这一步把你的工作从"提示工程"推进到"接口设计"，是 thread-transfer 实测里"single biggest reliability lever"。它的代价是前期要为每个 agent 定义并校验 schema，收益是故障从"模糊的 prompt 行为漂移"变成"清晰的 schema 违约"，可观测、可重试、可告警。 ## 十、生产级参考架构与成本对比 把上述五式与三道防线组装起来，一份生产级骨架长这样：supervisor + 结构化状态对象（非 transcript）；3–7 个 worker，每个带严格角色契约与 JSON schema 校验；确定性路由函数读状态返回下一个发言者，supervisor LLM 仅在路由函数无法编码时介入；Redis 认领锁带 5 分钟 TTL；三层终止（任务完成 + 20 轮上限 + 50K token 上限 + 循环检测）；Langfuse/LangSmith 追踪，每轮一个 span，团队频道钉一个消息图仪表盘。 成本对比极具冲击力：同一项 5-worker 研究综合任务，生产级架构约 12–22K 输入 + 4–8K 输出、每对话 0.30–0.60 美元（Sonnet 4）；朴素群聊则 80K+ 输入 + 15K+ 输出、每对话 2.50 美元以上，外加 15% 的循环率让平均值再翻倍。**架构在你跑完前 50 个对话时就已回本**。一个值得注意的结论：框架选择远没有人们想得那么重要——AutoGen、LangGraph、CrewAI 甚至手写 orchestrator 都能用大致相同的成本实现这套模式，胜出的框架只是"其状态模型最贴合你团队心智模型"的那个。图思维的团队读 LangGraph 最顺，角色思维的团队读 CrewAI 最顺，路由原则对所有框架一视同仁。 ## 架构图：生产级发言权决策管线 ```mermaid flowchart TD U[用户任务] --> S[结构化状态对象
task / pending / completed / claims] S --> R{确定性路由函数
零 LLM 调用} R -->|规则可编码| W1[Worker A] R -->|规则可编码| W2[Worker B] R -->|需推理| SL[Supervisor LLM 兜底] SL --> W3[Worker C] W1 --> L{认领锁
Redis TTL} L -->|获取成功| EX[执行子任务] L -->|已被占用| RR[请求重新分配] EX --> CV[JSON Schema 校验] CV -->|合规| UP[更新状态] CV -->|违约| RT[拒绝 / 重试 / 升级] UP --> LD{循环检测
hash / cosine>0.92} LD -->|无循环| T1{任务完成?} LD -->|检测到循环| BR[强制综合或中断] T1 -->|是| F[final_answer] T1 -->|否| T2{轮次<20 且 token<50K?} T2 -->|是| S T2 -->|否| H[硬上限熔断] style R fill:#e8f5e9 style L fill:#fff3e0 style LD fill:#fce4ec style T2 fill:#e3f2fd ``` 这张图的核心信息：发言权不是一次 LLM 决策，而是一条由确定性路由、认领锁、契约校验、循环检测、双层终止串成的管线。绿色节点是省钱的关键（零 LLM 调用），橙色节点是防重复劳动的闸，粉色节点是防死循环的闸，蓝色节点是防失控账单的闸。去掉任何一道闸，系统都会在某个边界条件下塌缩。 ## 失效模式 → 防御层映射 ```mermaid flowchart LR subgraph FM[四大发言权失效模式] A1[论证死循环
A提议-B批评-A辩护] A2[回声室
三人轮流附和] A3[静默认领冲突
两人同做一事] A4[管理者漂移
manager 忘记策略] end subgraph DEF[防御层] D1[确定性路由
消灭 A4] D2[认领锁
消灭 A3] D3[循环检测+综合注入
消灭 A1 A2] D4[轮次/Token 硬上限
兜底全部] end A1 --> D3 A2 --> D3 A3 --> D2 A4 --> D1 D1 -.兜底.-> D4 D2 -.兜底.-> D4 D3 -.兜底.-> D4 ``` 映射关系说明了一个关键判断：**四种失效模式里只有一种是"推理失败"（论证死循环的早期阶段），其余三种本质都是"协议失败"**。agent 本身没问题，是它们之间的协议坏了。这就是为什么"调 prompt"几乎从不解决群聊问题——你调的是模型，坏的是协议。 ## 场景化推荐方案 **如果你在做客服分流（route→resolve→verify）**：用中心点名式 + 确定性路由。意图分类器决定路由，监督者只在意图模糊时介入。这是 τ-bench 多轮客服（零售场景前沿上限约 70%）最稳的架构。 **如果你要做多观点决策/投票/假设生成**：用广播聚合式。不要被"群聊"诱惑，你要的是并行 + 综合，broadcaster 一轮搞定，成本仅为其他范式的 1/3。 **如果你要做长程研究（retrieval→fact-check→write 有依赖）**：用中心点名式 + 认领锁 + 三层终止。这是 41 轮灾难的正解，典型 5–9 轮收敛。 **如果你要做开放的 agent marketplace（动态成员、即插即用）**：用合同竞标式 + 声誉系统。新 agent 注册能力即自动接活，contract net 是唯一原生支持动态拓扑的范式。 **如果你现在就有一个跑在生产里的群聊系统**：按这个顺序排障——拉最近 100 个对话画轮次直方图，长尾超过 15 轮即有循环问题；算每对话 token 与单 agent 基线之比，超过 4× 即路由在烧钱；检查 manager prompt 是否吃完整 transcript，是的话在下个 sprint 前换成结构化状态对象。这三步能在一小时内完成，且能定位 80% 的群聊病根。 一句话收尾：群聊式多智能体的胜负不在模型多强、agent 多多，而在"谁言"这件事是被一次昂贵的 LLM 臆测决定，还是被一条确定性的、带锁、带终止、带循环检测的管线决定。前者烧钱且不可调试，后者便宜且可量产——发言权，才是多智能体真正的系统边界。 ## 参考来源 1. [Supervisor vs Swarm Architecture — LangGraph 101 DeepWiki](https://deepwiki.com/langchain-ai/langgraph-101/6.1-supervisor-vs-swarm-architecture) — LangGraph 中心化监督者与分布式 swarm 两种协调模式的技术对比与实现细节 2. [Designing Multi-Agent Group Chat Systems: Routing, Conflict, and Coordination — Thread Transfer](https://thread-transfer.com/blog/2026-06-17-multi-agent-group-chat-routing-design/) — 含 5-agent 41 轮收敛、22% 重复点名、四失效模式与生产级参考架构的实测数据（2026-06） 3. [Agent Orchestration Patterns: Swarm vs Mesh vs Hierarchical vs Pipeline — DEV Community/gurusup](https://dev.to/jose_gurusup_dev/agent-orchestration-patterns-swarm-vs-mesh-vs-hierarchical-vs-pipeline-b40) — 五大编排模式的吞吐量、单点故障、可扩展性与失败边界分析 4. [Group Chat Orchestration Definition — FutureAGI (2026)](https://futureagi.com/glossary/group-chat-orchestration/) — 生产级群聊编排定义，指出 speaker-selection 为质量回归首要来源，含 τ-bench / GAIA 基准 5. [Group Chat with Customized Speaker Selection Method — AutoGen 官方文档](https://microsoft.github.io/autogen/0.2/docs/notebooks/agentchat_groupchat_customized/) — AutoGen speaker_selection_method 的 auto/manual/random/round_robin/custom 五种模式官方说明 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。