一个审查自己判决的法官，永远会判无罪。这句话几乎就是那类让80%智能体项目翻车的错误的全部定义：你搭起一套系统，模型先生成一份输出，然后同一个模型、或者它的孪生兄弟，被交派一个任务——"检查这个对不对"。模型照做了，而且永远向着自己。
结果是可以预见的。模型会放行自己编造出来的幻觉，因为在它自己的逻辑里，那些东西听起来很有说服力。同一张网络、同一组权重、同一批盲区。你等于在问作者：你这段文字写得好不好？你指望听到什么答案？
这是经典的"LLM当裁判"被指错了方向：法官和被告是同一个模型。没有人喊叫，没有红色警报响起。报告一片绿色，而最糟糕的那类失败，恰恰是你根本看不见的那种。
举个具体的例子。一个智能体从发票里抽取数据、写进数据库。它把一个金额弄错了，但错得很一致：同一个错误数字既进了"应付金额"字段，也进了摘要。你问模型这次抽取对不对，它看到内部自洽，回答"对"——从它站的位置看，一切严丝合缝。错误藏在裁判从未看到的输入里。
仪表盘显示"状态：正常"，而垃圾数据正在落进你的数据库。系统在跑，只是从内部悄悄毒化产品。
再跑一遍，救不了
本能反应是让模型再过一遍输出，或者立一个孪生模型在旁边，让它检查同事的活。问题是孪生模型继承了同一批盲区。如果原始模型编造了一个并不存在的API端点，用同样训练数据复制出来的模型会判定它合理，然后盖章放行。你付出了额外的成本和延迟，信心只在纸面上上涨。那不是验证，是回声。
两层验证
在智能体工程里，我不问模型有没有出错。我把验证拆成互不信任的两层：
- 硬层：用代码验证——schema、测试、事实是否对得上。确定性的、二元的。凡是能用代码检查的，绝不交给大模型。
- 软层：另立一个模型，用不同的提示词。它不参与生成，只做审计。
硬层很无聊，而这正是它有效的原因。一个JSON schema要么通过要么不通过；一个测试要么过要么挂；一个数字要么匹配要么不匹配。这里没有"听起来很有说服力"的容身之处。多数团队把本该由普通校验器在微秒内解决的问题推给大模型，然后在生产环境里用幻觉来付账。你检查代码能不能编译、URL能不能响应、ID在不在数据库里——这些都不去问模型，因为模型靠猜，编译器知道答案。
软层承接的是代码查不了的东西：回答是否切题、语气是否合适、推理是否站得住。这里确实需要一个模型，但必须是另一个模型——不同的提示词、不同的角色、对输出零参与。它是审计员，不是共同作者。同一个模型既写又评，你得到的是表演，不是控制。
顺序同样重要。硬层先把明确错误的东西筛掉，只有活下来的才送到软层审计员面前。这样昂贵的模型不必烧token去抓JSON里的拼写错误，你拿到的是两道独立的闸门，而不是一道替自己说话的闸门。
今天就能做的最简单测试
走进你的流水线，找到模型给自己的输出打分的那一处。然后问一个问题：这里有什么能用代码检查？今天就把它挪到硬层。剩下的交给一个从未碰过生成过程的独立审计员。做到这一步，"状态：正常"就重新有了意义。规则很简单，没有例外：没有人可以给自己的判决签字。
热门跟贴