千个同模型代理的协作验证盲区

dev.to · AI#多智能体#评测#可靠性

Editor brief · 编辑速览

文章审视扩展至 1,024 个代理的 Agensh 实验，指出同模型协作可能产生相关性错误，且缺少独立尝试后按测试结果合并的对照组。共享看板禁止复核同伴 FACT 的规则，也可能让错误结论持续传播。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

把 AI 编程任务拆给 1,024 个 agent，能增加并行尝试，却未必能增加独立纠错能力。这篇针对 Agensh 的评论，追问的是：当所有 worker 都使用同一个模型，还被要求不要复查同伴写下的 FACT，谁来阻止错误成为整个团队的共同前提？

作者提出在共享事实写入和代码合并时增加证据审查。这个建议有价值，但作者也在推广自己的 ST21-Door。读这篇文章，需要把对实验的质疑、提出的方案和已经展示的证据分开看。

Agensh（arXiv:2609.26781）采用无领导者的协作机制：worker 自行领取子任务，把发现写入共享看板，再把成果合并进共享仓库，规模扩展到 1,024 个 agent。

评论作者指出，所有配置都运行 gpt-5.6-sol。同一个模型的多个实例可能重复相似的错误，因此，同伴审查不能直接视为独立验证。并行数量增加了，判断方式的多样性却未必增加。

他们引用的收益数据是：从 1 个增加到 8 个 agent，得分增加 1.37 点；128 个 agent 的总增益为 9.47 点。这里是「点」，不能改写成百分比；所给原文也没有说明具体评分指标。

这些数据能说明扩展后有收益，却不足以解释收益来自哪里。作者认为，还需要一组对照：让 N 个 agent 各自独立完成任务，再按测试结果合并成果。如果这种方式也能取得相近收益，共享看板和协作规则的额外贡献就需要重新评估。

更多尝试带来的收益，不能直接算成组织协作的收益。

更具体的质疑来自 worker 提示词。作者引用 Appendix A 的要求：

Do not rederive a peer's FACT, and do not retry something recorded as FAIL.

即不要重新推导同伴记录的 FACT，也不要重试已经记为 FAIL 的事情。

这条规则可以减少重复劳动，但也可能让错误记录失去复查机会。某个 worker 把未经充分支持的判断写成 FACT，其他 worker 随后把它当作可靠前提，错误就可能进入更多任务。

这里的关键不是共享信息太多，而是「发现」如何升级为「事实」。对于共享上下文的系统，读写效率之外，还要考虑记录是否可信、能否被质疑。

作者表示，他们没有在论文中找到错误 FACT 的传播测量，也没有找到专门核对断言与证据的机制。这是评论作者对论文的阅读结论，不能进一步写成「实验已经证明错误大规模传播」。

作者同意中央规划者难以扩展，但认为检查证据不必承担任务调度。他们建议在两个位置设置独立的边界审查者（boundary judge）：

这个角色不负责计划、分工或管理，只核对「凭这些证据，能不能作出这个判断」。

作者团队开发的 ST21-Door 就采用这种定位：输入断言及其依据，返回 ALLOW、BLOCK 或 NEEDS_EVIDENCE。它不判断答案最终是否正确，而是判断现有依据是否足以支撑这个断言。

Agensh 的 FACT 和 PATCH_SUMMARY 已有 evidence= 字段，在结构上具备接入这种检查的条件。不过，有字段不等于证据充分，更不等于审查机制已经有效。

作者还提到，他们公开审计了 13 起真实 AI 事件，提供可复现的「断言、依据、裁决」三元组，并提供公开试用端点。原文没有给出 ST21-Door 接入 Agensh 后的实验结果。

我认同这篇评论对共享事实入口的关注。多个 agent 可以共同引用同一条错误记录；引用次数再多，也不会自动增加这条记录的可信度。

但「相同模型的互审就是自审」说得偏满。相同模型仍可能因为任务上下文、执行路径和工具结果不同而发现彼此的问题，只是不能预设它们的错误相互独立。究竟能纠正多少错误，需要实验回答。

ST21-Door 的方案也有边界。检查断言是否得到依据支持，和确认依据本身是否可靠，是两道不同的问题。原文没有说明审查者如何验证证据、如何评估误放行和误拦截，也没有提供它与测试、人工审查等方式的对照数据。

证据审查可以补充测试，但原文没有证明它能替代测试。

因此，这篇更适合作为一份有针对性的设计质疑和方案提议。13 起事件审计值得进一步查看，但不足以直接证明它在千级 agent 协作中有效。