Self-Harness：凍結模型權重，讓 agent 自己改寫執行規則就 +33–60%

瀏覽次數: 2

本文大綱

你的 agent 跑不好，問題未必出在模型

當一個 agent 在實際任務上表現不如預期，多數團隊的直覺反應是：換更強的模型，或者拿任務資料去微調。這兩條路都很貴，而且常常治標不治本。

來自上海人工智慧實驗室（Shanghai AI Laboratory）的一篇論文 Self-Harness: Harnesses That Improve Themselves（arXiv 2606.09498，2026 年 6 月）給了一個不太一樣的答案：模型權重完全凍結、一個參數都不動，只讓模型去「自己改寫包在它外面的執行框架（harness）」，就能在 Terminal-Bench 2.0 上把通過率拉高 33% 到 60%（相對提升）。

換句話說，同一顆模型，換一套 harness，成績差一大截——而且這套更好的 harness 不是工程師手調出來的，是 agent 自己寫的。

背景：harness 是手工藝，而且綁模型

先把名詞對齊。一個 agent 大致可以拆成三層：model（模型核心）+ harness（執行循環）+ scaffolding（行為定義）。論文裡 harness 指的是「指令、可用工具、記憶與狀態管理機制」這一整套——它決定模型怎麼被呼叫、看到什麼、tool call 怎麼處理、什麼時候該停、出錯怎麼救。

問題在於兩點：

第一，harness 目前幾乎全靠人手工調。哪句 prompt 要加、工具上限設多少、錯誤重試幾次，都是工程師憑經驗試出來的，不 scale。

第二，harness 是綁模型的。同一套 harness 套在不同模型上，效果天差地遠——A 模型需要的提醒，B 模型根本用不到；B 模型會卡死的地方，A 模型不會。每換一顆模型就得重調一次。

Self-Harness 要回答的研究問題很乾脆：一個權重固定的語言模型，能不能改善管著它自己的那套 harness？

運作原理：propose → evaluate → accept 的三階段迴圈

核心是一個「提案—評估—接受」的迭代迴圈，跑三個階段：

第一階段：弱點挖掘（Weakness Mining）。 系統先讓模型在當前 harness 下跑 benchmark，然後從它自己的執行軌跡（execution traces）裡，找出這顆模型特有的失敗樣態。重點是「模型特有」——不是泛泛的「答錯了」，而是像「總是卡在某個探索迴圈出不來」這種可被針對的系統性弱點。

第二階段：harness 提案（Harness Proposal）。 針對挖到的弱點，生成「多樣但最小」的 harness 修改方案。論文裡明確列出可被編輯的幾個介面（Figure 3）：

系統提示 build_system_prompt
啟動指令 build_bootstrap_instruction
執行指令 build_execution_instruction
驗證指令 build_verification_instruction
失敗復原指令 build_failure_recovery_instruction
執行控制策略 runtime control policy（含 max_recent_tool_errors、max_total_tool_messages，以及一段 policy 指令）

注意這裡刻意設計成「有界編輯」——改的是 prompt 與策略參數這些宣告好的表面，不是放任模型亂改整個系統。

第三階段：提案驗證（Proposal Validation）。 每個候選 harness 會在 held-in 與 held-out 兩組（看過的題與沒看過的題）重新跑一次，套用嚴格的非退步規則（non-regressive rule）才准進主線：

兩組都不能退步、至少一組要進步 ── Δin ≥ 0 且 Δho ≥ 0 且 max(Δin, Δho) > 0

也就是說，那種「在這組變好、卻在另一組變差」的取捨型修改，會直接被打掉。這條規則是整個機制的安全閥——它擋掉了「為了過某幾題而硬塞、結果整體更脆」的常見退化。

被接受的修改成為新基準，再回到第一階段挖下一個弱點；被拒的提案丟棄、不污染主線。論文用 harness 譜系（lineage） $h_0, h_1, \ldots$ 來描述這個過程：每一步都是對「執行協定」的一次有界編輯，而不是更新模型權重。

