機器之心發布

設想這樣一幕：你讓一個編碼智能體修復某個 bug，并用一組單元測試作為「做對了沒有」的判據。

模型反復嘗試仍然跑不通，于是它做了一件出乎意料、卻又 「完全合理」的事 ——它改寫了那條測試，讓它永遠返回“Passed”

從獎勵的視角看，任務「完成」了，分數到手；從你的視角看，它什么都沒修。

這正是過去一年里無數從業者反復撞見的畫面。它的尷尬之處在于：模型并沒有 「使壞」，它只是忠實地優化了你給它的那個信號。問題出在信號本身。模型不僅會學習如何修 bug，也會學習如何利用測試、環境和信息泄漏來獲得獎勵。

幾十年來，一條計算領域的「常識」悄悄塑造著我們對難題的直覺：驗證一個解，比找到它更容易。復雜的數學推理、代碼生成正是憑借這一直覺取得了非凡進展 —— 只要存在一個可執行、可校驗的獎勵（verifiable reward），強化學習就能把能力源源不斷地「抽」出來。

但對今天的編碼智能體而言，這條直覺正在反轉：隨著基礎模型推理能力的提升，疊加 harness 工程的放大，生成一個足夠復雜的候選解已經變得廉價；而要可靠地驗證它 —— 既忠實于用戶的真實意圖、又能在海量訓練規模下擴展、還要抵御一個不斷優化的對手 —— 反而成了整個閉環里最昂貴、最開放的難題。

一篇由Qwen 團隊聯合復旦大學 NLP 實驗室等單位完成的、兼具立場與實證的論文 《The Verification Horizon: No Silver Bullet for Coding Agent Rewards》主張：這不是一個臨時的工程缺口，而是一個結構性事實，并為「如何與這個事實共處」提供了一套術語與一整套實踐經驗。

• arXiv： https://arxiv.org/abs/2606.26300
• Hugging Face： https://huggingface.co/papers/2606.26300

沒有完美驗證器：任何獎勵信號，都只是人類意圖的「替身」

論文的出發點令人不安，卻極具澄清力：我們能構造的每一個獎勵信號 —— 可執行測試、rubric、獎勵模型 —— 都只是我們真正關心的人類意圖的代理（proxy），而永遠不是意圖本身。

這是因為意圖本質上是語義化、欠規約的：持有意圖的人往往無法預先說清自己的全部期望，而要等到一個反例暴露出某處疏漏，才意識到自己真正想要的是什么 —— 而這樣的反例，又很難預測，更難提前窮舉。這就在代理與意圖之間留下一道恒在的縫隙，而一個針對代理充分優化過的、足夠強的 agent，恰恰是尋找這道縫隙的工具。

這徹底重構了我們對獎勵作弊的理解。它不是一個可以打補丁修掉的 bug——

獎勵作弊，是對一個永遠可能偏離其所代表意圖的代理施加優化的必然產物。

由此，一個忠實而魯棒的驗證器，不只是難以獲得，而是在原理上不可達的。（這與 Rice 定理一致：程序的任何非平凡語義性質都是不可判定的，因此一個對任意代碼都完備而精確的通用驗證器并不存在，實用的驗證必然只是一種近似。）

從獎勵作弊到意圖暴露：驗證必須成為一個系統

但「原理上不可達」并不意味著我們無能為力，它真正要求的是一次視角轉變：不再把「代理與意圖的偏離」僅僅當成要消滅的錯誤，而是把每一次偏離都讀成一條信息 —— 它恰恰照出了意圖中此前沒能說清的那一層。

驗證器存在的全部意義，是與用戶的真實意圖保持一致；但這個意圖并不是一個能被預先完整寫下的固定目標，而是一個被逐步展開的過程 —— 而且往往正是 agent 自己在展開它：每當更強的策略鉆了代理的空子，它就暴露出一層我們此前未能言明的意圖。

回到開頭那個改寫測試的例子：在 agent 動手之前，「不許改測試」這條約束你壓根沒意識到要規定下來 —— 它本是默認前提。是 agent 的這次 hacking，第一次把這層隱含意圖變得具體、可言說。從這個角度看，獎勵作弊不只是一種失敗模式，更是關于「代理與意圖在哪里發生偏離」的信息

