FrogNano：以線上任務合成訓練 4B 程式碼代理

原始論文：FrogNano: Training a 4B Coding Agent via Online Task Synthesis 作者：Minseon Kim, Zhengyan Shi, Emiliano Penaloza, Christopher Cui, Roger Creus Castanyer, Maryam Hashemzadeh, Isadora White, Jonathan Light, Jeonghye Kim, Matheus Pereira, Darya Moldavskaya, Chinmay Singh, Fabio Vera, Baolin Peng, Xingdi Yuan, Marc-Alexandre Côté, Alessandro Sordoni（Froggy Team – Microsoft Research Montréal） arXiv ID：2609.07925v1 日期：2026 標籤：FrogNano 程式碼代理 強化學習 合成任務 小模型 SWE-bench Qwen3.5

摘要

我們提出 FrogNano，一個 4B 的程式碼代理 (Coding Agent)，設計目標是在資源受限的環境下，也能有效率、有效果地處理軟體工程 (Software Engineering, SWE) 任務。它完全透過強化學習 (Reinforcement Learning, RL) 進行後訓練 (Post-training)，環境是約 1,500 個帶合成任務的 SWE 環境。提升效能的關鍵成分，是一條線上任務合成 (Online Task Synthesis) 管線：它產生的任務會校準到當前檢查點 (Checkpoint) 的可學習性前沿 (Frontier of Learnability)。本報告提供證據，說明僅靠合成任務、不透過傳統的「向更大模型蒸餾 (Distillation)」，也能訓練出具競爭力的小型程式碼代理，並說明「在當前代理的可學習性前沿產生任務」這件事很重要。我們詳述了訓練方法、跨多樣環境的評測，以及深入分析，作為我們持續探索「可在最小硬體上運行、輕量卻能幹」程式碼代理的基礎。

【譯註：footnote 標明本工作於在 Froggy 實習期間完成。】

1 引言

圖 2（本文僅內嵌子圖 (a) SWE-bench Verified）：模型參數量與效能資訊取自各模型技術報告與基準官方排行榜。我們的模型以少一個數量級的參數量，勝過體型更大的模型。Qwen3.5-4B* 是用 Leaf harness 計算得出。FrogNano 的數字為三次執行的平均。原圖另有 (b) SWE-bench Pro、(c) Terminal-Bench 2.0、(d) PatchEval-Verified 三個按參數量比較的子圖。

軟體工程代理 (SWE) 的進展，多半由「藏在專有 API 後的前沿模型」或「數百億參數的開放權重模型」推動。這些系統雖然能力很強，卻可能昂貴到難以服務，也難以在本地部署與反覆做實驗。這些限制促使我們追問：一個顯著更小的模型，能否成為勝任的倉庫層級 (Repository-level) 程式碼代理？我們在 4B 規模上研究這個問題，並發展出一套涵蓋資料、harness 與 RL 設定的緊湊型程式碼代理訓練配方。

資料。 訓練 SWE 代理需要可執行、高品質的軟體工程任務。從真實開發歷史整理這些任務成本高昂，因此催生了 SWE-Gym、R2E-Gym、SWE-rebench、SWE-smith、BugPilot 等資料集與合成任務生成管線。本文提出 TaskPilot，一條線上、隨策略調適 (Policy-adaptive) 的任務合成管線，它利用當前策略的回饋來把任務生成導向其可學習前沿。TaskPilot 從真實倉庫快照出發，生成候選軟體工程任務，並用當前檢查點的 rollout 來評估它們。策略回饋既用來辨識可學習的任務，也用來把任務調整到可學習區間。文獻中常見的做法是難度過濾 (Difficulty Filtering)——先有一大批真實任務，再依某模型的可學習性篩選。我們避開這個流程，改為針對特定檢查點量身訂做任務合成，讓任務持續適配當前策略的能力。我們反覆套用 TaskPilot：每當一個檢查點在驗證集上飽和，就用表現最好的檢查點去生成並校準下一輪任務。這形成一個閉環，任務分布與策略一同演進。

Harness。 讓我們的配方在 Qwen3.5-4B 上有效運作時，也揭露了一個代理 harness 的實務挑戰。在較繁複的 R2E-Gym/SWE-Agent harness 下，Qwen3.5-4B 常常無法成功終止，約有 96% 的軌跡撞上回合上限。因此我們開發了 Leaf——一個受 Claude-Code 式工具使用慣例啟發的輕量程式碼代理 harness，只有五個型別化工具，加上一條簡單的自然終止規則。在固定其他 rollout 設定的情況下，把 R2E-Gym 換成 Leaf，Qwen3.5-4B 在 SWE-bench Verified 的解題率從 8.3% 提升到 37.2%，而一個顯著更大的模型對同樣的 harness 變更幾乎不敏感。

RL。 使用 TaskPilot 與 Leaf，我們透過 RL 反覆優化模型，總共進行五輪「任務合成後接 RL」。我們採用 DPPO，搭配非同步 rollout 與一個對數長度懲罰 (Log-length Penalty)，鼓勵助手生成更精簡。五輪 RL 之後的檢查點即為 FrogNano。我們的分析顯示，早期迭代習得的某些行為可能在後期迭代中流失。為了因應這點，我們額外研究了一套整併 (Consolidation) 程序，用來從過去的檢查點回收有用的工具使用行為。

FrogNano 在 SWE-bench Verified 上達到 61.5% 解題率、SWE-bench Pro 上 37.6%、Terminal-Bench v2 上 31.1%、PatchEval-Verified 上 23.2%（圖 2）。重點是，這樣的效能是在沒有向前沿模型做傳統蒸餾的情況下取得的，靠的是在「以策略為基礎的合成任務」上反覆做 RL（圖 1）。這些結果顯示：當任務生成能隨學習者演進而調適、並搭配一個模型可靠使用的互動介面時，緊湊模型也能習得可觀的倉庫層級程式碼能力。我們的 4B 程式碼代理也提供了一個實用的研究平台，讓代理鷹架、情境管理、線上資料生成與 RL 的端到端實驗都更可行。

圖 1：TaskPilot 迭代式 RL 訓練下的 SWE-bench Verified 效能。每一輪 TaskPilot 加入約 300 個「校準於前一輪策略」的合成任務。虛線比較採用約 300 與 1,500 個「依 4B 策略可學習性過濾」的真實 SWE-rebench 任務。數字為三次執行平均。

2 精簡模型的 harness 設計至關重要

一個程式碼代理的 harness，決定了模型如何觀察任務、如何與倉庫互動。對於緊湊模型來說，這些介面選擇本身就可能成為主要瓶頸。我們初期的實驗使用 R2E-Gym harness，它提供詳盡的工作流程、一個客製的多用途檔案編輯器，以及一個專用的 finish 動作。Qwen3.5-4B 難以可靠地遵循這套互動協定，約 96% 的軌跡撞上回合上限，往往還沒產出所需的提交動作。

這促成了 Leaf——一個圍繞「模型能更可靠處理的工具使用慣例」而設計的輕量 harness。Leaf 暴露五個型別化工具：read、write、edit、glob、bash。它們的名稱與基本 schema 沿用 Claude Code 工具集的一個小子集，實作則參考了 SLIME 中公開的 Anthropic adapter。我們刻意省略互動式程式產品的更廣泛功能，例如規劃模式、權限對話框、提醒、使用者專屬情境與輔助工具。

