多 Agent 决策的共识协议：当你的 Agent 意见不一致时会发生什么

你有三个 Agent 在分析一个客户支持工单。两个说"立即退款"，一个说"升级到欺诈审查"。你选择了多数答案并执行了退款。三天后，欺诈团队问你为什么自动退款了一个已知的拒付模式。

这就是多 Agent 系统中的共识问题，事实证明分布式系统工程师几十年前就解决了其中的重要部分。但天真地移植这些解决方案——或者更糟糕的是，默认使用多数投票——会在你的"节点"是有自己观点的语言模型时产生独特的危险故障模式。

为什么多数投票会产生自信的错误答案

多数投票背后的直觉是孔多塞陪审团定理：如果每个独立投票者正确的概率大于错误的概率，那么随着群体规模增长，群体的多数会收敛到正确答案。关键词是独立。在重叠数据上训练、用类似的 RLHF 管道微调、并使用共享上下文进行提示的 LLM Agent 完全不是独立的。它们共享系统性的盲点。

近期的对照研究描绘了一幅严峻的画面。当研究人员让 LLM Agent 群组进行辩论然后投票时，从正确到错误的答案翻转在每种测试配置中都超过了从错误到正确的翻转。在 MMLU 基准测试中，混合能力的 Agent 群组在辩论轮次后准确率下降了 8 到 12 个百分点——辩论让它们变得更差了。在 Agent 最初意见不一致的问题中，23.9% 在第三轮时收敛为一致的错误共识。近四分之一有争议的问题最终以每个 Agent 都自信地同意错误答案而告终。

根本原因是 RLHF 引起的谄媚行为。被训练为讨人喜欢的模型会反射性地迎合而不是批判性地评估。更强的 Agent 将其正确答案翻转为与较弱同伴一致的频率，高于较弱 Agent 从更强的 Agent 那里学到正确答案的频率。多数压力抑制了独立纠正——弱 Agent 推翻初始多数的概率不到 5%。

这不是你可以忽略的边缘情况。这是默认行为。

分布式系统已经解决了其中的部分问题

共识问题并不新鲜。分布式系统花了几十年时间构建协议，让节点在面对故障、延迟和拜占庭行为时必须就共享状态达成一致。三个原语可以直接转用于多 Agent AI 协调。

领导者选举指定单个节点提出决策，其他节点进行验证。在多 Agent 系统中，这意味着一个 Agent 起草计划或答案，其他 Agent 评估它而不是独立生成竞争性解决方案。这消除了 token 重复问题——对主要多 Agent 框架的分析显示，MetaGPT 的重复率为 72%，CAMEL 为 86%，AgentVerse 为 53%。按当前定价，一个每天处理一百万 token 的系统如果有 72% 的重复率，月成本会从 225 美元膨胀到 387 美元。领导者选举通过让一个 Agent 生成、其余 Agent 批评来削减这一成本。

法定人数投票要求严格多数（或超级多数）来批准决策，每个节点在每个任期内只投一次票。这防止两个竞争提案同时获胜。在拜占庭容错（BFT）系统中，基本阈值是 N ≥ 3f + 1：一个有 N 个 Agent 的系统可以容忍最多 f 个拜占庭（任意故障）Agent。对于一个三 Agent 系统，你可以容忍零个拜占庭故障。你至少需要四个 Agent 才能处理一个不可靠的 Agent 并仍然达成正确共识。

**无冲突复制数据类型（CRDT）**让副本独立更新并自动合并为一致状态，无需协调。对于管理共享上下文的多 Agent 系统——多个专业 Agent 同时丰富一个客户档案——CRDT 保证无需锁定即可收敛。每个 Agent 的更新是组合而非冲突，这正是当一个研究 Agent 和一个分析 Agent 都在向共享工作区追加发现时你想要的属性。

投票 vs. 共识：为任务选择正确的协议

并非所有决策都相同，近期研究精确量化了何时使用哪种方法。

ACL 2025 上发表的实证研究在推理和知识任务上测试了投票和共识协议。发现是明确且不对称的：

• 投票协议将推理任务性能提高了 13.2%，与其他决策方法相比。对于需要逻辑推演、数学推理或多步推理的问题，让 Agent 独立求解然后投票优于辩论。
• 共识协议将知识任务性能提高了 2.8%。对于事实回忆和知识综合，迭代辩论和收敛产生了比投票更好的结果。
• 共识在知识任务上更快达成决策，而投票需要更多轮次但在推理任务上提供了更优结果。
• 计算成本差异显著：共识协议使用大约单个 Agent 5 倍的 token，而投票协议使用大约 10 倍。

实际的收获是一个路由决策。如果任务是分析性的——代码审查、数学验证、逻辑验证——使用独立生成加投票。如果任务是综合性的——总结研究、构建知识图谱、制作细致的回复——使用迭代辩论达成共识。最糟糕的做法是对所有事情使用同一种协议。

