新聞｜Harness²：模型權重不動，agent 在沒有標準答案的任務上自己改 harness

重點

• Google Cloud AI Research 與西北大學在 arXiv 發表 Harness²（2610.14224，10 月 9 日上傳），程式碼以 Apache 2.0 授權放在 google-research/harness2。模型權重固定，改的是模型周圍的 harness：系統提示、guardrails、記憶、工具說明、skills、scripts、子代理與 plugin，共八個元件。
• 任務層的核心步驟叫 Propose–Probe–Compose：先跑一次目前的 harness，提出兩個修改版本（一個針對工作方式，一個針對領域知識），在同一個任務上各跑一次，比對行為差異後組出新的 harness。整個過程看不到標準答案、評分量表或分數。
• 跨任務層把每個任務最後採用的 harness，連同有執行證據支持的心得，存進一個改進庫。下一個任務仍從同一個基礎 harness 出發，但提案時可以參考庫裡的元件與經驗。
• 單一步驟在三個基準、四種執行器組合上都進步：WorkBuddy-Bench 最多 +11.5 分（GLM-5 搭 OpenCode，64.2 → 75.7），JobBench 最多 +4.5 分，Harvey 法律基準 LAB 的 partial pass rate 最多 +11.8 個百分點。平行遞迴開到 k=5，再多 2.6 到 6.7 分。
• 代價是每個任務要多跑好幾次執行與編輯 session。預設編輯器與選擇器都是 Claude Opus 4.8，JobBench 的評審也是同一個模型；失敗分析裡，選擇器曾把 55 分的輸出選在 95 分前面。

Harness 是什麼，為什麼要自動改

論文採用「Agent = 模型 + harness」的說法。harness 指模型以外、讓它能當 agent 用的一切：提示、記憶、工具、技能與調度方式。同一個模型換一個 harness，表現可能差很多；agent 從寫程式擴展到辦公文件、法律工作之後，靠人手調 harness 越來越吃力。

已經有不少方法自動改 harness，論文把它們分成兩類：

• 離線搜尋：例如 Meta-Harness，在一組訓練任務上反覆評分、挑出最好的 harness 再部署。前提是有訓練任務和評分回饋，部署後遇到新類型任務就不再調整。
• 測試時調整：例如 Harness Scaling，每個任務各自多花推論預算修改 harness，但任務之間不保留任何東西。

Harness² 要處理的情境是「開放世界」：任務一個接一個進來，事先沒見過，也沒有標準答案可以驗證。論文提出兩個問題：沒有驗證器時要怎麼判斷一個修改有沒有用，以及為某個任務做的修改怎麼幫到下一個任務。

八個可編輯元件

每個元件都是一個檔案，修改就是一份 diff。

編輯器的提示詞特別交代：常駐的文字每次都要付 token，新規則優先寫成 skill、script 或 plugin；每個 skill 的名字必須出現在系統提示或 guardrails 裡，否則整份提案驗證不過、直接丟掉。

任務層：Propose–Probe–Compose

一個改進步驟分三段：

1. Propose。先用目前的 harness 跑一次，得到參考執行。這次執行用來觀察 harness 的行為，不判斷交付物對不對。接著提出兩個候選 harness：
   • 不變式候選：處理跨領域都可能出現的工作方式問題，例如規劃、工具使用、context 管理、委派。
   • 領域候選：補上這個領域需要的知識、流程與限制。
2. Probe。兩個候選在同一個任務、同樣的模型與環境設定下各跑一次。拿它們的軌跡和交付物跟參考執行比，看修改有沒有解決鎖定的問題、沒有效果，還是造成退步。
3. Compose。讀參考執行、兩個候選、它們相對目前 harness 的 diff，以及所有執行證據，組出下一版 harness。可以合併有支持的修改、修正互相衝突的修改、整個採用其中一個，或保留原樣。每個決定都要對應到軌跡裡的具體觀察。

編輯器的提示詞要求每項修改都追溯到軌跡中的某個時刻，並給了優先順序：先處理幾次執行之間表現不一致的地方（代表模型其實做得到，只需要提醒），再處理每次都重複的失敗，最後才是看得到但還沒發生的風險。

平行與序列遞迴

預算參數 $k$ 控制探索幅度：

• 平行遞迴：跑 $k$ 次參考執行，各提出 $k$ 個不變式候選與 $k$ 個領域候選，再開 $k$ 個獨立的組合 session，每個都讀完整個候選池。概念上借用 RSA（recursive self-aggregation）的聚合方式，只是聚合的對象換成可執行的 harness 和它們的行為結果。
• 序列遞迴：連續做 $k$ 個改進步驟，每一步都帶著前一步的 harness 和累積的執行紀錄。

$k>1$ 時，最後由一個選擇器比較匿名化的交付物，依任務要求與原始資料挑一份。選擇器不知道交付物出自哪個 harness，也不另外產生新內容。$k=1$ 時兩種形式都退化成單一步驟，不經選擇。

跨任務層：改進庫

每個任務結束後，系統回顧完整的改進紀錄，整理出「哪些修改在什麼條件下解決了哪個問題」。只有執行對照支持的心得才會留下；某份輸出被選中，本身不算可以轉移的證據。

庫裡每一筆包含整份採用的 harness 和一份 EXPERIENCE.md，記錄適用情境、心得與證據，另有索引供後續 session 查閱。下一個任務一樣從基礎 harness 出發，舊元件要經過 Propose 階段挑選或改寫才會用上，不會自動繼承。模型權重、各階段的指令和決策規則都不變，變的只有這個庫。