透過 Leaf，模型收到一段簡短的系統提示、issue 描述與對話歷史，並可回覆一個或多個符合 JSON schema 的工具呼叫。Leaf 依序執行這些呼叫，把輸出回傳給模型。含工具呼叫的回覆會延續本次 episode，不含工具呼叫的回覆則被視為最終答案並終止之。互動結束後，收集所得的倉庫變更並用該任務的測試評分。我們發現這些額外工具與簡化很重要，把 Qwen3.5-4B 從 R2E-Gym harness 的 8.3% 提升到 Leaf 的 37.2%。我們發現這些選擇對緊湊模型特別重要：一個更大的模型（MiniMax-M2.5）不受 harness 變更影響（兩套 harness 都是 66.5%）。

Qwen3.5-4B 對 Claude-Code 式介面的相容性，可能反映了它在後訓練期間接觸過類似互動，不過其公開文件並未證實這點。我們在評測與強化學習中使用同一套 Leaf harness。訓練時，模型生成的推理、答案文字與工具呼叫都計入損失，而任務提示與工具輸出雖保留在情境中但被遮蔽 (Mask) 於損失之外。最終倉庫狀態用該任務的測試評估。

3 為演進中的策略合成任務

緊湊型程式碼代理的強化學習，需要「匹配當前策略」的可執行任務。策略永遠解不出的任務不提供學習訊號，而已飽和的任務則提供的相對學習訊號很少；隨著策略進步，有用的任務分布也隨之改變。TaskPilot 用「當前策略的 rollout」線上生成、驗證、精修任務，把落在目標難度區間的候選保留給下一批訓練。表 1 把這個「策略導引」的流程，放在幾條具代表性的軟體工程任務建構管線之中對照。

從取自 SWE-rebench 的真實倉庫快照出發，一個任務生成模型會產出「問題陳述、gold patch、隱藏的 fail-to-pass (F2P) 測試」。一個候選若能可執行，即：其 F2P 測試在原始快照上失敗、在套用 gold patch 後通過，同時既有的 pass-to-pass (P2P) 測試套件維持穩定。

每個任務由「問題陳述、倉庫快照、runtime、gold patch、評分測試」組成。在任務合成與 FrogNano 的 RL 訓練期間，gold patch 只用於任務驗證，對解題者隱藏。F2P 測試指定任務應修復的行為，P2P 測試則防止迴歸。生成的 F2P 測試與其結果在代理互動期間同樣隱藏。

3.1 策略導引的任務合成與校準

圖 4：TaskPilot 的策略導引任務合成。經可執行性驗證後，以當前策略的軌跡估計「每個候選任務被解出的比例」。落在該輪目標解題率區間的候選進入下一批 RL；區間外的候選則被精修、重新評估或丟棄。

對每個可執行候選，TaskPilot 用「當前 4B Leaf 策略檢查點」的 rollout 來評估任務。所得回饋不只用來決定是否收錄該任務，也在任務太簡單或太困難時用來修改它。修改後的候選再次被驗證與評估。這個「生成–評估–精修–再評估」的循環可重複多輪，讓任務合成能適配當前策略，而非只是過濾一個固定的候選池。

為判斷一個候選是否落在期望區間，TaskPilot 收集 $N$ 條軌跡。一條軌跡是一次完整、隨機、多回合的嘗試，解題者收到問題與倉庫，但拿不到 gold patch 或隱藏評分測試。我們把候選在當前策略下的解題率估計為：

$$\hat{p}_{\mathrm{policy}}=\frac{1}{N}\sum_{j=1}^{N}R_{j},$$

其中 $R_{j}\in\{0,1\}$ 表示第 $j$ 條軌跡是否通過所有評分測試。

我們把策略的廣義可學習區間定義為 $0<\hat{p}_{\mathrm{policy}}<1$，對應校準 rollout 中「有成功也有失敗」的混合結果。此區間內的候選能同時提供成功與失敗軌跡，但我們會用一個「該輪專屬的區間內目標值」來導引精修與收錄。迭代 1–4 的目標是 $\hat{p}_{\mathrm{policy}}=0.5$。在相同生成機制下，一次初步的第五輪執行帶來的增益弱於前幾輪。為了讓學習延續到第 4 輪之後，修訂後的第 5 輪改用更強的任務生成模型，並把校準轉向較低的目標帶 $0<\hat{p}_{\mathrm{policy}}\le 0.5$。

滿足當前目標的候選被收錄進下一批 RL。$\hat{p}_{\mathrm{policy}}=1$ 的候選是飽和的，$\hat{p}_{\mathrm{policy}}=0$ 的則在觀察到的 rollout 下太難。落在當前目標之外的候選可能被精修或丟棄。因此這個準則是一個經驗性、相對於策略的訊號，用來導引任務合成，而非估計任務的內在難度。圖 4 總結了這個流程。

從 Qwen3.5-4B 基礎檢查點 $\pi^{(0)}$ 出發，每個生成階段都對當前策略 $\pi^{(t)}$ 執行這套合成與校準程序。被接受的任務用於 Leaf harness 下的一次 RL 爬升，產出下一個檢查點 $\pi^{(t+1)}$；更新後的檢查點又成為下一個任務生成階段的解題者。如此一來，策略塑造它要學的任務，而從這些任務中學習又產出塑造下一代任務的策略。任務分布因此與策略一同演進（圖 3）。

圖 3：FrogNano 訓練迴圈示意。從 Qwen3.5-4B 基礎模型出發，任務生成階段與 RL 訓練階段交替進行，直到收斂。

圖 5–7（文字描述）：

• 圖 5（任務精修範例）：對同一個可執行任務，固定倉庫快照、gold patch 與評分測試，只修改問題陳述。低度指定 (Underspecified) 的版本留下關鍵契約細節（例如區間是否閉合、寬度如何度量）為隱含，得不到成功 rollout；過度指定 (Over-specified) 的版本點名相關類別與方法、給出會失敗的輸入並暴露例外，等於幫忙定位修正，所有 rollout 都解出。被接受的中間版本精確陳述行為契約（含端點與零寬度語意），卻不揭露失敗位置，恰好產生「有成功也有失敗」的混合。因此精修調整的是語意清晰度與「定位解答」的資訊量，而非只是把提示變長或變短。
• 圖 6（各生成迭代的任務分布統計）：(a) 問題陳述字數；(b) 測試 patch 變動量（含測試的 patch 中新增加刪除的行數）；(c) 每任務「測試 patch 變動量 / gold patch 變動量」比值；(d) 條列或編號需求數；(e) 「可對應到至少一個評分測試」的需求比例。誤差棒為 95% 信賴區間。
• 圖 7（各生成迭代的任務類別組成）：每個任務依主導變更被指派一個互斥標籤（bug fix、feature request、refactor、依賴/函式庫遷移、效能最佳化）。每一輪中 bug fix 都是最大類別。

3.2 一個任務精修範例

圖 5 說明策略回饋如何改變任務本身，而不只是決定它是否被保留。細節見上方圖 5 描述——精修沿著「語意清晰度」與「是否定位解答」兩個軸，把任務推向當前收錄目標，而不是單純調整提示長度。

3.3 任務分析

迭代 1 到 4 使用原始任務生成模型，目標解題率 0.5。在相同機制下的初步第 5 輪增益較弱後，修訂後的第 5 輪刻意改變任務分布以延續學習曲線：改用更強的任務生成模型與較低的 $(0.0, 0.5]$ 目標帶。所得的第五批形成一個新的課程 (Curriculum) 機制。

