Self-HPO 讓程式代理改流程再訓練自己：57.8% 到 64.8%，改善來自哪裡？
Self-HPO 讓程式代理用自己的失敗改寫外部工作流程，再透過強化學習訓練模型。本文拆解 H-step、P-step、三組 SWE-bench 結果、可下載模型與資源限制，區分自身提案與外部模型協助的版本。
Self-HPO 研究裡，AI 在資料夾裡改好了程式，最後卻只交出一段說明，驗收時仍可能得到零分。程式能力之外，代理如何接收資訊、執行命令與提交修改，也會決定工作是否完成。
Microsoft Research 與合作研究者在 10 月 19 日公開 Self-HPO 的程式與訓練後模型，讓寫程式的模型先分析失敗、改進外部流程，再在新流程裡訓練自己。
這層外部流程稱為 harness，會管理工具、回饋與結束條件。而負責決定下一步的模型稱為 policy。兩者輪流改善，下一輪處理的就會是更新後仍做不好的工作。
以 Qwen3.5-35B-A3B 為起點，研究的三組軟體修正評測平均解決率從 57.8% 升到 64.8%。這是指定模型、流程與測試條件的結果，不等於日常所有程式工作都有同樣提升。
有自動驗證環境與訓練資源的團隊，可以研究這種從失敗更新流程的方法。一般開發者則比較適合先理解它避免漏交成果的設計，不必把下載模型當成完成整套訓練。
要看懂改善從哪裡開始，先把模型寫出修正與代理真正交出可驗收成果的差別拆開。
模型會寫程式，為什麼代理仍可能交不出成果？
模型產生有用修改之後，外部流程還得讓它取得工具回饋，並把真正的程式差異送進驗證器。否則檔案裡有改動，交出去的成果仍可能是空的。
這個差別在研究的案例中很具體。同一個訓練後模型已經修改原始碼、通過現有測試，卻在結束時只提交一段工作說明，導致沒有程式差異可以評估。
換到演進後的流程，系統會攔住第一次提交，指出沒有包含檔案，讓模型再繼續處理。模型於是寫出修補內容、檢查後重新提交，這次驗證器才拿得到實際修改。
案例顯示的不是模型突然學會新的程式語言，而是既有能力有沒有經過正確的提交路徑。對代理來說，回答「我完成了」與交出可驗收成果，必須由外部流程連起來。
原始論文把模型與這層流程視為一個配對。模型決定採取什麼行動，流程則決定它看到什麼、命令如何執行，以及什麼情況下會結束。
研究從 mini-SWE-agent 的基本循環開始，讓模型在隔離的任務環境中呼叫命令、讀取回饋，再交出修補。隔離環境在這裡也提供執行檢查，而不只是一個聊天視窗。
這使得有些失敗可以從流程下手。論文另以外部模型提案的 HPO 比較流程，示範時間快用完時提醒收斂，或在收到空成果時要求補交。但提醒是否對症，仍要看實際執行紀錄，不能只因多加一段要求就認定會改善。
論文案例也記錄了一個判斷錯誤的提醒，因為它從無關文字抓到關鍵字。這表示流程能補救某種提交失敗，同時仍可能產生雜訊，不能把每個新增檢查都當成正確。
這些失敗會留下執行紀錄，也就成為下一步修改流程時可以檢查的證據。
H-step 如何用自己的失敗改進流程？
H-step 暫時固定模型，讓它查看失敗軌跡，提出新的流程候選，再用同一批搜尋任務比較效果。因此，這一步在修改的是模型周圍的程式與提示。
軌跡是模型回答、工具呼叫與環境回饋的連續紀錄。它能顯示失敗發生在找檔案、修改、測試或提交的哪個位置，比分數低了幾分提供更多線索。
Self-HPO 的特點是由目前的模型自己提出流程修改，而不另找一個更大的模型專職設計。提出修改時，模型會讀取父版本、先前候選的結果與失敗案例，形成新的假設。
候選可以調整提示，也可以修改執行時邏輯。例如在特定狀態回傳補充訊息，讓模型再多處理一輪，而不是原封不動接受第一次提交。
但搜尋有固定邊界。研究要求保留父版本的方法，再加入新的機制。模型、取樣設定、步數與驗證器等條件也會固定，避免候選只靠放寬限制取得高分。
流程設計者能查看搜尋題目的參考修正，協助診斷錯在哪，但不能把參考程式或題目特定答案直接塞給執行模型。新機制必須在執行時自行產生訊號。
這一點會影響研究結果的解讀。若流程只記住某道題的答案，測試變好也未必有遷移價值。研究要找的是能在不同任務觸發的補救方法。
每輪 H-step 比較六個候選，並在同一批搜尋任務上選出效果較好的版本。因為這批題目在該步驟內固定，分數差異才比較能對應候選改動。
不過，模型更新之後，原本的弱點也可能改變。因此，下一輪搜尋不會永遠盯著最初那批題目，而要接收訓練後仍未完成的工作。
流程改完之後，模型不會因此自動學會新行為，所以接下來還要在選定流程裡更新模型。
P-step 如何訓練模型，再決定下一輪要修什麼？
P-step 固定剛選出的流程，透過可驗證結果訓練模型，再把仍然從未成功的訓練任務交回下一輪搜尋。兩步輪流進行，才會改變模型與流程的整體配對。
這裡的訓練採強化學習，也就是根據嘗試後的結果調整模型。軟體任務有能執行的驗證器，產生的修補通過檢查才算成功，讓回饋不只取決於文字聽起來是否合理。
研究使用的方法會比較多次嘗試的結果，並調整取樣，減少一整組都失敗而難以取得學習差異的情況。這是在改善訓練訊號，不表示每次失敗都能立刻找到正確答案。
流程也會影響模型能遇到哪些經驗。若它在模型還有機會補交時就結束，訓練只會看到失敗。若適時回傳有用訊息，模型才可能走到可被驗證的成功路徑。
反過來，模型學會了新行為，原本必要的提醒可能就不再是最有用的改動。因此，訓練結果會改變後續流程搜尋的重點，兩邊並非彼此獨立的加分項。
研究從三個公開來源整理 2,484 道訓練任務，同時供流程搜尋與模型訓練使用。這些題目與最後報告的測試資料應分開理解，不能把訓練時找到的失敗直接當測試成績。
實驗進行兩輪流程與模型交替更新，每個 P-step 有五十次強化學習更新。停止條件與難題集合是否穩定有關，並沒有宣稱系統能不受限制地持續變強。
交給下一輪的難題，是上一個訓練步驟中所有嘗試都未解決的任務。若只是偶爾失敗，和完全沒有成功路徑，對流程修改的意義可能不同。
這樣刷新搜尋集合，能讓設計者關注新模型仍卡住的地方，而不是一直修復它早就學會的問題。論文對照實驗也顯示，固定沿用最初集合的效果較差。
因此，兩種更新會改變彼此面對的問題，是否真的優於只改一邊，必須用相同評測比較。
57.8% 到 64.8% 的結果，怎麼比較才合理？
64.8% 是三組程式修正評測解決率的平均，並且來自模型與流程共同更新的組合。它描述的是特定研究設定，不能直接當成所有程式工作的成功機率。
三組測試分別是 SWE-bench Verified、Multilingual 與 Pro。Verified 有五百題，Multilingual 有三百題，Pro 使用的公開版本有六百四十二題，涵蓋不同的軟體問題。
因為每組題數不同，三組分數的等權平均，和把所有任務加在一起算比例並不相同。57.8% 到 64.8% 應讀成平均增加七個百分點，而不只說「多成功百分之七」。
官方模型卡列出的主要結果如下，分數都是修補通過相應驗證的解決率。
| 組合 | Verified | Multilingual | Pro | 三組平均 |
|---|---|---|---|---|
| 基礎模型與原流程 | 61.0% | 54.2% | 58.3% | 57.8% |
| Self-HPO 模型與流程 | 69.5% | 59.7% | 65.2% | 64.8% |
表中的提升來自模型與流程一起改變。論文以三次評估的平均與標準差報告結果，因此一個百分點內的差異，也應連同執行波動理解。
只更新模型的比較組，三組平均為 61.9%。只更新流程則為 60.1%。共同更新組的平均更高，支持在這組任務裡，兩種改進互相配合有額外價值。
另一個比較把更新後的流程接回基礎模型，或把更新後模型放回原流程。兩者都保留部分改善，但完整配對在 Verified 得到最高結果，說明下載其中一部分不會自動等於完整系統。
研究也測試由外部 Opus 4.8 提出流程修改的 HPO 版本，三組平均可到 66.3%。這個版本額外使用外部設計者，不能把它與不需要外部提案模型的 Self-HPO 成績合併。
若允許同一道題嘗試八次，研究的至少一次成功指標也從 80.0% 增加到 84.8%。這個結果描述多次取樣後能不能找到解法，與一次就交出正確成果的可靠度不同。
因此，有完整驗證器而且能接受重試的流程，可以把多次嘗試納入評估。若使用者只願意等待一次回答，就仍要看單次結果。兩種用法需要的時間與檢查成本不同，不能只挑較高的數字作採用依據。
改善也沒有發生在每一道題上。論文把題目依基礎模型原本成功程度分組，發現部分原本很穩定的題目反而退步，所以平均變好仍要查看自己在意的工作類型。
成績支持兩邊一起改善，但採用前仍要確認拿到的是哪一版模型，以及和它配對的流程。
公開模型與程式，適合怎樣的團隊使用？
公開成果包含訓練後模型與對應流程，但重現研究仍需要沙盒服務、評估資料與足夠的運算資源。使用這些成果，與重新執行全部自我改善實驗，是不同工作量。
這次公開也有明確時間依據。論文最早於十月十六日提交，程式在十月十九日上傳，模型檔案的首次釋出紀錄也在同日，因此本週新增的是可取得的程式與訓練成果。
官方程式庫分別提供模型服務、產生執行軌跡與評分的步驟。評估時要讓模型與指定流程配對，再保存每一輪的實際結果，才有辦法對照研究數字。
研究團隊使用八張 B200 執行評估與訓練。這是公開重現環境的參考，不能把較小的啟用參數數量，直接解讀成一般筆電就能完成同樣訓練。
沙盒服務也要另外準備。它負責每個任務的隔離容器與工具執行，因此只有模型服務啟動，仍不等於已能在相同環境重現軟體修補評估。
對一般開發者，最容易先借用的是把提交結果變成可檢查資料的想法。測試通過、變更檔案與最終交付若能互相對應，就比較容易抓到「做了但沒交出來」的失敗。
但不宜直接照抄所有提醒。研究自己的案例就出現誤判訊號，所以應先找出流程中反覆發生的具體失敗，再檢查新增機制是否真的在那種狀況觸發。
授權也分開處理。程式庫採 MIT，模型卡採 Apache License 2.0，隨附工具仍有各自條款。下載訓練後模型，沒有自動替所有環境與資料取得使用權。
Self-HPO 的研究價值，在於讓失敗同時影響流程設計與下一輪模型學習。它提供可檢查的訓練迴圈，也保留了評估資料、驗證器與資源條件這些邊界。
先從可重現的一類程式任務與正確提交成果做起，再評估是否值得加入訓練迴圈，才能把自我改善落在可檢查的進展上。
若要比較其他程式模型與外部流程的設計，可從下列兩項研究了解不同改進方向。
延伸閱讀：Recursive Flint 開放權重：40B 本機程式模型，Eureka Machine 幫忙做了什麼？
延伸閱讀：OpenVLHarness 視覺代理框架：不重訓模型，工具與多模態記憶能改善哪些看圖工作？
Self-HPO 常見問題
Self-HPO 的論文與程式何時公開？
論文最早於 2026 年 10 月 16 日提交，程式與訓練後模型於 10 月 19 日發布。這次關注的是本週可取得的程式與模型成果。
需要外部大模型設計流程嗎？
這個自提案版本使用目前的模型自己提案。研究另有外部 Opus 提案的 HPO 比較組，數字與資源條件應分開看。
64.8% 是某一組 SWE-bench 的分數嗎？
這是三組評測解決率的平均，並非全部任務加權比例，也不是單一 Verified 分數。
