Harness 與架構演進：從 Harness² 看它和普通 harness 的區別

2026 年 10 月，Google Research 開源了 Harness²，對應的論文叫《Recursive Agent Harnessing for an Open World》¹。README 給的數字是這樣的：模型權重完全不動，只做一步改進，GLM-5 和 Gemini 3.5 Flash 在三個專業工作基準上都比原來的 harness 分數高，最多的一項是 WorkBuddy-Bench 上的 11.5 分²。

權重不動，那動的是什麼？翻開倉庫，JobBench 用的起點 harness 是一個目錄，裡面最主要的三個檔案長這樣³：

systemprompt.md      <!-- c1 system prompt. EMPTY in v0 — v0 is the BARE stock OpenCode run … -->
guardrails.md        <!-- c6 guardrails. EMPTY in v0. Evolution adds always-on rules here. -->
LongTermMEMORY.md    <!-- c3 memory. EMPTY in v0. Evolution adds durable, GENERAL domain facts here … -->

三個檔案都只有一行註解，skills/、scripts/、sub_agents/ 也只放了說明檔。也就是說，起點幾乎是一個空的 harness，往裡面填東西的不是人，是另一個 agent。這就帶出幾個問題：

1. harness 具體由哪些東西組成？平常是誰在改它？
2. 這裡的任務事先沒見過，也沒有標準答案。一次修改是變好還是變壞，憑什麼判斷？
3. 命令列上的 --k 是改進的預算，預算多了該怎麼花？
4. 為一個任務改好的 harness，下一個任務還用得上嗎？名字裡的「平方」指的是什麼？
5. 回過頭看，它和我們平常說的 harness 到底差在哪，多花了什麼？

本文就順著這五個問題，一層一層往下讀。讀的是 2026-11-02 的提交 6868817。先說明一點：三個基準都要真實的模型額度，我們沒有重跑，文中的分數全部引自論文、專案頁和 README；機制部分則都對過原始碼，圖裡出現的檔名、函式名和環境變數都是倉庫裡的原樣。

一、普通 harness 的構成

harness 是一棵檔案樹

README 開頭給了兩個定義：harness 是包在模型外面、讓它能當 agent 用的那套系統，包括提示、工具、記憶、技能、編排；harnessing 是優化這套系統的過程²。用過 Claude Code、Codex 或 OpenCode 的人對它不陌生：AGENTS.md、skills/、hooks，就是 harness 落在磁碟上的樣子。

Harness² 把可以改的部分固定成八個元件。以 OpenCode 為例，它們掛在一次執行的不同位置上⁴：

圖裡要看的是左右兩邊的成本不一樣。左邊四份常駐文字每一次執行都在上下文裡，每個字都和 agent 自己的輸出搶預算；右邊的腳本、子 agent 只在被呼叫時才花成本，外掛則卡在工具呼叫的必經之路上，模型想跳也跳不過去。這個差別後面會決定一條修改該放在哪裡。Codex 上的佈局略有不同：常駐檔案只有 AGENTS.md 一個，外掛的位置換成 .codex/hooks.json。

最下面那一條是 OpenCode 和 Codex 本身。倉庫把它們叫做 substrate，也就是「底座」，視為凍結的基礎設施；改進只發生在上面這八個元件的路徑上，寫到別處的檔案會被直接丟掉⁵。

平常誰在改它

知道了 harness 是什麼，再看它平常怎麼變。

最常見的做法是人手改。 我們看到 agent 某件事做得不好，就去 AGENTS.md 補一條規則，或者寫一個 skill。這樣的 harness 是寫給「所有任務」的：部署之前定稿，之後每個任務都用同一份。它的問題也在這裡，寫的人不可能預見所有任務，補的規則只會越堆越長。

第二種做法是把修改自動化，但放在部署之前。 論文把這一類叫離線方法，舉的例子有 Meta-Harness、AHE 等：準備一批固定的訓練任務，讓優化器反覆改 harness、跑任務、看分數，搜出一份最好的再上線¹。這已經不需要人了，可它需要兩樣東西：事先拿得到的任務，和能打分的評分器。

Harness² 針對的恰好是這兩樣都沒有的情況。任務到來時才第一次見到，沒有評分器，也沒有標準答案，還能不能改 harness？

二、沒有標準答案時的修改依據

現象：開放世界

論文把這種設定叫開放世界（open world）：任務像一條流一樣陸續到來，設計 harness 的時候沒見過，執行的時候也沒有人告訴你做得對不對¹。三個基準都是這一類工作：JobBench 是各種職業的辦公任務，LAB 是法律工作，WorkBuddy-Bench 是辦公、網頁和程式碼²。交付的是一份文件或一張表，沒有單元測試可以跑。