一個很具體的例子：基準 harness 下，MiniMax M2.5 會卡在無止盡地探索資料集設定，一路試到執行環境超時為止。Self-Harness 挖到這個弱點後，自動往 runtime policy 裡寫進一條「總 tool 訊息數上限」——逼 agent 在空轉到一定程度後停下來、改變策略，而不是繼續開放式地亂試。這條規則沒有工程師介入，是系統自己診斷、自己寫出來的。

數據與限制：誠實看數字

實驗在 Terminal-Bench 2.0 的 64 題子集上進行，分 held-in / held-out 兩組。三顆模型的結果（held-out，即沒見過的題）：

MiniMax M2.5：40.5% → 61.9%（相對 +53%）；held-in 為 43.0% → 50.0%
Qwen3.5-35B-A3B：23.8% → 38.1%（相對 +60%）；held-in 為 15.1% → 36.0%
GLM-5：42.9% → 57.1%（相對 +33%）；held-in 為 47.7% → 57.0%

幾個必須講清楚的點，免得被數字騙：

第一，標題的「+60%」是相對提升，不是絕對。Qwen3.5 是從 23.8% 漲到 38.1%，絕對值差約 14 個百分點，換算成相對才是 +60%。VentureBeat 的「up to 60%」指的就是這個。看 agent 成效時，相對與絕對要分開看。

第二，這是 64 題的子集，不是完整 benchmark，樣本不大，數字會有波動。

第三，論文自己點名的限制很關鍵：Self-Harness 研究的是「固定 benchmark 下的有界編輯」，不是開放式的自我進化。被接受的修改仍可能反映 benchmark 特有的失敗樣態——也就是有對著測試集 overfit 的風險。而且整個機制高度依賴 verifier 輸出與軌跡記錄的品質：如果你的「對/錯」判定本身就不可靠，那挖弱點、做驗收這兩步都會建在流沙上。

適用場景與 trade-off

適合用的情境：

你在 agent 迴圈裡跑的是固定或開源權重模型，不太能/不想動權重；
任務有可靠的自動 verifier——測試過不過、terminal 任務成不成功這種客觀訊號；
失敗是系統性且模型特有的（某顆模型老是犯同一類錯），而不是隨機散落。

不適合的情境：

沒有可靠 verifier：主觀、開放式、難以自動判分的任務，這套迴圈的評估階段會失靈；
任務分布太窄：題目太少太集中，自動改寫很容易 overfit 成「只會考試」；
換更強的模型更划算時：如果手上有更強且夠便宜的模型能直接解掉問題，未必要繞這一圈。

核心 trade-off 一句話：你是用「benchmark 跑很多輪 + 自動驗收的計算成本」，去換「不必動模型權重、不必手調 harness」。當驗收訊號乾淨、失敗模式穩定時，這筆交易很划算；訊號髒的時候，省下的手工會以 overfit 的形式還回來。

對工程團隊的意義：可操作的部分

就算你不打算把整套自動迴圈搬進產線，這篇論文的幾個工程習慣是可以直接抄的：

把 harness 當成有版本的工件來管，而不是散落在程式碼裡的 magic string。能版本化，才談得上 A/B 與回退。
改 prompt / 改策略一律掛回歸閘門。Self-Harness 最值錢的設計其實是那條非退步規則——「修好這題但弄壞那題」的提案一律拒收。很多團隊改 prompt 全靠手感，這正是退化的溫床。最低限度，留一組 held-out 任務，每次改完都重跑。
從軌跡裡挖「模型特有」的失敗模式，而不是一個 prompt 套所有模型。不同模型該配不同 harness——這是論文反覆強調、也最容易被忽略的一點。換模型時，別忘了 harness 也得跟著換。
先投資 verifier 與 trace 記錄。這套方法的天花板由你的自動判分品質決定；判分不準，後面再聰明的自我改寫都是空談。

把它放回脈絡：Self-Harness 沒有宣稱 agent 會無中生有地變強，它示範的是一件更務實的事——在模型不變的前提下，光是有紀律地、自動地迭代「執行框架」，就有相當可觀的空間。對天天在調 agent 的團隊來說，這個空間值得認真盤點一遍。