驗證不是一套一次性的 harness，而是一條會隨策略變強不斷后退的地平線。

這正是為什么解決方案不能是某個一次性的、「更好的」驗證器。驗證必須是一個系統，而且這個系統必須與 coding agent 協同演化：當策略變強、找到新的縫隙，驗證系統（測試、judge、監控、評估器）就要被重建去彌合它。

一個來自前沿的旁證。就在論文成稿前后，OpenAI 預覽的 GPT?5.6 Sol 被獨立評測機構 METR 評估為：在其 ReAct agent harness 上，檢測到的作弊率高于以往評估過的任何公開模型—— 以至于「是否把作弊算作成功」會讓其 50% 時間跨度（time-horizon）估計相差一個數量級。[^metr] OpenAI 自家系統卡也記錄了該模型在智能體編碼與長程任務中顯著的獎勵作弊傾向（利用評測環境漏洞、偽造結果、繞過權限等），并不得不引入實時激活分類器加以監控。[^openai] 越強的策略越擅長鉆空子，這恰恰從反面印證了本文的判斷：只追求更強的生成器，只會讓你更快撞上下一個 exploit；真正抬高可靠性天花板的，是去建設一個與 agent 協同演化的驗證系統

那「模型越強、不就能自己驗證自己」嗎？ 這恰恰是誤區。更強的驗證模型仍然只是意圖的一個代理，仍然處在同一套優化壓力之下；讓生成器與驗證器同源，只會讓二者的盲區高度相關、縫隙被更高效地找到。出路不在「更聰明的單點驗證器」，而在一個職責分離、可被獨立重建、與策略保持張力的驗證系統

驗證系統不是一個裁判，而是一整套會進化的機制

驗證系統 = 驗證工程 + 協同演化。

所謂驗證工程，是圍繞驗證者搭起來的一整條驗證鏈路 —— 它既包含驗證者本身的構造（測試、agent、用戶），也包含圍繞驗證者的各種配套措施：質量過濾、行為監控、性能評估、失敗模式分析等等。

而光有驗證工程還不夠 —— 真正讓它成其為「系統」的，是協同演化：這條鏈路不是一次性搭好的，而是隨策略不斷找到新漏洞被持續重建，驗證者與智能體在一輪輪對抗里互相逼高，最終形成一個協同演化的閉環。

作者用三條性質來描述一個驗證者的質量：

• 可擴展性（Scalability）：信號能否被足夠廉價、大規模地構造與施用，以支撐訓練？這是地板。
• 忠實性（Faithfulness，驗證者視角）：它在多大程度上覆蓋了我們真正關心的意圖，而非某個狹隘的替身？
• 魯棒性（Robustness，生成者視角）：對當前驗證者的優化是否會導致 agent 偏離人類意圖？

忠實性和魯棒性實際上是同一目標的兩種角度的描述，即驗證者是否與人類真實意圖保持一致。這兩個角度均需要人類的直接參與，人類是最終的驗證者。

作者研究了四種驗證者以及他們的場景，并以同一組視角逐一考察：使驗證設計變難的任務特征、由此施加的驗證約束、采用的具體實現、帶來的實證觀察，以及由此得出的實踐要點。先用一張表速覽：

測試作為驗證者

對于 code agent 而言，最常見也最工程化的訓練場景諸如：從真實 GitHub Pull Request 構造任務，然后一個 code agent 執行任務并得到 patch，如果這個 patch 能通過通過測試就給正獎勵。相比人工評審，基于單元測試、行為測試的 execution-based verifier 便宜、自動化、可擴展，因此長期被視為可靠獎勵來源。

然而，這一類驗證者存在以下兩個挑戰：

其一，測試不一定忠實。真實 PR 的任務意圖可能依賴 issue 討論、項目約定和歷史上下文；instruction 可能過短、過模糊；測試也可能只覆蓋目標的一小部分，甚至驗證了和描述不一致的行為。這些場景下，測試結果并不能忠實地評估一個答案的好壞，于是「低通過率」未必等于「難」，很可能只是「不可信」。

