CodeRescue 用預算路由修復代理

CodeRescue 怎麼決定 coding agent 失敗後要不要繼續便宜修復？

CodeRescue 讓寫程式代理在失敗後，依預算決定先便宜修復，還是直接升級更強模型。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：35% 的 mean recovery cost
• 突破點：Supervised recovery router plus CRC budget calibration

這篇論文在處理一個很實際的問題：coding agent 不是只會「答對」或「答錯」。它常常是先失敗，然後留下 runtime、測試或錯誤訊息，這些訊號其實還有用。問題就變成，失敗之後要怎麼走下一步，才不會把預算浪費在不必要的升級上。

CodeRescue 的核心想法很直接。不要把失敗當成單純的升級開關。它把失敗後的處理，改寫成一個 recovery routing 問題：哪些案例值得再用低成本方式修一次，哪些案例應該直接交給更強、也更貴的模型。論文再加上一層校準，讓同一個 routing policy 可以在不同預算下部署，不必每次都重訓。

這篇在解什麼痛點

對做 coding agent 的團隊來說，第一輪輸出常常不是終點。程式跑起來之後，系統會回傳錯誤、測試失敗或執行結果。這些回饋會透露很多資訊，甚至足以讓一次便宜的修復嘗試把問題救回來。

但很多 cost-aware 系統的做法還是太粗。它們常見的模式是 cascade：先用便宜模型，失敗就把難題升級給更強的模型。這種做法在「失敗就是死路」時很合理，可是在 coding agent 場景裡，失敗往往只是中途訊號，不一定代表要立刻升級。

所以這篇論文要修的是控制邏輯，不是單純換模型。它問的不是「這題難不難」，而是「看過失敗回饋後，哪一種 recovery action 的成本與成功率最划算」。這就是 CodeRescue 想處理的 routing 決策。

方法怎麼運作

方法分兩層。第一層是把 post-failure decision 定義成在 heterogeneous actions 之間做 recovery routing。白話一點，就是 router 不再只做「便宜 vs. 昂貴」的二選一，而是根據情況挑不同的修復路徑。

第二層是訓練方式。論文說這個 router 是用 supervised 的方式，根據 execution rollouts 來學。摘要沒有把所有特徵、模型架構或標註細節寫滿，但主軸很清楚：把過去失敗後的執行歷史和結果拿來學，讓系統知道在什麼情況下哪種 recovery action 比較容易成功。

真正讓它能部署在不同預算下的，是 CRC，也就是 Conformal Risk Control。論文把 CRC 加進來，當成一個 calibration layer，用來在部署時選擇 cost penalty，而且不用重訓 router。這點很重要，因為實務上的預算不是固定的。有時候你想省錢，有時候你又想衝 solve rate，如果每換一次目標就要重訓，維運成本會很高。

作者還把這層校準描述成能在 exchangeability 假設下，提供 marginal expected-cost control。講白話，就是它想讓這個「預算旋鈕」不只是經驗法則，而是有統計意義的控制手段。對操作端來說，這比單純調 heuristic 更有可預期性。

論文實際證明了什麼

評估是用五個 coding benchmark 的 held-out failures。摘要沒有列出 benchmark 名稱，也沒有公開完整的每項分數，所以這裡看不到完整 benchmark 細節。能確認的是，便宜修復和升級處理在這些失敗案例上呈現互補的成功模式。

這個互補性是整篇論文最重要的實證訊號。它表示選擇不是「便宜一定比較差」或「昂貴一定比較穩」。有些失敗值得再做一次低成本修復，有些則應該直接升級。CodeRescue 的目標，就是把這兩類 case 分開，而不是硬塞進同一條 cascade。

摘要還說，經過校準的 frontier 比 fixed actions、prompt-only routers 和 binary cascade baseline 都更好。最明確的數字是：在主 GPT-5.4-nano / GPT-5.4 設定裡，某個 CRC-calibrated frontier point 的 solve rate 超過 always-escalate，而且只用了它平均 recovery cost 的 35%。

這個結果對實作者很有意思，因為它不是單純拿準確率換成本。至少在那個操作點上，它可以比「一律升級」更會解題，同時把 recovery 成本壓得很低。不過摘要沒有給完整 frontier 曲線，所以無法從這段資料判斷這個優勢在所有 budget 下是否都穩定。

對開發者的實際影響

如果你在做 coding agent，這篇論文最直接的提醒是：失敗處理本身就是一個 budgeted control problem，不只是 fallback。一次失敗的執行結果，常常是有價值的訊號。下一步不一定要立刻丟給最大模型，也可能先用便宜的 recovery 再試一次更划算。

這對產品和基礎設施都很有感。產品面上，它有機會在不把所有難題都送去最貴路徑的前提下，提高 solve rate。基礎設施面上，它提供一個更明確的方式去管理失敗後的推理支出。很多 agent workflow 的預算，其實就是在這些「失敗後再試一次」的環節慢慢燒掉的。

CRC 的校準角度也很實用。部署預算通常不會永遠固定，今天要省、明天要衝，臨時改 cost target 很常見。如果能直接調 penalty，而不是每次重訓一個 router，操作上會乾淨很多。前提當然是你的資料分佈和論文假設夠接近。

限制與還沒回答的問題

摘要把方法講得很清楚，但實作細節留得不少。它沒有交代 router 的具體架構、supervised label 怎麼做、五個 benchmark 分別是什麼，也沒有說 recovery actions 的完整形式。這些資訊對要重現系統，或拿來跟自家 agent stack 比較的人來說，都很重要。

還有一個統計上的限制。CRC 依賴 exchangeability 假設，並且給的是 marginal expected-cost control。這種保證有用，但不代表在 production 裡一定穩。只要你的工作負載分佈變了、工具鏈變了、測試環境 drift 了，這個假設就可能開始鬆動。

最後，摘要只報告一個強的 operating point，沒有完整部署故事。我們知道它在 35% 的 mean recovery cost 下能超過 always-escalate solve rate，但不知道 latency 會怎麼變，也不知道它對不同 coding 任務、不同模型配對的敏感度有多高。這些都會影響真實上線價值。

總結

CodeRescue 想做的事，其實很務實：讓 coding agent 在第一次失敗後，別急著全數升級，而是先判斷哪種 recovery 路徑最划算。它把失敗視為有資訊的狀態，再用 supervised router 加上 CRC 校準，把預算控制做得更細。

對開發者來說，這篇的訊息很明確。post-failure routing 不是小題目，而是會直接影響成本與 solve rate 的核心控制問題。這篇論文展示了一條可行路徑，但摘要也留下不少空白。真正的考驗，會是它能不能在論文列出的 benchmark 之外，還維持同樣的成本品質平衡。

• 失敗後的執行回饋，可以當成有用訊號來路由。
• CRC 讓同一個 recovery policy 能對不同預算做校準。
• 摘要中的最佳點，是 35% mean recovery cost 下仍能超過 always-escalate。