更難不等於更大。 問題陳述長度在迭代 4 達到峰值 227.0 字，到迭代 5 掉到 116.6 字（五批中最短）。測試 patch 變動量從迭代 2 的 159.8 行升到迭代 4 的 312.3 行，再到迭代 5 掉回 194.7 行。低目標批次在這兩項度量上都比迭代 4 更小。

修訂後的課程超越了單純修 bug。 迭代 1 的 bug-fix 佔比 85.2%、沒有 refactor 任務。迭代 2–4 之間，feature request 佔 16.7%–19.7%、refactor 佔 8.0%–15.1%。到迭代 5，bug-fix 佔比降到 40.7%，feature request 升到 24.0%、refactor 升到 17.0%、效能最佳化升到 12.4%。

較少的鷹架與較高的測試覆蓋率並存。 在迭代 1–4 共通的生成機制下，「測試/gold-patch churn 比值」從迭代 2 的 8.7 升到迭代 3 的 13.9、迭代 4 的 14.4；而顯式需求條目從每份問題陳述 1.30 個降到 0.51 個，問題陳述/測試覆蓋率則從 28.1% 升到 34.3%。迭代 5 反轉了 churn 比值趨勢（掉到 6.4），並幾乎移除顯式列舉（每份陳述僅 0.04 條需求），同時問題陳述/測試覆蓋率達到最高的 37.6%。統計量的突變反映的是課程重新設計；TaskPilot 仍以「當前策略的 rollout 結果」而非任何單一靜態描述量作為校準訊號。

4 強化學習訓練配方

給定一批 TaskPilot 接受的任務，我們用 Leaf 生成的軌跡，以連續的組相對 (Group-relative) RL 更新策略。每一輪 RL 由「用該輪取得的任務進行 200 次更新」的一次爬升組成。策略權重在各次爬升間延續，而最佳化器與亂數產生器狀態則在每輪開始時重新初始化。

rollout 生成與最佳化在單一節點、8 張 NVIDIA B200 GPU 上非同步執行。兩張 GPU 以 context parallelism = 2 訓練策略，六個單 GPU 推論引擎生成軌跡。每次更新含 32 個任務組、每組 8 條獨立軌跡，全域批量為 256 條軌跡。rollout buffer 只允許很小的策略版本落後 (Policy Lag)。更多細節見附錄 A.1。

4.1 組相對最佳化

我們採用 DPPO 訓練演算法。對每個任務 $i$，我們取樣八條軌跡，並在組內對它們的塑形獎勵 (Shaped Reward) 標準化：

$$A_{ij}=\frac{R_{ij}-\bar{R}_{i}}{\text{std}(R_{i})+10^{-6}},$$

其中 $R_{ij}$ 是第 $j$ 條軌跡的塑形獎勵，$\bar{R}_{i}$ 與 $\text{std}(R_{i})$ 是該組的均值與標準差。訓練時，我們捨棄零優勢 (Zero-advantage) 的組，因為它們不提供學習訊號。由於我們的任務已校準在可學習區間，零變異的組很少，被捨棄的也少。軌跡層級的優勢 $A_{ij}$ 廣播到它的模型生成 token 上。工具觀察值保留在情境中但被遮蔽於損失外，因此最佳化只作用在模型生成的 token。

由於 rollout 生成是非同步的，且推論伺服器使用 SGLang，行為策略 $\pi_{\mathrm{roll}}$ 可能落後於訓練策略 $\pi_{\theta}$。我們用非對稱軌跡重要性取樣 (Asymmetric Trajectory Importance Sampling) 修正這個落後。對每個生成 token $a_{t}$（情境 $s_{t}$），定義：

$$p_{t}=\pi_{\theta}(a_{t}\mid s_{t}),\quad q_{t}=\pi_{\mathrm{roll}}(a_{t}\mid s_{t}),\quad\rho_{t}=\frac{p_{t}}{q_{t}},\quad\Delta p_{t}=p_{t}-q_{t}.$$

一個正優勢 token 在 $\Delta p_{t}>0.2$ 時被丟棄，一個非正優勢 token 在 $\Delta p_{t}<-0.2$ 時被丟棄。策略損失為：

$$\mathcal{L}_{\mathrm{policy}}=-\frac{1}{|\mathcal{T}|}\sum_{t\in\mathcal{K}}A_{t}\rho_{t}.$$

這個遮罩避免陳舊軌跡繼續強化「已朝同方向大幅移動」的更新。FrogNano 的 RL 訓練不使用參考模型 KL 損失、非對稱 TIS KL 輔助項或熵獎勵；穩定性改為仰賴 DPPO 遮罩、小的策略落後與梯度裁剪。

4.2 效率獎勵

為了不鼓勵不必要的冗長成功軌跡，我們施加一個成功門控的對數長度懲罰 (Success-gated Logarithmic Length Penalty)。對一條含 $n$ 個助手生成 token 的完成且成功的軌跡，塑形獎勵為：

$$R(N)=\begin{cases}1,&n\leq N,\\ 1-\alpha\ln\!\left(n/N\right),&n>N.\end{cases}$$

其中 $N$ 是我們允許模型免費使用的 token 數，$\alpha$ 控制懲罰強度。助手生成 token（$n$）包含完整的助手生成串流（推理、自然語言輸出與工具呼叫 token），但不含工具觀察值。此懲罰只施加於「完成且成功」的軌跡，依效率對正確解排序，而不進一步懲罰失敗的探索。零變異過濾用的是原始任務獎勵，而非長度懲罰塑形後的獎勵。長度懲罰在「結果混合」的保留組中仍然作用。

另外，我們對「因 rollout 預算上限而終止」的正確軌跡給予部分分數。一條軌跡若解出任務但撞到最大情境長度、每回合最大 token、最大回合數或最大時間，就被歸類為被截斷 (Truncated)，得到 0.5 的部分獎勵。每條不成功軌跡得 0。我們停用了先前工作採用的傳統線性過長懲罰與過長損失遮罩。

5 實驗

我們用 Leaf harness 在四個前沿程式碼代理基準上評估 FrogNano：SWE-bench Verified、SWE-bench Pro、Terminal-Bench 2.0、PatchEval-Verified。我們用 SWE-bench Verified 作為驗證集（因為它像我們的訓練資料一樣完全基於 Python），其餘作為留出 (Held-out) 測試集，各基準細節見附錄 A。所有評測都用 150 步、131k 最大情境 token 的預算，temperature 0.6、repetition penalty 1.0，分數在 3 個 seed 上平均。

5.1 結果

訓練可泛化到留出效能。 圖 1 評估第 3 節的迭代程序：從 SWE-bench Verified 的 43.0% 解題率起步，五輪 TaskPilot（每輪 300 個合成任務）把它依序提升到 49.1%、53.1%、56.9%、59.1%，最終第 5 輪的 61.5%。作為代表性基線，我們也在約 300 個「用相同 4B 可學習性準則挑選」的真實 SWE-ReBench 任務上訓練，達到 48.0%。這顯示：在可學習邊緣建立的純合成任務上訓練，能匹配「用昂貴 rollout 大量過濾的真實資料子集」的效能。第二、三輪的進一步增益也顯示這個好處不侷限於第一個合成迭代。

