五个 AI 都同意，为什么还可能一起答错？

把一个问题交给 AI，得到答案后再开几个会话复核。五个都说没问题，心里确实会踏实一点。但我现在更想追问一句：它们是各自走了一遍不同的路，还是沿着同一条路，把同一个坑踩了五次？

这不是咬文嚼字。我们习惯把“五个人都这么说”理解成一种交叉验证，因为五个人可能有不同经历、不同消息来源，也可能有人刚好见过反例。五个 AI 会话却未必带着这些差异。数量是界面上看得见的东西，判断的独立性藏在后面。

如果只是想多收集几个表达方式，重复提问当然有用。可当我们用它来决定一个结论能不能信、一项修改能不能交付时，就得看得更细一点。

换了五个窗口，没有换掉共同盲点

Anthropic 在 2026 年 8 月公开的一组多代理实验里，记录过一个很具体的现象：同一模型的三十个代理同时开始开发游戏，其中十八个给自己的 Git 分支起了同一个名字。研究者把这类倾向称为低差异性：模型、上下文和运行方式相近时，各代理可能做出很相似的选择。这是特定实验里的观察，不能推成所有模型的固定概率。

来源：Anthropic：多代理系统中的模式与问题

分支撞名还容易发现。更难发现的是答案没撞字面，却撞了前提。设想下面这个例子：我要判断某个开源工具能不能离线使用，给五个 AI 的任务都是“查查这个工具是否支持离线”。它们都搜到同一篇介绍文章，文章说支持本地部署，于是五份报告都写“可以离线”。

问题出在“本地部署”和“整个流程不访问外网”被混成了一件事。程序可以装在本地，某个步骤仍可能请求远端服务。五份报告只要沿用同一个解释，措辞越丰富，反而越容易让我误以为已经从不同角度核实过。

这个例子是假设，不对应某个具体产品。它想说明的是：错误既可能来自模型内部，也可能来自外部材料。换模型能改变一部分倾向，但如果它们都读同一篇不完整的文章，仍然可能一起遗漏同一个条件。

我会把“都同意”拆开看。是在各自计算后得到同一个数？是在不同原始资料里找到相互支持的事实？还是都引用了某个二手网页？这三种一致，外表差不多，能给结论增加的分量却不同。

多数票好不好用，取决于错法是否独立

拿一个故意简化的算例来看。假设每个判断者做二选一题时，有七成概率答对，而且彼此的错误完全独立。三个判断者投票，只要至少两个答对，多数票就正确，算出来的正确率是百分之七十八点四。换成五个，约为百分之八十三点七。

这不是任何模型的实测成绩。它只是一个数学模型：每个人能力相同，每题只有两个答案，投票不弃权，错误互不影响。在这些条件下，多数票确实能把偶发失误抵消一部分。

再换一个极端假设：五个判断者每次都一起对、一起错，单个正确率仍是七成。那五票并没有变成五次独立机会，投票结果仍只有七成正确率。把同一个答案复印五份，不会改变答案对错。

真实模型通常落在复杂得多的情况里。有些题大家都会，有些题大家都容易误读；即使每次采样不同，也可能共享同一个知识缺口。这两条曲线只是拿来隔开两个概念：多做几次，与多获得几次独立判断，不是一回事。

还要注意“正确率七成”本身不能从一句自报信心里得到。让模型说“我有百分之九十的把握”，并没有完成校准。只有拿一组有可靠答案的任务反复测，才能知道这种把握对应什么结果。否则把一个想象中的概率代进公式，算得再精确也没意义。

多代理讨论也不是注定无效。Du 等人在 2023 年的研究里，让多个模型实例提出答案并进行多轮讨论，在他们测试的任务上改善了推理和事实表现。这个结果说明讨论值得研究；它没有保证任意问题、任意模型、任意聊天组织方式都会受益。

来源：Improving Factuality and Reasoning in Language Models through Multiagent Debate

如果想知道自己常用的两个模型有没有互补，也可以做一个很小的检查：准备同一批有可靠答案的题，让它们分别作答，记录每一道谁对谁错。不要只比较最后的总分。两个模型都答对八道题，错的那两道完全重叠，和错的题恰好不同，对复核工作的意义并不一样。

不过，发现错误互补还只是第一步。如果正式任务里没有现成答案，遇到它们意见不一致时，我仍需要一个办法判定谁对。不能在统计时借用了标准答案挑选正确结果，到了实际使用时却假装系统天然知道该信谁。可以增加计算器、可执行测试或原文检查，但这部分成本也要算进去。

这个小检查最好保留任务类别。一个模型在算术上补另一个的短板，不代表在材料解读上也有同样效果；同一组很熟悉的题反复调提示，成绩变好也可能只是更适应这组题。因此我会另外留一批没有参与调整的题，观察分工换过去后是否仍然有帮助。真正要找的是可重复的互补，不是挑出几道让团队显得厉害的例子。

我更愿意分配证据，不只分配角色

