ExecCritic：學會測試，以測試改進

資料來源#

• ExecCritic: Learn to Test, Test to Improve for Coding Agents

摘要#

ExecCritic（Tao、Peng、Wang、Wang、Cheng、Yao、Wu、Ge、Li 與 Gao——University of Wisconsin-Madison / Microsoft Research / Georgia Tech，arXiv 2609.09133，2026-09-08，empirical）訓練程式碼庫修復代理程式，使其不輕信自身的驗證證據。其基本想法是：若同一條軌跡既撰寫補丁，又撰寫檢查補丁的測試，那麼兩者就會共享同一個盲點——補丁與測試可能「對問題採取相同的不完整解讀」，導致錯誤修正通過錯誤檢查。解法首先是架構設計，而非訓練配方：將測試撰寫與修復拆成兩個代理程式，讓彼此無法看到或影響對方的產物，再根據各自實際能控制的結果分別訓練。這項研究屬於相同的執行回饋 RL 家族 RLEF，是此資料庫中首個顯示：決定迴圈是否有幫助的，是回饋的來源，而非回饋是否存在。

耦合論點#

形式化表示（§2）：一個實例為 x = (d, R_B)，包含問題描述與有錯誤的程式碼庫。在傳統由代理程式控制的迴圈中，(p, E) ~ π_ω(·|x)——修復補丁 p 與其驗證證據 E 由同一個政策與軌跡取樣。當 E = ∅ 時，代理程式不做本機檢查便提交；當 E ≠ ∅ 時，對問題的共同誤解可能同時影響補丁、看似能驗證補丁的證據，以及停止決策。舉例來說：錯誤只會在空清單時觸發；代理程式修好常見情況，撰寫一個只涵蓋常見情況的測試，測試通過後便認定問題已解決，原本的錯誤卻仍然存在。官方評估器 V*_x(p) ∈ {0,1}——隱藏的 fail-to-pass 與 pass-to-pass 測試——始終是正確答案的依據；這套架構不會碰觸它。

ExecCritic 的解法是在無法存取候選修復軌跡的情況下產生測試，並在修訂期間固定測試。論文特別指出，這裡所說的獨立，是指產生情境與寫入權限獨立，並非錯誤在統計上獨立：「兩個代理程式仍可能共享對問題的錯誤解讀」（見 Open Questions）。

架構#

每次執行都包含以下三個元件：

1. 測試代理程式（π^T_φ）只根據 (d, R_B) 探索程式碼庫，並提交測試套件 b = (Δ_b, c_b, κ_b)——原生於程式碼庫的測試補丁、精確執行命令，以及 JSON 行為契約。每回合最多可嘗試提交五次。
2. Fail-closed harness 對 b 進行資格審核：必須能有效執行，且在 Base 上產生乾淨的失敗（B_x(b) = 1）。第一個通過門檻的套件就會被凍結；審核資格不要求它在 Gold 上通過，因此 harness 檢查的是「這個測試目前會不會失敗」，而不是「這個測試是否正確」。若沒有任何一次嘗試通過 Base 門檻，該實例會標記為 Base-gate failure，不會啟動以回饋引導的修復，只有 Round-0 補丁會送交官方評估器——這些實例仍留在解決率分母中，不會被剔除。
3. 修復代理程式（π^R_θ）只修訂原始碼，絕不修改測試。每一輪都會將隔離工作區重設為 R_B，套用目前補丁與固定的測試套件，然後回傳 z_t ∈ {PASS, FAIL} 和有限長度的執行輸出 o_t。本機 PASS 會立即結束該回合（這是停止條件，不代表修復正確）；FAIL 則讓代理程式繼續修訂，或直接提交。最多修訂 T_max = 5 輪，每輪 40 個回合；若始終沒有通過，harness 會強制提交最後一個候選版本。

