【2026 最新】RRSI 實作教學：讓 Agent 改進 Harness，又不背 benchmark

你讓 Agent 跑完 20 題，成功率從 60% 升到 90%。看起來像「它學會了」，但也可能只是把這 20 題的名字、格式與解法塞進 prompt。這正是 RRSI 實作教學要解決的問題：如何讓 Agent 改進自己的 Harness，又不把 benchmark 背起來。

這篇專為第一次接觸 Agent 系統評測的讀者寫。你不需要先懂機器學習數學；我們會用「反覆修改食譜」的比喻，拆開 propose、critic、evaluate、keep、prune 五個動作，再把它縮成一個可套進現有 Agent 專案的最小流程。最後你會知道該怎麼切 evolve／holdout、記錄 Token 與變更收據，以及何時應該拒絕一個看似更高分的修改。

本文鎖定 2026 年 9 月 22 日的官方程式 commit e4d1a7a。RRSI 目前是 2026 年 9 月 21 日提交的 arXiv v1 預印本；以下把作者報告的結果當成有邊界的研究證據，不把小型 benchmark 增益外推成通用遞迴自我改進。

先說結論：RRSI 改的是 Harness，不是模型權重

• 一句話定位：RRSI ＝可編輯 Harness ＋受限制的提案流程＋有成本意識的驗收門檻＋獨立 holdout。
• 它改什麼：prompt、control flow、工具、skill、記憶、context management 與 subagent 等執行層。
• 它不改什麼：研究設定中的 backbone model 權重、評分器、搜尋目標與 holdout 題目。
• 最重要的習慣：把「訓練題變高分」與「沒看過的題也變好」分成兩張成績單。
• 新手起手式：先讓每個候選只改一個可歸因項目，留下收據，再談自動化搜尋。

RRSI 實作教學的記憶錨點：會改食譜的廚師，也會偷背評審口味

Harness 是模型外面的「執行食譜」；RRSI 是決定食譜怎麼改、哪一版能留下的品管流程。

模型像一位固定能力的廚師，Harness 則是食譜、器具、備料順序、計時器與出餐檢查。普通自我改進迴圈會看失敗菜色、改食譜、再試一次；問題是同一批評審反覆試吃後，食譜很容易迎合這批人的偏好。RRSI 不封死可以修改的零件，而是限制每次能改多少、要求修改附帶假設、先檢查是否偷塞考題資訊，再用分數、噪音與成本決定是否收下。

如果你還不熟悉 Model 與 Harness 的分工，先讀 Agent Harness 是什麼；想看最小 Agent loop，接著讀 30 行 Harness 實作。RRSI 是在那個 loop 外面再加一層「修改與驗收 loop」。

五個零件：RRSI 如何防止「高分但沒泛化」

1. Propose：「每次少改一點，才知道誰有功」

痛點是候選一次塞進十個修改，就算分數上升，也不知道是哪一個改動有效。RRSI 用 cosine schedule 計算 edit budget b_t：前期容許較多協同修改，後期逐漸減少，讓歸因更清楚。白話就是裝修時先處理格局，接近完工後一次只動一個插座，免得整屋跳電卻找不到原因。

但官方 v1 有一個值得新手知道的實作細節：公開程式執行 t=0…T-1，公式又向上取整，因此官方三組設定的實際最後一輪仍可宣告兩個 edits，並沒有走到 b_min=1。所以自己的玩具實驗若要強制單一變更，直接設定 b_min=b_max=1，比照抄論文設定更清楚。

2. History＋Explore：「失敗假設也要記帳」

每個被量測的 edit 都要記錄 component、hypothesis、diff、分數差、Token 差與去留。這張 ledger 讓 proposer 看見哪些想法已被否證；若最近幾輪進步仍落在噪音帶內，系統會把一個候選名額留給尚未嘗試的 component，例如一直改 prompt 沒效果，就去檢查 tool、memory 或 subagent。

官方 README 把它概括成 edit history；公開實作傳給 proposer 的是最近最多 40 筆，未量測的 gate failure 最多保留四筆。這仍比只看上一輪好，但不要把它誤寫成無限、完整、永不遺忘的記憶。

3. Critic：「先查有沒有偷帶答案，再花錢考試」

Critic 先讀 candidate diff，檢查 task ID、entity name、答案、grader 路徑、magic constant、跨 trial 保存特定題目資料，以及沒有停手條件的 loop。官方實作先跑 regex，再交給 LLM review；被拒絕的候選可在有限輪次內修補，仍不合格才丟棄。精確說法是「防明顯洩漏的 diff gate」，不是「證明沒有 overfit」。

