64 个 Agent 一小时写出 50 年猜想候选证明：真正危险的是“共识幻觉”

当64个AI同时给出相同答案时，我们是否该无条件相信？OpenAI最新研究揭示了多Agent系统的‘共识幻觉’风险——表面上的集体智慧可能只是同一偏见的64次重复。本文深度拆解数学证明案例背后的Agent协作机制，揭示产品经理必须警惕的四大认知陷阱，以及构建真正可靠多Agent系统所需的四道防火墙。

一个 AI 胡说八道时，你会怀疑它。

但如果 64 个 AI 反复研究，最后都支持同一个答案呢？

你可能就不再怀疑了。

这才是问题。

7 月 10 日，OpenAI 研究员 Ethan Knight 公布消息称，GPT-5.6 Sol Ultra 调用 64 个子 Agent，在不到一小时内，为图论中的“循环双覆盖猜想”生成了一份完整证明。

这是一个困扰数学界约 50 年的问题。OpenAI 随后公开了候选证明、原始 Prompt，以及由 GPT-5.6 Sol 编写的 Lean 形式化版本。

目前，这个结果仍然需要数学界继续独立核验，不能直接写成“AI 已经正式攻克 50 年数学难题”。但专业研究者已经给出了积极评价。

曼彻斯特大学数学家 Thomas Bloom 称它是一份“很漂亮的证明”，认为证明简短、基础，使用的数学工具在 20 世纪 80 年代就已经存在。

但他同时指出，证明没有提到一篇 1983 年的相关研究，容易让读者误以为其中一些方法是全新的。

也就是说，这份答案即使在数学逻辑上最终成立，也不代表它在知识来源和贡献归属上已经完整。

这件事对产品经理最大的提醒，不是“64 个 Agent 有多强”，而是：多个 Agent 给出相同结论，不等于结果经过了多次独立验证。

它也可能只是同一个模型、同一批资料和同一种偏见，被复制了 64 次。

我把这种风险称为“共识幻觉”：

系统没有获得更多独立证据，却因为多个 Agent 表达了一致意见，把一个仍然可能错误的判断包装成了确定结论。

单 Agent 时代，我们担心模型产生幻觉。

多 Agent 时代，我们还要担心一群模型共同把幻觉变成“共识”。

64 个 Agent，不等于 64 个独立专家

多 Agent 最容易制造一种团队可靠感。

一个主 Agent 拆解问题，几十个子 Agent 分头研究，最后再由主 Agent 汇总。它看起来很像一支专业团队：有人找资料，有人做分析，有人写结论，还有人负责审核。

但 Agent 团队和真实的人类团队有一个重要差别。

真实团队里的成员有不同教育背景、工作经历、知识结构和利益位置。同一个方案交给研发、销售、法务和财务，他们很可能从完全不同的角度提出反对意见。

多个 Agent 却可能使用同一个底层模型，接受相似的系统指令，读取相同的资料，并被同一个主 Agent 引导。

表面上，它们是多个角色；认知上，它们可能只是同一个大脑的多个窗口。

如果主 Agent 过早认定某条路线正确，再把这个判断同步给所有子 Agent，后面的协作就很容易变成集体补强。

一个 Agent 寻找支持证据，一个 Agent 优化表达，一个 Agent 补充案例，另一个 Agent 检查格式。每个 Agent 都完成了任务，却没有人继续追问：最开始那个判断是不是就错了？

这时，Agent 越多，错误不一定越容易被发现，反而可能被包装得越完整。

它有了更多论据、更漂亮的结构、更统一的表述，最后以“多 Agent 共识”的形式交到用户手里。

一个 Agent 的错误，看起来像错误。

64 个 Agent 的相关性错误，却可能看起来像事实。

研究已经提醒：错误真的会被多 Agent 放大

这不只是理论上的担心。

Google Research、Google DeepMind 与 MIT 等机构的研究者在《Towards a Science of Scaling Agent Systems》中，测试了三类模型、五种 Agent 架构和四类任务，共计 180 组配置。

结果并不是“Agent 越多越好”。