Base-to-Gold success 是測試代理程式訓練與評估的核心指標，定義為 Q_x(b) = B_x(b)·G_x(b)——在 Base 上乾淨失敗，且套用參考（Gold）補丁後通過。Gold 結果與有標註的候選補丁只用於訓練獎勵與離線稽核；它們不會篩選哪些測試套件能進入修復階段，也不會進入測試代理程式自己的軌跡。

角色專屬 RL#

兩種角色都從 Qwen-3.5-35B-A3B 起步，分別訓練於 SWE-ReBench（Badertdinov et al., 2025），並在 SWE-bench Verified 上評估；訓練和評估皆透過 Orchard（Peng et al., 2026）進行，這是一套開放原始碼的 agentic-RL／沙箱框架。全程以 GPT-5.6-sol（中等推理力度）作為較強模型的參考。

**學會測試。**先以 DeepSeek-V4-Flash-0731 教師模型產生的 5,000 條思維鏈軌跡進行 SFT，再以 DAPO 風格的動態取樣進行 200 步 on-policy RL（每次更新取樣 16 組非零變異數的問題群組 × 8 條軌跡 = 128 條軌跡）。獎勵以每項任務取樣的 K 個測試套件為基礎，使用最多八個去重後且有標註的候選修復補丁計算平衡準確率 BA_x(b) = ½(TPR + TNR)：

• −0.2 — 沒有有效提交
• 0 — 有效提交，但 B_x(b) = 0 或 G_x(b) = 0
• 0.2 — Q_x(b) = 1，BA < 0.8
• 0.5 — Q_x(b) = 1，0.8 ≤ BA < 1
• 1.0 — Q_x(b) = 1，BA = 1

任何候選項目執行時發生的操作錯誤，都會使優勢值歸零，並遮罩整條軌跡，而不是將其計為行為失敗。若某條軌跡比其獎勵級別中最短的軌跡多出八個以上回合，便只給一半分數。

**以測試改進。**修復訓練僅涵蓋 Base 模型實測 Round-0 準確率低於 0.4 的 SWE-ReBench 問題（經常能解決的問題不會提供修訂訊號）；採用相同的動態取樣形式進行 100 步 GRPO。每項任務會選擇一個 Oracle F2P 測試並固定不變。修復代理程式只能看到執行回饋，看不到測試原始碼。終端補丁 p_t 的獎勵（z^train_t 是所選測試的結果，u_t 是官方結果）：

• 0 — 終端補丁無效（包括違規修改測試）
• 0.1 — 所選測試 FAIL
• 0.2 — 所選測試 PASS，官方測試 FAIL
• 1.0 — 兩者皆 PASS，t > 0（修訂後）
• 1.5 — 兩者皆 PASS，t = 0（Round-0，直接解決）

0.2 與 1.0 之間的差距正是設計重點：通過訓練測試的價值，比起通過測試且通過完整隱藏測試套件，低了一個數量級。較高的 Round-0 獎勵（1.5 對 1.0）則是刻意用來抵銷一種風險：政策可能學會延後提交不完整的 Round-0 解法，寄望之後靠修訂補救。

結果#

**主要結果。**將 RL 訓練的測試代理程式（RL-35B）與訓練後的修復代理程式組合，在 SWE-bench Verified 上達到 72.6%——比訓練後修復代理程式自行執行的無測試 Round-0（68.3%）高 4.3 個百分點，比原本未訓練的無測試基準（61.2%）高 11.4 個百分點——評估時不需要 GPT-5.6 或 Oracle 回饋。

**測試品質決定回饋是否有幫助（表 2，固定修復代理程式）。**讀者註記：這是論文中最有力的單項結果，也只把測試來源設為變因：

測試來源（提供給 Base 修復代理程式）	解決率（%）	相較於無測試的差異
無（Round 0）	61.2	—
Base-35B（未訓練的 Qwen 測試代理程式）	57.3	−3.9
RL-35B（訓練後的 Qwen 測試代理程式）	64.1	+2.9
GPT-5.6-sol	65.3	+4.1
Oracle F2P	69.4	+8.2