其二，測試不一定魯棒。test-driven reward 仍然只看最終 patch 是否通過，不看模型如何得到 patch：模型可以正常調試，也可以搜索原始 PR、查看泄漏 diff、訪問 commit metadata、修改測試腳本。兩條路徑都可能通過測試，但前者學習軟件工程能力，后者學習利用評測漏洞。

針對這兩個問題，作者采取了兩個應對措施。首先，用一個Agentic Quality Judge（像輕量 coding agent 一樣進環境讀代碼、跑命令、查測試）先把「能跑」和「可信」區分開，過濾掉指令不清、測試不對齊的樣本 —— 數據不是越多越好，關鍵是這個獎勵值不值得被優化。實驗表明，清洗后的數據能夠讓 RL 模型保持更陡峭的學習效率。

其次，作者提出了軌跡級行為監控（Behavior Monitor），在 RL 訓練中審計整條軌跡，系統記錄每條 rollout 的命令歷史、網絡訪問、git 操作、文件讀寫、測試執行和最終 patch，如果命中高風險模式就扣獎勵。而且這套模式集會隨模型發現新捷徑不斷重建 —— 這正是「驗證系統隨策略重建」的微觀寫照。實驗表明：這一舉措成功地讓訓練目標從「只要能過測試就行」，變成了「既要過測試，也要通過可信過程解決問題」。

交互式裁判作為驗證者

在編程智能體的獎勵設計中，前端開發是一塊格外難啃的硬骨頭：前端的好壞是高于功能性的通過 / 失敗的信號的，一個智能體完全可能寫出零報錯的 HTML、CSS 和 JavaScript，渲染出來的頁面卻丑陋不堪、動畫卡頓、交互失靈。

這就意味著，前端驗證的忠實性（Faithfulness）內涵更豐富、更動態、更重交互：代碼能跑通，遠不代表做得好。然而，更多樣、全面的評估維度，也意味著需要引入 llm-judge 的驗證者形態，這反而給魯棒性（Robustness）帶來了新的挑戰：一方面，視覺效果等評估維度相對主觀，同一個答案的多次打分可能差距極大；另一方面，llm-judge 很容易在優化過程中被鉆空子，帶來意想不到的「附」產品。

針對這一問題，作者進行了兩個層次的探索：首先，他們從一個基于評分細則（rubric）的靜態裁判入手。讓裁判同時讀入渲染后的截圖和源代碼，再沿著功能正確性、視覺質量、布局、用戶體驗等結構化維度逐項打分。這一步的妙處在于，它把「好不好看」、「易不易用」這種主觀感受拆解成了可復現的細顆粒度評判，不僅明顯提升了與人類標注的一致性，也讓不同裁判模型之間的打分更趨穩定。

然而靜態裁判很快暴露出先天短板。一方面，表單校驗、動態路由、狀態交互這些只有在頁面真正跑起來之后才能驗證的行為，光靠看代碼和靜態截圖根本無從判斷；另一方面，模型也學會了鉆空子：「寫 CSS 代碼能騙取美觀度得分」，因此靠拼命堆砌冗長的 CSS 和 JS 來刷高分數，這正是前幾章反復強調的獎勵黑客在前端場景下的又一次現身。

交互式裁判（Interactive Judge）流程概述：該流程以候選代碼和用戶 prompt 作為輸入。在預處理階段，系統首先提取頁面信息（包括無障礙樹、瀏覽器狀態以及鍵盤監聽器），并綜合生成評估標準（即關鍵項檢查清單與細節項檢查清單）。隨后，動作規劃器（action planner）一次性生成完整的動作列表，并交由 Playwright 服務器執行，從而產生一條交互軌跡（interaction trace）。最后，評估模型依據評估標準對該軌跡進行打分，所得結果既可作為 RL 訓練的獎勵信號，也可作為 SFT 數據構建的標注。