在缺少交流和验证机制的独立多 Agent 架构中，错误放大达到单 Agent 基线的17.2 倍；加入集中协调者后，错误放大被压到4.4 倍。

而在需要严格顺序推理的任务上，研究测试的所有多 Agent 架构都出现了性能下降，降幅达到 39%—70%。

研究还发现，当单 Agent 的基础准确率已经超过约 45% 时，继续增加 Agent 很可能出现负收益。协作成本、上下文分散和重复劳动，会抵消新增 Agent 带来的收益。

另一项研究《Understanding Agent Scaling in LLM-Based Multi-Agent Systems via Diversity》提出了一个更值得产品经理关注的概念：决定系统上限的，不是 Agent 的原始数量，而是“有效通道”数量。

两个 Agent 如果沿着几乎相同的推理路径工作，只能算一个有效通道；只有它们真正提供了互补证据和不同方法，系统才获得了新的信息。

所以，多 Agent 的核心问题不应该是：

“我能不能再多调用几个 Agent？”

而应该是：

“新增的 Agent，究竟带来了一条新的判断路径，还是只把已有答案重复了一遍？”

多 Agent 可靠性不取决于有多少张票，而取决于这些票是不是独立产生的。

OpenAI 原始 Prompt 的真正价值，是故意制造“不一致”

我把 OpenAI 公开的原始 Prompt 完整看了一遍。

它只有两页，但真正关键的部分，并不是“最多可以调用 64 个 Agent”，而是它如何防止 64 个 Agent 太快达成一致。

首先，它要求从真正不同的路线开始。

Agent 要分别尝试不同的数学表达、结构分解、归纳方式、流理论、代数视角和计算检查。这里不是把同一条路线机械拆成 64 份，而是尽量增加搜索路径之间的差异。

其次，它提出了一个很反常识的要求：不要把当前最看好的路线告诉大多数 Agent。

正常的团队管理里，我们习惯信息同步、统一目标、减少重复劳动。但在探索未知问题时，过早同步“领导最看好哪个答案”，会让所有成员迅速向同一方向靠拢。

OpenAI 反而要求早期保持信息隔离。不同 Agent 先独立发展，等到每条路线的优势和漏洞都充分暴露，再进行交叉讨论。

第三，它要求主 Agent 建立“方法注册表”。

系统不能只看已经生成了多少内容，还要记录当前有哪些方法家族、多少 Agent 正在研究每条路线、哪些方向尚未充分探索。

如果大量 Agent 涌向同一类方法，就把一部分算力重新分配到冷门路线。

第四，它要求给失败路线明确标记。

如果一条证明最终卡在一个与原猜想同样困难的引理上，不能因为前面的推导写得优雅，就把它包装成“已经接近成功”。这条路线必须被标记为阻塞。

除非有人提出新的机制、变量或构造方法，否则不应该继续让更多 Agent 在同一个死胡同里消耗算力。

最后，它要求持续使用对抗 Agent。

每一份候选证明，都要有人专门寻找漏洞：有没有把重复经过边的闭合路径误当成环？有没有遗漏平行边和非连通图？有没有在推导中偷偷使用一个与原猜想等价的结论？

这些 Agent 的任务不是帮主方案变得更漂亮，而是尽可能证明它不成立。

换句话说，OpenAI 没有把 64 个 Agent 全部变成执行者。

它刻意保留了一批拥有否决目标的反对者。

这可能比 64 这个数字本身更值得产品经理学习。

多 Agent 最容易做出的，不是错误答案，而是错误流水线

我自己在做多 Agent 视频生成流程时，对这种风险感受很深。

一条视频可以拆成需求理解、脚本、分镜、素材匹配、配音字幕和合规审核。每个环节交给更专业的子任务，看起来比让一个 Agent 从头做到尾更稳定。

但真正运行以后会发现：多 Agent 不会自动消灭错误，它还可能让一个上游错误顺着流程不断扩散。