未訓練的測試代理程式產生的測試，讓同一個修復代理程式表現得比完全沒有測試更差——品質差的檢查會引導修訂去滿足不完整或錯誤的需求，而非真正的故障。這個排序與獨立的 Base-to-Gold 測量結果一致（表 1：Base Qwen 為 22.2%，GPT-5.6-sol 為 87.8%）：能產生較可靠的 Base-to-Gold 測試的來源，其回饋也更能幫助修復。

**測試代理程式訓練（表 1，SWE-bench Verified 上的 Base-to-Gold success）。**僅做 SFT：22.2% → 39.6%（+17.4 個百分點）。再加上 RL：→ 62.2%（進一步增加 +22.6 個百分點），接近 Codex-5.3（61.0%），但仍比 SFT 教師模型（DeepSeek-V4-Flash-0731，73.4%）低 11.2 個百分點，比 GPT-5.6-sol（87.8%）低 25.6 個百分點。SFT 資料集擴充（圖 6a）顯示，增加至 5K 條軌跡後效益遞減（10K 在這項指標上沒有帶來提升），而教師模型的參考值始終接近 73%——RL 才是縮小大部分剩餘差距的關鍵，而且必須從經 SFT 初始化的政策開始：從原始 Base 檢查點開始的 RL 表現仍低且起伏不定（群組內沒有可供訓練的差異化獎勵），而從 SFT 檢查點開始的 RL 則穩定上升。

**修復代理程式訓練（表 2，完整矩陣）。**無測試 Round-0 從 61.2% 升至 68.3%（+7.1 個百分點，直接修復能力）。Test-to-Improve 接著在 RL-35B 回饋下，為未訓練的修復代理程式增加 +2.9 個百分點，為訓練後的代理程式增加 +4.3 個百分點——兩者的起點不同，因此不能視為單獨衡量「使用回饋能力」的配對估計；不過，無論與哪一版本的另一個元件搭配，兩個訓練後的元件都能提升系統表現。使用訓練後的代理程式組合時，Oracle F2P 回饋可達 77.6%，比生成測試組合高出 5.0 個百分點的差距。作者將此歸因於測試品質與涵蓋率仍有提升空間。

**現成的前沿代理程式（圖 5a）在不同規模下呈現相同的「回饋效果取決於涵蓋率」模式。**GPT-5.6 在 SWE-bench Verified 上的表現為：81.5% → 使用生成測試後為 85.7%（+4.2），→ 使用 Oracle F2P 後為 89.7%（+8.2）。在 SWE-bench Pro 上則為：61.6% → 使用生成測試後為 62.3%（+0.7，幾乎沒有提升），→ 使用 Oracle 後為 73.4%（+11.8）。Pro 每個實例的 F2P 測試數中位數／平均數為 3／14.43，Verified 則為 1／3.03——一個針對單一問題行為的生成測試套件，很可能無法涵蓋更廣泛規格中的其他部分。不過論文謹慎指出，這是相關性解讀，而非單獨隔離出的成因。

**消融實驗。**直接解決獎勵會影響 Round-0 與最終結果的平衡（表 3）：完整的 T2I 達到 68.3%／72.6%；移除獎勵後，Round-0 降至 66.4%，最終結果的增幅也縮小至 71.4%——這與獎勵能阻止政策延後修訂的說法一致。SFT 教師模型是否提供推理過程，在 RL 後的影響遠大於只做 SFT（表 4）：非 CoT 的 GPT-5.6-sol 教師與 CoT DeepSeek-V4-Flash-0731 教師在 SFT 後只差 4.2 個百分點（35.4 對 39.6），但在 RL 後相差 26.0 個百分點（36.2 對 62.2）。然而教師身分與 CoT 可見性互相混淆，因此這並未乾淨地隔離思維鏈的因果效果。修復階段使用 Oracle 測試訓練，比使用生成測試訓練高出 0.7–1.7 個百分點（表 6）——更乾淨的訓練回饋有幫助，但幅度不大，因為終端獎勵已經涵蓋整條軌跡，包括 Round-0 補丁。