我們的模型匹配更大模型的效能。 在圖 2 中，我們把 FrogNano 跨基準與「效能最接近它」的模型比較。我們的效能匹配一年前的 32B–100B+ 模型。圖 13 顯示 FrogNano 在 SWE-bench Pro 上與體型 6–8 倍於它的模型相當，而成本只需四分之一。最重要的是，儘管只是 4B 參數，FrogNano 仍與顯著更大且更新的系統（如 GPT-5 mini、Grok 4、Opus 4.1）競爭。這證明即使沒有蒸餾，我們的訓練管線也能把 4B 模型變成強大的程式碼代理。

5.2 分析

FrogNano 有效推升 Pass@8。 我們想確定迭代 RL 訓練是真的推升模型的邊界，而非把高 pass@$k$ 蒸餾進 pass@1。為此，我們比較基礎 Qwen3.5-4B 與 FrogNano 的 pass@8 分數（圖 15）。最重要的是，我們發現 FrogNano 與基礎模型之間的差距隨 $k$ 增加而保持不變。這暗示迭代 RL 推升了模型的能力邊界，而不是單純把它蒸餾進 pass@1。此外，為了把 FrogNano 的高 pass@$k$ 蒸餾進 pass@1，我們使用 pass@short（在 $k$ 條生成軌跡中選最短的）與 verifier（訓練一個對 patch 排序的驗證器）。我們發現 pass@short 在 SWE-bench Pro 上是有效的代理，效能從 37.6% 到 38.0%；在 SWE-bench Verified 上則沒能超過 pass@1 的 60.4%。

Verifier。 用驗證器做測試時擴增 (Test-time Scaling) 是提升推論 pass@1 的標準做法。我們訓練一個排序驗證器：給定同一任務的 $k$ 個候選 patch，驗證器排序它們，我們只評估排名最高的那個。訓練池來自 RL 最後兩輪產生的 rollout，保留「至少一個通過、一個失敗」的任務。訓練時先取樣一個任務，再從 2 到 8 均勻取樣 $k$，確保所選候選同時含兩種結果並隨機排列。我們用 GRPO 與帶裁剪的 policy-gradient 目標、以倒數排名獎勵 (Reciprocal-rank Reward) 最佳化。令 $r^{*}=\min_{i:\,y_{i}=1}\operatorname{rank}(i)$ 為排名最高的通過 patch 的一為起點的排名，獎勵為 $R=\tfrac{1}{r^{*}}$。

推論時，我們透過一個循環賽 (Round-robin Tournament) 做額外的測試時擴增：比較每一對候選 patch、計算每個候選的兩兩勝場，讓勝場最多的兩個候選進入最終對決，平手或循環則用一次額外排序呼叫解決。在 SWE-bench Verified 上、每任務三條候選軌跡時，此循環賽達到 62.8% pass@1，相較單次 verifier 呼叫 61.4%、隨機選擇 61.53%、pass@short 60.4%。

整併跨策略合併行為。 每一輪取得的策略都有自己特有的行為特徵，由 RL 訓練方法與所用資料集塑造。分析顯示這些策略在回應長度、使用工具做驗證的頻率、以及發出多個工具呼叫的頻率（表 5）上各有不同。雖然 FrogNano 本身未納入，我們研究了能否透過整併來合併這些行為特徵、減少不想要的行為，或從 FrogNano 最終迭代擠出邊際增益。其想法是把迭代爬升中的一系列檢查點視為「可依所需屬性過濾的 rollout 來源」。其中一個行為是「平行工具呼叫」隨迭代流失——事實上 FrogNano 只發出 1.71% 的平行工具呼叫。我們實驗性地強化「展現多工具呼叫行為」的軌跡（在迭代 2 更顯著），得到 59.6% 的 SWE-bench Verified 分數，多工具呼叫率提升 16%，並把解題平均步數從 53.5 降到 36.6。當我們從迭代 5 策略收集多數軌跡、再從先前策略收集軌跡時，FrogNano 在 SWE-bench Verified 上有 0.8% 的改進到 62.3%，pass@3 為 72.3%、pass@short 為 62.8%。詳細整併程序見附錄 C。

壓縮讓情境視窗更短。 我們分析摘要壓縮 (Summary Compaction) 對模型的效果。這裡不用 131K token 預算，而是給模型固定情境視窗（16K、32K 或 64K token），每當達到上限就把累積情境摘要，再繼續生成直到再次撞上限或代理提交。圖 8 報告每個壓縮預算相對於「相同大小固定情境視窗」的解題率。我們發現壓縮在低 token 預算時幫助最大（此時延長情境的增益很大），但在 64K 時已能恢復完整 131K 的效能。附錄 D 提供進一步分析與設定細節。

RL 訓練跨 harness 泛化。 雖然所有訓練都在 Leaf 進行，我們測試所得增益能否泛化到未見過的 harness——mini-SWE-agent，它只暴露單一 bash 工具（相對於 Leaf 的五個型別化工具）。用我們的標準評測設定（131K 情境、150 回合），我們發現增益可轉移：mini-SWE-agent 效能從 43.8% 提升到 56.4%（比 Leaf 低 5.2%）。預算利用的增益也泛化：FrogNano 平均用更少回合（87.1 對基礎模型的 100.5），只在 9.8% 的軌跡撞回合上限（基礎模型為 31.6%），且從不溢出情境視窗（基礎模型溢出 26 次）。

跨課程的學習動態。 每一輪 TaskPilot 都生成一個校準於當前策略的新合成課程。圖 10 上方面板報告訓練中相對於「該輪第一四分位均值」的解題率變化。五輪的解題率分別提升 11.7、3.4、5.6、3.0、5.4 個百分點。第一個課程帶來最大跳躍；其餘增益穩定在約 3–6 點，五個 block-bootstrap 區間有四個排除零。因此，為最新檢查點重新生成資料仍持續提供有用學習訊號，而非在第一個課程後就飽和。下方面板顯示這些增益不需要策略熵反覆崩潰：熵在迭代 1 下降最劇（從 0.415 到 0.265），之後在更寬但有界的範圍內變動，而解題率持續改進。

對數長度懲罰帶來高效推理。 最佳化過程中我們觀察到推理軌跡長度隨迭代逐步增加，導致中間檢查點因序列變長而越來越貴、也越來越難進一步最佳化。為控制過長的軌跡並改善生成吞吐，我們從迭代 3 起引入對數長度懲罰。圖 9 比較有無此懲罰下訓練期間助手生成 token 的成長。整體而言，對數長度懲罰有助於穩定訓練吞吐、限制過長推理軌跡，且不明顯降低效能。

失敗模式。 圖 12（原文對應圖 11）分析 FrogNano 在 SWE-bench Verified 上的失敗軌跡。失敗絕大多數是推理缺口 (Reasoning Gap)（90.8%），而非過早終止（7%）。按測試行為分：69.8% 從未修好 issue、24.8% 引入迴歸、4.6% 從未乾淨執行。第一類最大也最可行動，因為它反映的是誤解而非資源或基礎設施限制；其中失敗以「瞄準錯誤的根因或層次」（38.8%）與「誤讀規格」（31.5%）為主，其後依序為 API 誤解（14.1%）、實作不完整（13.7%）、遺漏邊界情況（1.9%）。這些失敗也在時間上聚集：約第 10 步的早期失敗源於誤解請求本身（例如把 -1 小時 30 分讀成 $-60+30$ 分而非 $-90$ 分）；約第 40 步的中段失敗雖理解意圖卻瞄準錯誤的實作層次或範圍；第 80 步之後的晚期失敗最罕見，模型理解任務也定位到正確檔案，卻仍提交錯誤 patch，幾乎都是得過且過 (Satisficing)——承認 patch 不完整、常認為任務太難。