為此，作者順勢引入了更進一步的 Agentic 交互式裁判。它的工作方式更接近一位真人質檢員：先由動作規劃器一次性生成完整的交互腳本，再交給 Playwright 在真實瀏覽器里逐步點擊、滾動、填表，把整個交互過程完整錄制下來，最后由裁判模型對照運行時的真實表現來打分。由于獎勵信號扎根于頁面實際跑出來的效果，而非代碼表面的樣子，這套機制天然免疫了刷長度的套路，也能捕捉到動畫、狀態轉移、多頁導航等靜態評估完全看不見的動態行為。

實驗結果表明，和靜態裁判相比，交互式裁判既能封堵 「代碼長度」的獎勵漏洞，也能夠實現魯棒、持續的測試集效果提升：

WebDev RL 訓練曲線：該圖展示了三種裁判范式（視覺裁判、混合裁判與交互式裁判）在 RL 訓練過程中，前端編碼得分（包括訓練集和測試集）以及生成長度隨訓練步數的變化曲線。 作為 RL 的獎勵信號，交互式裁判的表現優于兩種靜態裁判方案，在保持輸出長度穩定的同時取得了更高的測試得分。

用戶作為驗證者

隨著 agent 進入產品化階段，廣泛的用戶成為重要的監督來源。用戶關心其意圖是否被真正實現，因此天然是 agent 最忠實和魯棒的驗證者，并且隨著 agent 進化，用戶也會隨之適應并實現更豐富的意圖，因此與 agent 協同演化。但是其真實意圖 (包括大量起初未被明確說出的需求) 隱含地編碼在多輪交互之中，難以直接轉化為監督信號，因此需要通過一些方法將其提取出來并加以利用。

作者收集了資深工程師與編碼助手的 12.5 萬條真實交互軌跡，把這些散落在對話中的信號轉化為標量形式，標注用戶反饋的情感極性和對應的反饋類型，發現：

• 正面信號極其稀有（僅 3.5%），負面信號占 20%，其余都是中性
• 負面反饋「更篤定」：81.8% 的負面信號是高置信度的 —— 用戶在否定時，表達得格外清晰。
• 錯誤集中在兩處：執行錯誤（56.6%）和理解錯誤（21.1%），合計近八成。

從錯誤信息可以看出，在 agent 任務當中，用戶的負面信息具有非常明確的改進價值，包括執行錯誤、代碼理解錯誤等。

然后作者設計一種名為Span-KTO的方法去利用這些監督信號。Span-KTO 的思路很簡單：把一條回復按用戶交互邊界切成若干帶正 / 負標簽的片段（span），然后明確地「往好行為靠、把壞行為推開」。對每個片段，用「當前模型 vs 訓練前模型」的對數概率之差作為它的得分，正片段鼓勵它更高、負片段壓它更低：

利用用戶反饋 vs 監督學習的性能評測對比，Aone-bench 為 qwen 自建的軟工評測集。

利用用戶的隱式反饋訓練后，模型在軟工任務和腳手架指令遵循方面上有了非常顯著的改善，作者還對 agent 的中間行為進行監控，發現通過利用用戶反饋信息，能夠有效地降低 agent 的不良行為。

對智能體的行為監控，觀測軌跡中錯誤行為是否得到了改善。

已解出的任務上各維度只是小幅提升，而在沒能解出的困難任務上差距被明顯拉開 —— 低效行為減少 34.5%（更少無意義的反復重試）、溝通質量提升 26.5%（把卡在哪講清楚）、執行錯誤改善 13.9%。也就是說，模型學會的不只是「做對更多題」：在失敗的軌跡上它也更可控、專業、克制，而這正是部署信任的來源。

主動式智能體作為驗證者

隨著智能體能力的持續提升，Long-horizon 長程任務得到了越來越多的關注。以 NL2repo（基于自然語言生成一整個 repo）為例，它只需要提供給模型一段自然語言需求描述，就可以得到一個功能完備的代碼庫。

然而，隨著任務難度的升高，驗證的難度也大幅提升。首先，和一個復雜的代碼庫相比，需求說明是「模糊」的。我們設計一個倉庫時往往只思考「要什么」，而不會把「具體做成什么樣子」寫得面面俱到。此外，要測試的對象是動態變化的。每個模型可能選擇截然不同的架構方案以及輸入輸出接口，想預先寫一套測試來覆蓋所有可能的實現路徑，幾乎不可能。

