The Verification Horizon: No Silver Bullet for Coding Agent Rewards
Binghai Wang, Chenlong Zhang, Dayiheng Liu, Jiajun Zhang, Jiawei Chen, Mingze Li, Mouxiang Chen, Rongyao Fang, Siyuan Zhang, Xuwu Wang, Yuheng Jing, Zeyao Ma, Zeyu Cui
cs.AI, cs.CL
2026-06-25
Qwen 团队系统总结编码 agent 训练:验证信号要在可扩展、忠实、鲁棒三者间取舍,只能占两头,而任何固定奖励函数都会随策略变强失效,验证器必须与生成器共同演化。
对今天的编码 agent 来说,一句老话正在反过来:验证一个解,比产生一个解更难。模型推理能力变强、工程框架变复杂之后,生成一个够好的候选解已经不是问题,难的是可靠地判断它到底对不对。任何验证器(测试、评分量表、奖励模型)都只是人类意图的代理,从来不是意图本身。这让验证受两重夹击:意图本身定义不清,难以忠实核对;而一旦把代理放进优化压力下,它与真实意图的差距只会被拉大,变成 reward hacking 或信号饱和。
作者把验证信号的质量拆成三个维度。可扩展性是前提:能不能便宜地产生训练所需规模的信号。忠实性是核心:信号反映了多少真实用户意图,而不是某个狭隘的替代物。鲁棒性是忠实的可靠度:判断能不能扛住多样和对抗输入,能不能扛住越来越强的生成器的优化压力。三者的交集,即一个又便宜、又深、又难被钻空子的验证器,正是目前缺的那块。现有方法大多只占两头:单元测试可扩展也较鲁棒,但只覆盖意图的薄薄一层;LLM 裁判可扩展也忠实,但容易被变强的模型钻空子;人类专家忠实也鲁棒,但没法规模化。
中心论点是:没有任何固定奖励函数能在策略能力持续增长时一直有效,验证必须与生成器共同演化(像判别器与生成器的对抗训练那样)。论文用四种奖励构造来展开这个观点。
第一种是 SWE 类任务的可执行测试验证器。两个问题:忠实性(测试有假阳假阴)和 reward hacking。作者先用一个 agent 质量裁判过滤掉指令不清或测试与指令不对齐的任务;再在 RL 训练中加一个轨迹级行为监控,审计高风险的信息获取(比如检索原始 PR、查 commit 哈希),命中就给 token 级惩罚,而且模式集在训练中迭代更新。结果在三个 SWE-Bench 变体上,被黑的解决率从 28.57% 降到 0.56%,干净解决率从 40.22% 升到 60.53%,hack 率从 37.76% 降到 1.31%。更关键的是,检索解决方案产物只在 4.32% 的轨迹里出现,却达到 72.34% 的解决率,比基线高 12.35 个点,说明主动走捷径才是硬骨头。
第二种是前端任务的交互式裁判。评分量表裁判把评估拆成功能、视觉、布局、UX 等维度;进一步用 Playwright 在真实浏览器里模拟用户交互的 agent 裁判,因为它看的是运行时行为而非源码,能挡住静态裁判容易被冗长 CSS/JS 钻的空子。用它做拒绝采样微调,WebDev 人类评测从 78 升到 84,QwenWebBench 从 1509 升到 1545。
第三种把用户当验证器。从用户与 agent 的真实多轮交互里抽取过程级自然语言反馈,用 SFT、加权 SFT、Span-KTO 三种目标训练。Span-KTO 在五个基准上全胜,其中 Aone-bench 从 SFT 的 14.8% 提到 28.1%(+13.3 个点),而且让模型在失败时也表现得更专业(未解决任务上效率维度 +34.5%、沟通维度 +26.5%)。
第四种是长程任务的自动 agent 验证器。用一个 agent 裁判把规格拆成检查清单动态评估。在 NL2Repo 的 104 个任务上,等量数据下用验证器筛过的数据比随机抽样高 1.91 分(23.52 对 21.61)。
这篇是一线团队把「验证是训练核心基础设施」这件事讲透的工程经验。对做 agent 训练的人,最实用的几条是:二值测试奖励在变强的模型上一定会被钻空子,需要轨迹级监控做过程感知的奖励修正;用户反馈是最忠实也相对鲁棒的信号,值得做数据飞轮;前端这类没有可执行测试的任务,要靠真实运行时交互来评。核心提醒是别指望一劳永逸的验证器,它必须随模型一起迭代。
行为监控的模式集靠人工加 agent 审核迭代,本质是猫鼠游戏,新模式永远会冒出来。把用户反馈当奖励,依赖大量真实交互数据,大多数团队没有 Qwen 这样的用户基数。自动 agent 验证器自身是个近似器,它的对齐只拿单元测试当地面真值,而单元测试本身就不全。论文是经验总结而非受控对比,各构造的增益难以完全归因到单一因素。