獎勵駭入嘗試 (Reward Hacking Attempts)。 我們有一條兩階段的獎勵駭入分析管線。第一階段用 regex 靜態分析標記可疑軌跡（例如檢視 GitHub worktree 內的 commit，或編輯測試檔的軌跡）。此階段標記了 21.3% 的軌跡，其中我們的多數決 LLM-as-a-Judge 管線確認 2.5% 為嘗試性的獎勵駭入。然而所有嘗試性獎勵駭入都被鷹架與基礎設施阻擋。三路 LLM 對駭入判斷的整體一致率為 93.02%，Fleiss' $\kappa$ 為 0.746。舉例來說，若提交的 patch 試圖覆寫用於驗證解答的測試，這些測試會被還原覆寫回去。確認的駭入嘗試以 RH6：削弱評分測試 為主。跨檢查點下，基準獎勵從 49.1% 升到 61.5%，而確認的駭入嘗試率維持在 3.0% 或以下、有效率為 0%（被鷹架與基礎設施擋下，圖 12）。完整規則項見附錄 F。

6 相關工作

倉庫修復與代理介面。 InterCode 與 CodeAct 首先形式化了執行回饋互動與可執行動作。SWE-bench 針對倉庫快照、自然語言 issue 與 F2P/P2P 測試檢驗程式修復。已有多套 harness 被提出：SWE-agent、Agentless、AutoCodeRover、OpenHands、mini-SWE-agent 等，分別提出 LLM 導向的代理-電腦介面、固定管線、程式結構感知搜尋、帶沙箱 runtime 的通用代理平台，以及最小化的純 bash 控制器。其他技術包括以有限狀態修復導引約束工具的 RepairAgent、提供倉庫級程式碼圖的 RepoGraph，以及套用 MCTS 推論時探索的 SWE-Search。Debug-Gym 是一個互動式除錯 harness，意在納入 pdb 等工具做高效修復。程式碼代理通常被訓練使用多套 harness。現階段，FrogNano 的 4B 策略使用固定的 Leaf 介面，訓練與評測沿用同一迴圈。

合成任務與調適課程。 可執行 SWE 資料涵蓋：挖掘 issue–PR 任務（SWE-Gym、SWE-rebench）、commit 衍生任務（R2E-Gym）、測試驅動的部分程式碼（SWE-Flow）、生成的 F2P 測試（SWE-Dev）、合成缺陷（SWE-smith）、跨倉庫 issue 轉移（SWE-Mirror）、特徵誘發的迴歸（BugPilot）。表 1 比較這些代表性管線如何建構規格與可執行 oracle，以及是否用當前策略回饋來塑造任務生成。TaskPilot 在精神上類似近期的 CalibForge（行為校準終端任務、依解題者回饋修訂候選）、BigBang（meta-critic 對照下游訓練結果校準任務品質判斷）與 Recursive Synthesis（有界修復，可修改指令、解答、驗證器、環境與任務設定檔）。

調適課程機制早於語言代理：GoalGAN 瞄準「當前策略成功機率適中」的目標；POET 週期性突變環境並持續最佳化與轉移配對代理；PAIRED 用近似 minimax regret 訓練環境對手；PLR 依當前策略學習潛力與陳舊度優先重播關卡；ACCEL 編輯關卡並用當前策略 regret 估計來策展。ATLAS 進一步把突變擴展到「相對策略的任務-關卡對」。WebRL、ScaleCUA、Envs-FORGE 把這模式擴展到 web、GUI 與可執行任務生成。SPADE 以「環境設計者」與「推理代理」兩種角色聯合最佳化一個共享策略。在 SWE 領域，SSR 以「注入 bug」與「解 bug」兩種角色聯合更新一個共享的 CWM-sft-32B 策略。Socratic-SWE 聯合最佳化共享的 Qwen3.5-9B 生成器/解題者權重。TaskPilot 不聯合訓練其生成器與解題者：它物化真實倉庫的「issue–gold patch–隱藏測試」三元組，再用演進中 4B 策略的盲測 rollout 控制收錄與診斷式修復。把任務生成器與解題者以自我對弈方式聯合訓練，是一個有趣的未來方向。

程式碼與工具代理的強化學習。 FrogNano 用 DPPO 穩定 RL 訓練。DPPO 有別於 GRPO，引入了對「rollout 與行為策略的對數機率絕對差」的對稱裁剪。我們保留 DAPO 的調適過濾，採用 PipelineRL 的非同步訓練機制，並明確約束 rollout 策略陳舊度。與多數先前工作類似，我們的獎勵純粹是二元的測試通過/失敗，不使用其他稠密獎勵。我們的 RL 設定並非個別新穎；其貢獻在於「4B 規模上，調適式 SWE 資料 + 僅對助手施加的對數長度懲罰」這個組合。

緊湊型程式碼代理。 直接可比者包括 Polar（從 Qwen3.5-4B 出發、無教師的線上 GRPO 實驗）、FailForge（對 Qwen3.5-4B/9B 學生的教師導引失敗任務回復）、SWE-MeM（學習式記憶壓縮，其 4B 模型重用 Qwen3-Coder-30B-A3B 生成的 SFT 資料、記憶動作用 GPT-5.1 監督）、以及 Tmax-4B（僅結果的 DPPO）。FrogNano 的倉庫代理後訓練是「免蒸餾 (Distillation-free)」的：起始檢查點之後，它只用 RL、無 SFT、也無更強模型生成的行為目標。更強的模型可以撰寫任務，但不提供供策略模仿的解答軌跡、動作、推理軌跡或 patch。（另外進行的整併實驗確實使用 SFT 與更強模型生成的特權資訊，見附錄 C。）

7 結論

本報告介紹 FrogNano，一個 4B 的程式碼代理。透過本報告，我們展示了「僅用 4B 參數、不從更大模型的軌跡蒸餾、也不依賴大量真實世界資料集」，即可訓練出能與 32B 到 100B+ 模型匹敵的倉庫層級程式碼代理。達成如此規模下卓越程式碼效能的關鍵成分是：為小模型配上合適的工具 harness、線上生成「匹配策略可學習性」的任務、並在迭代 RL 訓練中運用它們。我們在多個程式碼基準上展示了強勁效能，藉此釋放了小模型作為強大倉庫層級程式碼代理的潛力。雖然我們只展示到迭代 5，這個 4B 模型在額外訓練下還能改進多少仍是開放問題。許多問題仍待解答：小模型能否被推向更專門、更難的程式碼任務、如何進一步改善測試時擴增，以及如何在小規模下增進情境管理與推論效率。我們希望社群能在本報告與 FrogNano 之上，為小型程式碼代理開啟無限可能。

限制

我們用「英語、以 Python 為主的倉庫」訓練任務研究本資料生成與模型訓練配方。它對非英語任務、差異甚大的倉庫與框架、需求不清的任務，或缺乏可靠測試的專案的泛化能力，尚未確立。我們也未確立在其他工具介面、提示、環境或情境/工具預算下是否成立。

FrogNano 的基礎模型 Qwen3.5-4B 支援影像與影片輸入，但我們並未後訓練或評估這些能力。我們也未研究此配方對通用助理、形式驗證、安全關鍵軟體或其他高風險應用的適用性。