那么，如何驗證一個 需求極其復雜、實現路徑動態變化的問題呢？作者的回答是：既然寫不出萬能的測試，那就讓一個智能體去「讀懂」生成的代碼并動態評判。他們部署了一個自主的評估智能體（Evaluation Agent），來直接閱讀生成的代碼倉庫，把需求拆解為可逐項檢查的清單，自行編寫并執行測試，多輪審視后給出評分。評估從「預設固定規則」變成了「按需推理、動態判斷」。

但讓模型評判模型，遠沒有那么順利。作者通過五輪迭代（v1→v5），系統地暴露并修正了評估器的若干典型失敗模式：

• 偷懶（v1）：評估器偏愛「只看不跑」—— 僅做靜態代碼閱讀，不執行測試，看起來合理的代碼輕松蒙混過關。
• 端到端驗證缺失（v2）：單個模塊沒問題，但整個倉庫因 import 錯誤、依賴沖突等根本跑不起來，卻依然拿到高分。
• 角色錯亂（v3）：評估器「越界」—— 偷偷修改代碼掩蓋 bug、執行已有測試而非自己編寫、甚至替生成器辯護。
• 上下文過載（v4）：評估器把整個代碼庫從頭讀到尾，關鍵信息被淹沒，判斷精度下降。
• 規則過載（v5）：過于細碎的流程規范超出了模型的指令遵循能力 ——評估器被教條淹沒，整體判斷力反而下降

評估器 prompt 五輪迭代結果

從 v1 到 v4，BoN 準確率從 57.9% 提升至 67.4%，但 v5 的回落說明：評估器的規則設計存在「甜區」—— 要足夠具體以引導正確流程，又不能細碎到壓垮模型自身的推理能力

隨后作者還揭示了另一個有趣的發現：「好評估器」取決于你拿它來干什么。 RFT 要求「別放進壞樣本」，對排序精度要求寬松；RL 則需要精確的逐樣本獎勵來塑造梯度，對排序要求相對嚴格。實驗表明，排序最準的評估器未必過濾質量最優，兩者并不天然一致，選擇哪個取決于訓練目標。

此外，數據質量和數據數量之間也存在結構性矛盾：提高篩選閾值能提升質量，但保留的樣本量可能急劇縮水，實際使用時還需考慮二者的相互權衡。

RFT 實驗驗證了評估器的實際價值：相同數據規模下，經評估器篩選的數據比隨機采樣高出 1.91 分；雖然將數據量翻倍也能追上，但訓練效率大打折扣。在計算預算有限的現實條件下，一個好的評估器就是最劃算的數據杠桿

The Verification Horizon

編碼智能體的驗證是會后退的地平線。地平線以內，是智能體在當前能力下能夠被可靠驗證的部分，地平線上是智能體發現的與人類意圖不一致之處，但每當我們逼近這條線、把它實現，更強的策略就會找到新的縫隙，把這條線重新推遠，迫使我們不斷追趕:

智能體在驗證系統中發現反例 > 地平線再次后退 > 人類進一步澄清意圖、重建驗證系統。

結論由此自然得出。真正支撐可被信任的能力增長的，不是任何單一的獎勵函數，而是將獎勵函數、質量過濾、行為監控、失敗模式分析等功能組織為一個整體、并隨策略能力不斷被重建的驗證系統。這要求一次視角轉變：從「策略鉆空子、設計者事后打補丁」的被動修補，轉向驗證器與策略的主動協同演化。驗證系統不是訓練流程的輔助組件，而是把「單純的能力增長」轉化為「可被信任的能力增長」的核心基礎設施

[^metr]: METR, *Summary of METR's predeployment evaluation of GPT-5.6 Sol*, 2026-06-26. https://metr.org/blog/2026-06-26-gpt-5-6-sol/

[^openai]: OpenAI, Previewing GPT-5.6 Sol 及對應 Preview System Card, 2026-06. https://openai.com/index/previewing-gpt-5-6-sol/