多智能体协商:当共识本身就是缺陷
我的AI智能体产生的最危险输出不是错误。错误很容易处理。代码检查工具能捕获语法错误,测试套件能捕获回归问题,而我构建的95个钩子能捕获except: pass和强制推送。真正危险的输出是一个看起来自信且论证合理、但恰好是错误的建议。
我让一个单独的智能体审查一个API端点的安全问题。该智能体检查了身份验证,验证了输入净化,并核实了CORS头。一切正常。而另一个被单独提示为渗透测试人员的智能体发现,该端点接受无限制的查询参数,可能通过数据库查询放大触发拒绝服务攻击。第一个智能体从未检查这一点,因为它的评估框架中没有将查询复杂度视为安全攻击面。
这个盲区是结构性的。再多的提示工程也无法修复它,因为限制不在提示本身。限制在于让一个视角去评估一个多维度的问题。
我构建了一个多智能体协商系统来弥合这个差距。具有不同角色的智能体独立研究、辩论发现结果,并通过结构化投票达成共识。该系统运行141个测试,在智能体之间强制执行上下文隔离,并使用双门验证架构来阻止过早达成一致。
TL;DR
单智能体AI系统存在结构性盲区:它们无法质疑自身的假设。一个运行Sonnet的Ralph循环以每小时10美元的速度生成代码,但模型中的每个盲区也以同样的速度被交付。多智能体协商在任何决策锁定之前,强制从多个视角进行独立评估。我的实现使用10个研究角色、一个7阶段状态机和两个验证门(共识检查+品质检查),运行在Claude Code钩子之上。系统在低置信度决策(低于0.70)时触发,每次协商大约增加3倍的令牌成本。对于安全决策、架构选择以及任何不可逆操作,这个成本在第一次捕获到单智能体遗漏的问题时就能回本。对于文档修复和常规编辑,则完全跳过协商。
我的智能体们一致同意搞砸一切的那个夜晚
2026年2月。一个周二。我让我的智能体”调查改进钩子分发系统”然后走开去冲咖啡。智能体评估自身置信度为0.58(低于0.70阈值),这触发了协商。系统生成了3个研究智能体。每个研究智能体评估问题,发现子问题,然后生成自己的研究智能体。那些智能体又生成了更多。
七分钟后:23个活跃智能体进程。烧掉了4.80美元的API额度。~/.claude/state/目录被JSON状态文件填满,因为每个智能体都尽职地持久化了自己的发现。令牌消耗以大约每分钟0.70美元的速度攀升,没有收敛迹象。
我为质量系统构建的递归守卫追踪的是深度(父进程生成子进程,子进程生成孙进程),而不是广度(父进程生成12个子进程,每个子进程又各生成12个)。深度限制为3从未触发,因为智能体们是水平扩展的。我手动终止了所有进程,然后盯着那些状态文件。
每个智能体都同意钩子分发系统需要改进。每个智能体都提出了听起来合理的变更方案。没有一个智能体质疑调查本身的范围是否正确。二十三个智能体在错误的问题上达成了共识。
修复只用了20分钟:一个追踪每个父进程活跃子进程总数的生成预算,上限为12。更深层的教训则需要更长时间来领悟。我记录的基础设施加速曲线使得协商系统能在2周内构建完成,正是因为钩子基础设施已经存在。但快速构建并不能防止结构性故障。从单智能体RAG管道到自主系统的演进遵循可预测的弧线。多智能体协商位于末端是有原因的:只有在单智能体自信地交付了错误答案之后,您才会去构建它。
共识,而非分歧,才是危险的失败模式。
协商的解剖
该系统有两个结构性组件:一个排序工作的状态机,以及两个防止错误共识被交付的验证门。
状态机
七个阶段,每个阶段由前一个阶段控制:
IDLE -> RESEARCH -> DELIBERATION -> RANKING -> PRD_GENERATION -> COMPLETE
|
(or FAILED)
RESEARCH(研究):独立智能体调查主题。每个智能体获得不同的角色(技术架构师、安全分析师、性能工程师,以及其他7种)。上下文隔离确保智能体在研究期间无法看到彼此的发现。L0(系统规则)和L1(项目上下文)是共享的。L2(智能体特定关注点)是私有的。L3(领域模式)为每个角色加载相关的模式库。1
DELIBERATION(协商):智能体查看所有研究发现并生成替代方案。辩论智能体识别不同视角之间的冲突。综合智能体合并不矛盾的发现。
RANKING(排序):每个智能体按5个加权维度对每个提案进行评分:
| 维度 | 权重 |
|---|---|
| 影响力 | 0.25 |
| 质量 | 0.25 |
| 可行性 | 0.20 |
| 可复用性 | 0.15 |
| 风险 | 0.15 |
加权分数汇总为共识分数。阈值是任务自适应的:安全决策0.85,架构0.80,默认0.70,重构0.65,文档0.50。2
双重验证门
第一道门:共识验证(PostToolUse:Task钩子)。每个协商智能体完成后运行四项检查:
- 阶段必须至少达到RANKING
- 至少2个智能体已完成(可配置)
- 共识分数满足任务自适应阈值
- 如果有智能体持异议,其关注点必须被记录
任何一项检查未通过都会阻止协商推进。3
第二道门:品质检查(Stop钩子)。会话关闭前运行五项质量检查:
- 方法多样性:包含多个不同角色
- 矛盾透明度:异议有记录的理由
- 复杂度处理:至少生成2个替代方案
- 共识置信度:分数被分类为强(高于0.85)或中等(0.70-0.84)
- 改进证据:最终置信度超过初始置信度
双门架构在不同阶段捕获问题。第一道门在过程中防止过早收敛。第二道门防止交付看似完整但缺乏严谨性的结果。
情报分析师先遇到了这个问题
我在2026年1月构建了协商系统。两周后,我在一个关于结构化决策的阅读清单上发现了Richards Heuer的《情报分析心理学》。第8章描述了竞争假设分析法(ACH):分析师同时针对多个假设评估证据,而不是为自己偏好的结论构建论证。4
这种平行让人不安。Heuer的框架于1999年为CIA发布,解决的是我一直在调试的同一个结构性故障:聪明人因为从未强迫自己评估替代方案而收敛于单一解释。
以下是ACH在实践中的样子。一位情报分析师在调查疑似武器项目时,不会问”这是武器项目吗?”(确认偏误)。相反,分析师会列出所有合理假设(武器项目、民用研究、军民两用设施),针对每个假设评估每条证据,并识别哪些证据最能区分不同假设。
我的系统用不同的词汇做同样的事情。三个智能体评估一个拟议的数据库模式变更。智能体A(技术架构师)写道:”模式干净,规范化至3NF。”智能体B(性能工程师)写道:”查询模式将需要在每次读取时跨4个表进行连接。”智能体C(安全分析师)写道:”PII字段未进行静态加密。”同一个模式,三种不同的评估,三条区分性证据。排序阶段按照ACH针对证据评估假设的方式,根据这些独立评估来评价提议的方案。
我并非根据Heuer的框架设计了这个系统。我通过反复试错重新发明了ACH的一个子集,然后发现已经有人写了教科书。诚实的版本比自我美化的版本更有用:独立地得出相同的架构,证实了底层问题是真实的,而非理论性的。
为什么共识是危险的失败模式
Charlan Nemeth从1986年开始研究少数派异议,直到她2018年出版的《为异见者辩护》一书。有异议者的群体比快速达成一致的群体做出更好的决策。异议者不需要是正确的。异议行为本身迫使多数人审视他们原本会跳过的假设。5
James Surowiecki在《群体的智慧》中提出了群体明智决策的四个条件:意见多样性、判断独立性、去中心化,以及汇聚机制。6违反独立性(让智能体在研究期间看到彼此的工作)就会产生羊群效应。违反多样性(对每个智能体使用相同的提示)就会产生回音室效应。
我直接测试了独立性条件。两个智能体在能看到彼此发现的情况下评估同一部署策略:智能体A将风险评为0.45。智能体B看到该分数后给出0.48。同样的智能体在没有可见性的情况下:0.45和0.72。0.48和0.72之间的差距就是羊群效应的代价。智能体B的独立评估标记了一个容器编排风险,而这个风险在社会压力进入评估时消失了。
最新研究证实这两种模式都适用于LLM智能体。Choi等人在NeurIPS 2025上发现,独立提示的智能体之间的多数投票能获取多智能体系统大部分的质量提升。7 Kaesberg等人在ACL 2025上量化了这种分化:投票在推理任务上提高了13.2%,而共识协议在知识任务上提高了2.8%。8这表明选择应取决于任务类型。这就是为什么我的系统使用任务自适应阈值而不是单一的共识数值。
Wu等人测试了LLM智能体是否能真正辩论,发现如果没有结构性的分歧激励,智能体会收敛于听起来最自信的初始回应,而不管其正确性。9 Wynn等人走得更远:辩论可能是主动有害的。模型会在同伴推理的影响下从正确答案转向错误答案,即使更强的模型数量上超过较弱的模型。10 Liang等人确定了根本原因为”思维退化”:一旦LLM在某个立场上建立了信心,自我反思就无法生成新的反论,这使得多智能体评估在结构上成为必需。11
我的系统通过上下文隔离(L2层在研究期间对智能体私有)来保障独立性。多样性来自10个具有不同评估优先级的独特角色。汇聚使用5个维度的加权评分而非简单投票。对异议的结构性激励较弱:我追踪异议是否被记录,但不奖励智能体的异议行为。一致性检测模块试图弥补这一差距,效果参差不齐。
检测虚假分歧
一致性模块追踪表明智能体在未进行真正评估的情况下达成一致的模式。跨智能体重复相同语言的记录关注点、可疑地聚集在阈值附近的分数、或所有角色一致支持(安全分析师和性能工程师很少在所有事情上达成一致)都会触发警告。
它能捕获的:模板化异议(智能体复制彼此的关注语言)、分数聚集(每个智能体在10分制中评分差距在0.3分以内)、以及缺失的少数派视角(来自优先级冲突的角色的一致批准)。
来自我日志的一个例子:五个智能体评估一个身份验证重构方案。五个智能体都将安全风险评分在7.1到7.4之间。一致性检测器标记了这个聚集。当我在刷新上下文隔离(清除L2缓存)后重新运行时,分数扩展到5.8-8.9。原始聚集反映的是共享上下文污染,而非真正的一致。
它遗漏的:智能体确实从其角色视角进行了真正评估,但恰好因不同原因得出相同结论的复杂一致性。当推理看起来是独立的时候,该模块无法区分真正的共识和羊群效应。我尝试在真正一致与人为一致的示例上训练分类器,但训练数据太少(不到50次协商会话),信号太弱。一致性检测器捕获了明显的情况,遗漏了微妙的情况。
诚实的评估:一致性检测为10-15%的智能体过快收敛的协商添加了有用的合理性检查。对于其余85-90%的情况,共识和品质检查门提供了足够的验证。我考虑过构建更复杂的一致性系统,但认为工程投入与边际改进不成比例。
行不通的尝试
死胡同1:自由形式辩论轮次
第一个版本让智能体针对彼此的发现撰写长篇反驳:3轮来回文字辩论。我看着一场关于数据库索引策略的协商在7500个令牌的辩论中展开。第1轮:关于复合索引与单列索引的真正分歧。第2轮:用少量补充重述立场。第3轮:几乎相同的论点包裹在不同的措辞中。信号在第1轮达到峰值,之后逐步衰减。
每次协商的令牌成本达到2-4美元,而有用信息密度随每轮下降。修复方案:用结构化维度评分取代自由形式辩论。智能体用数值在5个维度上为提案评分,而不是写文章。成本和时间下降了约60%,最终排名的质量实际上提高了,因为数值评分强制了散文所掩盖的精确性。
死胡同2:基于深度的递归用于协商
无限生成事件暴露了一个根本性的建模错误。递归守卫追踪深度:深度0的父进程生成深度1的子进程,子进程生成深度2的孙进程,最大深度3。但协商智能体应该宽幅展开(10个研究智能体在同一层级),而不是深度展开(一个智能体生成一个子进程再生成一个孙进程)。深度限制3从未触发,因为深度1的23个智能体仍然是”深度1”。
修复方案是生成预算模型:协商智能体继承父进程的深度而不是递增,并共享总计上限为12的子生成预算。预算模型映射到实际的失败模式(总智能体太多)而不是代理指标(嵌套层级太多)。智能体谱系记录在JSON文件中,以便预算在异步智能体完成时持久化。12
死胡同3:单一验证门
第一个实现在会话结束时运行一个验证钩子,将共识检查与质量检查合并。失败模式在第一周内就出现了。一个智能体以0.52的共识分数完成了协商——低于0.70的阈值。然后它继续执行了20分钟的不相关任务,之后会话结束钩子才标记了这个失败。20分钟的工作建立在一个未通过验证的基础之上。
拆分为两道门修复了时序问题。第一道门(共识验证)作为PostToolUse:Task钩子运行,在协商智能体完成后立即捕获错误共识。第二道门(品质检查)在会话结束时运行,捕获跨步骤累积的质量问题。两个钩子在不同的生命周期节点,匹配了故障实际发生的方式:有些是即时的(错误分数),有些是渐进的(多样性不足、异议记录缺失)。
诚实的数学
协商消耗令牌。每个研究智能体处理大约5000个令牌的上下文并生成2000-3000个令牌的发现。以3个智能体(有效协商的最低要求)计,每个决策额外增加15,000-24,000个令牌。以10个智能体(完整研究面板)计,大约50,000-80,000个令牌。
按Opus定价(每百万令牌$15/$75),3智能体协商大约花费$0.68-0.90。10智能体协商花费$2.25-3.00。我的系统在大约10%的决策上触发协商(那些置信度低于0.70的),因此所有决策的摊销成本为每次会话$0.23-0.30。
这是否值得取决于一个错误决策的代价。生产部署中遗漏的安全漏洞会消耗数小时的事件响应时间。错误的架构选择会消耗数周的重构时间。文档中的拼写错误则没有成本。
置信度模块决定哪些决策触发协商。四个维度(模糊性、复杂度、影响程度和上下文依赖性)各产生一个0-1的分数。多个维度需要高分才能使整体置信度降至0.70以下并触发协商。单维度问题(”这很复杂但不模糊”)保持在阈值之上并跳过协商。13
两个智能体,一条规则
您不需要10个研究角色、8个Python模块或141个测试就能从多智能体协商中获得价值。从2个智能体和1条规则开始:智能体必须在看到彼此工作之前独立评估。
最小可行协商
Decision arrives
|
v
Confidence check: is this risky, ambiguous, or irreversible?
|
├── NO -> Single agent decides (normal flow)
|
└── YES -> Spawn 2 agents with different system prompts
Agent A: "Argue FOR this approach"
Agent B: "Argue AGAINST this approach"
|
v
Compare findings
|
├── Agreement with different reasoning -> Proceed
├── Genuine disagreement -> Investigate the conflict
└── Agreement with same reasoning -> Suspect herding
上面的决策流程图涵盖了80%的价值。以下是最简实现:
# Minimum viable deliberation: 2 agents, 1 rule
def deliberate(decision_description):
agent_for = spawn_agent(
f"Argue FOR this approach: {decision_description}",
persona="advocate"
)
agent_against = spawn_agent(
f"Argue AGAINST this approach: {decision_description}",
persona="critic"
)
if same_reasoning(agent_for, agent_against):
return "WARNING: Suspect herding. Verify independently."
elif genuine_conflict(agent_for, agent_against):
return "Investigate the specific disagreement."
else:
return "Proceed. Independent agreement with different reasoning."
其他一切都是增量改进:5维度排名、任务自适应阈值、一致性检测。核心洞察仍然简单:两个独立视角能捕获一个视角遗漏的失败。
单智能体与多智能体:有何不同
| 场景 | 单智能体 | 多智能体协商 |
|---|---|---|
| 安全审查 | “架构看起来很干净” | 智能体A:”干净。”智能体B:”管理员接口缺少速率限制” |
| 模式设计 | “规范化至3NF” | 智能体A:”干净。”智能体B:”每次读取需要跨4个表连接” |
| 依赖升级 | “测试通过,可以发布” | 智能体A:”测试通过。”智能体B:”变更日志显示v3有破坏性API变更” |
| 文档更新 | “README已更新” | 所有智能体达成一致(正确跳过,低于置信度阈值) |
什么需要协商
| 需要协商 | 可以跳过 |
|---|---|
| 安全架构 | 文档拼写错误 |
| 数据库模式设计 | 变量重命名 |
| API契约变更 | 日志消息更新 |
| 部署策略 | 注释措辞调整 |
| 依赖升级 | 测试固件更新 |
测试协商系统
该系统跨三个层运行141个测试:14
- 48个bash集成测试:钩子语法验证、共识流程、品质检查门、递归守卫执行,以及跨配置兼容性
- 81个Python单元测试:所有7个库模块(状态机、置信度、上下文隔离、排名、智能体、一致性、PRD生成)
- 12个端到端测试:从置信度评估到PRD输出的完整管道模拟
测试一个为分歧而设计的系统需要测试两类情况。正常路径:智能体建设性地分歧并达成共识。失败路径:智能体过快收敛、永不收敛、或超出生成预算。端到端测试用确定性智能体响应模拟每种场景,验证两道门捕获了每种记录在案的失败模式。
从2智能体模式开始。当2智能体版本在特定任务上遗漏了某些东西时再增加复杂度。我系统中的每个额外智能体、阈值和验证门都是因为更简单的版本在特定任务上失败了才存在的。您的失败会有所不同,您构建来捕获它们的系统应该反映您的失败,而不是我的。
核心要点
- 共识是危险的失败模式。单智能体无法质疑自身的假设。两个具有不同评估优先级的独立智能体能捕获质量门和方法论无法解决的结构性盲区。
- 两道门胜过一道。过程中的共识验证能尽早捕获问题。会话结束时的品质检查能捕获跨步骤累积的问题。将验证拆分为两个不同生命周期节点的钩子,与故障实际发生的方式相匹配。
- 选择性协商。置信度模块在大约10%的决策上触发协商。对所有决策都进行协商浪费令牌。对所有决策都不协商则会遗漏独立视角最重要的那些决策。
常见问题
多智能体协商每次决策的成本是多少?
按Opus定价,3智能体协商大约花费$0.68-0.90的API令牌(额外15,000-24,000个令牌)。完整的10智能体面板花费$2.25-3.00。系统在大约10%的决策上触发协商,因此所有决策的摊销成本为每次编程会话$0.23-0.30。
每个决策都需要协商吗?
不需要。置信度模块在四个维度(模糊性、复杂度、影响程度、上下文依赖性)上对决策评分。只有整体置信度低于0.70的决策才会触发协商,大约占总决策的10%。文档修复、变量重命名和常规编辑完全跳过协商。安全架构、数据库模式变更和不可逆部署则会一致地触发协商。
这能用于Claude以外的模型吗?
架构原则(独立评估、结构化投票、双门验证)适用于任何能够遵循角色指令并产生结构化输出的LLM。实现使用Claude Code钩子和Task工具进行智能体生成,这是Claude特有的基础设施。移植到其他模型需要替换生成机制和提示模板,同时保留状态机、排名系统和验证门。
如何测试一个旨在产生分歧的系统?
跨三个层的141个测试:48个bash集成测试验证钩子行为(共识流程、品质检查门、递归守卫),81个Python单元测试用确定性输入覆盖每个库模块,12个端到端测试用固定智能体响应模拟完整的协商管道。端到端测试覆盖成功路径(建设性分歧达成共识)和失败路径(过早一致、无法收敛、预算耗尽)。
协商对延迟有什么影响?
3智能体协商增加30-60秒的实际等待时间(智能体通过Task工具顺序运行)。10智能体协商增加2-4分钟。共识和品质检查钩子各自运行时间不到200毫秒。主要瓶颈是每个智能体的LLM推理时间,而非编排开销。对于需要协商的决策,延迟是可以接受的,因为替代方案(事后发现错误)消耗的时间要多得多。
参考文献
-
作者的协商上下文隔离模块。实现位于
~/.claude/lib/deliberation/context_isolation.py。四个隔离级别:L0(系统规则,共享)、L1(会话上下文,共享)、L2(智能体关注点,私有)、L3(领域模式,按角色分配)。 ↩ -
作者的协商配置。阈值定义于
~/.claude/configs/deliberation-config.json。 ↩ -
作者的协商后共识钩子。实现位于
~/.claude/hooks/post-deliberation.sh,连接到PostToolUse:Task。 ↩ -
Heuer, Richards J.,《情报分析心理学》,中央情报局情报研究中心,1999年。第8章:竞争假设分析法。全文(CIA)。 ↩
-
Nemeth, Charlan,《为异见者辩护:异议在生活和商业中的力量》,Basic Books,2018年。另见:Nemeth, C. J.,”多数派和少数派影响的差异性贡献”,《心理学评论》,93(1),23-32,1986年。 ↩
-
Surowiecki, James,《群体的智慧:为什么多数人比少数人更聪明》,Doubleday,2004年。第1章。 ↩
-
Choi, H. K., Zhu, X., and Li, S., “Debate or Vote: Which Yields Better Decisions in Multi-Agent Large Language Models?” NeurIPS 2025 Spotlight. arXiv:2508.17536. ↩
-
Kaesberg, L. B. et al., “Voting or Consensus? Decision-Making in Multi-Agent Debate,” Findings of ACL 2025, pp. 11640-11671. ACL Anthology. ↩
-
Wu, H., Li, Z., and Li, L., “Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning,” arXiv:2511.07784, 2025. ↩
-
Wynn, A., Satija, H., and Hadfield, G., “Talk Isn’t Always Cheap: Understanding Failure Modes in Multi-Agent Debate,” arXiv:2509.05396, 2025. ↩
-
Liang, T. et al., “Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate,” EMNLP 2024, pp. 17889-17904. ACL Anthology. ↩
-
作者的递归守卫。生成预算模型位于
~/.claude/hooks/recursion-guard.sh。智能体谱系追踪于~/.claude/state/agent-lineage.json。 ↩ -
作者的置信度模块。实现位于
~/.claude/lib/deliberation/confidence.py。四个维度:模糊性、复杂度、影响程度、上下文依赖性。 ↩ -
作者的测试套件。48个bash测试位于
~/.claude/tests/test-deliberation-pipeline.sh,81个Python测试位于~/.claude/tests/test_deliberation_lib.py,12个端到端测试位于~/.claude/tests/test_deliberation_e2e.py。 ↩