多 Agent 流水线在每一次演示中都表现正常。但是到了生产环境，它可能在第四步之前就悄悄积累了三个错误决策，最终输出自信、流畅但是完全错误。并且最后没有人发现问题，因为根本没有信号可以捕捉链条末端只剩下一个看起来干干净净的结果。
这是 2026 年生产级 Agent 系统最典型的失败模式。正确构建验证层需要理解四种不同的架构模式、各自的失效边界，以及一个被多数团队忽视的规律。
为什么模型无法可靠地检查自己的工作
让 LLM 验证自身输出，它往往会同意自己。原因不在于它认真检查过，而在于结构上的倾向性，并且使用更好的提示词也改不了这一点。
同一个模型同时扮演生成器、评估器和批评者，倾向于在多次迭代中复现同样的推理结构，修正幅度极其有限。如果第一次推理就出了错，导致错误的那些表征偏差在重新评估时依旧存在。针对单 Agent Reflexion 的研究表明，自我反思大多只是重复先前的错误认知，很少引入新的推理路径。
多 Agent 验证之所以能在自我纠正失败的地方生效，机制就在于多样性：第二个 Agent 带着不同的角色设定、上下文甚至人设介入，对同一份输出给出截然不同的推理路径。
还有一层架构上的区别，传统评估只看最终输出但对于运行长序列动作的 Agent——研究工作流、编程助手、多步骤规划器——仅关注终点会遮蔽出错的位置。等到评估最终答案时，三步之前的根本原因早已不可见。正是这个缺口催生了过程验证的思路：逐步评估，而非只检查终态。
https://avoid.overfit.cn/post/dcf135116d4d4107b90e419c8ef689f4