第一次嘗試及其不足

最直覺的辦法是讓 agent 做完之後回頭看自己的軌跡，反思哪裡沒做好，再把教訓寫進 harness。這條路的問題是只有一次執行：agent 這次漏了一步，是 harness 沒交代清楚，還是這一次抽樣剛好走偏了？一條軌跡分不出來。更麻煩的是寫進去的修改有沒有用也無從知道，因為沒有再跑一次來對照。

解決：Propose–Probe–Compose

Harness² 的辦法是把「同一個任務多跑幾次」當成證據來源。先介紹兩個角色：執行器（倉庫裡叫 solver）是真正做任務的 agent，它每完整跑一次任務稱為一次 rollout；改進器（improver）是另一個 agent 會話，它不做任務，只負責讀證據、改 harness。兩者連用哪個模型都是分開設定的。它們在倉庫裡的關係是這樣⁶⁷：

兩個 agent 之間沒有任何直接的通訊。執行器跑完留下一個執行目錄，方法層的 context.py 把它整理成一個 context/ 目錄；改進器在一個臨時工作目錄裡讀它，直接修改其中的 context/harness/，會話結束後這棵檔案樹被取回來，校驗通過才裝進下一次 rollout。方法層本身不呼叫模型，它只負責排程、擺放證據和檢查結果。

有了這張圖，一步改進的過程就好講了。它分三段，倉庫把這三段叫 Propose–Probe–Compose：

1. Propose（提案）：執行器先用原始 harness 跑任務，得到參照執行 base1。兩個改進器各自讀這份軌跡和產出，各提出一份修改後的 harness，標籤是 inv1 和 dom1。
2. Probe（試探）：兩份候選 harness 各自在同一個任務上再跑一次。
3. Compose（合成）：第三個改進器拿到全部材料，合成出最終的 harness agg1，再跑一次，這次的產出就是交付物。

合成者手上到底有什麼？倉庫附了一個不需要模型的本地演示：任務是把 ledger.csv 裡帶正負號的金額加總，起點 harness 的 scripts/summarize.py 多寫了一個 if amount > 0，把負數漏掉了⁸。ledger-1 的三筆金額是 100.25、−20.10、5.00，照原始碼算，漏掉負數得到 105.25，正確的總和是 85.15。把合成者的工作目錄畫出來是這樣：

演示裡的兩個「編輯者」是同一段寫死的腳本，所以 inv1 和 dom1 改的是同一處；接上真模型時，兩者的分工是不同的，下面會講。

圖裡要看的是兩個數字。合成者不知道 85.15 才是對的，沒有人告訴它；它能看到的是行為上的對照：去掉那個過濾條件之後，總和把負數算進來了，而任務說的是「每一筆帶正負號的金額」。論文對這一點說得很克制：對照顯示的是行為怎麼變了，不是答案對不對¹。

兩個編輯者的分工

Propose 階段為什麼是兩個編輯者，而不是一個？提示裡把修改的方向切成了兩個互不重疊的維度⁴：

• INV（invariant）管 agent 怎麼做事：流程、工具的用法、怎樣才算做完，與題材無關。提示要求它找出軌跡裡最早偏掉的那一步，並且「不要加專業規則」。
• DOM（domain）管這一行的人知道什麼：交付物該有哪些部分、哪些數字要對得上、內行人不會漏掉什麼。提示要求它「不要診斷命令、重試、腳本或 hook」。

兩份候選各改一個維度，各跑一次，合成者才能分清一個變化是哪一類修改帶來的。如果只有一個編輯者把兩類修改混在一起，跑出來變好了，也說不清是誰的功勞。

證據怎麼算數

對照不等於真相，所以提示花了很多篇幅約束合成者怎麼讀證據⁴：

• 參照執行要當成一組樣本來讀。只在 k 次裡出現一次的缺陷算噪音，針對它的修改是對單一樣本過擬合。
• 每個候選只跑了一次，一次好結果只是弱證據。一條修改要留下來，必須指得出軌跡裡的具體時刻；「這看起來是好習慣」不算。
• 幾個候選意見一致只是支持，不是獨立的證明，因為它們出自同一個模型、同一批證據。
• 什麼都不改是合法的結論，叫 KEEP_BASE。提示的原話是：證據不支持的改動只花上下文，買不到東西。

合成者最後要交一份筆記，每個決定一行，格式是 kept|revised|dropped -> 哪條修改 -> 哪個軌跡時刻。