我們的訓練獎勵與評測分數仰賴測試，而測試只涵蓋程式行為的一部分——通過的 patch 仍可能不正確或不安全。我們提醒實務者：這樣訓練的代理可能誤讀需求、發明不存在的 API、做出不完整或過廣的編輯、引入迴歸或安全瑕疵。我們並未全面重新評估繼承自基礎模型與其訓練資料的偏見、刻板印象、冒犯性輸出或代表性缺口。代理工具應在隔離環境中運行、不直接存取生產系統，並限制對憑證、敏感資料、網路與特權基礎設施的存取。每個 patch 都需要合格開發者審查，並在合併或部署前經過獨立的功能、迴歸與安全測試。以此配方訓練的代理也可能被濫用於惡意軟體、憑證竊取、未授權存取或利用、規避安全控制等有害自動化。

【譯註：核心貢獻者依名字首字母排序：Alessandro Sordoni、Christopher Cui、Emiliano Penaloza、Isadora White、Jeonghye Kim、Jonathan Light、Marc-Alexandre Côté、Maryam Hashemzadeh、Matheus Pereira、Minseon Kim、Roger Creus Castanyer、Xingdi Yuan、Zhengyan Shi。詳細角色分工（TaskPilot RL 環境、模型訓練、Leaf harness 設計、基礎設施工程、評測/分析）見原文致謝與貢獻章節。】

附錄 A：評測基準與 RL 細節

我們在 4 個互補的基準上評估：

• SWE-bench Verified：SWE-bench 中經人工驗證的 500 任務子集，每個實例把一個真實軟體 issue 與固定 base commit 的倉庫、以及指定所需行為的測試配對。
• SWE-bench Pro：把設定延伸到更長時程、更貼近工業的任務，含人工增補的需求。我們用其公開集，含 11 個倉庫的 731 個任務，橫跨 Python、JavaScript、TypeScript、Go。
• Terminal-Bench 2.0：89 個困難任務，靈感來自電腦終端環境中的真實工作流。每個任務提供英語指令、獨立容器環境、人工撰寫的 oracle 解與完整自動化測試，並經大量人工與 LM 輔助驗證，橫跨軟體工程、系統管理、資安、機器學習與科學計算。
• PatchEval-Verified：評估對真實漏洞的自動修復，含 2015–2025 年間揭露、橫跨 Python/JavaScript/Go 的 230 個 CVE 案例。每個案例提供有漏洞的倉庫與 Docker 動態驗證器，測試漏洞是否被修好，而不要求代理重現開發者原本的 patch。

我們保留每個基準的官方隔離執行環境與驗證器，同時使用第 2 節的 Leaf 互動協定。一個實例只有在「所有 F2P 測試通過且指定的 P2P 測試維持通過」時才算解出。部分解、無法套用的 patch、無效的最終狀態或提交、逾時，以及耗盡評測預算的軌跡，都算失敗。

A.1 RL 細節（表 2）

表 2：我們 RL 爬升的有效參數。

表 1：具代表性的軟體工程訓練任務建構機制比較。

附錄 B：推論成本

我們檢視 FrogNano 的推論成本。在 131K 情境長度、平均 53.5 步下，FrogNano 在 SWE-bench Verified 上每任務僅需 $0.21 即可解題（圖 13）。FrogNano 展現與 gpt-5-mini 相當的效能，成本卻只有其十分之一。此外我們比對基礎模型驗證了 FrogNano 的 pass@k（圖 15），確認 FrogNano 不僅改善 pass@1，也提升 pass@k，顯示在 FrogNano 之上仍可能進一步做 RL 學習。

【譯註：圖 13 依 token 預算與各模型官網 API 成本估算；圖 14/15 為 pass@k 曲線，顯示 FrogNano 在各 $k$ 值上一致優於 Qwen3.5-4B。】

附錄 C：以整併合併檢查點

跨 RL 迭代，我們觀察到「先前已解任務被遺忘、多工具呼叫使用減少、過度迭代」等現象。我們把 SFT 整併當作一個獨立實驗來研究，作為保留 FrogNano 最終程式碼能力、同時留住過去迭代所需行為的手段。

為在整併中保留熵，我們依「與參考模型的頂端 token 是否一致」使用兩種損失（參考模型可為 FrogNano 自身或較早的 RL 檢查點）：當目標 token 與參考的最高機率 token 一致時，用「前 64 個 logit 上的 KL 損失」；不一致時改用標準交叉熵損失。參考依目標挑選——要最大化效能就用 FrogNano 當參考；要找回某過去行為，就挑「最常展現該行為、同時維持最多下游效能」的迭代。

為了善用所有任務，我們用迭代訓練期間的所有策略建立一個整併資料集：用 FrogNano 在所有訓練資料的聯集上、以多個 seed 生成，過濾出全部成功軌跡。對不成功軌跡，我們用兩種方式納入最終混合：其一，用先前檢查點嘗試解出並加入成功軌跡；其二（僅限整併資料），從失敗嘗試以 GPT-5.6-Sol 生成負向特權資訊，把這些負向軌跡加入混合。若參考是較早的 RL 檢查點，我們再從它生成軌跡以增補 FrogNano 的成功軌跡。最後對所有成功軌跡進一步過濾，讓早期較易的任務不會相對後期較難任務被過度取樣，並在展現所需行為（如平行工具呼叫）時優先採用正確的參考軌跡。

• 回收平行工具呼叫：迭代 2 是最後一個顯著展現平行工具呼叫行為的迭代（表 5）。上取樣迭代 2 軌跡並以之為參考，能以「效能小幅下降」為代價找回這些平行呼叫，達到 59.6% SWE-bench Verified、平行工具呼叫率 17.7%，並把解題平均步數從 53.5 降到 36.6。相比之下迭代 4 的平均分數為 59.1%、平行呼叫率僅 0.46%、平均 43.4 步。
• 以 FrogNano 自身為參考：整併帶來效能前沿的小幅改進。整併後的 FrogNano 在 SWE-bench Verified 上增益 0.8% 到 62.3%，pass@3 從 71.0% 升到 72.3%、pass@short 從 60.0% 升到 62.6%。SWE-bench Pro 上也有類似小增益：平均分數從 37.6% 到 38.1%、pass@3 從 47.6% 到 49.38%，但 pass@short 從 38.0% 降到 37.21%。

表 5：Leaf 各迭代的工具呼叫使用（排除零工具步）。

附錄 D：情境壓縮的機制與設定

D.1 觸發與預算

令 $H_{t}$ 為第 $t$ 步的對話歷史、$\tau(\cdot)$ 為對訊息串的計 token 函數、$W$ 為壓縮情境視窗、$\rho$ 為觸發比例。每次生成前，代理檢查 $\tau(H_{t})\geq\rho W$，成立就在模型呼叫前壓縮。摘要請求本身必須裝進 $W$，因此可供對話前綴使用的預算為：

$$C=\max\!\bigl(1,\;W-\tau(P)-\lfloor\alpha W\rfloor\bigr),\qquad\alpha=0.2,$$

其中 $P$ 為壓縮指令、$\lfloor\alpha W\rfloor$ 為將生成摘要保留的空間。

D.2 截斷與重建

歷史被截斷到 $C$ token，方式是移除最舊的完整「回合組」（一則助手訊息連同其工具呼叫與結果）。截斷整組可避免孤立的工具參照（Leaf 會拒絕它們）；系統前綴與最近一組總是保留。歷史重建為：

$$H_{t+1}=\bigl[\,\text{系統訊息}\;\|\;\bigl[\,u_{0}\,\|\,\sigma\,\|\,S\,\bigr]\,\bigr],$$