如果脚本 Agent 一开始误解了产品卖点，后面的分镜 Agent 会把这个错误变成更有感染力的画面；素材 Agent 会认真寻找与错误脚本匹配的素材；配音 Agent 会把错误表达得更自然；审核 Agent 如果只检查敏感词和格式，甚至可能给出“通过”。

最后，六个 Agent 全部显示任务完成。

但它们共同生产了一条不能使用的视频。

这类问题最麻烦的地方，是每个局部步骤看起来都没有失败。

系统日志里，脚本已完成，分镜已完成，素材已匹配，字幕已生成，审核已通过。只有重新回到最开始的业务目标，才会发现整条链路建立在一个错误前提上。

如果所有下游 Agent 都默认信任上游结果，它们组成的不是专家团队，而是一条把错误加工成成品的流水线。

这也是为什么“再增加一个审核 Agent”通常不够。

审核 Agent 如果使用相同上下文、相同资料和相似判断标准，仍然可能继承同一个盲区。

真正的验证，不是让系统把自己的答案再读一遍，而是让检查者拿着不同目标、不同证据和不同失败条件，重新审视结果。

产品经理要给多 Agent 装上四道“共识防火墙”

现在很多多 Agent 产品喜欢展示组织结构。

一个研究 Agent、一个数据 Agent、一个写作 Agent、一个审核 Agent，再配一个负责调度的主 Agent。页面上出现五六个头像，任务状态不断跳转，很容易给人一种“数字团队正在协作”的感觉。

但产品经理真正应该设计的，不是角色数量，而是系统如何在形成共识之前，主动阻断相关性错误。

可以把它压缩成四道“共识防火墙”。

第一道：探索隔离

早期不要让所有 Agent 共享主 Agent 的偏好。

不同 Agent 可以使用不同检索词、不同资料集合、不同初始假设和不同方法，先独立形成判断，再交换结果。

这不是浪费算力，而是在购买真正的认知多样性。

第二道：路线登记

主 Agent 不能只收集答案，还要知道答案是怎么产生的。

哪些 Agent 属于同一个方法家族？哪些结论引用了同一个来源？哪些路线只是表述不同，底层逻辑其实完全相同？

只有记录这些信息，系统才能识别“十个回答，其实只有一条思路”的伪共识。

第三道：对抗审查

审核 Agent 不能以“帮助任务顺利完成”为唯一目标。

它必须拥有明确的反对任务：寻找失败条件、反例、引用缺失、边界遗漏和循环论证。更重要的是，它发现关键问题后，必须有权阻止结果进入交付状态。

没有否决权的反对者，最后很容易退化成润色者。

第四道：外部锚定

多个 Agent 相互认可，只能证明它们意见一致，不能证明事实成立。

关键结论仍然要回到原始资料、确定性程序、业务数据库、真实测试或者专业人员。

三个模型都说一个数据正确，不等于三个独立来源；三个代码 Agent 都说功能没问题，也不如一组真实测试更有说服力。

这四道防火墙对应的不是四个页面功能，而是四种产品责任：保护独立探索、记录判断来源、允许系统反对自己、把结论重新锚定到现实。

可以把它记成一句话：

多 Agent 可靠性，不是 Agent 数量，而是有效独立路径 × 对抗审查 × 外部证据。

当多个 Agent 给出不同答案，主 Agent 必须进行汇总。

最省事的方法，是看多数意见。

六个 Agent 支持方案 A，两个 Agent 支持方案 B，于是系统选择 A。

但多数票只在判断相互独立时才有意义。如果六个 Agent 使用同一批资料、同一种模型和同一条推理路线，它们不是六票，更像是同一票被复制了六次。

主 Agent 不应该只汇总结论，还要汇总结论的证据结构。

哪些结论获得了不同方法和不同来源的共同支持？哪些地方仍然存在实质分歧？哪些方案曾经被尝试，却因为明确的问题被放弃？

用户不需要阅读几十个 Agent 的聊天记录，但他需要知道：这个结论为什么成立，反对意见是什么，系统排除了哪些风险，还有哪些不确定性没有解决。

真正的信任，不来自页面上显示“64 个 Agent 已达成共识”。

