Google Harness²查核：不改模型權重，改Agent外殼；離線demo與研究成績的界線

結論：固定模型權重，改的是可執行的Agent外殼

Harness²是Google Research公開的recursive agent harnessing研究框架。它把模型外圍的prompt、工具指引、記憶、skills與編排等作為可修改對象，對同一任務比較執行軌跡，再整理可供後續任務使用的經驗。模型權重保持固定，不代表沒有新增程式、重跑任務或模型費用。[2][3]

本篇讀取原帖、固定提交6868817518876de8fd170c6a8354daca273b6191、論文arXiv:2610.14224v1及執行文件，並實跑免金鑰demo與7項workflow回歸測試。這是限定的離線實測，不是完整重現WorkBuddy、JobBench或LAB研究成績。

先訂正社群最容易混淆的四件事

不是8個檔案：官方說的是8類可編輯元件：system prompt、guardrails、memory、tool guidance、subagents、skills、scripts、plugins；其中多類可包含整個目錄和多個檔案，不是固定只改八份文字。[2]
+11.8是百分點：LAB指Partial pass rate，即通過條件的比例；不是相對提升11.8%，更不是整份法律工作完全正確的機率。[2][3]
43到77是單例：論文JobBench案例的精確值是43.1到77.8，增加34.7分，不是整個JobBench平均提升34.7分。[3]
不用key限本地demo：真正model-backed benchmark仍需要模型、認證與多輪推論；固定權重不等於免費或一次執行。[2][4][5]

怎麼改：兩層遞迴，不是只有讓AI寫一次code review

Task-level：先執行base harness取得參考，再Propose通用流程與領域候選修改；Probe把候選放回同一任務重跑；Compose比較輸入、輸出及軌跡後形成精修版本。研究設計的改進階段不依賴隱藏ground-truth verifier，最終研究評分是另一層；「有軌跡證據」仍不是保證每個新任務都會變好。[2][3]

Harnessing-level：對採用的外殼與修改經驗做反思，寫入分領域的library，供後續任務參考。保存內容不只是EXPERIENCE卡，也包含採用的harness。元件按run、executor、mode、budget等範圍分開；同領域任務依序讀較早經驗，不是把任何任務的輸出無條件塞進同一個全域記憶。[4][6]

程式允許NO_ENTRY；不符合經驗欄位要求的內容不應入庫。本次測試亦涵蓋無經驗／反思失敗時的行為。這是格式及流程保障，不等於證明每則被保存的教訓都具有因果正確性。

並行與循序：k不是免費的能力旋鈕

文件定義並行模式會提出k個通用候選、k個領域候選，再形成k個composition；循序模式則連續做k輪Propose–Probe–Compose，傳遞前一輪harness與證據。兩種模式都需參考執行；執行器、編輯器、selector與judge可能有不同成本。[4]

所以增加k會增加探索與執行預算。比較時應固定任務選擇、模型、judge、網路可見範圍與seed，不能把多花算力的結果寫成無成本升級。文件也指出max-tasks是每個domain的上限，不是整批總上限。[4]

研究數字應怎麼讀？

README及論文報告，單步在GLM-5與Gemini 3.5 Flash、OpenCode與Codex等四組配置，最大提升為WorkBuddy-Bench 11.5分、JobBench 4.5分及LAB Partial 11.8個百分點。這些是研究方在指定測試下的結果，不是本次實測，也不是對任意模型、工作或私人資料的保證。[2][3]

作為不同配置的例子，官方網站列Gemini 3.5 Flash／OpenCode的WorkBuddy平均由72.4到77.5，並非每組都提升11.5分；其並行k=5為80.8。網站標示三次run的reported means，WorkBuddy平均是Code、Web、Office的macro-average，不能混成單一任務的最佳值。[3][9]

43.1到77.8的JobBench案例使用Gemini 3.5 Flash／OpenCode：base未對帳不同來源，輸出後未重開驗證；通用修改補驗證流程，領域修改補對帳skill與數字格式工具指引，再由Composer保留四項編輯。它展示一個可理解的改善機制，不足以單獨建立平均收益或完全消除錯誤的結論。[3]

本次真跑了什麼？

以固定原始碼，在macOS、Python 3.13.13、隔離HOME及暫存輸出中執行harness2.cli.demo --k 2，預設both模式；結果為2個合成帳務任務完成、0失敗。實際有28次本地Python執行，並非28次模型呼叫。分別讀回並行與循序模式的四個選定輸出，與來源CSV的Decimal加總核對，兩題均為85.15與20.25；另產生四份EXPERIENCE卡。[5]

之後執行選定的tests/test_workflow.py，7項測試全部通過，涵蓋預算／resume、證據與library前綴、無效修改重試、NO_ENTRY、選擇失敗不送評分、失敗重跑清除舊selection、重評結果與選定輸出的對應。日誌中的模擬故障是測試情境，不是這七項測試失敗。[5]

重要限制：DemoProposer是預寫的deterministic editor，不是模型自主發現修法。它會移除「只加正數」的篩選，selector亦直接計算CSV合計來挑候選。因此成功可驗證流程、檔案與真Python執行，但不能證明LLM在無真值提示的開放任務已學會可靠自我改進。官方建議的完整benchmark環境是Linux／Python 3.12；本次輕量demo在Mac成功，不代表完整Linux工具鏈已在Mac驗收。[2][5]

採用前最重要的風險：無沙箱與評測洩漏

README與實驗文件明示executor網路不受本專案限制，Codex執行時關閉sandbox；固定adapter可見bypass approvals、sandbox及hook trust的啟動選項。這不是只讀prompt分析器，不能因為叫「改外殼」就把它放進可信私有工作區無限制試跑。本次沒有啟動這條真實Codex／OpenCode模型路徑。[4][7]

官方另記錄release驗證時，有Codex rollout自行下載公開JobBench rubric。即使本地context排除答案檔，外網仍可能取得評分規則；正式比較需在允許的隔離環境限制benchmark答案來源，並報告網路政策。這是上游已披露的風險，不能擴寫成所有論文結果都已證實洩漏或不實。[4]

授權與資料流不是一張Apache標籤就結束

根程式為Apache-2.0，但third_party、benchmark與資料各自保留授權。固定WorkBuddy Bench授權含不擬供歐盟境內使用的territorial條款；不能把主程式Apache授權套到整套評測資產。本次沒有下載或執行WorkBuddy資料集，也沒有啟動Docker、模型bridge或雲端judge。[8]

研究方也明示這不是Google正式支援產品。真實任務的軌跡、文件及持續經驗library可能含私人資料，應另外確認送往何種executor／improver／judge模型、保存位置與保留政策；本地跑Python或保存Markdown，不代表模型推論也在本地。

可借用的方法（編輯建議）

適合借用的是：保存base、將失敗拆成流程與領域問題、對同任務檢查修改影響、在未參與調整的題目回歸，再把有範圍與證據的教訓保存。每次變更保留rollback；不要讓單次高分、單張experience卡或人氣指標直接升格為全域政策。本篇未改動現有助手的模型、effort、記憶規則或權限。

來源與範圍

查核日2026-11-03。已讀原帖、GitHub連結預覽、可見留言與第一方文件；原帖可見回覆只有「留」，推薦串排除，留言coverage為partial。預覽圖是repo名稱與人氣資訊，不是benchmark圖。已做固定檔案hash核對、前述demo與7項測試；未重現研究benchmark或任何付費模型成績。