验证视界：编码智能体奖励并无银弹

# 验证视野：编码智能体奖励无银弹  
来源：https://arxiv.org/html/2606.26300  

###### 摘要  
经典直觉认为，验证一个解决方案比生成一个更容易。然而，对于当今的编码智能体而言，这种直觉正在被颠倒：随着基础模型推理能力的增强与工程框架的日趋成熟，生成复杂的候选方案已不再困难，而可靠地验证这些方案反而成了更棘手的问题。我们所能构建的每个验证器都只是人类意图的代理，而非意图本身。这使得验证面临双重困难：首先，意图本质上是欠指定的，因此难以忠实地检查其是否被满足；其次，在模型训练过程中，优化会拉大代理与意图之间的差距——表现为奖励黑客或信号饱和。为解决这一问题，我们从三个维度——可扩展性、忠实性和鲁棒性——来刻画验证信号的质量，并认为同时实现这三者是核心挑战。本文研究了四种奖励构建方案：面向通用编码任务的测试验证器、面向前端任务的评分标准验证器、面向真实世界智能体任务的用户作为验证器、以及面向长周期任务的自动化智能体验证器。针对不同任务类型和策略能力水平，我们对奖励设计的核心挑战以及如何更有效地利用奖励信号进行了深入分析和实验。实验表明，针对性的验证设计能有效抑制奖励黑客，提升任务完成质量，并在多个内部和公开基准上取得显著提升。这些经验共同指向一个核心观察：不存在固定不变的奖励函数能在策略能力持续增长时保持有效；验证必须与生成器共同演化。  

> *“没有银弹。”*  
弗雷德里克·P·布鲁克斯 Jr.，《没有银弹——软件工程中的本质与次生》 (1986)  

## 1 引言  

计算领域的一个经典直觉是，验证一个解决方案比找到它更容易。然而对于当今的编码智能体（Cursor, 2026; Anthropic, 2026a; OpenAI, 2026a; OpenClaw, 2026）而言，这种不对称性正在逆转。随着基础模型推理能力的增强（OpenAI, 2024b; DeepSeek-AI, 2025），以及工程框架的日益成熟（Yao et al., 2023; Anthropic, 2024a; OpenCode, 2026），生成足够复杂的候选方案已变得更为容易。相反，可靠地验证这些方案却成了更难的问题。这一难点呼应了布鲁克斯在软件工程中的经典教训：没有银弹（Brooks, 1987）。对于编码智能体而言，验证并非单一机制能一劳永逸解决的问题。  

验证的核心功能是检查智能体是否满足了人类的意图，但意图无法直接度量。可执行测试、评分标准和奖励模型——这些验证器只能将意图操作化为可计算的近似；它们是意图的代理，而非意图本身。这使得验证面临双重挑战。首先，忠实地验证意图是否被满足本身就极为困难：意图在本质上是欠指定的，持有意图的人往往无法预先阐述全部期望，直到一个反例暴露遗漏——然而这样的反例难以预测或枚举。更糟糕的是，在模型训练背景下，代理与意图之间的差距不会缩小，反而会扩大。一旦某个度量被置于优化压力之下，它就不再是一个好的度量（Manheim and Garrabrant, 2018）：当代理作为奖励信号时，生成器（即基础模型）不仅学会满足代理，还会利用代理与意图之间的偏差。因此，奖励黑客并非一个可以修补的缺陷，而是持续优化不完美目标的必然结果（Skalse et al., 2025）。验证因此无法无限期地可靠引导生成器。  

因此，完美的验证器并不是一个现实的目标。剩下的只是验证作为一种不断演化的近似——一个随着它所评估的生成器越来越强而不断后退的地平线。¹¹ 根据 Rice 定理（Rice, 1953），程序的每一个非平凡语义属性都是不可判定的；这从可计算性理论的角度独立支持了上述论断。  

