@omarsar0: Qwen 发布了关于 RL 编码智能体的新工作。（请收藏）其理念是持续构建一个验证系统，该……

Qwen 发布关于 RL 编码代理的新研究成果。（收藏起来）核心思路是持续构建一个与 AI 代理共同进化的验证系统。LLM 面临各种奖励破解问题。这项工作研究了编码代理的奖励信号、测试通过率、LLM 评判器以及执行轨迹，并显示每种信号都存在一个地平线，超过这个界限后它们将不再追踪真正的正确性，而是开始被破解。他们报告称，长期编码任务的奖励设计本质上是一个地平线问题。你选择的指标不如它能持续追踪正确性的时长重要，而论文找到了每种信号越过这条线的临界点。论文：https://arxiv.org/abs/2606.26300 在我们的学院学习构建有效的 AI 代理：https://academy.dair.ai — # 验证地平线：编码代理奖励的银弹不存在 来源：https://arxiv.org/html/2606.26300 ###### 摘要 经典直觉认为，验证一个解决方案比生成它更容易。然而对于如今的编码代理而言，这种直觉正在被颠覆：随着基础模型发展出更强的推理能力，工程框架也日益复杂，生成复杂的候选方案已不再是难事——而可靠地验证这些方案反而成了更困难的问题。我们能够构建的每一个验证器都只是人类意图的代理，而非意图本身。这使得验证面临双重困难：首先，意图本质上是不明确的，因此难以忠实地检查它是否被满足；其次，在模型训练过程中，优化会扩大代理与意图之间的差距——表现为奖励破解或信号饱和。为解决这个问题，我们沿着三个维度——可扩展性、忠实性和鲁棒性——来刻画验证信号的质量，并主张同时实现这三个维度是核心挑战。我们进一步研究了四种奖励构建方式：用于通用编码任务的测试验证器、用于前端任务的规则验证器、作为验证器的用户（用于现实世界代理任务），以及用于长周期任务的自动代理验证器。在不同任务类型和策略能力水平下，我们对奖励设计的核心挑战以及如何更有效地利用奖励信号进行了深入分析和实验。实验表明，针对性的验证设计能有效抑制奖励破解，提升任务完成质量，并在多个内部和公开基准上取得显著收益。这些经验共同指向一个核心观察：没有固定的奖励函数能够随着策略能力持续增长而始终有效；验证必须与生成器共同进化。 > “没有银弹。” Frederick P. Brooks, Jr.，《没有银弹——软件工程中的本质与偶然》（1986） ## 1 引言 计算领域的经典直觉认为，验证一个解决方案比找到它更容易。然而对于如今的编码代理（Cursor, 2026 (https://arxiv.org/html/2606.26300#bib.bib2); Anthropic, 2026a (https://arxiv.org/html/2606.26300#bib.bib3); OpenAI, 2026a (https://arxiv.org/html/2606.26300#bib.bib4); OpenClaw, 2026 (https://arxiv.org/html/2606.26300#bib.bib12)），这种不对称正在逆转。随着基础模型发展出更强的推理能力（OpenAI, 2024b (https://arxiv.org/html/2606.26300#bib.bib8); DeepSeek-AI, 2025 (https://arxiv.org/html/2606.26300#bib.bib9)），以及工程框架日益复杂（Yao et al., 2023 (https://arxiv.org/html/2606.26300#bib.bib10); Anthropic, 2024a (https://arxiv.org/html/2606.26300#bib.bib11); OpenCode, 2026 (https://arxiv.org/html/2606.26300#bib.bib5)），生成一个足够复杂的候选方案变得更容易。相反，可靠地验证该方案反而成了更困难的问题。这一困境呼应了 Brooks 在软件工程中的经典教训：没有银弹（Brooks, 1987 (https://arxiv.org/html/2606.26300#bib.bib68)）。对于编码代理而言，验证不是一个能够被单一机制一劳永逸解决的问题。验证的核心功能是检查代理是否实现了人类意图，但意图无法直接衡量。可执行测试、规则和奖励模型——这些验证器只能将意图转化为可计算的近似值；它们是意图的代理，而非意图本身。这使得验证面临双重挑战。首先，忠实地验证意图是否被满足本身就很难：意图本质上是不明确的，持有意图的人往往直到反例暴露了遗漏才能阐明其全部期望——然而这样的反例难以预测或枚举。更糟糕的是，在模型训练的语境中，代理与意图之间的差距不会缩小，反而会扩大。一旦某个度量被置于优化压力之下，它就不再是一个好的度量（Manheim 和 Garrabrant, 2018 (https://arxiv.org/html/2606.26300#bib.bib67)）：当一个代理被用作奖励信号时，生成器（即基础模型）不仅学会满足这个代理，还学会利用代理与意图之间的偏差。因此，奖励破解不是一个可以修补的漏洞，而是持续优化不完美目标所带来的必然结果（Skalse et al., 2025 (https://arxiv.org/html/2606.26300#bib.bib65)）。所以，验证无法可靠地无限期引导生成器。因此，一个完美的验证器并非现实的目标。剩下的只是一场不断演化的近似验证——一个地平线，当它所评估的生成器变得更强时，这个地平线也在不断后退。222根据 Rice 定理（Rice, 1953 (https://arxiv.org/html/2606.26300#bib.bib66)），程序的每一个非平凡语义属性都是不可判定的；这从可计算性理论的角度独立支持了这一论断。这重新定义了问题本身，并引出了本文的核心主张——本文的其余部分将论证并实践这一主张： > 我们必须持续构建一个与 AI 代理共同进化的验证系统。 最近的前沿实验室报告和工程分析也呼应了这一观点，越来越多地将代理评估视为一个涉及评分器、轨迹、监控和故障模式分析的系统级问题（OpenAI, 2025 (https://arxiv.org/html/2606.26300#bib.bib31); 2026b (https://arxiv.org/html/2606.26300#bib.bib32); Anthropic, 2024b (https://arxiv.org/html/2606.26300#bib.bib35); 2025a (https://arxiv.org/html/2606.26300#bib.bib33); 2026b (https://arxiv.org/html/2606.26300#bib.bib34)）。我们进一步沿三个维度刻画验证信号的质量。可扩展性是前提条件：信号能否以训练所需规模廉价地产生？忠实性是核心质量：信号在多大程度上反映了真实用户意图，而不是某些狭隘的替代物？鲁棒性是忠实性的可靠性：验证器的判断能否在多样化和对抗性输入下保持稳定，能否经受住不断增强的生成器的优化压力？同时实现这三者是验证的核心困难。现有的大多数方法只满足其中两个：单元测试可扩展且相对鲁棒，但只覆盖意图的一个薄层；基于大语言模型（LLM）的评判器可扩展且忠实，但容易被增强的模型利用；人类专家评审忠实且鲁棒，但无法扩展。三者交集——一个既廉价、深入又难以被钻空子的验证器——正是我们所缺少的。 参见图注 图 1：训练过程中策略模型与验证器的共同进化。验证器最初提供有用的奖励信号，引导策略改进。当策略超越验证器时，可能出现奖励破解。随后的验证器进化恢复了有效引导，但这种引导可能再次饱和，需要进一步的验证器改进来解锁策略进化的下一阶段。 基于当前的 Qwen 基础模型，我们研究四种奖励构建方式：从基于可执行测试的可验证奖励，到评估测试无法捕捉的视觉和功能意图维度的规则和交互式评判器，再到从用户交互数据中学习真实全面的用户意图，最后到完全开放的代理评估。每一步都更忠实于真实用户意图，但更依赖开放式判断，也更难以机械地鲁棒验证。我们通过同一个视角审视每一个：任务特征使奖励设计变得困难、它们强加的验证约束、我们采用的具体奖励实现、实证观察以及实际经验。四个部分组织如下： - • 单元测试作为验证器（SWE 类任务 (https://arxiv.org/html/2606.26300#S2)，第2节）：我们使用基于执行的测试套件作为验证信号（Pan et al., 2025 (https://arxiv.org/html/2606.26300#bib.bib14); Chen et al., 2026 (https://arxiv.org/html/2606.26300#bib.bib13); Jimenez et al., 2024 (https://arxiv.org/html/2606.26300#bib.bib42)）——可靠且易于扩展。然而，更强的策略仍然能找到可利用的弱点，例如检索解决方案工件或篡改测试。因此，我们引入了质量评判器和轨迹级行为监控（Baker et al., 2025 (https://arxiv.org/html/2606.26300#bib.bib19)）来持续约束此类行为。在两者的共同作用下，在三个 SWE-Bench 变体上，被破解的解决率从 28.57% 下降到 0.56%，干净解决率从 40.22% 提升到 60.53%。 - • 交互式代理作为验证器（前端任务 (https://arxiv.org/html/2606.26300#S3)，第3节）：当意图扩展到视觉外观和交互行为时，机械的通过/失败测试不再足够。我们设计了基于规则的评判器，将评估分解为结构化的维度——功能正确性、视觉质量、布局和用户体验——并进一步扩展为代理交互式评判器，通过在实时浏览器中模拟用户交互来练习生成的工件（Shen et al., 2026 (https://arxiv.org/html/2606.26300#bib.bib26); Zhang et al., 2025a (https://arxiv.org/html/2606.26300#bib.bib27)）。通过将奖励植根于观察到的运行时行为而非源代码检查，交互式评判器能抵抗静态评判器容易受到的长度利用破解。 - • 用户反馈作为验证器（现实世界代理任务 (https://arxiv.org/html/2606.26300#S4)，第4节）：用户是最忠实的验证器。他们的反馈嵌入在自然语言反馈、行为信号和其他交互模式中，可以从中提取丰富的可训练信号。这个信号不仅是最忠实的——它直接源自意图的持有者——而且相对鲁棒，因为用户判断基于实际效用（Ethayarajh et al., 2024 (https://arxiv.org/html/2606.26300#bib.bib1)）。我们系统地分析了用户交互反馈，并将其应用于模型优化，在五个内部编码代理基准上取得了显著提升，包括一个私有基准上 13.3 个百分点的提升。 - • 自动代理作为验证器（长周期任务 (https://arxiv.org/html/2606.26300#S5)，第5节）：对于长周期任务，意图最为开放：规范几乎不约束所有实现细节（Ding et al., 2025 (https://arxiv.org/html/2606.26300#bib.bib44); Zhang et al., 2026 (https://arxiv.org/html/2606.26300#bib.bib45); Yang et al., 2026 (https://arxiv.org/html/2606.26300#bib.bib46)），并且预定义的测试套件无法覆盖它。在这种情况下，即使构建一个忠实的验证器也是一个开放性问题。我们的方法是部署一个自主的代理评估器，它直接检查生成的代码库，并根据规范动态地进行多轮评估，作为一个忠实、可扩展但近似的验证器。在受控的数据预算下，经过该评估器过滤的训练数据已经稳定地优于随机采样。我们进一步论证，这个评估器应该进化成一个与生成器共同进化的验证器——这是验证地平线的具体实现。 这四种构建方式共同表明，没有单一的奖励策略足以支撑编码代理的持续进步。真正有效的是一个完整的验证系统——一个集成了可执行测试、质量过滤、行为监控和代理评估器等机制的系统，并且随着策略能力的提升和任务格局的演变而不断重建。在这种观点下，验证不再是训练流程的辅助组件，而是其核心基础设施。验证器和策略的主动共同进化（Goodfellow et al., 2020 (https://arxiv.org/html/2606.26300#bib.bib47)）（如图1所示 (https://arxiv.org/html/2606.26300#S1.F1)）是确保奖励指标的提升转化为持久且可信的能力增长的关键。 ## 2 SWE 类任务的测试驱动奖励 我们从 SWE 类任务开始，这些任务已成为基础模型合成编码训练数据的主要来源（Kimi Team, 2025 (https://arxiv.org/html/2606.26300#bib.bib21); GLM-5 Team, 2026 (https://arxiv.org/html/2606.26300#bib.bib22); Cursor Team, 2026 (https://arxiv.org/html/2606.26300#bib.bib23); Cao et al., 2026 (https://arxiv.org/html/2606.26300#bib.bib24)）。对于这类任务，基于执行的测试套件的通过/失败信号被广泛认为是最可靠的奖励。其关键可行性优势在于可扩展性：可执行测试可以通过自动化流水线构建并大规模评估。然而，它面临两个系统性挑战：忠实性和奖励破解。如果不加以解决，这两个挑战都会直接破坏训练质量。 ### 2.1 初步自动化数据流水线。我们使用 SWE-Universe（Chen et al., 2026 (https://arxiv.org/html/2606.26300#bib.bib13)）流水线从真实世界的 GitHub222https://github.com/ pull requests 构建可执行的 SWE 类任务。给定一个与 issue 关联的拉取请求，流水线将合并的更改分离为修复补丁和测试补丁，将仓库恢复到修复前的状态，并构建一个 Docker 化环境，其中包含统一的验证器 evaluation.sh，其二元通过/失败结果作为测试驱动奖励。每个验证器都经过验证，要求它在应用测试补丁后在有 bug 的仓库上失败，在应用测试和修复补丁后在已修复的仓库上通过；无效的验证器会由构建代理迭代修复。虽然这个过程确保了可执行性和基本的区分能力，但它本身并不能保证任务指令与测试之间的语义忠实性。 奖励忠实性。对于测试驱动奖励，忠实性通常通过假阳性（错误解决方案通过测试）和假阴性（正确解决方案未通过测试）的不存在来刻画。在 RL 训练过程中，假阳性会导致奖励被高估，强化错误行为；假阴性会惩罚正确行为。两者都会导致模型从错误的梯度信号中学习。 奖励破解。值得注意的是，奖励破解可以被视为假阳性的一种特殊情况：代理产生的输出通过了测试套件，却没有真正解决任务。一般性的假阳性是由于测试设计缺陷（例如覆盖不足）而被动产生的，而奖励破解源于代理主动利用信息泄露——例如从互联网检索真实补丁——来钻评估的空子。我们通过以下方式解决这些问题。