RRSI:讓 AI 代理人「自我進化」的鷹架,如何避免練成應付考試的假把式
RRSI: Regularized Recursive Self-Improvement of Agent Harnesses
背景
近年來最會做事的 LLM agent,強的往往不只是背後那顆語言模型,而是包在模型外面的「harness」——也就是 prompt 設計、控制流程、工具呼叫方式、記憶機制與 context 管理這一整套系統。同一顆凍結不動的 backbone model,換一套 harness 就可能有天差地遠的表現。於是研究者開始嘗試讓 AI 自己去修改、優化自己的 harness:反覆提出修改方案、測試、挑出更好的版本,再繼續迭代——這其實就是一種「代理人系統層級的遞迴自我改進」(recursive self-improvement, RSI)。
問題是,這種自動演化很容易「背答案」。當演化過程一直拿同一組訓練任務當作評分標準,系統很容易學會針對這批任務的特定捷徑或小抄式邏輯,結果在訓練集上分數飆升,一換到沒看過的 out-of-distribution(OOD)benchmark,漲幅就大幅縮水,甚至完全消失,等於是過擬合(overfit)到了訓練任務,而非真正學會更好的通用工作方法。這正是 Google 研究團隊(作者包括 Peng Xia、Chen-Yu Lee 等人)在這篇論文想解決的核心痛點,他們提出的方法叫 RRSI(Regularized Recursive Self-Improvement of Agent Harnesses)。
方法
RRSI 的核心思路很直白:在自我演化的「提案」與「篩選」兩端都加上正則化(regularization)限制,逼系統只留下真正可重複使用的機制,而不是死記硬背的benchmark 專屬技巧。
在提案端(proposer),系統採用「時間退火的編輯預算」(temporally annealed budget):越到演化後期,一次候選修改能綁在一起的編輯數量就越少,避免一次性堆疊太多變動導致難以歸因效果。同時 proposer 會參照完整的演化歷史紀錄,避免重複提出已經被證明無效的假設,並主動把探索預算導向還沒被動過的元件,鼓勵系統嘗試「未探索過的路徑」而非反覆微調同一塊。
在篩選端(selector),系統配備了「critic」與「pruner」兩道關卡。critic 扮演審查者角色,專門攔截那些疑似寫死了任務名稱、答案內容或 benchmark 專屬邏輯的候選方案(可理解為一種「洩題偵測」);同時還設有「雜訊校正門檻」,要求分數提升必須明顯高於評測本身的隨機波動,以及「成本規則」,要求新增的 token 開銷必須有相對應的效能回報才算數。pruner 則負責清掉那些改動太小、太貴、或已經不再有用的元件,持續為 harness 瘦身。整套機制實作上用 git worktree 把每個候選 harness 存成獨立分支,並以 JSONL 紀錄每次編輯的元件、假設、分數與判定結果,方便回溯整個演化史。
實驗結果
研究團隊在橫跨三大領域、共八個 benchmark 上驗證 RRSI,涵蓋程式編寫(coding)、代理人工作空間(agentic workspace,如處理法律/職缺類任務)、以及工程設計(engineering design)。實驗設計把其中幾個 benchmark 當作「演化時看得到」的訓練分割,其餘則完全隔離作為 OOD 測試集。
結果顯示,在演化直接對抗的訓練分割上,RRSI 相較未正則化的版本最多可拉出 14.1 分的進步;更關鍵的是,在五個完全沒被用來訓練、真正意義上的 OOD benchmark 上,RRSI 依然能帶來最多 4.7 分的提升,而且是穩定的正向增益,不是曇花一現。作為對照,傳統不加限制的自我演化方法,雖然在訓練集上也能衝出亮眼分數,但一放到 OOD benchmark 就明顯退步,印證了「背答案」式的過擬合問題確實存在。
除了準確率之外,RRSI 演化出來的 harness 在推論效率上也更精簡:執行同樣任務所需的 policy tokens(即模型在解任務過程中實際產生的 token 量)比未正則化版本減少了 30%。這代表 RRSI 找到的不是靠「講更多話、想更久」硬堆出來的效能,而是更精煉、更聰明的工作流程設計——用更少的計算換到更好且更通用的結果。
意義
這篇論文提醒我們一個容易被忽略的風險:讓 AI 自己優化自己的工作方式,聽起來很酷,但如果評分標準本身有限,系統很可能學會的是「怎麼在這場考試拿高分」,而不是「怎麼把事情做得更好」。RRSI 的貢獻不是提出全新的自我改進框架,而是替既有的 harness 自我演化裝上「防作弊」與「防炒短線」的煞車——透過退火預算、探索導向、洩題偵測、雜訊門檻與成本紀律等一整套正則化手段,讓系統偏好那些能跨任務重複使用的通用機制,而非投機取巧的小抄。
對正在打造 agent 產品的團隊來說,這套思路具有直接的實務參考價值:當你用自動化流程去調校 prompt、工具鏈或記憶機制時,務必留一部分完全隔離、模型從未見過的評測集做為「誠實的量尺」,並且把 token 成本、修改幅度這些變數也一併納入篩選條件,而不是只看單一分數是否上升。更長遠來看,隨著 agent harness 本身逐漸變成一個可被自動演化、甚至可能遞迴改進的「軟體系統」,如何在追求效能提升的同時避免過擬合、控制推論成本,將會是這類自我進化系統能否真正落地、而不只是在 benchmark 上好看的關鍵課題。