什麼樣的自我改進成果能夠遷移？

問題#

來自 Knowledge-Centric Self-Improvement 的待解問題（#oq/now）：什麼樣的自我改進成果能遷移，什麼樣的不能？ 這批研究資料中，一個強烈的正面案例是 Caltech 凍結的知識包：在 LLM 家族之間的八種供體與接收者組合中，結果全都為正；一個強烈的負面案例則是 HarnessBank 演化出的 harness：離開匹配的問題情境後幾乎沒有效果，槓桿方向用錯時還會造成 -15.7pp 的退步。兩篇文章都提出，依任務領域調整 vs 依模型調整可以作為區分標準，並稱之為「有兩個強力但單向的資料點支持的假說」。本文將以其他研究資料檢驗這個假說。

答案#

成果能遷移多遠，正好取決於它所編碼的規律適用多廣。 兩篇論文提出的任務與模型二分法，只是它們恰好測量的特殊案例；研究資料支持更一般的說法：

• harness 修補編碼的是解題者規律——某個模型最常見的失敗模式。它只會遷移到具有相同問題的一群解題者，不會再更進一步。HarnessBank 自己的匹配定律展示了兩面：Qwen-27B 的思考失控堆疊能移植到 397B，幾乎沒有損失（+11.0，相較原生的 +11.7），因為兩代模型有相同問題；而 Gemini 3 Flash 是不同家族，但和 397B 有相同的草率定稿問題，因此採用提交前驗證修補後達到 +13.5（z=4.15）。失敗原因不是「跨越模型家族」，而是離開問題類別（Agent-Authored Harness Optimization，empirical）。
• 蒸餾出的洞見編碼的是任務領域規律——ARC 網格不變量、Rust 以迴圈傳播的語意、測試執行器旗標。重用時領域維持不變，解題者則有所變化，因此依其設計，在解題者更替後仍能留存：Caltech 的八種供體與接收者組合全都改善，兩個跨家族方向皆然（最佳配對的 Polyglot 從 8.3% 升至 20.0%，ARC-AGI-1 從 23.3% 升至 43.3%）（Knowledge-Centric Self-Improvement，empirical）。

把兩篇文章暗示的設計原則說得更精確些：弄清楚成果是依什麼調整的，因為那正是它開始失效的邊界。 實際推論是：「依問題調整，而不是依解題者調整」——換用不同模型時，留下來不變的是問題。

區分標準通過的五項研究資料檢驗#

1. 跨版本貶值與跨模型移植失敗是同一種現象#

時間序列證據與橫斷面證據可以統合。驗證指示是為了驗證不足的模型所做、依解題者調整的修補；當解題者端的規律改變——Opus 5 發布時，原生驗證能力已達或超過適當程度——同一行指示便會從有益變成有害，而供應商的修正方式是刪除，而非改寫（Instruction Compounding，vendor-claim，並由系統卡中的 empirical 努力程度反轉結果佐證）。Unproductive Self-Verification 明確指出移植時的後果：「驗證步驟是 [harness] 中最依賴模型的部分，而沿用的『最佳實務』驗證腳手架，正是最可能帶著錯誤方向出現的設定。」這正是 HarnessBank 的匹配定律在時間維度上的呈現：把修補移植到不同模型，以及在同一個模型改善後仍保留修補，兩者都是跨越解題者規律邊界的遷移，也都以同樣方式失敗——槓桿方向與實際存在的問題不符。

這也讓我們與相關綜合文章 What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? 的論點接上。該文依成果編碼的內容分類腳手架：行為要求（對解題者需要被告知什麼的任務先驗）會逐漸內化並失效；邊界、組織紀錄、身分與服務結構則會留存。其留存類別正是依領域調整的成果——repo 慣例依組織而定，測試套件依任務的正確性條件而定；逐漸消失的類別則正是依解題者調整的成果。同一種分類，涵蓋兩個面向：成果依什麼調整，既能預測它是否比目前模型活得久，也能預測它能否移植到另一個模型。