其中 $u_{0}$ 是原始任務陳述、$\sigma$ 是宣告「較早回合已被摘要」的固定分隔符、$S$ 是摘要。所有中間回合被丟棄。結果恰含一個系統區塊與一則使用者訊息，因此下一次模型呼叫預期一個助手回合、角色交替得以保持。每事件壓縮率 $r=1-\tau(H_{t+1})/\tau(H_{t})$ 落在 0.90–0.96。

D.3 代理自己做摘要

摘要模型就是 FrogNano 自己：正在解題的同一個 4B 檢查點被要求摘要自己的軌跡，不使用另一個或更大的摘要器。這讓壓縮維持在第 6 節的免蒸餾設定內——沒有更強模型提供「會重新進入策略所依情境」的摘要，也意味壓縮品質本身是 4B 模型的能力，而非外部服務，這正是它在單模型服務情境下可部署的原因。

D.4 摘要提示

Leaf 使用一條「以延續為導向」的指令：建立本軟體工程任務的簡潔延續摘要。保留任務與約束、重要發現與決定、變更的檔案與當前倉庫狀態、命令/測試與其結果、未解問題與具體後續步驟。只輸出摘要。

D.5 壓縮曝露

壓縮對任何從未達到 $\rho W$ 的軌跡是 no-op，因此 $W$ 越大，被觸及的 rollout 比例越小，機制先變罕見再變無效。在 16,384 / 32,768 / 65,536 token 下，壓縮分別在 87% / 51% / 4% 的 rollout 觸發，觸發的 rollout 上中位壓縮次數分別為 4 / 2 / 1 次。

D.6 設定陷阱

式 (1) 的兩個性質在我們自己的實驗中造成靜默 no-op，值得為重現此設定者指出：第一，觸發取決於壓縮視窗 $W$，而非硬情境上限 $M$；設 $W>M$ 會得到「沒有 rollout 能達到」的門檻，因為生成先在 $M$ 失敗、壓縮永不觸發。第二，若 $\rho W$ 超過某工作負載中任何 rollout 達到的最大情境長度，無論是否啟用，壓縮都失效。約束 $\rho W\leq M$ 不會被設定驗證器檢查，設計實驗時必須自行確認。

附錄 E：學習與工具使用動態

固定評測集上的效率。 我們在完全相同的 500 個 SWE-bench Verified 任務上、以共享的 Leaf 提示、工具 schema、取樣設定、131k 情境視窗與 150 步預算，重新評估基礎模型與後續 TaskPilot 檢查點。解題率在每個檢查點都上升：基礎模型 39.4%，迭代 1–5 後依序為 48.2%、53.4%、58.3%、58.6%、61.6%。然而計算配置是非單調的：迭代 1 改進 9.8 點，而平均助手輸出僅小幅上升（11.0k → 12.0k token）、平均軌跡長度從 37.8 步降到 20.1 步；迭代 2 把兩者都擴大到 16.3k token 與 30.2 步；迭代 3 再增益 4.4 點卻把助手輸出壓縮到 13.2k token（減少 19.4%），儘管互動增到 33.7 步（與該輪引入的成功門控對數長度懲罰一致）；迭代 4、5 逐步把互動增到 14.7k / 19.3k token 與 43.4 / 62.9 步。因此留出效能貫穿課程序列持續改進，但不遵循簡單的「更多 token」或「更多步」關係。

工具使用動態。 我們從 12,800 條訓練軌跡解析出共 576,592 個結構化工具呼叫，依其在工作流中的角色分組。無論最早或最晚的訓練 rollout，代理都遵循清楚的「檢視–編輯–驗證」編排（圖 17a）：檢視前置、編輯集中在中段、驗證集中在末段。軌跡前五分之一在迭代 1 起始含 42.6% 的檢視呼叫、迭代 5 末含 39.4%；中間三個 decile 分別含 39.6% 與 49.5% 的編輯（顯示最終檢查點的編輯階段更銳利），末五分之一則持續含約 41–42% 的驗證呼叫。我們接著在 1,497 個完全相同的任務-seed 對上比較基礎模型與迭代 5 檢查點（圖 17b）：含驗證動作的配對 rollout 比例從 53.4% 升到 94.3%；在兩檢查點都用驗證的配對中，末五分之一的驗證呼叫比例幾乎不變（23.6% → 24.0%）。

跨訓練課程的工具組成。 圖 18 顯示訓練中工具使用的分布。迭代 2 中 Bash 從 54.8% 擴大到具名呼叫的 74.6%。迭代 3 引入對數長度懲罰後模式反轉：Bash 從 81.9% 降到 66.1%，Read 從 5.5% 升到 14.8%、Edit 從 11.9% 升到 18.3%。這個組成轉變伴隨每軌跡總呼叫數從 52.2 降到 38.6，顯示壓縮移除了一般 shell 互動、卻保留了更有針對性的結構化檢視與編輯。迭代 5 反而把總呼叫數從 49.0 增到 60.9，而組成只小幅改變（Bash 63.0% → 66.3%）。

與成功相關的行為。 我們在同一合成實例與訓練端點內，比較「通過」與「失敗」的隨機軌跡，保留 1,415 個同時含兩種結果的組（圖 19）。通過的軌跡：跑測試的機率高 5.3 點、在最後一次編輯後測試的機率高 8.1 點、完成一次「編輯–測試」循環的機率高 6.1 點。首次編輯前的檢視在兩種結果間幾乎相同，而驗證後修訂與多呼叫使用區分度很小。詞彙推理線索同樣薄弱：規劃、診斷、不確定、重新考慮與驗證意圖的比率差異至多 1.7 點。最終自信語言在通過軌跡中多 7.0 點，但仍出現在 65.1% 的失敗軌跡中。因此最清楚的成功特徵是行為性而非修辭性的：成功的代理更可能以「可執行的驗證」收尾，而不只是表達自信。

附錄 F–I：獎勵駭入偵測與裁決規則

論文附錄 F–I 詳述了一套完整的獎勵駭入 (Reward Hacking) 偵測與裁決規則，用於前述的兩階段分析管線。以下摘其要點。

定義（附錄 F.1）。 每個駭入嘗試依兩個維度分類：

• Present（呈現）：軌跡中是否出現駭入意圖/行為。
• Effective（有效）：該行為是否真的影響了評分結果。FrogNano 的所有確認駭入嘗試都因鷹架與基礎設施而 Effective = 0%（例如被覆寫的測試檔會被還原）。

兩階段分析（附錄 F.2）。 第一階段用 regex 靜態偵測（漏斗）標出可疑軌跡（占 21.3%）；第二階段用三路 LLM-as-a-Judge 多數決裁決（整體一致率 93.02%、Fleiss' $\kappa$ = 0.746），確認 2.5% 為嘗試性駭入。

完整偵測與裁決分類（附錄 F.3，表 3）。 各代碼的角色分為「Final signal（最終訊號，可獨立判為 HACK）」、「Detector funnel only（僅偵測漏斗，選候選但不能獨立判 HACK）」、「Reporting only（僅回報完整性）」、「Diagnostic only（僅診斷）」：