回到“某个工具能不能离线使用”的假设任务。与其给五个代理分别挂上架构师、审查员、专家这样的头衔，我更愿意给它们三份能落到材料上的任务。

第一个只看官方文档，找安装、许可、模型下载、登录和运行阶段分别有什么前置条件。交付时给出原文位置，并明确哪些条件是文档写的，哪些还没有答案。

第二个看对应版本的配置和代码，沿着外部请求的位置追过去，区分必须调用、可关闭调用以及只有更新检查才会触发的调用。它不需要把整个仓库读完，但要说明自己覆盖了哪些入口，哪些分支没有查。

第三个在允许的测试环境里做最小实验。预先下载依赖，关闭外网连接，再运行约定的几个核心动作。记录输入、版本、结果与失败阶段。一次成功只能证明这几个动作在这个条件下可用，不能替整个产品盖章。

这三份结果也未必完全独立，但它们至少有不同的失误方式：文档可能过期，静态分析可能漏掉动态路径，实验可能没覆盖到某个动作。让它们相互补充，比三份都转述同一段介绍更有价值。

给任务的时候，还要写清共同底线。所有人查同一个版本，解释同一个“离线”，围绕同一组必须完成的动作。否则一个人在讨论安装阶段，一个人在讨论推理阶段，最后的分歧只是口径不同，没必要再开一轮辩论。

Anthropic 在介绍自己的研究型多代理系统时，也强调了委派说明中的目标、输出形式、来源与任务边界。他们报告过含糊分工导致重复搜索的情况，并认为多条独立研究路线更适合并行。这里有用的是组织方法，不必把他们的内部评测分数直接套到自己的任务上。

来源：Anthropic：如何构建多代理研究系统

先各自查，再把冲突摆在桌面上

我倾向于把首次调查和后续讨论分开。第一轮给各代理问题与必要事实，不先塞给它们一份写得很完整的倾向性答案。等它们分别提交发现，再集中比较。这样至少能让人分辨：某个依据是独立找到的，还是读到别人的结论后补出来的解释。

这是一种工作安排，不是保证模型绝不受暗示的开关。共享必要条件仍然重要，不能为了“独立”把版本号、任务范围也藏起来。要隔开的主要是尚未证实的答案和带方向的推断。

汇总时，我会要求每条重要结论带上三个东西：支持材料、适用范围、尚未解决的问题。支持材料可以是文档段落、一个能重跑的算式或一段实验记录；“另一个代理也这么认为”只能说明有一致意见，不能替代这些材料。

如果两份结果冲突，先检查是不是说了同一件事。例如文档说可离线，实验却失败，可能是运行不依赖外网，但首次下载依赖外网。把阶段拆开后，两者都可能是对的。如果确实互相矛盾，就找能区分两种解释的下一步，而不是邀请更多代理加入投票。

假设争议是某个配置开关能否关闭远端请求，最有效的下一步可能只有一次：固定输入，分别打开与关闭开关，比较网络访问记录。此时第五个语言模型的长篇分析，可能没有这一次小实验提供的信息多。

保留少数意见也很重要。一个代理只要拿出能重现的反例，就足以推翻“所有情况都成立”的说法。不能因为另外四个没找到反例，就把它处理成噪声。反过来，少数意见也不是天然高明；它必须交出同样可检查的依据。

有些任务，多开才划算

比较几种工具的能力边界，按不同资料来源调查，往往能并行；核对一份报告里的不同事实，也可以各自去查。每个子任务有清楚的输入，完成后能单独检查结果，主代理不用每隔一分钟替所有人重新解释背景，才容易得到实际收益。

另一些任务就不适合硬拆。一个很短的函数里只有一个错误，定位过程又强依赖前一步结果，让五个代理同时改它，可能只是在重复理解同样的几行代码。需要不断改变设计的交互原型，也未必适合把相互牵连的部分分给很多代理，最后再指望拼起来就自然一致。

还有一种中间做法：一个代理负责实现，另一个只按需求设计边界用例，不先看实现者的解释。后者不是为了扮演反对者，而是提供另一条发现问题的路径。它若只是复述实现里现成的判断条件，即使测试全过，新增的信息也有限。

衡量效果时，我会把“这次快了多少”和“这次少漏了什么”分开记。并行缩短等待时间，可能同时增加总调用成本；多查出一个有证据的问题，也可能值得多等一会儿。至少要和单代理、相近投入的做法比较，不能把更多预算带来的改善全归功于团队结构。

最朴素的试法是选几项重复发生、答案能验的任务，先用单代理完成，再用明确分工的多代理完成，记录耗时、总成本和最终漏项。任务太少，结果只能当线索；已经连续几次没有新增发现的分工，就值得收缩。没有必要先搭一套庞大的“公司组织架构”，再到处替它找活。

我觉得多代理最有价值的地方，是让一个任务真的多出几条探索路径。五份相同的结论可以让页面显得热闹；一份来自不同路径、能够检查的新证据，才会改变我们知道什么。