它来自系统敢于告诉用户：这里仍然有人不同意。

Thomas Bloom 的质疑，暴露了“已验证”的另一面

Thomas Bloom 对这份证明的评价很值得产品经理注意。

他一方面认可证明本身，称它简短、漂亮，并分析了其中一个关键的非常规步骤；另一方面又批评证明没有充分引用已有工作。

这说明一个结果至少有两个不同的验收维度。

第一，结论在逻辑上是否成立。

第二，结论的来源、引用和贡献归属是否完整。

一个数学检查 Agent 可能验证了推导，却不一定检查引用；一个事实核查 Agent 可能确认了数据，却不一定识别观点是否来自已有研究；一个合规 Agent 可能确认没有敏感词，却不一定理解内容有没有误导用户。

如果产品把这些不同问题都压成一个“审核 Agent”，就容易出现一种假象：系统已经验证过，所以结果没有问题。

但“通过验证”必须继续追问：通过了哪一种验证？

对于行业报告，可能需要事实验证、来源独立性验证和引用完整性验证。

对于代码，可能需要功能测试、安全测试和权限测试。

对于营销内容，可能需要数据核验、品牌审核和合规审核。

不同验证之间不能相互替代。

这次证明即使最终被确认在数学上成立，引用缺失仍然是一个需要单独面对的问题。

产品经理要避免的，就是用一枚绿色的“已验证”标签，掩盖结果只通过了部分检查。

不是所有任务，都值得叫来一支 Agent 团队

64 个 Agent 很震撼，但 OpenAI 自己的多 Agent 文档也明确提醒：增加子 Agent 会增加 Token 消耗，而且对依赖单一顺序推理、频繁修改共享状态，或者被某个外部慢操作限制的任务，不一定有价值。

前面的 180 组配置研究也证明了这一点：在严格顺序任务中，多 Agent 的表现反而下降 39%—70%。

多 Agent 更适合能够形成不同探索路线、可以并行收集证据，并且值得为更高可靠性支付额外成本的复杂任务。

如果任务本身只有一条严格顺序链路，把它拆给多个 Agent，可能只会增加等待、同步和冲突。

如果任务没有明确的失败标准，对抗 Agent 也只能泛泛地说“建议进一步核实”。

如果系统没有记录路线、证据和分歧，64 个 Agent 最后仍然只能交出一份无法追溯的汇总。

所以，在决定上多 Agent 前，产品经理至少应该问六个问题：

1. 这个任务真的可以并行探索吗？
2. 不同 Agent 能否使用不同方法和证据？
3. 多个答案到底是独立判断，还是重复采样？
4. 对抗 Agent 有没有阻止交付的权力？
5. 主 Agent 能不能看到分歧、死路和证据依赖？
6. 发现错误的价值，是否高于额外的成本和延迟？

如果这些问题回答不上来，一个边界清晰、证据完整的单 Agent，可能比一支热闹的数字团队更可靠。

AI 团队越强，越需要保留反对派

过去我们担心单个模型产生幻觉。

现在，多 Agent 把问题推进到了下一层：当多个模型互相引用、彼此补强，并共同生成一个漂亮结果时，人还能不能发现它们共享的那个错误？

64 个 Agent 挑战 50 年猜想，展示了 AI 并行探索和持续尝试的能力。

但 OpenAI 的原始 Prompt 也揭示了另一面：要让这样的系统可靠，不能只增加执行者，还要主动保护不同路线、记录失败方法、限制过早共识，并给反对者真正阻止交付的权力。

这可能是多 Agent 产品最反常识的设计原则。

系统不是越统一越聪明。

有时候，它必须故意保留分歧，才能避免所有 Agent 一起走进同一个错误。

下一代多 Agent 产品的竞争，也不只是看谁能调动更多数字劳动力。

真正的分水岭是：当一支 AI 团队看起来已经达成共识时，系统有没有能力再追问一次——

这些 Agent 是真的从不同方向证明了同一件事，还是只把同一个错误说了很多遍？

本文由 @困困 原创发布于人人都是产品经理。未经作者许可，禁止转载