把答案擋在外面

既然整個方法的前提是「沒有標準答案」，評分材料就不能出現在改進器讀得到的任何地方。程式碼裡有三處在守這條線：

提示層：每一段任務提示都帶著一節 WHAT YOU DO NOT HAVE，寫明上下文裡沒有 rubric、評分條件、參考答案或分數，也不准去猜「評分器想要什麼」⁴。

資料結構層：描述一次 rollout 的 RunView 沒有分數欄位；基準適配器提供的提示文字如果出現 benchmark、rubric、score 這些字眼，建構時就直接報錯；真正的打分函式 score() 只在最終選定之後才由獨立的 harness2-judge 呼叫⁹。

檔案層：context/ 目錄交給模型之前，會按一組標記字串（例如 "pass_rate"）掃描檔名和內容，命中就拒絕。註解特地寫明這是絆線而不是防線：觸發了要去找是哪條讀取路徑漏了，不要去加長標記清單¹⁰。

圖的下半部是這三層管不到的地方。實驗指南坦白記了一件事：驗證這個版本時，有一次 Codex 執行器沒有人指示，自己上網把任務的評分標準下載了下來，因為 JobBench 的 RUBRICS.json 就公開掛在 Hugging Face 上¹¹。Codex 執行時沙箱是關掉的，所以文件要求評測前在網路層封掉 huggingface.co、github.com 這些網域，並且在報告結果時一併說明用了哪些限制。

改在哪個元件上

還剩一個問題：編輯者想加一條指示，放進八個元件的哪一個？回到圖 1 左右兩邊的成本差別。提示直接給了優先順序：有明確觸發情境的做成 skill，確定性的操作做成腳本，輸入大而答案小的調查交給子 agent，模型屢次跳過的檢查放進外掛，常駐文字排最後，而且加一段就得刪一段⁴。理由是這類工作最貴的失敗，是 agent 把輸出預算全花在推理上、最後什麼都沒交。常駐文字越長，這種失敗越容易發生。

論文附錄裡有一組數字可以對照這個排序。在 WorkBuddy-Bench 上，把改好的 harness 裡某一類元件拿掉再評分：拿掉 skill 掉 5.3 分，拿掉腳本掉 3.7 分，拿掉常駐文字那幾項只掉 1.5 分；改動的檔案裡，skill 和腳本大約佔一半¹。論文也提醒，這幾個數字不能直接相加，但方向是清楚的：起作用的主要是按需載入的那幾類。

提案在執行之前還要過一道校驗⁵：每個 skill 的名字必須在常駐文字裡出現（否則 agent 不知道要載入它），提到的腳本必須真的存在且能編譯，常駐文字不能超過上限（OpenCode 是 24,000 字元，Codex 是 8,000）。不合格的提案會連同錯誤訊息退回去重試一次，再不行就沿用目前的 harness⁶。

到這裡，一步改進就講完了。一步要跑四次任務：一次參照、兩次試探、一次最終。如果願意多花一些預算，該把它花在哪裡？

三、遞歸預算的兩種用法

命令列上的 --k 就是這個預算，--mode 決定怎麼花²。兩種模式的開頭一樣：先用原始 harness 跑 k 次參照執行。之後分成兩條路⁶：

並行把預算一次鋪開：k 個 INV 候選和 k 個 DOM 候選彼此看不到對方，各自從同一批參照執行出發；然後 k 個合成者各自讀全部 2k 個候選的證據，各合成一份。提示還特地要求合成者不要去湊共識，交出自己站得住腳的那一份。

串行把預算疊起來：每一輪只提兩個候選，合成出一個檢查點，下一輪在這個檢查點上繼續改。這個檢查點自己跑的那一次，就是下一輪最直接的證據，它顯示的是「目前正在改的這份 harness 實際做了什麼」。合成者可以把更早被否決的候選撿回來，也可以原樣重現更早的檢查點。

兩種模式的帳是一樣的。ledger.py 規定每個任務恰好 4k 次 rollout（k 次參照、2k 個候選、k 個最終）和 3k 次改進會話，執行結束時對不上就報錯¹²。這樣比較兩種模式時，花的錢是相等的。

k 大於 1 時會有 k 份最終產出，交哪一份？這一步叫盲選¹³。選擇者只看到任務原文、原始材料和各份產出，候選的代號是打亂的 A、B、C，它不知道哪份產出來自哪份 harness，也看不到執行過程。評判的順序是：要求的東西有沒有交齊、形狀有沒有照任務說的來、內容對不對得上原始材料、自己和自己是否一致。k 等於 1 時只有一份，不開選擇會話，直接交付。