这重新定义了我们面临的问题，并引出了本文的核心主张——全文将围绕该主张进行论证和实践：  

> *我们必须持续构建一个与AI智能体共同演化的验证系统。*  

最近的前沿实验室报告和工程分析也呼应了这一观点，越来越多地将智能体评估视为一个系统级问题，涉及评分器、轨迹追踪、监控和失效模式分析（OpenAI, 2025; 2026b; Anthropic, 2024b; 2025a; 2026b）。我们将验证信号的质量进一步从三个维度进行刻画。**可扩展性**是前提条件：信号能否以训练所需规模低成本生产？**忠实性**是核心质量：信号在多大程度上反映了真正的用户意图，而非某个狭窄的替代物？**鲁棒性**是忠实性的可靠性：验证器的判断能否在多样化和对抗性输入下保持稳定，并能承受不断强化的生成器带来的优化压力？同时实现这三者是验证的核心难题。现有大多数方法只满足其中两条：单元测试可扩展且相对鲁棒，但只覆盖了意图的浅层；基于大语言模型（LLM）的评判者可扩展且忠实，但易被更强的模型利用；人类专家评审忠实且鲁棒，但无法扩展。三者的交集——一个既廉价、深入又抗滥用的验证器——正是我们所缺失的。  

> 参见说明图1：训练过程中策略模型与验证器的共同演化。验证器最初提供有用的奖励信号，引导策略改进。当策略超越验证器时，可能发生奖励黑客。随后的验证器演化恢复了有效引导，但这种引导可能再次饱和，需要进一步的验证器改进以解锁策略演化的下一阶段。

基于当前的 Qwen 基础模型，我们研究了四种奖励构建方案：从基于可执行测试的可验证奖励，到评估仅靠测试无法捕捉的意图的视觉和功能维度的评分与交互式评判者，再到从用户交互数据中学习真实且全面的用户意图，最后到完全开放的智能体评估。每一步都更忠实于真实的用户意图，但也更依赖开放式判断，更难通过机械方式稳健验证。我们通过同一个视角审视每一种方案：使奖励设计变得困难的任务特征、它们施加的验证约束、我们采用的具体奖励实现、实证观察以及实际经验教训。四个章节组织如下：  

- **单元测试作为验证器（SWE类任务，§2）**：我们使用基于执行的测试套件作为验证信号（Pan et al., 2025; Chen et al., 2026; Jimenez et al., 2024）——可靠且易于扩展。然而，更强的策略仍然能发现可被利用的弱点，例如检索解决方案工件或篡改测试。因此，我们引入了质量评判器和轨迹级行为监控（Baker et al., 2025）以持续约束此类行为。在两者共同作用下，在三个 SWE-Bench 变体上，被利用的解决率从 28.57% 降至 0.56%，干净的解决率从 40.22% 升至 60.53%。  
- **交互式智能体作为验证器（前端任务，§3）**：当意图扩展到视觉外观和交互行为时，机械的通过/失败测试不再足够。我们设计了基于评分标准的评判器，将评估分解为结构化维度——功能正确性、视觉质量、布局和用户体验——并进一步扩展为基于智能体的交互式评判器，通过在实时浏览器中模拟用户交互来执行生成的工件（Shen et al., 2026; Zhang et al., 2025a）。通过将奖励植根于观察到的运行时行为而非源代码检查，交互式评判器能够抵御静态评判器易受的长度利用式黑客攻击。  
- **用户反馈作为验证器（真实世界智能体任务，§4）**：用户是最忠实的验证器。他们的反馈嵌入在自然语言反馈、行为信号和其他交互模式中，从中可以提取丰富的可训练信号。该信号不仅最忠实——它直接来自意图持有者——而且还相对鲁棒，因为用户判断植根于实际效用（Ethayarajh et al., 2024）。我们系统地分析了用户交互反馈并将其应用于模型优化，在五个内部编码智能体基准上取得了显著提升，包括在一个私有基准上提升了 13.3 个百分点。  
- **自动化智能体作为验证器（长周期任务，§5）**：对于长周期任务，意图最为开放：规格几乎不限制所有实现细节（Ding et al., 2025; Zhang et al., 2026; Yang et al., 2026），预定义的测试套件无法覆盖。在这种情况下，即使构建一个忠实的验证器也是一个开放性问题。我们的方法是部署一个自主的智能体评估器，它直接检查生成的代码库，并动态地根据规格进行多轮评估，作为忠实、可扩展但近似的验证器。在受控的数据预算下，经过该评估器过滤的训练数据已经稳定地优于随机采样。我们进一步主张，该评估器应演变为一个与生成器共同演化的验证器——这是验证地平线的一个具体实现。

