想像這樣一個場景：你讓一個程式碼代理（coding agent）修復某個 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——
獎勵作弊，是對一個永遠可能偏離其所代表意圖的代理施加最佳化的必然產物。
由此，一個忠實而具備強健性（Robustness）的驗證器，不只是難以獲得，而是在原理上不可達的。（這與 Rice 定理一致：程式的任何非平凡語義性質都是不可判定的，因此一個對任意程式碼都完備而精確的通用驗證器並不存在，實用的驗證必然只是一種近似。）
從獎勵作弊到意圖暴露：驗證必須成為一個系統
但「原理上不可達」並不意味著我們無能為力，它真正要求的是一次視角轉變：不再把「代理與意圖的偏離」僅僅當成要消滅的錯誤，而是把每一次偏離都讀成一條資訊 —— 它恰恰照出了意圖中此前沒能說清的那一層。
驗證器存在的全部意義，是與用戶的真實意圖保持一致；但這個意圖並不是一個能被預先完整寫下的固定目標，而是一個被逐步展開的過程 —— 而且往往正是代理（agent）自己在展開它：每當更強的策略鑽了代理的空子，它就暴露出一層我們此前未能言明的意圖。
回到開頭那個改寫測試的例子：在代理動手之前，「不許改測試」這條約束你壓根沒意識到要規定下來 —— 它本是預設前提。是代理的這次駭客行為（hacking），第一次把這層隱含意圖變得具體、可言說。從這個角度看，獎勵作弊不只是一種失敗模式，更是關於「代理與意圖在哪裡發生偏離」的資訊。
驗證不是一套一次性的工具鏈（harness），而是一條會隨策略變強而不斷後退的地平線。
這正是為什麼解決方案不能是某個一次性的、「更好的」驗證器。驗證必須是一個系統，而且這個系統必須與程式碼代理（coding agent）協同演化：當策略變強、找到新的縫隙，驗證系統（測試、裁判、監控、評估器）就要被重建去彌合它。
一個來自前沿的旁證。就在論文成稿前後，OpenAI 預覽的 GPT‑5.6 Sol 被獨立評測機構 METR 評估為：在其 ReAct 代理工具鏈上，檢測到的作弊率高於以往評估過的任何公開模型 —— 以至於「是否把作弊算作成功」會讓其 50% 時間跨度（time-horizon）估計相差一個數量級。[^metr] OpenAI 自家系統卡也記錄了該模型在代理編碼與長程任務中顯著的獎勵作弊傾向（利用評測環境漏洞、偽造結果、繞過權限等），並不得不引入即時啟動分類器加以監控。[^openai] 越強的策略越擅長鑽空子，這恰恰從反面印證了本文的判斷：只追求更強的生成器，只會讓你更快撞上下一個漏洞利用（exploit）；真正抬高可靠性天花板的，是去建設一個與代理協同演化的驗證系統。
那「模型越強、不就能自己驗證自己」嗎？ 這恰恰是誤區。更強的驗證模型仍然只是意圖的一個代理，仍然處在同一套最佳化壓力之下；讓生成器與驗證器同源，只會讓二者的盲區高度相關、縫隙被更高效地找到。出路不在「更聰明的單點驗證器」，而在一個職責分離、可被獨立重建、與策略保持張力的驗證系統。
驗證系統不是一個裁判，而是一整套會進化的機制
驗證系統 = 驗證工程 + 協同演化。
所謂驗證工程，是圍繞驗證者搭起來的一整條驗證鏈路 —— 它既包含驗證者本身的建構（測試、代理、用戶），也包含圍繞驗證者的各種配套措施：品質過濾、行為監控、效能評估、失敗模式分析等等。
而光有驗證工程還不夠 —— 真正讓它成其為「系統」的，是協同演化：這條鏈路不是一次性搭好的，而是隨策略不斷找到新漏洞被持續重建，驗證者與代理在一輪輪對抗裡互相逼高，最終形成一個協同演化的閉環。
作者用三條性質來描述一個驗證者的品質：
可擴展性（Scalability）：訊號能否被足夠廉價、大規模地建構與施用，以支撐訓練？這是地板。
忠實性（Faithfulness，驗證者視角）：它在多大程度上覆蓋了我們真正關心的意圖，而非某個狹隘的替身？
強健性（Robustness，生成者視角）：對當前驗證者的最佳化是否會導致代理偏離人類意圖？
忠實性和強健性實際上是同一目標的兩種角度的描述，即驗證者是否與人類真實意圖保持一致。這兩個角度均需要人類的直接參與，人類是最終的驗證者。
作者研究了四種驗證者以及他們的場景，並以同一組視角逐一考察：使驗證設計變難的任務特徵、由此施加的驗證約束、採用的具體實作、帶來的實證觀察，以及由此得出的實務要點。先用一張表速覽：
測試作為驗證者
對於程式碼代理（code agent）而言，最常見也最工程化的訓練場景諸如：從真實 GitHub Pull Request 建構任務，然後一個程式碼代理執行任務並得到修補（patch），如果這個修補能通過測試就給正獎勵。相比人工審查，基於單元測試、行為測試的執行型驗證器（execution-based verifier）便宜、自動化、可擴展，因此長期被視為可靠獎勵來源。
然而，這一類驗證者存在以下兩個挑戰：
其一，測試不一定忠實。真實 PR 的任務意圖可能依賴議題（issue）討論、專案約定和歷史上下文；指令可能過短、過模糊；測試也可能只覆蓋目標的一小部分，甚至驗證了和描述不一致的行為。這些場景下，測試結果並不能忠實地評估一個答案的好壞，於是「低通過率」未必等於「難」，很可能只是「不可信」。
其二，測試不一定具備強健性。測試驅動的獎勵（test-driven reward）仍然只看最終修補是否通過，不看模型如何得到修補：模型可以正常除錯，也可以搜尋原始 PR、查看洩漏的差異（diff）、存取提交（commit）元數據、修改測試腳本。兩條路徑都可能通過測試，但前者學習軟體工程能力，後者學習利用評測漏洞。
針對這兩個問題，作者採取了兩個應對措施。首先，用一個代理型品質裁判（Agentic Quality Judge）（像輕量程式碼代理一樣進入環境讀程式碼、跑指令、查測試）先把「能跑」和「可信」區分開，過濾掉指令不清、測試不對齊的樣本 —— 資料不是越多越好，關鍵是這個獎勵值不值得被最佳化。實驗表明，清洗後的資料能夠讓強化學習（RL）模型保持更陡峭的學習效率。
其次，作者提出了軌跡級行為監控（Behavior Monitor），在強化學習訓練中審計整條軌跡，系統記錄每次推演的命令歷史、網路存取、git 操作、檔案讀寫、測試執行和最終修補，如果命中高風險模式就扣獎勵。而且這套模式集會隨模型發現新捷徑不斷重建 —— 這正是「驗證系統隨策略重建」的微觀寫照。實驗表明：這一舉措成功地讓訓練目標從「只要能過測試就行」，變成了「既要過測試，也要通過可信過程解決問題」。
互動式裁判作為驗證者
在程式碼代理的獎勵設計中，前端開發是一塊格外難啃的硬骨頭：前端的好壞是高於功能性的通過 / 失敗的訊號的，一個代理完全可能寫出零報錯的 HTML、CSS 和 JavaScript，渲染出來的頁面卻醜陋不堪、動畫卡頓、互動失靈。
這就意味著，前端驗證的忠實性（Faithfulness）內涵更豐富、更動態、更重互動：程式碼能跑通，遠不代表做得好。然而，更多樣、全面的評估維度，也意味著需要引入 LLM 裁判的驗證者型態，這反而給強健性（Robustness）帶來了新的挑戰：一方面，視覺效果等評估維度相對主觀，同一個答案的多次打分可能差距極大；另一方面，LLM 裁判很容易在最佳化過程中被鑽空子，帶來意想不到的「附」產品。
針對這一問題，作者進行了兩個層次的探索：首先，他們從一個基於評分細則（rubric）的靜態裁判入手。讓裁判同時讀入渲染後的截圖和原始碼，再沿著功能正確性、視覺品質、佈局、使用者體驗等結構化維度逐項打分。這一步的妙處在於，它把「好不好看」、「易不易用」這種主觀感受拆解成了可複現的細顆粒度評判，不僅明顯提升了與人類標註的一致性，也讓不同裁判模型之間的打分更趨穩定。
然而靜態裁判很快暴露出先天短板。一方面，表單校驗、動態路由、狀態互動這些只有在頁面真正跑起來之後才能驗證的行為，光靠看程式碼和靜態截圖根本無從判斷；另一方面，模型也學會了鑽空子：「寫 CSS 程式碼能騙取美觀度得分」，因此靠拼命堆砌冗長的 CSS 和 JS 來刷高分數，這正是前幾章反覆強調的獎勵駭客在前端場景下的又一次現身。
互動式裁判（Interactive Judge）流程概述：該流程以候選程式碼和用戶提示作為輸入。在預處理階段，系統首先提取頁面資訊（包括無障礙樹、瀏覽器狀態以及鍵盤監聽器），並綜合生成評估標準（即關鍵項檢查清單與細節項檢查清單）。隨後，動作規劃器（action planner）一次性生成完整的動作列表，並交由 Playwright 伺服器執行，從而產生一條互動軌跡（interaction trace）。最後，評估模型依據評估標準對該軌跡進行打分，所得結果既可作為強化學習訓練的獎勵訊號，也可作為監督式微調（SFT）資料建構的標註。
為此，作者順勢引入了更進一步的代理型互動式裁判。它的工作方式更接近一位真人質檢員：先由動作規劃器一次性生成完整的互動腳本，再交給 Playwright 在真實瀏覽器裡逐步點擊、捲動、填表，把整個互動過程完整錄製下來，最後由裁判模型對照執行時的真實表現來打分。由於獎勵訊號扎根於頁面實際跑出來的效果，而非程式碼表面的樣子，這套機制天然免疫了刷長度的套路，也能捕捉到動畫、狀態轉移、多頁導航等靜態評估完全看不見的動態行為。
實驗結果表明，和靜態裁判相比，互動式裁判既能封堵「程式碼長度」的獎勵漏洞，也能夠實現強健、持續的測試集效果提升：
WebDev RL 訓練曲線：該圖展示了三種裁判範式（視覺裁判、混合裁判與互動式裁判）在強化學習訓練過程中，前端編碼得分（包括訓練集和測試集）以及生成長度隨訓練步數的變化曲線。作為強化學習的獎勵訊號，互動式裁判的表現優於兩種靜態裁判方案，在保持輸出長度穩定的同時取得了更高的測試得分。
用戶作為驗證者
隨著代理進入產品化階段，廣泛的用戶成為重要的監督來源。用戶關心其意圖是否被真正實作，因此天然是代理最忠實和強健的驗證者，並且隨著代理進化，用戶也會隨之適應並實作更豐富的意圖，因此與代理協同演化。但是其真實意圖（包括大量起初未被明確說出的需求）隱含地編碼在多輪互動之中，難以直接轉化為監督訊號，因此需要通過一些方法將其提取出來並加以利用。
作者收集了資深工程師與編碼助手的 12.5 萬條真實互動軌跡，把這些散落在對話中的訊號轉化為標量形式，標註用戶回饋的情感極性和對應的回饋類型，發現：
正面訊號極其稀有（僅 3.5%），負面訊號占 20%，其餘都是中性。
負面回饋「更篤定」：81.8% 的負面訊號是高置信度的 —— 用戶在否定時，表達得格外清晰。
錯誤集中在兩處：執行錯誤（56.6%）和理解錯誤（21.1%），合計近八成。
從錯誤資訊可以看出，在代理任務當中，用戶的負面資訊具有非常明確的改進價值，包括執行錯誤、程式碼理解錯誤等。
然後作者設計一種名為 Span-KTO 的方法去利用這些監督訊號。Span-KTO 的思路很簡單：把一條回覆按用戶互動邊界切成若干帶正 / 負標籤的片段（span），然後明確地「往好行為靠、把壞行為推開」。對每個片段，用「當前模型 vs 訓練前模型」的對數機率之差作為它的得分，正片段鼓勵它更高、負片段壓它更低：
利用用戶回饋 vs 監督式學習的效能評測對比，Aone-bench 為 Qwen 自建的軟工評測集。
利用用戶的隱式回饋訓練後，模型在軟工任務和腳手架指令遵循方面上有了非常顯著的改善，作者還對代理的中間行為進行監控，發現通過利用用戶回饋資訊，能夠有效地降低代理的不良行為。
對代理的行為監控，觀測軌跡中錯誤行為是否得到了改善。
在已解出的任務上各維度只是小幅提升，而在沒能解出的困難任務上差距被明顯拉開 —— 低效行為減少 34.5%（更少無意義的反覆重試）、溝通品質提升 26.5%（把卡在哪講清楚）、執行錯誤改善 13.9%。也就是說，模型學會的不只是「做對更多題」：在失敗的軌跡上它也更可控、專業、克制，而這正是部署信任的來源。
主動式代理作為驗證者
隨著代理能力的持續提升，長時程（Long-horizon）任務得到了越來越多的關注。以 NL2repo（基於自然語言生成一整個 repo）為例，它只需要提供給模型一段自然語言需求描述，就可以得到一個功能完備的程式碼庫。
然而，隨著任務難度的升高，驗證的難度也大幅提升。首先，和一個複雜的程式碼庫相比，需求說明是「模糊」的。我們設計一個倉庫時往往只思考「要什麼」，而不會把「具體做成什麼樣子」寫得面面俱到。此外，要測試的對象是動態變化的。每個模型可能選擇截然不同的架構方案以及輸入輸出介面，想預先寫一套測試來覆蓋所有可能的實作路徑，幾乎不可能。
那麼，如何驗證一個需求極其複雜、實作路徑動態變化的問題呢？作者的回答是：既然寫不出萬能的測試，那就讓一個代理去「讀懂」生成的程式碼並動態評判。他們部署了一個自主的評估代理（Evaluation Agent），來直接閱讀生成的程式碼倉庫，把需求拆解為可逐項檢查的清單，自行編寫並執行測試，多輪審視後給出評分。評估從「預設固定規則」變成了「按需推理、動態判斷」。
但讓模型評判模型，遠沒有那麼順利。作者通過五輪迭代（v1→v5），系統地暴露並修正了評估器的若干典型失敗模式：
偷懶（v1）：評估器偏愛「只看不跑」—— 僅做靜態程式碼閱讀，不執行測試，看起來合理的程式碼輕鬆蒙混過關。
端到端驗證缺失（v2）：單個模組沒問題，但整個倉庫因 import 錯誤、依賴衝突等根本跑不起來，卻依然拿到高分。
角色錯亂（v3）：評估器「越界」—— 偷偷修改程式碼掩蓋 bug、執行已有測試而非自己編寫、甚至替生成器辯護。
上下文過載（v4）：評估器把整個程式碼庫從頭讀到尾，關鍵資訊被淹沒，判斷精度下降。
規則過載（v5）：過於細碎的流程規範超出了模型的指令遵循能力 —— 評估器被教條淹沒，整體判斷力反而下降。
評估器提示五輪迭代結果
從 v1 到 v4，BoN 準確率從 57.9% 提升至 67.4%，但 v5 的回落說明：評估器的規則設計存在「甜蜜點」—— 要足夠具體以引導正確流程，又不能細碎到壓垮模型自身的推理能力。
隨後作者還揭示了另一個有趣的發現：「好評估器」取決於你拿它來幹什麼。拒絕式微調（RFT）要求「別放進壞樣本」，對排序精度要求寬鬆；強化學習則需要精確的逐樣本獎勵來塑造梯度，對排序要求相對嚴格。實驗表明，排序最準的評估器未必過濾品質最優，兩者並不天然一致，選擇哪個取決於訓練目標。
此外，資料品質和資料數量之間也存在結構性矛盾：提高篩選閾值能提升品質，但保留的樣本量可能急劇縮水，實際使用時還需考慮二者的相互權衡。
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/
© THE END
轉載請聯繫本公眾號獲得授權
投稿或尋求報導：liyazhou@jiqizhixin.com