論文的結果是，k 從 1 加到 5，兩種模式的分數都往上走：WorkBuddy-Bench 的程式碼子集上，並行從 76.5 升到 80.8，辦公子集從 79.5 升到 83.4。串行在 k=2 時的程式碼子集上略高，到 k=5 時並行反超¹。

到這裡，一個任務的事情做完了。可是下一個任務到來時，起點又是那份空的 base harness。前一個任務花四次以上執行換來的東西，就這樣丟掉嗎？

四、第二層遞歸：改進 harness

現象：改好的 harness 不能直接沿用

最直覺的做法是讓下一個任務直接從上一個任務改好的 harness 出發。Harness² 沒有這樣做：run_task 每次都重新讀 base 的檔案樹，每個任務仍然從 base 開始¹⁴。論文沒有專門解釋為什麼不沿用，下面的原因是我們從提示的寫法推出來的：為一個任務改的 harness 裡寫著那個工作區的具體事實（哪兩個欄位對得上、哪個數值才是對的），提示甚至鼓勵編輯者把驗證過的事實直接寫進去。這些事實換一個任務就是錯的錨點，一路累積下去，harness 會越來越偏向前面的任務。

解決：把成品和教訓存進經驗庫

它留下來的是另一種東西。交付之後多開一個反思會話（Reflect），讀這個任務的完整改進記錄，寫兩樣東西¹³：

1. 每條修改做了什麼。把每個候選 harness 和 base 逐一比對，每個被改過的元件寫一行，給一個判定：helped、hurt、no observed effect 或 confounded。提示明說要優先用 confounded（分不清）：一個候選同時改了好幾處，或者背後只有一次執行，就該這樣標。
2. 最多一條可以帶走的教訓。cue 寫這條教訓適用的情境形狀，lesson 寫要對 harness 做的操作，evidence 指回上面的哪幾行。記錄裡找不到具體的執行對照，就只寫一行 NO_ENTRY。

這裡有一個細節：盲選比的是產出，所以「被選中」只說明哪份產出讀起來最好，不說明哪條修改起了作用。提示因此要求反思時把所有候選都當證據，被否決的候選裡也可能有真正有用的修改。

反思通過了，被採用的整棵 harness 樹和一份 EXPERIENCE.md 才會存進經驗庫；三個欄位缺一個就不入庫¹⁵。用演示裡的任務畫出來是這樣：

下一個任務的編輯者會在 context/library/ 裡讀到這個庫：先看 INDEX.md，再打開看起來相關的幾條。庫裡的檔案只是範例，不在執行時的磁碟上，要用就得複製進自己的 harness；而且提示要求把舊任務斷言的工作區事實重新對過，因為那些在上一個任務是事實，在這裡只是假設⁴。

經驗庫按領域分開：同一個領域裡的任務按順序跑，只讀得到排在自己前面的任務；不同領域之間可以同時跑¹¹。

庫裡的東西實際被用了多少？論文統計過改動的檔案裡有多少帶著經驗庫的來源：LAB 和 WorkBuddy-Bench 的辦公子集是 22%，JobBench 是 47%；而一半以上的行直接來自庫的檔案只有 10% 到 22%¹。也就是說，編輯者多半是參考之後改寫，很少整份照搬。

名字裡的「平方」

現在可以回答「平方」是什麼意思了。

改進器本身也是一個 agent：一次 OpenCode 或 Claude CLI 會話，有自己的任務說明（MISSION.md），有自己的工作目錄（context/），有自己的參考資料（經驗庫）¹⁰。這些東西合起來，就是改進器的 harness。論文把它叫改進 harness（improvement harness），和做任務用的執行 harness 區分開²。

於是有了兩層，各改一份 harness：

• 任務級遞歸改的是執行 harness，一個任務之內完成，就是第二、三節講的 Propose–Probe–Compose。
• harnessing 級遞歸改的是改進 harness，跨任務進行，就是這一節的經驗庫。每做完一個任務，「怎麼改 harness」這件事本身多了一條有證據的經驗。

圖裡標著「不動」的幾格也要看清楚：模型權重不動，改進器的那幾段提示（也就是判斷規則）不動，會變的只有經驗庫的內容¹。所以這個「平方」說的是對 harnessing 這個過程再做一次 harnessing，並不是一個無限往上套的結構。