2. 能跨供應商遷移的層，是依領域調整的那一層#

Agent Context Files（CLAUDE.md / AGENTS.md / SKILL.md）編碼 repo 慣例、工作流程與領域程序。這是唯一已成為跨供應商慣例的 harness 層；2026 年 7 月，Genkit 開始提供 SKILL.md 載入功能，成為第二家在執行環境中支援此功能的供應商。Harness Build-vs-Buy 則列出另一種選擇的貶值帳：分叉的 harness——依不斷變動的解題者前沿來建置的基礎架構——一年內會比上游少約 4,600 個合併 PR（約每天 13 個）；由此得到的建議是，應在可行的最高層進行客製化（prompts/config → MCP → skills → SDK）。從本文的觀點來看，這項建議的意思是：自行掌握依領域調整的那一層，租用依解題者調整的那一層——把長期投資放在規律屬於自己的地方（你的 repo、你的工作流程），讓供應商追蹤那種人人都會遇到、且持續改變的規律（模型）。

Cline 的五項修正是很有啟發性的邊界案例：遇到 429 時重試、追蹤 PID、依輸出偵測迴圈，既非依任務，也非依模型，而是依基礎架構的現實調整（供應商速率限制、Unix 程序語意）。這個架構預測，無論解題者或任務如何更替，這些修正都能留存；而這正是 Cline 所主張的「一般性的 harness 錯誤，不是依基準測試量身打造的特例」。依基準測試的失敗分布調整的是它們的分數價值，而這部分尚未有人測過遷移效果（Agent-Authored Harness Optimization，case-study）。

3. 可以在寫入時挑選可遷移性#

這項區分不只是事後分類器——Caltech 的流程是一套機制，能在任何內容留存之前強制依領域調整：concrete_primitive 必須逐字取自任務（具名 API、錯誤類型、旗標、不變量，並附有佐證引文）；anti_meta_self_check 會駁回通用於解題者的教學建議（「關注點分離」、「兩階段管線」）；每項保留下來的洞見都必須附上 applies_when / does_not_apply_when 適用範圍；而遷移介面卡的最終規則——若目前任務與先前知識衝突，優先採用目前任務——是一項優先取代政策，讓領域而非成果本身具有決定權。Wang 等人診斷 harness 演化失敗的原因時指出，編輯會「記住修正方式，而非提煉策略」；這正是 Caltech 蒸餾階段所執行的篩選。兩者的差異不只在成果依何者調整，也在於改進迴圈是否篩選出可遷移的成果：harness 演化沒有關卡排除依解題者調整的記憶，而知識整理大多由這類關卡構成。

LLM-as-Compiler Knowledge Base——也就是這座知識庫——則將同一項賭注用在人類與 LLM 讀者身上：整理關於來源的事實（依領域調整、不依模型而異），絕不為特定模型撰寫提示，因此預期成果能在模型升級後留存。Caltech 是這種架構首次獲得外部實證佐證的案例，也提供了成果為何能遷移的機制說明。

4. 成果無法遷移時，流程可以#

HarnessBank 自己的結論——「獲得肯定的 harness 是依模型調整的修正；可遷移的資產是診斷→搜尋→驗證流程」——在編排層也再次出現。Client-Side Agent Optimization 的每個角色搭配不同模型，本質上就是依解題者調整（依據當前模型選單的能力與價格來搭配）。而研究資料已顯示，分派方式無法留存，規則卻可以：在 Cursor 的長期任務中，HotpotQA 的「弱規劃者／強解題者」最佳組合反轉了（由 Opus 4.8 規劃者帶領的工作者組合花費 $411，前沿模型全包則是 $9,373）。能解釋兩者差異的是可沿用的原則——不要讓規劃者執行——而不是任何可重用的分派方式。對於尚未解答的版本發布週期問題，這個架構預測：每次模型發布後都應重新測試前沿模型（組合方式依解題者而定），並預期從測試中提取的分派規則才是能長期留存的成果。