**跨語言泛化確實存在，但表現不均（表 5）。**測試代理程式只以 Python 進行後訓練，在 SWE-bench Multilingual 上的 Base-to-Gold success 為：Rust 66.7%、C++ 58.3%（兩者都高於 Python 語言內參考值 62.2%）、C 26.1%、Java 2.4%。此方法無需針對特定語言進行後訓練，就能移轉行為契約推論能力，但在某些工具鏈上的可靠度會大幅下降——這些數據是測試生成率，不是下游修復解決率，因此尚未分別測量一個在 Java 上可靠度接近 2.4% 的測試代理程式對實際修復的影響。

**修復額外成本仍低。**在使用訓練後代理程式組合進入修復階段的 120 條軌跡中，平均只需額外 13 個代理程式回合，就能從 68.3% 提高至 72.6%——大部分提升都不需要用完完整的 5 輪預算。每個問題／來源的測試生成只需執行一次，並在三次修復執行中重複使用；每個解決率數字都是這三次執行的平均值。

相關研究：固定測試與演進測試#

ExecCritic 在 §6 中根據驗證證據在修訂期間是否保持固定，將其置於一系列程式碼庫修復系統中。交錯進行探索、編輯、執行與修訂的程式碼庫層級代理程式——SWE-agent、OpenHands、Mini-SWE-Agent——是這套架構所建立其上的通用 harness 家族；它們會自行產生檢查，並未分離角色。TDFlow 與 ExecCritic 一樣，會凍結提供或生成的測試；SpecRover、Dynamic Cogeneration、CodeMonkeys、InfCode、Agent-CoEvo、CoHarden 和 TDD-Agent 則會隨修復進展更新、選擇或強化測試——演進中的測試可以修正品質不佳的證據，但也會在回合中途改變驗收標準，而這正是 ExecCritic 想避免的耦合風險。傳統自動化程式修復研究（DiffTGen、Opad、Patch-Sim、RGT、Poracle）處理的是相同的預言機問題——補丁對既有測試套件看似合理，語義上卻可能錯誤——但採用事後篩選，而非訓練時分離角色。

限制#

測試與修復是以分開的政策訓練，並只在訓練完成後組合——動作空間、軌跡結構與獎勵形式皆不同，因此本文未能採用共享權重目標。作者將聯合訓練列為未來工作，並提出由角色條件決定測試或修復行為，此外還包括多重檢查 harness 與更強的測試代理程式權重。

延伸閱讀#

• 來自執行回饋的 RL（RLEF） — 與 RLEF 同屬執行回饋 RL 脈絡，但結構更明確：RLEF 將測試執行納入獎勵迴圈，並在 CodeContests 上研究回饋豐富度與信用分配粒度；其中公開／私人測試來自同一個經策劃的基準切分。ExecCritic 則提出 RLEF 的設計從未分開處理的問題——測試本身是否為有效預言機——並在程式碼庫規模上回答，因為沒有人提供配對好的公開／私人測試。兩者不是對同一個未解問題提出相互競爭的答案：RLEF 探討固定格式檢查能回傳多少資訊，ExecCritic 探討檢查本身是否正確——應將後者視為前者的豐富度問題得以成立之前的先決條件
• Agent-Generated Test Quality — 本文為這項觀察性研究提供了因果性的訓練時補充。Jhanglani et al. 與 Dipongkor et al. 衡量代理程式撰寫的測試是否廣泛，以及是否涵蓋差異；ExecCritic 則以受控方式檢驗同一問題——固定修復代理程式，只更換測試來源——並得到明確方向的答案：未訓練測試代理程式的檢查會讓修復表現比沒有測試更差（57.3% 對 61.2%），可靠的測試則能帶來明顯改善（65.3%、Oracle 的 69.4%）。「廣度是內在屬性，目標選擇則取決於關係」在此多了第三個面向：可靠度，以 Base-to-Gold success 衡量；決定下游修復迴圈是否受益的是可靠度，而非廣度
• Reward Hacking — §2 的共享軌跡耦合論點，是一種結構性的獎勵駭取防護，與 RLEF 的公開／私人測試切分屬於同一類：不讓接受評估的政策寫入驗證產物，而非試圖塑造政策能讀取的獎勵。Harness 的 fail-closed Base 門檻就是執行機制——未通過資格審核的測試根本不能進入獎勵，而不會以有雜訊的零分計入
• 驗證成為新的瓶頸 （樞紐文章） — 這是同一主張在訓練時的一個實例：一旦 harness 讓驗證獨立且不可或缺，修復表現的上限就會受測試撰寫可靠度限制（表 1 的 62.2%，遠低於 GPT-5.6-sol 的 87.8% 參考值），而非只受修復能力限制
• OpenHands — 論文將其列為程式碼庫層級代理程式架構之一（與 SWE-agent、Mini-SWE-Agent 並列）；ExecCritic 的修復代理程式專精於並限制其探索、編輯、執行、修訂迴圈，而不是在其內部接受評估