三樣設計各值多少，論文做了消融（Gemini 3.5 Flash、OpenCode、k=1）¹：拿掉經驗庫，WorkBuddy-Bench 和 JobBench 分別掉 3.1 和 1.8 分；拿掉 INV 與 DOM 的分工，掉 2.9 和 3.7 分；拿掉合成這一步，掉 1.6 和 1.9 分。在 WorkBuddy-Bench 上掉得最多的是經驗庫，在 JobBench 上則是分工。

五、與普通 harness 的區別

回到那三個空檔案

現在回到開頭。起點 harness 是空的，分數卻往上走，因為在 Harness² 裡，harness 已經不是一份事先寫好的檔案：它是每個任務執行時當場生成的。空的 base 只是每個任務出發的地方；真正在跑任務的那份 harness，是讀過這個任務的幾次參照執行之後才寫出來的，其中甚至寫著這個工作區驗證過的事實。

把這個差別和第一節講的兩種做法放在同一條時間線上：

逐項對照是這樣：

效果與代價

效果上，論文的主結果表給了同一個模型（Gemini 3.5 Flash）、同一個底座（OpenCode）下各種方法在三個基準上的分數¹¹⁶：

表裡有兩點值得注意。其一，另外幾種方法並不總是比什麼都不做好：論文統計，Harness Scaling 在十二組「基準 × 配置」裡有七組低於 base。其二，Harness² 也不是每一格都領先：換成 Codex 底座時，LAB 上是 Meta-Harness 的 76.5 高於它的 75.6¹。

還有一個趨勢：比較弱的執行模型得益更大。README 裡那個最大的 11.5 分就出在 GLM-5 上，WorkBuddy-Bench 從 64.2 升到 75.7，只用了一步改進²¹。這也說得通，模型越弱，越需要有人把工作區的事實和步驟替它寫好。

代價同樣明顯，有四點要看清楚。

執行量至少是四倍。 k=1 時每個任務要完整跑 4 次，外加 3 次改進會話和 1 次反思；k=5 時是 20 次執行和 15 次改進會話。這是拿算力換分數，交付也要等這些都跑完。論文把它列為第一條局限，並且說明並行只能縮短等待時間，總計算量不會變少¹。

對照不等於正確。 這是論文列的第二條局限：執行有隨機性，幾個候選又出自同一個模型、帶著同樣的偏見，對照只能說明行為變了¹。演示裡 105.25 變成 85.15 之所以一眼能判斷，是因為任務說明夠清楚；任務本身含糊時，合成者和我們一樣沒有把握。

改進器得夠強。 讀幾份完整軌跡、比對候選、寫出能過校驗的 skill 和腳本，這本身就是一件不輕的 agent 工作。改進器用哪個模型由 HARNESS2_IMPROVER_MODEL 單獨設定。

它假設任務可以重跑。 Probe 的前提是同一個任務能在相同條件下跑好幾次。產生檔案的辦公任務可以；發郵件、下單這類有外部副作用的任務，跑四次就是做了四次。這一點是我們根據機制推出來的，論文正文沒有展開討論。

小結

1. harness 是什麼，誰在改？ 包在模型外面的一棵檔案樹：常駐文字、skill、子 agent、腳本、外掛。平常由人在部署前改，或由離線優化器拿訓練任務的分數去搜。
2. 沒有標準答案，憑什麼判斷修改的好壞？ 在同一個任務上多跑幾次：一次參照，INV 和 DOM 兩個候選各試一次，合成者看改前改後的行為對照，每個決定都要指得出軌跡裡的具體時刻。評分材料在提示、資料結構、檔案三層都被擋在外面。
3. 預算 k 怎麼花？ 並行一次鋪開 2k 個候選、合成 k 份；串行一輪接一輪在檢查點上改。兩者都是 4k 次執行和 3k 次改進會話，最後從 k 份產出裡盲選一份。
4. 改完的東西怎麼留下來？ 每個任務仍從 base 出發；留下的是經驗庫裡的整棵 harness 和一條有證據的教訓，供同領域後面的任務參考。這個給改進器用的 harness 就是「平方」的來歷。
5. 和普通 harness 差在哪？ 普通 harness 是部署前定稿、所有任務共用的一份檔案；Harness² 裡它是每個任務執行時當場生成的中間產物。換來的是不需要評分器也能改進，付出的是每個任務至少四倍的執行量。

想親手看一遍流程，可以跑倉庫自帶的演示，不需要任何模型憑證²：

uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

它用寫死的編輯者把並行和串行兩種模式各走一遍，產物都在 runs/demo/ 底下，可以對照圖 3、圖 4 和圖 7 逐個目錄打開來看。

參考資料