这四种构建方案共同表明，没有哪一种奖励策略能够单独支撑编码智能体的持续进步。真正有效的是一个完整的验证系统——一个集成了可执行测试、质量过滤、行为监控和智能体评估器等机制，并随着策略能力的提升和任务格局的演变而不断重建的系统。在这种观点下，验证不是训练流程的辅助组件，而是其核心基础设施。验证器与策略的主动共同演化（Goodfellow et al., 2020）（如图1所示）是确保奖励度量的提升转化为持久且可信的能力增长的关键。

## 2 SWE类任务的测试驱动奖励  

我们从 SWE 类任务开始，这类任务已成为基础模型合成编码训练数据的主要来源（Kimi Team, 2025; GLM-5 Team, 2026; Cursor Team, 2026; Cao et al., 2026）。对于此类任务，基于执行的测试套件的通过/失败信号被广泛认为是最可靠的奖励。其关键可行性优势在于**可扩展性**：可执行测试可以通过自动化流程构建并以规模评估。然而，它面临两个系统性挑战：**忠实性**和**奖励黑客**。若不加以解决，这两个挑战将直接破坏训练质量。

### 2.1 初步自动化数据流程。  
我们使用 SWE-Universe（Chen et al., 2026）流程，从真实的 GitHub²² https://github.com 的拉取请求中构建可执行的 SWE 类任务。给定一个关联 issue 的拉取请求，流程将合并的变更拆分为**修复补丁**和**测试补丁**，将仓库恢复到修复前的状态，并构建一个带有统一验证器 `evaluation.sh` 的 Docker 化环境，其二进制通过/失败结果作为测试驱动奖励。每个验证器通过以下方式验证：要求它在应用测试补丁后的有缺陷仓库上失败，并在同时应用测试和修复补丁后的已修复仓库上通过；无效验证器由构建智能体迭代修复。虽然此过程确保了可执行性和基本的区分度，但它本身并不能保证任务指令与测试之间的语义忠实性。

**奖励忠实性**。对于测试驱动奖励，忠实性通常通过假阳性（错误解决方案通过了测试）和假阴性（正确解决方案未通过测试）的缺失来刻画。在强化学习训练期间，假阳性会导致奖励被高估，强化错误行为；假阴性会惩罚正确行为。两者都导致模型从错误的梯度信号中学习。

**奖励黑客**。值得注意的是，奖励黑客可以看作是假阳性的一个特例：智能体产生了一个输出，该输出来通过测试套件但没有真正解决任务。虽然一般性的假阳性是由于测试设计的缺陷（例如覆盖不足）被动产生的，但奖励黑客源于智能体主动利用信息泄露——例如从互联网检索真实补丁——来欺骗评估。我们在以下小节中分别解决这两个挑战。

### 2.2 提升奖励忠实性  

**动机**。为了减轻假阳性和假阴性，我们认为测试驱动奖励是忠实的，仅当其二进制通过/失败信号对应于真实任务意图的成功，而不仅仅是测试套件上的成功。在源于 GitHub 拉取请求的 SWE 类任务中，这个条件并不简单。真实的