開放問題#

• 論文承認，獨立指的是產生情境與寫入權限，而非錯誤的統計獨立性——「兩個代理程式仍可能共享對問題的錯誤解讀。」組合式系統與 Oracle 回饋間的剩餘差距有多少（使用訓練後修復代理程式時，生成測試為 72.6%，Oracle 為 77.6%），來自測試與修復代理程式對同一段模糊問題文字的共同誤解，又有多少來自獨立的測試品質或修復能力不足？可證偽方式：比較組合式系統與使用 Oracle 回饋的修復代理程式在相同實例上的錯誤集合，並依測試套件目標與修復代理程式的誤讀是否吻合來分類重疊部分。
• 跨語言 Base-to-Gold success 在沒有目標語言後訓練的情況下，從 66.7%（Rust）降至 2.4%（Java）。這個差距是來自測試基礎設施探索（找到正確的建置／測試執行器與呼叫命令），還是行為契約推論本身（理解問題的要求）？兩種失敗模式需要不同的修正方式——工具架構或更多後訓練資料——而論文每個實例只生成一次的流程無法區分兩者。

資料來源#

• ExecCritic: Learn to Test, Test to Improve for Coding Agents — Leitian Tao、Baolin Peng、Haorui Wang、Hang Wang、Hao Cheng、Wenlin Yao、Qianhui Wu、Tao Ge、Sharon Li 與 Jianfeng Gao（University of Wisconsin-Madison / Microsoft Research / Georgia Tech），ExecCritic: Learn to Test, Test to Improve for Coding Agents，arXiv 2609.09133，2026-09-08，empirical。程式碼位於 github.com/MSR-Orchard/execcritic。§2 耦合形式化；§3 架構與 Learn-to-Test／Test-to-Improve 機制（圖 2–4）；§4 獎勵定義；§5 實驗（表 1–6、圖 5a–b、圖 6）；§6 相關研究；§7 限制。 **解析註記。**由 PDF 擷取（docling 2.126.0／docling-mlx 0.1.1，35 頁，rapidocr，信心極高）。表 1–6 的結果解析乾淨，直接引用；只有附錄超參數表帶有此知識庫的 docling 稽核通常會標示的合併／焊接警告，而本文未引用任何一張。 **證據。**完整閱讀後確認 empirical 標示成立：受控消融實驗（表 2、3、6）一次改變一個元件並固定另一個，每個條件的解決率以三次修復執行取平均；fail-closed harness 的資格條件可獨立於訓練訊號加以檢查；跨基準泛化測試（SWE-bench Pro、SWE-bench Multilingual）均未額外進行後訓練。有一項作者背景註記：第一作者的實習單位是 Microsoft Research，十位共同作者中也有六位任職於該機構——這是內部評估，而非獨立稽核；不過，基準（SWE-bench Verified／Pro／Multilingual）與比較用參考模型（Codex-5.3、DeepSeek-V4-Flash、GPT-5.6-sol）皆來自第三方。