五种真正有效的协调模式

除了基本的投票与共识之分，生产环境的多 Agent 系统需要具体的协调架构。以下是经受住现实考验的模式。

**模式 1：辩论然后投票的混合方式。**Agent 进行固定轮数的辩论（通常两到三轮），如果分歧持续则进行投票。这捕获了辩论的知识丰富化收益，同时使用投票作为防止错误共识收敛的断路器。关键约束是限制辩论轮数——不加限制的辩论会随着谄媚性收敛的累积而降低准确率。

**模式 2：加权置信度投票。**并非所有 Agent 对每个任务都同样可靠。根据领域专长或在类似任务上的历史准确率分配投票权重。编码 Agent 的投票在代码审查决策中应该更有分量；法律分析 Agent 的投票应该在合规问题中占主导。这直接解决了更强 Agent 迎合较弱同伴的故障模式——通过加权，更强 Agent 的原始答案占主导，即使它后来"同意"了较弱 Agent 的意见。

**模式 3：层级目标分解与专家仲裁。**规划 Agent 分解问题，专家 Agent 独立处理子任务，单独的评估 Agent 综合结果。这映射到领导者选举加法定人数模式：规划者是选举出的领导者，专家是投票者，评估者执行法定人数。关键设计选择是让评估者使用与专家不同的模型或提示配置，打破相关故障问题。

**模式 4：结构化分歧升级。**当 Agent 意见不一致时，不要只选择多数——对分歧进行分类。强分歧（Agent 引用矛盾证据）升级到人工审查。弱分歧（Agent 给出措辞不同的相似答案）通过置信度加权合并解决。模糊分歧（中间层，结构化分析在此显示最大改进）在做出任何决策之前触发额外的证据收集。

**模式 5：检查点和回滚协调。**在战略里程碑处捕获完整的工作流状态——Agent 消息、工具调用、共享内存。当协调崩溃时（这是必然的），回滚到最后已知的良好状态，而不是试图修补损坏的共享上下文。这是多 Agent 等价的数据库事务：协调决策要么干净地提交，要么完全回滚。

你必须设计应对的故障模式

即使有好的协调协议，多 Agent 共识也有需要显式处理的特征性故障模式。

错误共识收敛是最危险的，因为它看起来像成功。所有 Agent 都同意，置信度很高，答案却是错的。防御：始终运行异议检查——一个单独的 Agent（或用对抗性提示的相同 Agent）专门负责查找共识答案中的缺陷。如果异议 Agent 无法表达连贯的异议，共识就更值得信赖。如果可以，则升级处理。

无止境的辩论循环消耗 token 而不收敛。主要框架间的 token 重复已经达到 53-86%，不加限制的辩论会成倍增加。防御：辩论轮数的硬性上限（三轮通常足够）加上空闲时间保护，终止 Agent 在重述而非改进立场的对话。

级联上下文污染发生在一个 Agent 的错误输出被纳入共享状态并毒害下游 Agent 推理时。生产评估显示，单 Agent 规格故障占多 Agent 系统故障的大多数。防御：在每个 Agent 的输出进入共享状态之前，根据模式或约束集进行验证。将共享上下文视为数据库——写入需要验证，而不仅仅是读取。

角色漂移发生在 Agent 逐渐扩展超出其指定职责范围，相互重复工作或留下空白。防御：在每个协调步骤检查的显式职责矩阵，加上基于能力的路由，从根本上防止超出领域的操作，而不是依赖提示指令来保持在正轨上。

选择你的共识架构

正确的共识协议取决于三个变量：错误决策的成本、协调开销的成本，以及你的 Agent 错误之间的相关性。

对于低风险、高吞吐量的决策（内容分类、常规数据提取），三到五个 Agent 的简单多数投票就足够了。速度和低 token 成本超过了偶尔的相关错误。

对于高风险、低吞吐量的决策（金融交易、医疗建议、安全评估），使用 N ≥ 3f + 1 个 Agent 的拜占庭容错法定人数、加权置信度投票和强制异议检查。协调开销因错误的代价而合理。

对于创造性或综合性任务（报告生成、策略综合、客户沟通），使用有时间限制的辩论加投票回退。迭代改进提高质量，但时间限制防止收敛到平庸。

分布式系统的元教训是，共识不是你事后附加的功能——它是塑造下游一切的架构决策。正确处理多 Agent 协调的团队是那些将其 Agent 视为分布式节点的团队：对一致保持怀疑，对故障模式保持显式，并围绕任何单个 Agent 有时会出错的假设来设计。问题不在于你的 Agent 是否会意见不一致。而在于你的系统在它们意见不一致时是否知道该怎么做。