多个智能体意见一致，也要验收

三个 AI Agent 给出同一个答案，能证明答案可靠吗？作者的结论是：一致意见只能提供一个待验证的候选，不能代替验收。他用一次真实的路由故障说明，多个 Agent 如果共享同一份错误输入，也会一起绕开正确答案。

这篇文章值得读的地方，是把「多找几个 AI 复核」变成了一个更具体的问题：即使所有 Agent 都同意，什么证据仍然能推翻这个结果？对用 AI 写代码、审查改动和生成页面地址的开发者，这比单纯增加评审数量更有用。

三个 Agent 都选错，问题可能出在选项里

2026 年 9 月，作者网站的查询路由器提供了三个返回 404 的 URL。原因是候选目录根据翻译字典名称生成，而字典名称并不等于公开页面地址。

例如，consultant-program 对应一项真实服务，但服务的公开地址并不是这个名字。波兰语培训页面也使用了经过翻译的 slug，也就是 URL 中标识页面的那段路径。

模型可能完全理解用户想找什么，却只能选出一个打不开的地址。如果三个评审都从同一份目录中选择，正确地址根本不在选项里，再认真讨论也选不出来。

先验证候选是否存在，再让模型判断候选是否合适。

作者在 pull request #59 中记录了修复。后续检查会把所有路由候选与构建产物的 sitemap 对照，并确认 sitemap 中每个条目都有对应的 HTML 文件。只要目录里还包含那三个旧地址，就在调用模型之前拒绝它。

这次事故是候选目录故障，并不是证明多 Agent 投票效果的受控实验。它揭示的是一个具体风险：所有评审可能共享同一个未经验证的前提。

多数票有没有用，要看错误是否独立

作者给了一个简化计算：假设三个投票者回答二选一问题，每个投票者都有 20% 的概率答错。

如果错误相互独立，多数票出错的概率是：

3 × 0.2² × 0.8 + 0.2³ = 10.4%

但如果它们总在完全相同的问题上犯错，多数票的错误率仍然是 20%。

这组数字是数学示例，不是任何具体模型的实测成绩。它说明投票收益依赖什么，不能用来承诺生产环境的准确率。

启动三个进程，并不能证明三份判断独立。它们可能缺少相同的上下文，收到相同的误导指令，或者使用同一份错误目录。即使换成不同模型，目录中缺失的正确答案也不会自动出现。独立性需要通过代表性任务上的实际错误表现来支持。

作者引用了 Du 等人在 2023 年的研究：多 Agent 辩论在被评估任务上改善了推理和事实性。但这只能支持「辩论可能改善答案」，不能保证工作流接受的每个答案都正确。

因此，评审要交付的不只是赞同或反对，还应包括能检查答案的材料：一个触发失败的输入、一段与结论矛盾的来源文字，或者目标端点的实际响应。如果用 LLM judge 给多个答案排序，还应检查位置偏差，避免展示顺序影响判断。

验收脚本必须讲清楚自己证明了什么

对路由问题，「页面标题看起来相关」没有增加存在性证据；「候选地址不在 sitemap 中」则能直接否决候选。

作者提供了可执行检查：在该仓库根目录完成 npm run build 后，运行以下命令，不需要 API key。

node --input-type=module <<'JS'
import { inventory } from './tools/typesafe/corpus.mjs';
import { assertIndexable, indexablePaths } from './tools/typesafe/routing-data.mjs';
const pages = [...inventory('en'), ...inventory('pl')];
assertIndexable(pages, indexablePaths());
console.log(`${pages.length} candidate URLs checked`);
JS

关键是 assertIndexable(pages, indexablePaths()); 这一行：它检查提供给路由器的 URL 是否全部属于构建后的可索引集合。前面的 inventory('en') 和 inventory('pl') 汇总英语、波兰语候选。

这个检查的边界很窄。通过检查，不能证明页面内容回答了用户的问题，也不能证明部署站点的重定向和可用性正常。前者需要内容审查，后者需要单独检查 HTTP 响应。编译通过也类似，它只证明代码能够编译；测试通过，只证明断言覆盖的行为符合预期。

修复目录后，旧结果也需要重算。即使最终胜出的 URL 存在，无效候选仍可能影响第二名和置信度。直接修改旧 JSON 中的三个地址，会掩盖问题，却没有重新执行选择过程。

作者提出保留原始输入，用同一份 Search Console 导出重新比较；同时记录目录指纹、输入哈希、生成时间和实际响应的模型版本。目录变化后，页面审计应拒绝不匹配的旧报告，并使用新路由结果重新运行，再决定改写哪个页面。

我的判断

我赞同把可执行验收放在一致意见前面。URL 是否属于构建产物，适合用确定性规则检查；页面是否切题，再交给内容评审。这样每种检查都有明确职责，也更容易定位失败原因。

但原文没有给出这套流程与单 Agent、不同模型组合之间的生产对照数据。它提供的是一个故障案例、一组概率假设，以及一套验收设计，不能据此判断多 Agent 是否值得额外成本。

对一般团队，目录指纹和审计报告失效机制是否值得做，还取决于结果会不会被长期保存、反复用于后续决策。一次性辅助任务可以简化；持续驱动页面改写的流水线，则有必要记录结果来源。原文也没有报告实际模型版本，只有「应当记录版本」的要求。

能拿来做什么

• 让 AI 生成站内链接或路由候选时，先对照构建后的 sitemap 和 HTML 产物检查地址，再单独验证部署环境的 HTTP 响应。
• 让 AI 审查代码时，要求它提供能触发问题的输入或反例，并明确该检查覆盖的行为，避免把「看起来正确」当作验收结果。
• 使用多个 Agent 评审时，要求它们带回来源、运行结果或反例；如果只是对同一份材料重复表态，就不要把票数当作独立证据。
• 保存路由分析和页面审计结果时，一并保存输入哈希、目录指纹、生成时间与模型版本；基础数据变化后，重跑依赖它的结论。