4. Selection：「高分要超過噪音，變貴要說得過去」

候選先通過 S′ ≥ S* − δ 的 noise-adjusted floor，避免一次次接受「看起來只是小退步」的版本，最後累積成大退化。若分數增益超過噪音帶，Token 成本增加還要落在 β₀＋β₁ΔS 的預算內；若增益在噪音帶內，系統才改看分數、節省成本與 structural novelty 的加權結果。

這裡的 L0／L1／L2 是設計類比：edit budget 像限制一次啟動幾個變更，pruning 像結構稀疏化，cost rule 像抑制整體資源膨脹。它們不是直接在優化真正的 norm penalty。

5. Pruner：「沒有近期正面證據，就列入拆除名單」

Pruner 會看某個 component 在近期窗口裡最好的 measured gain；若仍不大於 0，就把它與過去接受的 machinery 交給下一輪 proposer，要求考慮刪除。它不會直接回滾程式碼；刪除版本仍要經過 critic、smoke test、evaluate 與 selection。這個差別很重要：RRSI 提議清理，證據決定是否真的拆。

證據怎麼看：無正則版本最會考 evolve，RRSI 的 OOD 較高

作者在 coding、agentic workspace 與 engineering design 三種 domain、八個 benchmark 上做實驗。主實驗固定 backbone，holdout 不參與搜尋；論文報告五個 OOD benchmark 與一個同分布 held-out split 都比初始 Harness 高。這些是作者報告的 point estimates，論文沒有為主要結果提供多個獨立 evolution seeds 或完整 confidence intervals，因此應把它們讀成「值得繼續驗證的 transfer 證據」。

摘要所說的「少 30% policy tokens」比較基準是 unregularized evolution，不是原始 Harness；Table 2 的 RRSI 2.42M 仍高於 H₀ 的 1.56M。這個數字也只算最終 Agent trajectory 的 policy tokens，不包含 proposer、analyst、critic 與反覆跑 candidate benchmark 的完整搜尋成本。因此最安全的解讀是：在作者的 workspace 實驗裡，RRSI 比無正則演化更輕、更能轉移，但不是比什麼都不改更省。

RRSI 實作教學：先跑官方 core，再做最小 Harness 迴圈

步驟一：鎖定官方 commit，先確認方法核心能跑

git clone https://github.com/google-research/rrsi.git
cd rrsi
git checkout e4d1a7a0388e02b388bc40eb0a125fcfc7123f8d
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e ".[dev]"
python -m pytest tests

官方 README要求 Python 3.10+。這組 core tests 涵蓋 schedule、aggregate、calibration、selection、history、component normalization 與 config；它不等於三個大型 benchmark 的端到端重現。

步驟二：把題目切成三個永不混用的盒子

1. evolve：Agent 與 proposer 可以看失敗軌跡，候選也在這裡被選擇。
2. ID holdout：同類型但未參與選擇，用來抓同分布記憶。
3. OOD holdout：換任務來源、格式或工具環境，只在版本凍結後驗收。

最容易犯的錯，是每輪都偷看 holdout，看到退步就回去修。只要它影響了選擇，它就不再是 holdout。可以把題目清單的 hash、切分規則與凍結時間寫進 eval-manifest.json，並讓搜尋程序只收到 evolve IDs。

步驟三：先做可讀的 propose → evaluate → keep 版本

incumbent = load_harness("h0")
best_score = evaluate(incumbent, EVOLVE)

for round in range(T):
    budget = edit_budget(round, T, b_min=1, b_max=1)
    candidates = propose(incumbent, history, max_edits=budget)

    for cand in candidates:
        if critic_rejects(cand.diff, leakage_patterns):
            receipt(cand, verdict="critic_reject")
            continue

        score, tokens = evaluate(cand, EVOLVE)
        if passes_floor_and_cost(score, tokens, incumbent, best_score):
            incumbent = cand
            best_score = max(best_score, score)
            receipt(cand, verdict="accepted")
        else:
            receipt(cand, verdict="rejected")

freeze(incumbent)
evaluate_once(incumbent, ID_HOLDOUT)
evaluate_once(incumbent, OOD_HOLDOUT)

這段省略 production error handling、型別、平行化與 git worktree；它的用途是先把責任邊界畫對。完整程式將 candidate 放在獨立 worktree，接受後才 fast-forward incumbent branch，並把 raw trials、history、diff 與 critic verdict 留在 runs/<domain>/。

步驟四：每次修改都留下「變更收據」

