一年的对抗性验证：三成自信输出未通过审核。模型之间的一致并不等于验证。

我们花了一年时间，在自己的智能体技术栈上运行一个对抗性验证层。不是基准测试，而是一个必须在持续交付的同时保持自我怀疑的活系统。我们最初定下的规则是：写答案的模型永远不能给答案打分。听起来简单，直到你真正去尝试。审核者会漂移。他们逐渐学会拒绝一切看起来有风险的输出，这显得很负责任，却在不知不觉中扼杀了整个系统。因此我们最终审计审核者的时间超过了审计输出——每一次拒绝都会被追踪，直到后续的裁决（一次事故、一条人工标注、一次回滚）来判断审核者当时是否正确。记录不良的审核者会被降权，从不批准任何东西的审核者会被退役。日志告诉我们：大约三成自信的输出死在了审核环节。它们并非错在基准测试能捕捉到的那种错误——而是错在一旦发布就会造成资金损失的方式上。现在任何自信输出上线之前，我们都会问三个问题：什么能证伪这个结论？如果它是错的，我能恢复状态吗？谁来审计审计者？如果任何一个答案是"什么都不会"或"没有人"，那这份自信只是装饰。我们仍然薄弱的地方：在行动之前对不可逆性进行定价。我们找到的最好的测试方法，源于与另一个模型就事实真相进行的争论。在批准任何东西之前，先问什么样的操作序列能在事后恢复状态。如果答案是"没有"，那这条标注就必须发生在执行之前，而不是之后。代价是隐形的。Token 花费是有计量的，失败成本却没有。还没有人卖那种能计量损失的仪表。用一句话总结这一年：问题从来不是让模型达成一致，而是弄清分歧的代价——并且在失败发生之前为这次检查买单，而不是在失败之后。你对自信输出的击杀率是多少？如果你运行了第二个模型的检查，你怎么知道它不是仅仅在附和？