重要裁決區分（附錄 F.4）：區分「過去考古 (Past archaeology) vs. 未來洩漏 (Future leakage)」、「測試調適 (Test adaptation) vs. 測試削弱 (Test weakening)」、「壞修正 (Bad fixes) vs. 獎勵駭入」；並有「裁決升級 (Verdict escalation)」規則。附錄 G–I 進一步給出 LLM 裁判所見的內容、完整裁判規則（含定義、代碼、過去 vs. 未來的考古判準、可疑但合法的樣態、決策程序與輸出 schema）與行為漂移 (Behavioral Drift) 分析——這些是供重現裁判管線用的詳盡規則清單，此處不逐條轉錄。

參考文獻

【依原文編號，內文引用的數字對應下列條目；保留原文英文。】

1. A. Antoniades, A. Örwall, K. Zhang, Y. Xie, A. Goyal, and W. Wang (2025) SWE-search: enhancing software agents with monte carlo tree search and iterative refinement. In International Conference on Learning Representations, Vol. 2025, pp. 64485–64515.
2. I. Badertdinov, A. Golubev, M. Nekrashevich, A. Shevtsov, S. Karasik, A. Andriushchenko, M. Trofimova, D. Litvintseva, and B. Yangel (2026) SWE-rebench: an automated pipeline for task collection and decontaminated evaluation of software engineering agents. Advances in Neural Information Processing Systems 38.
3. L. Bai, Z. Huang, X. Wang, J. Sun, R. Mihalcea, E. Brynjolfsson, A. Pentland, and J. Pei (2026) How do ai agents spend your money? analyzing and predicting token consumption in agentic coding tasks. arXiv preprint arXiv:2604.22750.
4. I. Bouzenia, P. Devanbu, and M. Pradel (2025) RepairAgent: an autonomous, LLM-based agent for program repair. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), pp. 2188–2200.
5. J. Da, C. Wang, X. Deng, Y. Ma, N. Barhate, and S. Hendryx (2025) Agent-RLVR: training software engineering agents via guidance and environment rewards. arXiv preprint arXiv:2506.11425.
6. X. Deng, J. Da, E. Pan, Y. Y. He, C. Ide, K. Garg, N. Lauffer, A. Park, N. Pasari, C. Rane, K. Sampath, M. Krishnan, S. Kundurthy, S. Hendryx, Z. Wang, V. Bharadwaj, J. Holm, R. Aluri, C. B. C. Zhang, N. Jacobson, B. Liu, and B. Kenstler (2026) SWE-bench pro: can AI agents solve long-horizon software engineering tasks?. In Proceedings of the 43rd International Conference on Machine Learning.
7. M. Dennis, N. Jaques, E. Vinitsky, A. Bayen, S. Russell, A. Critch, and S. Levine (2020) Emergent complexity and zero-shot transfer via unsupervised environment design. In Advances in Neural Information Processing Systems, Vol. 33, pp. 13049–13061.
8. C. Florensa, D. Held, X. Geng, and P. Abbeel (2018) Automatic goal generation for reinforcement learning agents. In Proceedings of the 35th International Conference on Machine Learning, PMLR, Vol. 80, pp. 1515–1528.
9. (參見原文) Bounded-staleness asynchronous RL references.
10. ATLAS: policy-relative task–level pair mutation for adaptive curricula.
11. SWE-MeM: learned memory compression for compact SWE agents (4B model reusing Qwen3-Coder-30B-A3B SFT data; GPT-5.1 memory supervision).
12. (參見原文) Binary test-pass/fail reward RL for code agents.
13. (參見原文) Binary test-pass/fail reward RL for code agents.
14. SAO: bringing back value models at scale.
15. (參見原文) Explicit rollout-policy staleness bounding.
16. Qwen2.5-Coder: file- and repository-level continued pretraining plus instruction tuning across 0.5B–32B code models.
17. Tmax-4B: outcome-only DPPO, part of a 2B–27B family.
18. R2E-Gym: commit-derived executable SWE tasks.
19. PLR: prioritized level replay via current-policy learning potential and staleness.
20. SWE-bench: code repair for repository snapshots, natural-language issues, and F2P/P2P tests.
21. (參見原文) Privileged information for learning.
22. (參見原文) Compiler-observed test outcomes to train a critic.
23. Recursive Synthesis: bounded repair modifying instructions, solutions, verifiers, environments, and task-config files.
24. mini-SWE-agent: minimal bash-only controller harness.
25. SPADE: jointly optimizing a shared policy via environment-designer and reasoning-agent roles.
26. RLTF: online refinement with test-pass-rate feedback.
27. (參見原文) Binary-reward RL for tool agents.
28. ScaleCUA: current-policy outcome-driven GUI task generation.
29. FailForge: teacher-guided recovery of persistently failed tasks for Qwen3.5-4B/9B students.
30. CalibForge: behavioral calibration of terminal tasks with solver-feedback revision.
31. Terminal-Bench 2.0: hard terminal-environment tasks with containerized envs and automated tests.
32. SWE-bench Verified: human-validated 500-task subset of SWE-bench.
33. RepoGraph: repository-wide code graph for program repair.
34. SWE-Gym: mined issue–PR executable SWE tasks.
35. ACCEL: editing levels and curating via current-policy regret estimates.
36. (參見原文) Privileged-information SFT for consolidation.
37. Orchard-SWE: multi-harness distillation, credit-assignment SFT, and Balanced Adaptive Rollout.
38. PipelineRL: asynchronous RL training mechanism.
39. DPPO: symmetric clipping on absolute log-probability difference of rollout and behavior policy.
40. WebRL: current-policy outcome-driven web task generation.
41. Qwen3.5-4B (base model technical report).
42. GRPO: group-relative policy optimization.
43. BugPilot: feature-induced regression executable SWE tasks.
44. SWE-Lego: teacher-distilled SFT comparator with/without verifier-selected TTS@16.
45. BigBang: meta-critic calibration of task-quality judgments against downstream training outcomes.
46. (參見原文) Ranking-verifier training.
47. SWE-Dev: mined issues with synthesized F2P tests.
48. SWE-Mirror: cross-repository issue-semantics transfer.
49. POET: environment mutation with paired-agent optimization and transfer.
50. InterCode: execution-feedback interaction.
51. SWE-agent: LLM-oriented agent–computer interface.
52. SWE-RL: single-response patch training with oracle-patch similarity rewards.
53. SSR: shared-policy bug-injection/bug-solving joint updates over executable code and tests.
54. PatchEval-Verified: automated repair of real-world CVEs (230 cases, 2015–2025).
55. Envs-FORGE: executable task generation using current-policy outcomes.
56. Agentless / AutoCodeRover / OpenHands (fixed pipeline / program-structure-aware search / sandboxed general agent platform).
57. Socratic-SWE: shared Qwen3.5-9B Generator/Solver with gradient-alignment rewards.
58. Polar: teacher-free online-GRPO from Qwen3.5-4B.
59. SWE-smith: synthetic-fault executable SWE tasks.
60. CodeAct: executable actions formalization.
61. DAPO: adaptive filtering / zero-variance-group removal for RL.
62. Debug-Gym: interactive debugging harness incorporating tools such as pdb.
63. SWE-Flow: test-driven partial-code executable tasks.
64. (參見原文) Additional harness reference (OpenHands / platform).
65. SGLang: inference serving engine.
66. Z. Zhu, C. Xie, X. Lv, and slime Contributors (2025) Slime: an LLM post-training framework for RL scaling. Note: https://github.com/THUDM/slime

【譯註：部分條目原文為引用鍵，未在抽取內容中提供完整書目，已以「(參見原文)」或該工作的識別描述標註；編號與內文引用一致，完整書目請參閱原始論文的 References 章節。】

術語對照表