{
  "round": 3,
  "component": "context_mgmt",
  "hypothesis": "先壓縮重複工具輸出，可降低 token 且不傷成功率",
  "evolve_score_before": 0.62,
  "evolve_score_after": 0.65,
  "policy_tokens_before": 18400,
  "policy_tokens_after": 15100,
  "critic": "accept",
  "selection": "accepted",
  "commit": "abc1234"
}

收據要能回答「改了什麼、為什麼、在哪些題目出現可觀察差異、花多少 Token、誰決定收下」。若一個 candidate 綁了多個 edits，官方實作會把同一組 candidate-level ΔS／ΔC 寫給每個 edit；這不是逐項 causal credit。也因此新手版本把 budget 固定為 1，通常更容易除錯。

步驟五：最後才打開 holdout，並排三張成績單

至少比較 H₀、無正則自我改進與 RRSI 三組；每組記錄 evolve success、ID holdout、OOD holdout、policy tokens、wall time、candidate 數、critic reject 數與最後 Harness diff。你要找的不是「哪組 evolve 最高」，而是「哪組在沒看過的題保持改善，而且成本與複雜度可接受」。

若你想把這種驗收習慣延伸到「Agent 自稱做完」的情境，Unlazy 的 Acceptance Ledger 教學會補上 runnable gate 與完成證據；若你的變更碰到長期記憶，Lossless Memory A/B Test可幫你把召回、歷史版本與成本拆開量。

四個常見坑：看起來像 RRSI，其實仍會背考古題

1. Holdout 被偷看：報表、trace 或錯誤訊息回流到 proposer，就已參與搜尋。
2. Critic 與 proposer 共用盲點：regex＋LLM review 能擋明顯洩漏，卻不代表語義捷徑一定會被抓到。
3. 只算最終推理 Token：若忽略搜尋時的 candidate evaluation、critic 與 analyst，會把整體成本說得太漂亮。
4. 把 benchmark points 寫成百分比：+4.7 points 與「提升 4.7%」不是同一件事；跨 benchmark 的量尺也不能直接相加。

還有一個實務判準：如果你的團隊沒有穩定 grader、沒有可隔離的 holdout、也無法保存 trial 與 diff，先不要自動改 Harness。先建立評測與版本收據，通常比加入 proposer 更有價值。這和AI 自己改寫開發流程裡的核心張力相同：自動化越快，獨立驗收越不能晚到。

FAQ：RRSI 實作教學最常被問的 8 題

1. RRSI 會讓模型自己訓練權重嗎？

不會。論文研究的是 frozen backbone 周圍的 Harness evolution；模型權重、評分目標與搜尋規則由外部固定。

2. 它能保證 Agent 不會 overfit 嗎？

不能保證。它會限制 proposal、篩查明顯 leakage、用噪音與成本門檻挑選，再以 holdout 驗收；這些設計降低作者實驗中的 transfer gap，但不能證明所有語義捷徑都被排除。

3. 為什麼不能每輪都看 OOD？

因為一旦回饋影響選擇，OOD 就變成新的 evolve set。真正的獨立驗收必須等候選凍結後才打開。

4. Critic 是品質評分器嗎？

不是。RRSI 的 critic 主要是 candidate diff gate；任務品質仍由 domain evaluator 與 grader 決定。

5. Pruner 會自動刪掉程式碼嗎？

不會直接刪。它把近期缺乏正向 measured evidence 的 component 標成刪除候選，再由 proposer 產生修改並走完整驗收。

6. 可以只改 prompt，不碰工具與 memory 嗎？

可以。但若搜尋停滯，RRSI 的 structured exploration 會鼓勵嘗試尚未量測的 component；是否接受仍由 evidence 決定。

7. 官方 repo 可以零成本跑完整結果嗎？

不行。官方三個 instance 需要 Vertex AI 模型存取，以及各自的 Docker／Harbor、Harvey LAB 或 EngDesign 環境；core tests 與完整 evolution 是兩個不同層級。

8. 什麼時候不該用 RRSI？

當你還沒有可靠 evaluator、隔離資料與版本收據時。那時自動提案只會把錯誤回饋放大；先讓 baseline 可重跑，再加入搜尋。

給新手的 7 個重點

1. RRSI 改 Harness，不改模型權重。
2. 先分 evolve、ID holdout、OOD holdout，再寫 proposer。
3. 第一次實作把 b_min=b_max=1，讓變更可歸因。
4. Critic 是洩漏閘門，不是無偏品質裁判。
5. 分數要超過噪音；Token 增加要換到足夠改善。
6. Pruner 提議移除，正式刪除仍要重新驗收。
7. 真正的成功是 holdout 也改善，而不是 evolve 最會考。