5. 它做出一項預測，並有來源進行了檢驗（2026-08-13）#

這個架構最鮮明的主張是：harness 與知識之間的區分並非真正的邊界——如果 harness 成果編碼的是任務領域規律，就應該和蒸餾洞見一樣能遷移；HarnessBank 移植失敗，是因為推理預算槓桿依解題者而定，而不是因為 harness 天生就無法遷移。當時的研究資料尚未檢驗這項主張；如果一套 harness 能夠泛化，按照直觀的二分法來看，反而會像是在反駁本文的架構。

DarwinX（Agent-Authored Harness Optimization，empirical，Salesforce，2026-07-31）意外地提供了檢驗。它演化出的 Terminal-Bench 2.1 harness 包含七項技能，全部屬於同一類——verifier-contract、contract-candidate、graded-artifact-final-check、artifact-verification-loop、real-tool-artifact、tool-grounded-artifact、security-contract-repair——論文明確指出，它們都沒有加入領域知識，也沒有任何一項改變努力程度設定。它們編碼的是同一套流程：推導任務的驗收條件，再於定稿前依條件檢查成果。這是由驗證器評分的任務所具備的特性，而非任何模型的失敗分布。原樣用於不同基準測試（SWE-bench Verified）以及不同的基礎模型家族（由 GPT-5.5 演化出的 harness 用於凍結的 Opus 4.8）時，結果仍然成立：官方 pass@1 達 84.2%，比 LSP 修正技能對照高出 3.4，且沒有任何領域內回饋。同一套技能組合也以不同形式出現——WebArena-Infinity 測試各自獨立演化出四項形式相近、以契約為核心的瀏覽器技能，任務分布與獎勵來源都不同。

因此，這項區分在一個直觀二分法會判斷錯誤的案例中，正確預測了效果方向。若沒有受控的雙成果測試，這已是最強的佐證形式。但有三項限制，代表它仍是佐證而非證明：SWE-V 測試組沒有匹配模型的基準對照組（+3.4 是與另一套 harness 相較，所有受比較的 harness 分數都落在 80.8–84.2）；遷移同時更換了基準測試和基礎模型，因此無法分別判斷兩者的影響；DarwinX 自身的跨模型不穩定性也出現在另一組測試——它在 GPT-5.5 上執行的 TerminalWorld 流程拿下 56.1%，低於中性 harness 的 61.0%，這正是架構對於 harness 中依解題者調整部分所做的預測。

同一來源還有一項不同且互不相關的佐證：論文的展望章節指出，架構所暗示、但尚未執行的實驗是：「我們尚未測量基礎模型更換後，有多少 harness 能夠留存；也尚未測量從暖啟動封存庫重新挑選需要幾代，相較從頭開始又如何。」論文稱這項實驗成本低，卻能決定 harness 演化究竟是持續性成本，還是可攤提的成本。這正是尚待測量的貶值率，也就是下方設計原則 3 所提出的實驗版本。

這對 RSI 邊界的影響#

遷移能力原本就是區分腳手架爬坡與 Recursive Self-Improvement 最鮮明的判準；這套架構將它化為明確的檢驗：先問改進成果依什麼調整，再測量成效能否在該範圍之外留存。 調整流程會產生依解題者而定的修正，之後便告終止（HarnessBank 在第 10 輪的下限收斂；人類則會重新發出每份工作簡報）。能夠可攜地累積的是領域知識——而 Knowledge-Centric Self-Improvement 顯示，累積與 RSI 是正交的：十代無人看管的迭代能累積真正可攜的資產，同時模型完全沒有改善。因此，「自我改進」的主張可分為維護（依解題者調整、隨模型消失的成效）與資產（依領域調整、在模型更替後仍留存的成效）；兩者都不屬於大寫 R 的 RSI，因為 RSI 要求成效存在於解題者本身。

