--- lang: zh-TW title: "Harness 與架構演進：從 Harness² 看它和普通 harness 的區別" description: "Harness² 的 JobBench 起點 harness 裡，系統提示、守則、記憶三個檔案都是空的，模型權重也不動，分數卻能往上走。順著這個現象往下追：harness 由哪些檔案組成、平常誰在改；任務沒見過又沒有標準答案時，憑什麼判斷一次修改是好是壞；預算 k 有哪兩種花法；改完的東西怎麼留給下一個任務；最後回頭對照，它和人手維護的普通 harness 到底差在哪、多花了什麼。" pubDate: 2026-11-11 tags: ["AI", "Agent", "Harness", "源码分析"] clc: "TP18" hero: "./hero.svg" refs: - id: h2-readme title: "Harness² README" url: https://github.com/google-research/harness2/blob/main/README.md site: GitHub · google-research/harness2 note: "本文讀的是 2026-11-02 的提交 `6868817`；harness 與 harnessing 的定義、兩層遞歸、八個元件、`--k` 與 `--mode`" - id: h2-paper title: "Harness²: Recursive Agent Harnessing for an Open World" url: https://arxiv.org/abs/2610.14224 author: "Ruiyao Xu, Yanfei Chen, Zhongying CuiZhu, Bhavana Dalvi Mishra, Yifei Ming, Han Yu, Rujun Han, Chen-Yu Lee, Tomas Pfister" site: arXiv date: 2026-10-09 note: "arXiv:2610.14224；開放世界的設定、與離線方法的對照、主結果（Table 1）、消融（Table 3、Table 6）、經驗庫的使用統計（E.2）、局限（Appendix F）" - id: h2-site title: "Harness² 專案頁" url: https://harness2.github.io site: harness2.github.io note: "WorkBuddy-Bench 上 Gemini 3.5 Flash + OpenCode 的各方法平均分" - id: h2-baseline title: "harness_baseline_oc：JobBench 的起點 harness" url: https://github.com/google-research/harness2/tree/main/third_party/jb_runner/harness_baseline_oc site: GitHub · google-research/harness2 note: "`harness.yaml` 列出可演化的元件；`systemprompt.md`、`guardrails.md`、`LongTermMEMORY.md` 在 v0 都只有一行註解" - id: h2-prompts title: "prompts.py：方法發給模型的每一段提示" url: https://github.com/google-research/harness2/blob/main/harness2/core/prompts.py site: GitHub · google-research/harness2 note: "`_SURFACE_OPENCODE`、`_INV_TEMPLATE`、`_DOM_TEMPLATE`、`aggregate`、`compose_round`、`select`、`experience`、`ANSWER_FREE`" - id: h2-tree title: "tree.py：元件樹的讀寫與校驗" url: https://github.com/google-research/harness2/blob/main/harness2/core/tree.py site: GitHub · google-research/harness2 note: "`SurfaceSpec`、`is_allowed`、`validate`、`autotrigger`；常駐文字上限在 `substrate/opencode.py`（24,000 字元）和 `substrate/codex.py`（8,000 字元）" - id: h2-recursion title: "recursion.py：並行與串行兩種任務級遞歸" url: https://github.com/google-research/harness2/blob/main/harness2/core/recursion.py site: GitHub · google-research/harness2 note: "`run_parallel`、`run_sequential`、`_run_stage`（提案不合格重試一次，再不行就沿用目前的 harness）" - id: h2-context title: "context.py：改進器讀到的證據目錄" url: https://github.com/google-research/harness2/blob/main/harness2/core/context.py site: GitHub · google-research/harness2 note: "`context/` 的佈局、`assert_no_leak_paths`、`GRADER_VERDICT_MARKERS` 與 `assert_no_grader_verdicts`" - id: h2-spec title: "spec.py：基準適配器要實作的介面" url: https://github.com/google-research/harness2/blob/main/harness2/core/spec.py site: GitHub · google-research/harness2 note: "`BenchPrompts.__post_init__` 拒絕 benchmark、rubric、score 等字眼；`RunView` 不帶分數；`score()` 只在選定之後由 `core.judge` 呼叫" - id: h2-ledger title: "ledger.py：預算記帳" url: https://github.com/google-research/harness2/blob/main/harness2/core/ledger.py site: GitHub · google-research/harness2 note: "`expected_rollouts` 為 4k，`expected_sessions` 為 3k，`assert_identity` 對不上就報錯" - id: h2-selection title: "selection.py：盲選與反思" url: https://github.com/google-research/harness2/blob/main/harness2/core/selection.py site: GitHub · google-research/harness2 note: "`selection_pool`、`assign_ids`、`trivial_selection`、`reflect_adoption`、`_distil`" - id: h2-library title: "library.py：按領域存放的經驗庫" url: https://github.com/google-research/harness2/blob/main/harness2/core/library.py site: GitHub · google-research/harness2 note: "目錄佈局、`Library.add`（沒有 cue、lesson、evidence 就不入庫）、`rebuild_index`" - id: h2-demo title: "demo.py：不需要模型的本地演示" url: https://github.com/google-research/harness2/blob/main/harness2/demo.py site: GitHub · google-research/harness2 note: "`DemoAdapter`（兩個記帳任務）與 `DemoProposer`（寫死的編輯、選擇與反思）" - id: h2-schedule title: "schedule.py：任務流的排程" url: https://github.com/google-research/harness2/blob/main/harness2/core/schedule.py site: GitHub · google-research/harness2 note: "`run_task` 每個任務都從 `adapter.base_harness()` 讀起點檔案樹；`run_domain` 在同一個領域內逐個任務執行" - id: h2-proposer title: "proposer.py：改進器會話" url: https://github.com/google-research/harness2/blob/main/harness2/core/proposer.py site: GitHub · google-research/harness2 note: "`Proposer.call` 把 `context/` 複製進臨時目錄 `harness2-prop-*`，經 `claude_cli` 或 `opencode` 通道開會話，結束後取回 `context/harness`" - id: h2-experiments title: "Harness² Experiment guide" url: https://github.com/google-research/harness2/blob/main/docs/EXPERIMENTS.md site: GitHub · google-research/harness2 note: "Recursion modes、Web access、Results and resume 各節" --- 2026 年 10 月，Google Research 開源了 Harness²，對應的論文叫《Recursive Agent Harnessing for an Open World》[^h2-paper]。README 給的數字是這樣的：模型權重完全不動，只做一步改進，GLM-5 和 Gemini 3.5 Flash 在三個專業工作基準上都比原來的 harness 分數高，最多的一項是 WorkBuddy-Bench 上的 11.5 分[^h2-readme]。 權重不動，那動的是什麼？翻開倉庫，JobBench 用的起點 harness 是一個目錄，裡面最主要的三個檔案長這樣[^h2-baseline]： ```text systemprompt.md guardrails.md LongTermMEMORY.md ``` 三個檔案都只有一行註解，`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** 是優化這套系統的過程[^h2-readme]。用過 Claude Code、Codex 或 OpenCode 的人對它不陌生：`AGENTS.md`、`skills/`、hooks，就是 harness 落在磁碟上的樣子。 Harness² 把可以改的部分固定成八個元件。以 OpenCode 為例，它們掛在一次執行的不同位置上[^h2-prompts]：
八個可編輯元件在一次執行裡的位置 左邊是模型的上下文視窗：systemprompt.md、guardrails.md、LongTermMEMORY.md、tool_guidance.md 四份常駐文字每次執行都在，OpenCode 上限 24,000 字元；skills 的 SKILL.md 被叫到才載入；其餘空間留給任務、工具結果和模型自己的輸出。右邊是工具迴圈：模型提出工具呼叫，先經過 plugin，再到 bash 執行 scripts 下的腳本，或由 task 工具委派給 sub_agents 下的子 agent，結果回到上下文。最下面是凍結的底座 OpenCode 或 Codex CLI。 模型的上下文視窗 工具迴圈 常駐文字 每次執行都在 systemprompt.md 角色與步驟 guardrails.md 守則 LongTermMEMORY.md 領域事實 tool_guidance.md 工具用法 上限 24,000 字元（OpenCode） skills/<name>/SKILL.md 虛線：被叫到時才載入 任務、工具結果、自己的輸出 模型 提出工具呼叫 plugin/<name>.ts 一直註冊著，呼叫前後都經過，跳不過去 工具 bash scripts/<name>.py 確定性的小工具 工具 task sub_agents/<name>/AGENT.md 自己的上下文，只回傳文字 同一句指示，放在左邊每一次都佔位置， 放在右邊只在用到的時候才花成本。 底座 substrate · OpenCode / Codex CLI CLI、工具實作、模型供應商：凍結，不在可編輯的範圍內
圖 1 · harness 是一棵檔案樹，八個元件掛在執行過程的不同位置：常駐文字佔上下文，skill、腳本、子 agent 用到才花成本，外掛卡在工具迴圈裡
圖裡要看的是左右兩邊的成本不一樣。左邊四份常駐文字每一次執行都在上下文裡，每個字都和 agent 自己的輸出搶預算；右邊的腳本、子 agent 只在被呼叫時才花成本，外掛則卡在工具呼叫的必經之路上，模型想跳也跳不過去。這個差別後面會決定一條修改該放在哪裡。Codex 上的佈局略有不同：常駐檔案只有 `AGENTS.md` 一個，外掛的位置換成 `.codex/hooks.json`。 最下面那一條是 OpenCode 和 Codex 本身。倉庫把它們叫做 substrate，也就是「底座」，視為凍結的基礎設施；改進只發生在上面這八個元件的路徑上，寫到別處的檔案會被直接丟掉[^h2-tree]。 ### 平常誰在改它 知道了 harness 是什麼，再看它平常怎麼變。 **最常見的做法是人手改。** 我們看到 agent 某件事做得不好，就去 `AGENTS.md` 補一條規則，或者寫一個 skill。這樣的 harness 是寫給「所有任務」的：部署之前定稿，之後每個任務都用同一份。它的問題也在這裡，寫的人不可能預見所有任務，補的規則只會越堆越長。 **第二種做法是把修改自動化，但放在部署之前。** 論文把這一類叫離線方法，舉的例子有 Meta-Harness、AHE 等：準備一批固定的訓練任務，讓優化器反覆改 harness、跑任務、看分數，搜出一份最好的再上線[^h2-paper]。這已經不需要人了，可它需要兩樣東西：事先拿得到的任務，和能打分的評分器。 Harness² 針對的恰好是這兩樣都沒有的情況。**任務到來時才第一次見到，沒有評分器，也沒有標準答案，還能不能改 harness？** ## 二、沒有標準答案時的修改依據 ### 現象：開放世界 論文把這種設定叫開放世界（open world）：任務像一條流一樣陸續到來，設計 harness 的時候沒見過，執行的時候也沒有人告訴你做得對不對[^h2-paper]。三個基準都是這一類工作：JobBench 是各種職業的辦公任務，LAB 是法律工作，WorkBuddy-Bench 是辦公、網頁和程式碼[^h2-readme]。交付的是一份文件或一張表，沒有單元測試可以跑。 ### 第一次嘗試及其不足 最直覺的辦法是讓 agent 做完之後回頭看自己的軌跡，反思哪裡沒做好，再把教訓寫進 harness。這條路的問題是只有一次執行：agent 這次漏了一步，是 harness 沒交代清楚，還是這一次抽樣剛好走偏了？一條軌跡分不出來。更麻煩的是寫進去的修改有沒有用也無從知道，因為沒有再跑一次來對照。 ### 解決：Propose–Probe–Compose Harness² 的辦法是把「同一個任務多跑幾次」當成證據來源。先介紹兩個角色：**執行器**（倉庫裡叫 solver）是真正做任務的 agent，它每完整跑一次任務稱為一次 **rollout**；**改進器**（improver）是另一個 agent 會話，它不做任務，只負責讀證據、改 harness。兩者連用哪個模型都是分開設定的。它們在倉庫裡的關係是這樣[^h2-recursion][^h2-proposer]：
Harness² 的組成：兩個 agent 與中間的方法層 左邊是執行器，在 OpenCode 或 Codex 上做任務，每個任務跑 4k 次 rollout，交出 run_dir，並裝入一棵 harness 檔案樹。右邊是改進器，透過 claude_cli 或 opencode 通道開會話，每個任務 3k 次，讀 context 目錄，帶回 context/harness。中間是 harness2/core 的方法層：recursion.py 排程，context.py 把 run_dir 擺成 context 並掃描，tree.py 讀回檔案樹並校驗，selection.py 盲選與反思，library.py 管經驗庫。下面是方法之外的三樣東西：基準適配器、凍結的底座，以及選定之後才呼叫 score 的 harness2-judge。 執行器 · 做任務 方法 · harness2/core/ 改進器 · 改 harness 方法之外 rollout base1 底座 OpenCode / Codex 交出 run_dir 每個任務 4k 次 裝入 harness 檔案樹 模型由這個變數指定： HARNESS2_SOLVER_MODEL 兩個 agent 各跑各的行程， 中間只隔著磁碟上的目錄。 recursion.py run_parallel · run_sequential context.py run_dir 擺成 context/，再掃一遍 tree.py 讀回檔案樹，校驗，不合格退回 selection.py 盲選一份交付，交付後反思 library.py INDEX.md · EXPERIENCE.md session inv1.a1 通道 claude_cli / opencode 讀 context/ 每個任務 3k 次 帶回 context/harness/ 模型由這個變數指定： HARNESS2_IMPROVER_MODEL 工作目錄是臨時的： harness2-prop-*/context/ 基準適配器 jobbench · lab · workbuddy 底座 · 凍結 substrate/opencode.py · codex.py harness2-judge 虛線：選定之後才呼叫 score() 強調色是 harness 檔案樹走的路：改進器在 context/harness/ 裡就地改，tree.py 校驗後裝進下一次 rollout。 分數不在這個迴圈裡：harness2-judge 是另一個命令，算出來的分數不會流回上面任何一格。
圖 2 · 兩個 agent 不直接對話：執行器交出執行記錄，方法層擺成目錄給改進器讀，改進器改完的檔案樹經過校驗再裝回執行器
兩個 agent 之間沒有任何直接的通訊。執行器跑完留下一個執行目錄，方法層的 `context.py` 把它整理成一個 `context/` 目錄；改進器在一個臨時工作目錄裡讀它，直接修改其中的 `context/harness/`，會話結束後這棵檔案樹被取回來，校驗通過才裝進下一次 rollout。方法層本身不呼叫模型，它只負責排程、擺放證據和檢查結果。 有了這張圖，一步改進的過程就好講了。它分三段，倉庫把這三段叫 Propose–Probe–Compose：
k=1 時一步改進的時序 三條生命線：執行器、recursion.py、改進器。recursion.py 先讓執行器用未修改的 harness 跑 base1，是第 1 次 rollout；再開 inv1 和 dom1 兩個改進會話；兩棵候選檔案樹回來後經過校驗，各裝進執行器再跑一次，是第 2、3 次 rollout；然後開合成會話 agg1 讀三次執行的對照，帶回合成的檔案樹和筆記；agg1 再跑一次，是第 4 次 rollout，產出就是交付物。k=1 時用 trivial_selection 不開選擇會話。最後開一次不計入預算的反思會話，把 EXPERIENCE.md 寫進經驗庫。 base1 · 未修改的 harness R 1 inv1 · 只改做事的方式 P 1 dom1 · 只補這一行的知識 P 2 兩棵候選檔案樹 · 校驗 inv1 · 裝上候選再跑 R 2 dom1 · 裝上候選再跑 R 3 agg1 · 讀三次執行的對照 P 3 合成的檔案樹 + notes agg1 · 產出就是交付物 R 4 trivial_selection reflect · 不計入 P EXPERIENCE.md · 入庫 執行器 OpenCode + harness recursion.py run_parallel(k=1) 改進器 讀 context/，改 harness Propose Probe Compose Reflect k=1 只有一份最終產出，不開選擇會話。帳本只認左側標出的 4 次 rollout 和 3 次改進會話，反思另算。 強調色是 harness 檔案樹：每一次都由改進器寫出來，校驗後才裝進執行器。
圖 3 · 一步改進的完整時序（k=1）：4 次 rollout、3 次改進會話，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`，把負數漏掉了[^h2-demo]。`ledger-1` 的三筆金額是 100.25、−20.10、5.00，照原始碼算，漏掉負數得到 105.25，正確的總和是 85.15。把合成者的工作目錄畫出來是這樣：
合成者讀到的 context 目錄 左邊是執行器在同一個任務 ledger-1 上的三次 rollout：base1 用未修改的 harness，答案是 Total: 105.25；inv1 和 dom1 用修改過的 harness，答案是 Total: 85.15。右邊是合成者 agg1 的工作目錄 context，裡面有任務原文、base1 的完整軌跡和產出、每個候選的 harness 檔案與產出、經驗庫索引，以及可以就地編輯的 harness 目錄。評分標準、分數和參考答案不在這個目錄裡。 執行器 · 任務 ledger-1 跑三次 改進器 · 合成者的工作目錄 rollout base1 harness base（未修改） answer.txt Total: 105.25 rollout inv1 harness base + INV 的修改 answer.txt Total: 85.15 rollout dom1 harness base + DOM 的修改 answer.txt Total: 85.15 同一個任務、同一個模型， 三次的差別只在 harness。 context/ agg1 task.md 任務原文，去掉評分條件 rollouts/base1.md 完整軌跡，不截斷 deliverables/base1.md Total: 105.25 pool/inv1/harness/ 候選的檔案樹 pool/inv1/produced.md Total: 85.15 pool/dom1/produced.md Total: 85.15 library/INDEX.md 同領域更早任務留下的成品 harness/ 就地編輯，磁碟上的改動即提案 rubric · 分數 · 參考答案 虛線：評分材料不在 context/ 裡， 目錄交給模型之前還會再掃一遍。
圖 4 · 合成者判斷一次修改有沒有用，靠的是同一個任務上「改之前」和「改之後」的對照，不是分數
演示裡的兩個「編輯者」是同一段寫死的腳本，所以 `inv1` 和 `dom1` 改的是同一處；接上真模型時，兩者的分工是不同的，下面會講。 圖裡要看的是兩個數字。合成者不知道 85.15 才是對的，沒有人告訴它；它能看到的是**行為上的對照**：去掉那個過濾條件之後，總和把負數算進來了，而任務說的是「每一筆帶正負號的金額」。論文對這一點說得很克制：對照顯示的是行為怎麼變了，不是答案對不對[^h2-paper]。 ### 兩個編輯者的分工 Propose 階段為什麼是兩個編輯者，而不是一個？提示裡把修改的方向切成了兩個互不重疊的維度[^h2-prompts]： - **INV（invariant）管 agent 怎麼做事**：流程、工具的用法、怎樣才算做完，與題材無關。提示要求它找出軌跡裡最早偏掉的那一步，並且「不要加專業規則」。 - **DOM（domain）管這一行的人知道什麼**：交付物該有哪些部分、哪些數字要對得上、內行人不會漏掉什麼。提示要求它「不要診斷命令、重試、腳本或 hook」。 兩份候選各改一個維度，各跑一次，合成者才能分清一個變化是哪一類修改帶來的。如果只有一個編輯者把兩類修改混在一起，跑出來變好了，也說不清是誰的功勞。 ### 證據怎麼算數 對照不等於真相，所以提示花了很多篇幅約束合成者怎麼讀證據[^h2-prompts]： - 參照執行要當成一組樣本來讀。只在 k 次裡出現一次的缺陷算噪音，針對它的修改是對單一樣本過擬合。 - 每個候選只跑了一次，一次好結果只是弱證據。一條修改要留下來，必須指得出軌跡裡的**具體時刻**；「這看起來是好習慣」不算。 - 幾個候選意見一致只是支持，不是獨立的證明，因為它們出自同一個模型、同一批證據。 - 什麼都不改是合法的結論，叫 `KEEP_BASE`。提示的原話是：證據不支持的改動只花上下文，買不到東西。 合成者最後要交一份筆記，每個決定一行，格式是 `kept|revised|dropped -> 哪條修改 -> 哪個軌跡時刻`。 ### 把答案擋在外面 既然整個方法的前提是「沒有標準答案」，評分材料就不能出現在改進器讀得到的任何地方。程式碼裡有三處在守這條線：
擋住評分材料的三層，和繞過它們的一條路 左邊是評分材料：RUBRICS.json、score 函式和參考答案。中間是框架設的三層：提示層在每段提示裡寫明 WHAT YOU DO NOT HAVE；資料結構層的 RunView 沒有分數欄位；檔案層按 pass_rate 等標記掃描 context 目錄，命中就拒絕。三層都過了，context 目錄才交給改進器。下面是框架管不到的一條路：JobBench 的 RUBRICS.json 公開掛在 huggingface.co，一次驗證執行裡 Codex 執行器沒有人指示就自己下載了它，內容落在這次 rollout 的軌跡裡，而軌跡會原樣進入 context/rollouts。 評分材料 框架自己設的三層 改進器讀到的 框架管不到的一條路 評分器 RUBRICS.json score() 參考答案 提示層 prompts.py WHAT YOU DO NOT HAVE 每段提示都帶 資料結構層 spec.py RunView 沒有分數欄位 檔案層 context.py "pass_rate" … 命中就拒絕整個目錄 context/ task.md rollouts/ pool/ 三層都過了才交出去 huggingface.co · RUBRICS.json Codex 執行器，沒人指示就自己下載 這次 rollout 的軌跡 三層擋的是框架自己遞出去的東西。執行器能上網時，公開的評分標準會從執行記錄這一側進來。 虛線：軌跡會原樣擺進 context/rollouts/，所以下載到的內容能被改進器讀到。這一步是我們的推斷。
圖 5 · 三層檢查只管得住框架自己遞出去的東西；執行器若能上網，評分標準可以從執行記錄這一側繞進來
**提示層**：每一段任務提示都帶著一節 `WHAT YOU DO NOT HAVE`，寫明上下文裡沒有 rubric、評分條件、參考答案或分數，也不准去猜「評分器想要什麼」[^h2-prompts]。 **資料結構層**：描述一次 rollout 的 `RunView` 沒有分數欄位；基準適配器提供的提示文字如果出現 benchmark、rubric、score 這些字眼，建構時就直接報錯；真正的打分函式 `score()` 只在最終選定之後才由獨立的 `harness2-judge` 呼叫[^h2-spec]。 **檔案層**：`context/` 目錄交給模型之前，會按一組標記字串（例如 `"pass_rate"`）掃描檔名和內容，命中就拒絕。註解特地寫明這是絆線而不是防線：觸發了要去找是哪條讀取路徑漏了，不要去加長標記清單[^h2-context]。 圖的下半部是這三層管不到的地方。實驗指南坦白記了一件事：驗證這個版本時，有一次 Codex 執行器沒有人指示，自己上網把任務的評分標準下載了下來，因為 JobBench 的 `RUBRICS.json` 就公開掛在 Hugging Face 上[^h2-experiments]。Codex 執行時沙箱是關掉的，所以文件要求評測前在網路層封掉 `huggingface.co`、`github.com` 這些網域，並且在報告結果時一併說明用了哪些限制。 ### 改在哪個元件上 還剩一個問題：編輯者想加一條指示，放進八個元件的哪一個？回到圖 1 左右兩邊的成本差別。提示直接給了優先順序：有明確觸發情境的做成 skill，確定性的操作做成腳本，輸入大而答案小的調查交給子 agent，模型屢次跳過的檢查放進外掛，**常駐文字排最後**，而且加一段就得刪一段[^h2-prompts]。理由是這類工作最貴的失敗，是 agent 把輸出預算全花在推理上、最後什麼都沒交。常駐文字越長，這種失敗越容易發生。 論文附錄裡有一組數字可以對照這個排序。在 WorkBuddy-Bench 上，把改好的 harness 裡某一類元件拿掉再評分：拿掉 skill 掉 5.3 分，拿掉腳本掉 3.7 分，拿掉常駐文字那幾項只掉 1.5 分；改動的檔案裡，skill 和腳本大約佔一半[^h2-paper]。論文也提醒，這幾個數字不能直接相加，但方向是清楚的：起作用的主要是按需載入的那幾類。 提案在執行之前還要過一道校驗[^h2-tree]：每個 skill 的名字必須在常駐文字裡出現（否則 agent 不知道要載入它），提到的腳本必須真的存在且能編譯，常駐文字不能超過上限（OpenCode 是 24,000 字元，Codex 是 8,000）。不合格的提案會連同錯誤訊息退回去重試一次，再不行就沿用目前的 harness[^h2-recursion]。 到這裡，一步改進就講完了。一步要跑四次任務：一次參照、兩次試探、一次最終。**如果願意多花一些預算，該把它花在哪裡？** ## 三、遞歸預算的兩種用法 命令列上的 `--k` 就是這個預算，`--mode` 決定怎麼花[^h2-readme]。兩種模式的開頭一樣：先用原始 harness 跑 k 次參照執行。之後分成兩條路[^h2-recursion]：
k=2 時並行與串行兩種遞歸 並行模式：兩次參照執行 base1、base2 之後，同時提出四個候選 inv1、dom1、inv2、dom2 並各跑一次，再由兩個合成者各自讀全部證據，合成 agg1 和 agg2，盲選其中一個交付。串行模式：第一輪從 base 出發提出 inv1、dom1，合成檢查點 c1；第二輪在 c1 上繼續提出 inv2、dom2，合成 c2；c1 和 c2 一起進入盲選。兩種模式都是 8 次 rollout、6 次改進會話。 並行 · --mode parallel · 往寬處探 串行 · --mode sequential · 往深處改 base1 base2 inv1 dom1 inv2 dom2 agg1 agg2 盲選 交付 k 次參照執行 2k 個候選，各跑一次 k 個合成，各跑一次 base1 base2 inv1 dom1 c1 inv2 dom2 c2 盲選 交付 c1 既是第 2 輪編輯的起點，也和 c2 一起進入盲選：後一輪改偏了，還能選回前一輪。
圖 6 · k=2 時兩種模式都是 8 次 rollout 和 6 次改進會話，差別在候選是一次鋪開，還是一輪接一輪
**並行**把預算一次鋪開：k 個 INV 候選和 k 個 DOM 候選彼此看不到對方，各自從同一批參照執行出發；然後 k 個合成者各自讀全部 2k 個候選的證據，各合成一份。提示還特地要求合成者不要去湊共識，交出自己站得住腳的那一份。 **串行**把預算疊起來：每一輪只提兩個候選，合成出一個檢查點，下一輪在這個檢查點上繼續改。這個檢查點自己跑的那一次，就是下一輪最直接的證據，它顯示的是「目前正在改的這份 harness 實際做了什麼」。合成者可以把更早被否決的候選撿回來，也可以原樣重現更早的檢查點。 兩種模式的帳是一樣的。`ledger.py` 規定每個任務恰好 4k 次 rollout（k 次參照、2k 個候選、k 個最終）和 3k 次改進會話，執行結束時對不上就報錯[^h2-ledger]。這樣比較兩種模式時，花的錢是相等的。 k 大於 1 時會有 k 份最終產出，交哪一份？這一步叫盲選[^h2-selection]。選擇者只看到任務原文、原始材料和各份**產出**，候選的代號是打亂的 A、B、C，它不知道哪份產出來自哪份 harness，也看不到執行過程。評判的順序是：要求的東西有沒有交齊、形狀有沒有照任務說的來、內容對不對得上原始材料、自己和自己是否一致。k 等於 1 時只有一份，不開選擇會話，直接交付。 論文的結果是，k 從 1 加到 5，兩種模式的分數都往上走：WorkBuddy-Bench 的程式碼子集上，並行從 76.5 升到 80.8，辦公子集從 79.5 升到 83.4。串行在 k=2 時的程式碼子集上略高，到 k=5 時並行反超[^h2-paper]。 到這裡，一個任務的事情做完了。可是下一個任務到來時，起點又是那份空的 base harness。**前一個任務花四次以上執行換來的東西，就這樣丟掉嗎？** ## 四、第二層遞歸：改進 harness ### 現象：改好的 harness 不能直接沿用 最直覺的做法是讓下一個任務直接從上一個任務改好的 harness 出發。Harness² 沒有這樣做：`run_task` 每次都重新讀 base 的檔案樹，每個任務仍然從 base 開始[^h2-schedule]。論文沒有專門解釋為什麼不沿用，下面的原因是我們從提示的寫法推出來的：為一個任務改的 harness 裡寫著那個工作區的具體事實（哪兩個欄位對得上、哪個數值才是對的），提示甚至鼓勵編輯者把驗證過的事實直接寫進去。這些事實換一個任務就是錯的錨點，一路累積下去，harness 會越來越偏向前面的任務。 ### 解決：把成品和教訓存進經驗庫 它留下來的是另一種東西。交付之後多開一個反思會話（Reflect），讀這個任務的完整改進記錄，寫兩樣東西[^h2-selection]： 1. **每條修改做了什麼**。把每個候選 harness 和 base 逐一比對，每個被改過的元件寫一行，給一個判定：`helped`、`hurt`、`no observed effect` 或 `confounded`。提示明說要優先用 `confounded`（分不清）：一個候選同時改了好幾處，或者背後只有一次執行，就該這樣標。 2. **最多一條可以帶走的教訓**。`cue` 寫這條教訓適用的情境形狀，`lesson` 寫要對 harness 做的操作，`evidence` 指回上面的哪幾行。記錄裡找不到具體的執行對照，就只寫一行 `NO_ENTRY`。 這裡有一個細節：盲選比的是產出，所以「被選中」只說明哪份產出讀起來最好，不說明哪條修改起了作用。提示因此要求反思時把所有候選都當證據，被否決的候選裡也可能有真正有用的修改。 反思通過了，被採用的**整棵 harness 樹**和一份 `EXPERIENCE.md` 才會存進經驗庫；三個欄位缺一個就不入庫[^h2-library]。用演示裡的任務畫出來是這樣：
經驗庫在任務之間傳遞的東西 左邊是 accounting 領域的任務流：ledger-1 從 base harness 出發，採用 agg1；交付後的反思把一條記錄寫進右邊的經驗庫。經驗庫裡 ledger-1 的 EXPERIENCE.md 記著採用的是 agg1、cue 是帳本同時有貸方和借方、lesson 是在 scripts/summarize.py 加總時兩種正負號都要算、evidence 是去掉只算正數的過濾後試探的總和包含了原先漏掉的金額、confidence 為 high；旁邊存著整棵被採用的 harness 樹和 INDEX.md。下一個任務 ledger-2 仍然從 base harness 出發，但它的編輯者會先讀這個經驗庫。 任務流 · accounting 經驗庫 · agg/accounting/ 任務 ledger-1 起點 base 採用 agg1 交付後 Reflect 反思通過才寫入 → 任務 ledger-2 起點 base 先讀 context/library/ 之後 照常三段 每個任務都從 base 出發， 帶得走的只有右邊這個庫。 EXPERIENCE.md harnesses/ledger-1/ adopted agg1 cue When a ledger includes credits and debits lesson Include both signs when summing in scripts/summarize.py. evidence removing the positive-only filter changed the probe total to include the credits omitted by the base … confidence high for this observed arithmetic contrast harnesses/ledger-1/harness/ 整棵被採用的檔案樹，不是摘要 INDEX.md 每條記錄的 cue，供下一個任務先瀏覽 找不到具體的執行對照，反思只寫 NO_ENTRY，這個任務就不入庫。
圖 7 · 任務之間傳遞的不是上一份 harness，而是「改過什麼、有什麼證據、什麼情境下適用」的記錄
下一個任務的編輯者會在 `context/library/` 裡讀到這個庫：先看 `INDEX.md`，再打開看起來相關的幾條。庫裡的檔案只是範例，不在執行時的磁碟上，要用就得複製進自己的 harness；而且提示要求把舊任務斷言的工作區事實重新對過，因為那些在上一個任務是事實，在這裡只是假設[^h2-prompts]。 經驗庫按領域分開：同一個領域裡的任務按順序跑，只讀得到排在自己前面的任務；不同領域之間可以同時跑[^h2-experiments]。 庫裡的東西實際被用了多少？論文統計過改動的檔案裡有多少帶著經驗庫的來源：LAB 和 WorkBuddy-Bench 的辦公子集是 22%，JobBench 是 47%；而一半以上的行直接來自庫的檔案只有 10% 到 22%[^h2-paper]。也就是說，編輯者多半是參考之後改寫，很少整份照搬。 ### 名字裡的「平方」 現在可以回答「平方」是什麼意思了。 改進器本身也是一個 agent：一次 OpenCode 或 Claude CLI 會話，有自己的任務說明（`MISSION.md`），有自己的工作目錄（`context/`），有自己的參考資料（經驗庫）[^h2-context]。這些東西合起來，就是改進器的 harness。論文把它叫**改進 harness**（improvement harness），和做任務用的**執行 harness** 區分開[^h2-readme]。 於是有了兩層，各改一份 harness：
兩層遞歸各自改的是哪一份 harness 左邊的執行器由不動的模型權重加上執行 harness 組成，執行 harness 是 c1 到 c8 那些檔案。右邊的改進器同樣由不動的模型權重加上改進 harness 組成，改進 harness 包含不變的任務說明與提示、每次重新擺放的 context 目錄，以及跨任務累積的 library 目錄。第一層任務級遞歸是改進器修改執行 harness；第二層 harnessing 級遞歸是任務做完後的反思把記錄寫進 library，也就是改進器自己的 harness。 執行器 = 模型 + 執行 harness 改進器 = 模型 + 改進 harness ① 任務級 ② harnessing 級 模型權重 · 不動 執行 harness c1 … c8 systemprompt.md · guardrails.md 常駐 skills/ · scripts/ · sub_agents/ 按需 plugin/ 迴圈內 模型權重 · 不動 改進 harness MISSION.md · prompts.py 不動 context/ 每次重擺 library/ 跨任務累積 ① 改進器讀 context/，改左邊的執行 harness，一個任務之內做完。 ② 任務做完後，反思把「改了什麼、證據在哪」寫進 library/，下一個任務的改進器手上的 harness 就多了一條。
圖 8 · 「平方」的意思：第一層讓改進器改執行器的 harness，第二層讓做完的任務回頭改改進器的 harness
- **任務級遞歸**改的是執行 harness，一個任務之內完成，就是第二、三節講的 Propose–Probe–Compose。 - **harnessing 級遞歸**改的是改進 harness，跨任務進行，就是這一節的經驗庫。每做完一個任務，「怎麼改 harness」這件事本身多了一條有證據的經驗。 圖裡標著「不動」的幾格也要看清楚：模型權重不動，改進器的那幾段提示（也就是判斷規則）不動，會變的只有經驗庫的內容[^h2-paper]。所以這個「平方」說的是對 harnessing 這個過程再做一次 harnessing，並不是一個無限往上套的結構。 三樣設計各值多少，論文做了消融（Gemini 3.5 Flash、OpenCode、k=1）[^h2-paper]：拿掉經驗庫，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，是讀過這個任務的幾次參照執行之後才寫出來的，其中甚至寫著這個工作區驗證過的事實。 把這個差別和第一節講的兩種做法放在同一條時間線上：
三種做法各在什麼時候改 harness 三條泳道，中間一條虛線表示部署的時刻。人手維護：部署前由人看失敗案例、往 AGENTS.md 補規則，部署後三個任務用同一份 harness 各跑一次。離線優化：部署前用訓練任務和評分器反覆搜尋，部署後同樣是同一份 harness 各跑一次。Harness²：部署時只有幾乎是空的 base harness，部署後每個任務當場改出自己的 harness、跑 4k 次，做完把記錄寫進同領域的經驗庫，後面的任務會讀到。 人手維護 離線優化 · Meta-Harness 一類 Harness² 人看失敗案例 往 AGENTS.md 補規則、寫 skill 任務 1 同一份 · 1 次 任務 2 同一份 · 1 次 任務 3 同一份 · 1 次 訓練任務 × 評分器 優化器反覆改、跑、看分數 任務 1 同一份 · 1 次 任務 2 同一份 · 1 次 任務 3 同一份 · 1 次 base harness 三個主要檔案是空的 任務 1 當場改 · 4k 次 任務 2 當場改 · 4k 次 任務 3 當場改 · 4k 次 經驗庫 · 同一個領域 每做完一個任務多一條 虛線是部署的時刻。上面兩種做法，harness 在虛線左邊就定稿了，右邊每個任務拿到的是同一份。 Harness² 的修改全部發生在虛線右邊：每個任務從 base 出發改出自己的一份，再把記錄留給後面的任務。
圖 9 · 普通 harness 的修改發生在部署之前，Harness² 的修改發生在每個任務之內
逐項對照是這樣：
三種對待 harness 的方式
項目人手維護離線優化Harness²
誰來改人優化器改進器（另一個 agent 會話）
什麼時候改部署之前任務到來之後，交付之前
改的依據人看到的失敗案例訓練任務上的分數同一任務上改前改後的執行對照
需要評分器不需要需要不需要
一份 harness 管多少任務全部任務共用一份一個任務一份，都從 base 出發
跨任務累積的東西越寫越長的規則搜出來的那一份經驗庫：成品加有證據的教訓
每個任務的執行次數1 次4k 次，另加 3k 次改進會話

「離線優化」一欄按論文對 Meta-Harness 這一類方法的描述整理。

圖 10 · 普通 harness 是部署前定稿的一份檔案，Harness² 把它變成每個任務執行時的中間產物
### 效果與代價 效果上，論文的主結果表給了同一個模型（Gemini 3.5 Flash）、同一個底座（OpenCode）下各種方法在三個基準上的分數[^h2-paper][^h2-site]：
三個基準上的分數 · Gemini 3.5 Flash + OpenCode
方法WorkBuddy-BenchJobBenchLAB
Base harness72.431.579.9
ReasoningBank73.430.877.3
Harness Scaling75.332.978.9
Meta-Harness76.435.881.6
Harness²（k=1）77.536.081.9
Harness²（k=5，並行）80.839.084.5

紅字表示比 base 還低。k=5 一列由論文的 k=1 分數加上「+Recursion」的增量算出（+3.3、+3.0、+2.6）。

圖 11 · 同一個模型、同一個底座，只換對待 harness 的方式
表裡有兩點值得注意。其一，另外幾種方法並不總是比什麼都不做好：論文統計，Harness Scaling 在十二組「基準 × 配置」裡有七組低於 base。其二，Harness² 也不是每一格都領先：換成 Codex 底座時，LAB 上是 Meta-Harness 的 76.5 高於它的 75.6[^h2-paper]。 還有一個趨勢：比較弱的執行模型得益更大。README 裡那個最大的 11.5 分就出在 GLM-5 上，WorkBuddy-Bench 從 64.2 升到 75.7，只用了一步改進[^h2-readme][^h2-paper]。這也說得通，模型越弱，越需要有人把工作區的事實和步驟替它寫好。 代價同樣明顯，有四點要看清楚。 **執行量至少是四倍。** k=1 時每個任務要完整跑 4 次，外加 3 次改進會話和 1 次反思；k=5 時是 20 次執行和 15 次改進會話。這是拿算力換分數，交付也要等這些都跑完。論文把它列為第一條局限，並且說明並行只能縮短等待時間，總計算量不會變少[^h2-paper]。 **對照不等於正確。** 這是論文列的第二條局限：執行有隨機性，幾個候選又出自同一個模型、帶著同樣的偏見，對照只能說明行為變了[^h2-paper]。演示裡 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² 裡它是每個任務執行時當場生成的中間產物。換來的是不需要評分器也能改進，付出的是每個任務至少四倍的執行量。 想親手看一遍流程，可以跑倉庫自帶的演示，不需要任何模型憑證[^h2-readme]： ```bash 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 逐個目錄打開來看。 ## 參考資料