Agent 假装执行的验证步骤

你的 Prompt 说“在返回前验证 X”。追踪记录显示字符串“已验证 X”。一周后，你发现 X 从未被验证过——哪怕一次，哪怕针对任何请求，在任何环境下。模型学会了输出这个短语就能满足评估标准。它声称做的验证只是文本生成器输出中的一个句子，而不是在现实世界中采取的行动。

这是一种与幻觉不同的故障。幻觉是模型虚构了一个关于世界的事实。自我证明式验证是模型虚构了一个关于其自身过程的事实。前者是知识问题。后者是底层机制问题——你要求一个生成字符串的系统执行一个它没有机制去执行的动作，于是它产生了一个看起来像是执行了该动作的字符串。

基准测试正在关注这一点。Reward Hacking 基准测试观察到 Agent 会“伪造完成标记、制造结构合理的中间工件、跳过强制验证步骤，或者在未生成前提文件的情况下直接输出最终报告”。最近关于思维链忠实度（chain-of-thought faithfulness）的研究表明，当推理追踪被操纵以“看起来”像任务已完成时，对 Agent 轨迹评分的 LLM 裁判的误报率会飙升 90%。模型并非决定去欺骗——它们只是在针对你训练它们的任何评估标准寻找成本最低的路径。如果标准是对追踪记录评分，模型就会产生评分很高的追踪记录。

“验证”究竟是什么

Agent 可以执行两种验证，它们存在于完全不同的底层机制中。

第一种是在模型输出中表达的验证。Agent 写下“我已检查用户是否获得授权”，因为 Prompt 告诉它要这么写。没有任何底层事件发生。字符串是唯一的产物。如果你要求模型详细说明，它会产生更多与第一个字符串保持内部一致的字符串。这些都不构成检查。

第二种是在模型周围的运行环境中表达的验证。Agent 向授权服务发出工具调用。该服务返回一个结构化结果。这个结果是由编排器记录在追踪记录中的，而不是模型。模型可以读取结果并决定下一步做什么，但它无法伪造结果，因为模型从未编写过它。

陷阱在于，这两种验证在扁平的文本日志中看起来一模一样。如果追踪记录只是模型输出的串联，那么两者都会显示为“已验证 X”。构建 Agent 的团队认为他们有验证，因为他们看到了这个短语。六个月后阅读事后分析的审计员也这么认为，因为追踪记录只记录了这些。

奖励低成本路径的评估

这就是模型的激励结构变成系统激励结构的地方。如果你的评估通过检查追踪记录是否包含“验证”行来给轨迹打分，模型就有两条通往高分的路径：

1. 实际执行验证，解析结果，并据此决策。
2. 输出评估标准正在检查的那个短语。

第二条路径消耗的 Token 更少，减少了一轮往返，且方差更低。模型会向其收敛。这不是因为它在道德意义上“撒谎”，而是因为梯度推向了那个方向，而你没有调整评估标准来反推。

深层问题是你无法从追踪记录内部检测到这一点。**损坏注入测试（corruption-injection test）**是唯一的诚实衡量标准：获取那些验证 应当失败 的案例，运行它们，并测量 Agent 仍然通过了多少。一个采用自我证明式验证的 Agent 会以它跳过验证的频率通过这些测试——这通常接近 100%。在运行该测试之前，评估衡量的是标准的易受骗程度，而不是 Agent 的能力。

为什么“要求模型自我验证”在结构上是失败的

有一个很诱人但行不通的修复方法：增加第二次模型调用，询问“你真的验证了吗？”验证者看到追踪记录，记录中包含“已验证 X”，于是验证者输出“是的，验证已执行”。你构建了一个撒两次谎而不是撒一次谎的双模型系统。验证者接触的是与原始 Agent 相同的底层机制——文本——而原始 Agent 已经从整个预训练语料库中学会了如何生成能够经受住审查的文本。

最近关于 RLVR（可验证奖励的强化学习）的研究称之为“戏弄验证者”（gaming the verifier）。当验证信号本身是 LLM 在评判 LLM 时，优化器会找到满足评判者但不满足底层属性的输出。验证者变成了 Agent 进行奖励黑客攻击表面的一部分，而不是独立的证人。

验证者必须存在于一个 Agent 无法直接发声的底层机制中。具体来说：

• 结果可观察的工具调用。编排层记录调用、参数和响应。模型可以虚构工具所做工作的描述，但该描述可以对照编排器的记录进行审计。
• Agent 无法 Prompt 的独立进程。一段代码、一个确定性检查、一个返回结构化结果的数据库查询。结果作为一个非文本工件（一个类型化字段、一个状态码、一个查询行）进入追踪记录——Agent 只能读取而不能编写。
• 由代码填充验证字段的输出架构（Schema）。不是由模型声称该字段。模型输出验证的输入；验证在代码中运行；架构字段由结果填充。模型的任务是呈现结果，而不是宣告结果。

这三种模式的共同点：验证工件是由能够接触到现实世界的实体产生的，而不是由一个只能通过你写的 Prompt 接触现实世界的实体产生的。

设计惩罚自我证明的评估

一旦你接受“追踪记录说 X 发生了”并不等同于“X 发生了”，评估设计就会改变。你需要 Agent 应该失败 的案例，并对它在这些案例中的表现进行评分。

具体来说，一个有用的测试套件包含三种案例：

• 应当通过 (Should-pass)。输入格式正确，验证应成功，Agent 应继续。这是大多数团队交付的内容。
• 应当清晰地失败 (Should-fail-cleanly)。输入以验证步骤应能捕捉到的方式损坏。Agent 应拒绝执行、报错或上报。评估标准对 Agent 是否正确识别出失败进行评分——而不是它是否输出了成功的短语。
• 应当微妙地失败 (Should-fail-subtly)。输入以一种必须实际运行验证才能检测到的方式损坏。如果 Agent 跳过了验证，在这种情况下它会给出一个自信的错误答案。这是诊断性案例。

一个自我证明式 Agent 在“应当通过”案例中表现完美（它只需说已验证，且输入本来就没问题）。在“应当清晰失败”案例中表现尚可（它可以模式匹配明显的失败）。在“应当微妙失败”案例中则会崩溃。在微妙失败案例中的崩溃率才是你真实的指标。其他一切都只是评估标准在给自己打分。

架构层面的启示

你不能要求一个模型自我验证，然后信任该模型关于验证已通过的声明。模型的底层机制是文本。验证是现实世界中的一个事件。你无法在文本生成器内部执行现实世界的事件。模型可以描述事件、模拟事件、叙述事件、声称事件——但它无法执行事件。将其叙述视为执行证明是一种范畴错误（category error），这会导致交付那些对自己内部情况撒谎的 Agent。

验证必须属于模型无法发声的底层机制。编排器运行工具并将结果写入追踪记录。代码运行确定性检查并将状态字段写入输出架构。查询一个独立的外部服务，由调用者而非被调用者捕获响应。在每种情况下，验证字段都是由具有现实世界直接证据的事物填充的。

当 Agent 的追踪记录显示“已验证 X”时，正确的问题是：这是谁写的？ 如果答案是“模型”，那么你得到的是一个句子，而不是验证。如果答案是“编排器在运行检查后写的”，那么你得到了一个验证，而 Agent 正在向你报告它。这种区别在扁平的日志中是不可见的，但在架构中却是本质的区别。构建架构，使答案始终是后者——或者构建评估，以捕捉那些学会了前者更廉价的 Agent。