谁言即乱：多智能体发言权五式

群聊式多智能体（Group Chat）是 2026 年最被高估也最容易翻车的协作形态。它看起来像一个团队，运行起来像一个凌晨三点所有人都在回复每条消息的 Slack 频道。一份针对真实生产系统的实测揭示了一个反直觉结论：绝大多数多智能体质量回归并不来自模型本身，而来自"谁该发言"这个看似琐碎的决策。FutureAGI 的生产级群聊追踪明确指出，speaker-selection 逻辑是质量回归的头号来源——财务智能体抢答了法律问题、reviewer 在工具执行者拉取证据之前就开口、同一个 agent 被连续点名三轮。本文以 AutoGen GroupChat、LangGraph Supervisor、OpenAI Swarm handoff 三类主流栈为载体，把"发言权"拆成五种可实测的范式，并用真实 token 与轮次数据告诉你哪一式该用、哪一式是灾难。

一、五式总览：发言权范式多维度对比

这张表的左上角是大多数团队的起点，右下角是大多数团队永远到不了的终点。下面逐一深拆。

二、自由混战式：AutoGen auto manager 的隐性灾难

范式	决策者	每轮路由成本	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 GroupChat 的默认配置，也是 90% 群聊翻车案例的根源。机制很简单：每轮结束，框架把完整对话历史塞进一个 manager prompt，让 LLM 输出下一个发言者的名字。问题在于这个 prompt 会随轮次线性膨胀。实测数据显示，4 个智能体跑到第 30 轮时，manager prompt 已经超过 30K token，manager 开始幻觉选人——它记不清自己的选择策略，转而按"谁上一次说话最客气"来点人。

一个真实客户案例更具说服力：5 个智能体组成的研究小组，平均要跑 41 轮才收敛，其中 manager 有 22% 的概率连续 3 轮点同一个智能体。这是纯粹的浪费——被重复点名的智能体拿不出新东西，只会把上一轮的话换个说法再说一遍。对应的代码长这样：

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 在没有原始证据时"先质疑着"，于是批评变成了无的放矢。它的失效不是成本问题，而是语义错配——对的人在对的时机没拿到话筒。

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 只在"路由函数无法编码的推理"发生时才被调用。

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 就退化成串行流水线，失去全部并行优势。

# 伪代码：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 之间。

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 重新分配。

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 轮，你就已经在循环里了。三层终止缺一不可：

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 最顺，路由原则对所有框架一视同仁。

架构图：生产级发言权决策管线

flowchart TD
    U[用户任务] --> S[结构化状态对象<br/>task / pending / completed / claims]
    S --> R{确定性路由函数<br/>零 LLM 调用}
    R -->|规则可编码| W1[Worker A]
    R -->|规则可编码| W2[Worker B]
    R -->|需推理| SL[Supervisor LLM 兜底]
    SL --> W3[Worker C]
    W1 --> L{认领锁<br/>Redis TTL}
    L -->|获取成功| EX[执行子任务]
    L -->|已被占用| RR[请求重新分配]
    EX --> CV[JSON Schema 校验]
    CV -->|合规| UP[更新状态]
    CV -->|违约| RT[拒绝 / 重试 / 升级]
    UP --> LD{循环检测<br/>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 调用），橙色节点是防重复劳动的闸，粉色节点是防死循环的闸，蓝色节点是防失控账单的闸。去掉任何一道闸，系统都会在某个边界条件下塌缩。

失效模式 → 防御层映射

flowchart LR
    subgraph FM[四大发言权失效模式]
        A1[论证死循环<br/>A提议-B批评-A辩护]
        A2[回声室<br/>三人轮流附和]
        A3[静默认领冲突<br/>两人同做一事]
        A4[管理者漂移<br/>manager 忘记策略]
    end
    subgraph DEF[防御层]
        D1[确定性路由<br/>消灭 A4]
        D2[认领锁<br/>消灭 A3]
        D3[循环检测+综合注入<br/>消灭 A1 A2]
        D4[轮次/Token 硬上限<br/>兜底全部]
    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 臆测决定，还是被一条确定性的、带锁、带终止、带循环检测的管线决定。前者烧钱且不可调试，后者便宜且可量产——发言权，才是多智能体真正的系统边界。