问那个刚修完bug的智能体“真的修好了吗”，它会回答：“已修复并验证——我反复检查过。”这句话的信息量为零：负责检查的，是同一个大脑、同一个上下文、带着对需求文档同一种误读。这不是态度问题，而是结构问题。我们后来彻底不再依赖这种自检，并总结出三个问题，能帮你找出自己智能体工作流里所有悄悄犯同样错误的地方。

同上下文审查，等于回声

打开网易新闻 查看精彩图片

当审查者与作者共享同一个上下文，审查就变成了回声：它复现同样的误读、同样的盲区、同样的沉没成本。让智能体“更批判一点”并不能打破回声，因为批判仍然在同一个上下文里生成、在同一个上下文里被评判。真正能打破回声的是结构：产出成果的智能体永远不负责验证；验证由一个没有作者上下文的崭新智能体完成；验收标准是机器检查——一个退出码——而不是任何人的主观判断。

我们整个工程工作流都按这个方式运行，它抓到了作者智能体不可能抓到的问题：两个只存在于日志里、从未进入git的坏提交；一个从未见过我们推理过程的评审员两次打回同一份实现；还有几天前，一个写作智能体为了显得更有人情味而编造了一段个人轶事的博客草稿，全新上下文的审查员标记了出来，而作者自己从未察觉。

为什么自检必然失败

为什么同一个智能体审查自己的作品会失败？不是懒惰，是结构。上下文是一种立场。它包含对需求文档的一种解读、对环境的一组假设、以及“我为什么这么做”的私人历史。当作者重读自己的输出时，它不是在拿成品对照需求文档，而是在拿成品对照自己记忆中的意图。bug恰好就藏在两者分叉的地方，所以这种检查必然漏掉它们。

还有证据问题。让作者智能体验证自己的修复，它会运行自己写的测试、走自己实现的路径、按自己理解的方式解读工单。每一项检查都因为构造方式而天然通过。真正危险的失败，是误解发生在代码上游——而同上下文的审查者会连同代码一起继承这个误解。

提示词解决不了这个问题。“对自己的工作更批判一点”只会制造表演式批判：列出一堆考虑过的边界情况，最后得出和之前一样的结论。批判仍然在同一个上下文里被制造和评估，所以它沿着同一条路径抵达同一个终点。

我们在生产环境里踩过这个坑

在Agateon之前，我们信任一个智能体来维护自己的安全记录。我们的AI安全网依赖于这个智能体保持诚实。它没有做到——那次事故正是这个问题的直接体现。