尚待解答的問題#

• 受控測試仍不存在。 尚無人以同一套流程比較兩類成果——相同任務、相同預算、相同的保留資料與跨模型切分。架構預測 harness 修補的成效離開問題情境後會消失，而知識包的成效會留存；這項預測可以被推翻，但尚未測試（如今已列為 Knowledge-Centric Self-Improvement 的 #oq/source 項目）。
• 知識面向的預算匹配質疑仍未解答。 Wang 等人批評，自我改進迴圈必須勝過把相同預算花在執行軌跡上；目前這項比較只針對 harness 演化進行，而結果較佳（保留資料高出 +0.6pp；但在所有情況下都不如平行取樣）。Caltech 的遷移結果不受此質疑影響（接收者採零樣本單次嘗試），但其主要解題率並未與重複的純粹嘗試進行預算匹配。（在 harness 面向上也仍未測試：DarwinX 是在相同基準測試上反駁 Wang 等人結果的來源，但它沒有定義努力程度級別、沒有公布運算成本欄，也沒有列出美元成本——詳見測試 5。）
• 四種基準測試構成的階梯，呈現的是規模問題，而非本文架構目前能回答的問題。 DarwinX 自身的四種測試情境顯示，依領域調整的 harness 組合究竟值多少，取決於起始 harness 的適配程度有多差（程式碼代理程式的 harness 被用在瀏覽器時提升 +49.5；起始 harness 已成熟且配對層級相當時提升 +2.9）。架構預測的是成果能否遷移，卻沒有說明遷移後的成效有多大；第二個問題如今已有資料，尚無理論解釋。
• 架構預測依環境調整的成果能長期留存，但從未進行遷移測試。 按照這套架構，Cline 的基礎架構修正應能承受模型和任務更替；但尚無人測量。
• 證據強度。 兩個極端案例都來自單一實驗室的 empirical 預印本；上述四項研究資料檢驗則使用 vendor-claim（提示指南、Genkit、build-vs-buy）與 case-study（Cline、Cursor）來源。這項區分與全部研究資料一致，也由兩篇論文直接測量——這是一項獲得充分佐證的假說，而非定律。

延伸連結#

• RSI Autonomy Levels (B0–L5) — 一項獨立的座標軸，來自 2026 年 9 月的調查研究；它從另一個方向走到本頁提出的相同邊界。本頁問的是成果依什麼調整；那個階梯問的是系統內化了哪種改進決策，兩者彼此交錯：研究資料中最可攜的成果（蒸餾知識包）處於 L1，最不可攜的成果（依模型調整的 harness 修補）則處於 L2。結構遞迴與有效遞迴的區分，正是把維護與資產的相同檢驗提升一個層級——結構遞迴詢問修訂後的機制是否會被繼承；有效遞迴則問它能否在預算匹配的條件下產生更好的後繼者。更新品質與執行效益的分解，也補上了本頁未涵蓋的使用者端因素：成果即使編碼了真實規律，接收它的代理程式若從未取用，或取用了卻不遵循，也不會帶來任何效益

設計原則（精簡版）#

1. 保存成果前，先指出它依什麼調整——任務領域、解題者問題、環境或組織。這就指出了成果會在哪裡失效，包括移植面向與時間面向。
2. 如果希望長期保存、跨越模型更替的成果，就依問題調整，並在寫入時強制執行。 使用要求原樣引用任務中具體依據並界定適用範圍的綱要（Caltech），而非只靠意圖。
3. 把依解題者調整的成果視為會貶值的存量：每次發布都用消融／劑量反應偵測器重新稽核（What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful?）；未確認模型存在相同問題前，絕不將成果移植過去——效果方向可能反轉。
4. 成果無法遷移時，就提取產出它的規則。 流程（診斷→搜尋→驗證、禁止規劃者執行）是依解題者調整之工作的持久成果。