實驗設定

比較對象有四個：基礎 harness、只做記憶檢索的 ReasoningBank、離線搜尋的 Meta-Harness（用各基準的訓練半邊搜尋），以及每題各自修改的 Harness Scaling。

結果

WorkBuddy-Bench 三個領域的平均分數：

JobBench 與 LAB：

幾個值得注意的地方：

• Harness² 在四種組合的 WorkBuddy-Bench 平均與 JobBench 分數都高於所有比較對象。LAB 上有一個例外：Gemini 搭 Codex 時，Meta-Harness 的 76.5 領先。
• 較弱的執行器在 WorkBuddy-Bench 與 LAB 上得到的提升比較多。GLM-5 改一步之後（75.7、75.3）超過 Gemini 用原本 harness 的分數（72.4、74.5）。
• 兩個比較對象不穩定：ReasoningBank 在寫程式任務上最多比基礎 harness 低 6.6 分；Harness Scaling 在 12 組基準與設定中有 7 組低於基礎 harness。
• 預算從 $k=1$ 增加到 5，WB-Code 從 76.5 升到 80.8，WB-Office 從 79.5 升到 83.4，兩種遞迴都隨預算單調上升。論文把所有 token 都算進去之後，Harness² 的兩個設定都落在成本與表現的 Pareto 前緣上；Meta-Harness 在 $k=5$ 時用的計算量比 Harness² 多，分數卻較低。

拆解：哪些部分有用

以 Gemini 3.5 Flash 搭 OpenCode、$k=1$ 做拆解：

其他分析：

• 元件貢獻：從改好的 harness 拿掉 skills，WorkBuddy 三領域平均少 5.3 分；拿掉 scripts 少 3.7 分；拿掉提示類元件少 1.5 分。skills 與 scripts 大約占每個基準一半的修改。
• 工具錯誤：改一步後，三個基準的工具錯誤率都下降，JobBench 從 14.4% 降到 9.1%。工具呼叫次數在 WorkBuddy 減少，在 JobBench 與 LAB 反而增加。
• 同一個模型兼任編輯器：五個模型（從 GLM-5 到 Claude Opus 5）都在三個基準上進步。Opus 5 在 WorkBuddy、JobBench、LAB 分別 +3.3、+5.5、+3.0；GLM-5 在 LAB +13.7。提升不一定需要更強的編輯器。
• 跨模型轉移：為 Gemini 3.5 Flash 改好的 harness 直接給 GLM-5 用，WB-Code 從 58.5 升到 75.8。
• 跨基準轉移：從 JobBench 累積的改進庫拿到 WorkBuddy-Bench，單步修改在三個領域分別多 0.6、0.5、2.9 分。

論文的 JobBench 案例：基礎執行只拿 43.1 分，軌跡顯示問題出在流程，沒有跨檔案核對數字，寫完檔案也沒有重新打開檢查。不變式候選加了一條 guardrail，要求先盤點所有輸入、追溯每個數字的來源，並用 script 重新打開產出的檔案檢查；領域候選加了一個核對排程、場地、人力與預算檔案的 skill。組合時四項修改全部保留，重跑後分數升到 77.8。

跟既有做法比新在哪

論文整理了二十多個 harness 改進方法，Harness² 的差別在於同時具備三件事：

• 不用正確性標籤：只用候選之間的行為對照，標準答案與評分只拿來做最後評估。
• 任務串流：任務逐一處理，不重跑已完成的任務。
• 改進者本身也會更新：被改的除了執行任務的 harness，還有負責修改的那一層。它對應的是「遞迴自我改進」的概念：改進的結果也會影響之後怎麼產生、評估和保留改進。

論文也做了一個對照：沒有參考執行、候選試跑和改進庫，只讓編輯器直接改基礎 harness，WB-Code 從 73.4 掉到 63.2，WB-Web 從 69.9 掉到 65.0。用 $k=1$ 累積的庫可以讓分數回到基礎水準；用 $k=5$ 累積的庫則在三個領域多 0.9、4.4、5.1 分。

限制

• 成本。每個任務要跑參考執行、候選試跑與組合後的執行，還有多個編輯 session。平行 session 可以降低等待時間，但不會減少計算量。論文只測了有限的預算範圍。
• 沒有標準答案的回饋本身有雜訊。行為對照會受到執行隨機性與模型共同偏誤影響，不保證修改正確，也不保證能轉移到其他任務。
• 評審與編輯器同源。編輯器、選擇器與 JobBench 的評審都是 Claude Opus 4.8，LAB 由 Claude Sonnet 4.6 評審。論文設計了防護，任何交給編輯器的工作目錄只要含有評分、量表或分數就會被拒絕，但同一個模型家族的偏好仍可能同時影響修改與評分。
• 測試集不大。WorkBuddy-Bench 測試集合計 100 題，JobBench 34 題，LAB 100 題，每個設定三次，部分差距落在標準差範圍內。
• 選擇與錯誤前提會造成退步。論文列出九個退步案例：WB-Code 有一題選擇器把 55 分的輸出選在 95 分前面；LAB 有一題因為涵蓋範圍變窄，從 54 分掉到 26 分；另有錯誤假設在所有候選間擴散，造成 2 到 11 分的損失。
• 專案定位。README 註明這不是 Google 官方支援的產品，目前支援 OpenCode 與 Codex 兩種執行器，以及 JobBench、LAB、WorkBuddy-Bench 三個基準。

參考資料

• arXiv：Harness²: Recursive Agent Harnessing for an Open World（2610.14224）
• GitHub：google-research/harness2