Google Harness2 開源代理自我改進，但驗證仍是考驗
Google 在報告稱，透過修改代理周邊軟件而非其模型，最高可帶來 11.5 分的提升後，已將 Google Harness2 開源。這項分別構成核心張力。該框架讓代理可修訂提示、工具、記憶及其他操作指令，但在沒有已知正確答案的情況下，仍須自行判斷這些修訂。
作者將該項目稱為 Harness²，來自與 Google Cloud AI Research 及 Northwestern University 有關聯的研究人員。其程式碼連同一篇 2026 年 10 月 9 日的研究論文一同發布，並採用 Apache 2.0 授權。這次發布將一種研究方法轉化為開發者可檢視、執行及修改的軟件。
該項目亦挑戰了對 AI 代理的一項常見假設。更佳結果不一定需要更新或更大型的模型，也可以來自修改 harness，即將語言模型轉化為可行動系統的軟件與指令。
這個論點令固定式代理框架面臨壓力。OpenCode、Codex、Claude Code 及類似系統，均將模型與提示、工具、記憶及編排結合。Google Harness2 提出一個問題：這些周邊組件在部署後是否應維持不變。
答案的影響超越基準排名。可自行編輯的 harness 能適應陌生的法律、辦公室、網絡及編程工作；但它也可能保留錯誤假設、選擇較弱的修訂，或為得出答案而消耗大幅更多運算資源。
Google Harness2 修改凍結模型周邊的軟件
這次發布將遞歸改進由模型訓練移至代理執行環境中八個可編輯部分。
AI 代理不只是回答提示的語言模型。它亦依賴指令、可用工具、儲存的上下文、委派規則，以及控制每項行動的軟件。這些組件合起來構成代理的 harness。
Google Harness2 開放八個組件供修訂：系統提示、護欄、記憶、工具指引、子代理、技能、腳本及中介軟件外掛。每個組件均以掛載到執行環境的檔案表示。底層模型權重則保持凍結。
這種分隔相當重要。訓練或微調模型需要專門基礎設施、準備好的資料及獨立部署流程；修改提示、技能或工具指令，則可在代理處理任務期間進行。
開源儲存庫將這套方法打包為適用於 Linux 的 Python 專案。它支援 Python 3.12、並行及順序式改進，並可整合 OpenCode 與 Codex 執行器。隨附示範使用確定性編輯器及本機 Python 執行，讓開發者無須模型憑證亦可檢視工作流程。
以模型為基礎的評估則需要更多基礎設施。儲存庫列明需要 Node.js、Google Cloud 驗證、透過 Vertex AI 存取模型，以及基準測試專用相依套件。WorkBuddy-Bench 需要 Docker，而法律基準測試則需要文件處理工具。
這套設定顯示該項目的現時受眾。這是為準備好進行受控評估的團隊而設的研究軟件，而非可悄然升級每個代理的消費者功能。發布提供了實驗所需的機制，但採用者仍需準備任務、執行環境、評審機制及操作限制。
該框架會以共同的基礎 harness 處理每項新任務。它不會單純將最新的任務專用設定帶到下一項工作；相反，它會暫時改進當前 harness，並將可重用經驗記錄在獨立的改進資料庫中。
這項決定回應了適應式系統常見的一種失敗情況。對合約分析有幫助的指令，可能損害試算表任務。若直接累積每次成功的編輯，harness 將愈來愈專門化，亦更難理解。
Harness² 反而嘗試保留關於某項編輯為何有效的證據。未來任務可借鑑這些經驗，而毋須繼承整個早前的執行設定。
因此，該項目呈現兩種軟件形式：一個 harness 執行工作，另一個 harness 改進執行工作的系統。正因這個第二層，作者將方法稱為遞歸代理 harnessing，而非一般的提示優化。
對已手動維護代理指令的開發者而言，這次發布將一套熟悉工作流程正式化。團隊會檢查失敗情況、修訂指令、重新執行任務，並保留有用技巧。Google Harness2 將這個迴圈的大部分工作交由代理處理，並把產生的變更記錄為結構化成品。
Google Harness2 如何在沒有正確答案下改進代理
其核心機制是在相配條件下比較行為，而非要求完美驗證器辨識正確輸出。
該框架將主要的任務級流程稱為 Propose-Probe-Compose。提議者會先研究原始執行過程，並建議具針對性的 harness 編輯。探測器會以這些候選項重新執行同一任務。其後，組合器根據結果軌跡之間的差異，整合獲支持的變更。
軌跡是模型回應、工具呼叫、觀察結果及生成檔案的記錄序列。它比單看最終答案提供更多證據。編輯器可看見某項修訂是否找到遺漏輸入、調用了合適工具，或在提交前驗證文件。
系統將提案分為兩個範圍。不變性編輯器著重一般執行行為，例如在寫入輸出後檢查結果。領域編輯器則著重任務專用知識、格式或程序。
這種分隔可降低每個問題都獲得同一種通用修正的可能性。當兩者均帶來有益的行為改變時，亦讓組合器可結合廣泛適用的流程規則與專門指引。
關鍵是，線上流程不會取得基準測試的答案鍵。研究論文描述了一個開放世界設定：任務在 harness 設計完成後才到來，執行期間未必有可靠的真實答案驗證器可用。
系統不會宣稱某個候選項正確，而是尋找對比。例如，假設基礎代理忽略多個來源檔案。一項修訂會盤點每個輸入，另一項則加入試算表核對指引。它們的軌跡可顯示這些介入是否改變了代理的流程。
組合器會利用這些證據建構另一個 harness，再次執行任務。這種做法並未消除判斷，只是將判斷由把輸出與已知答案比較，轉移為比較不同執行過程中的可觀察行為。
開發者可透過兩種方式增加測試時運算資源。並行遞歸會同時探索多個候選修訂，然後整合這些嘗試所得的證據。順序遞歸則在每次先前修訂後再進行一次改進。
變數 k 控制這個探索預算。較大的數值讓系統有更多機會尋找及測試編輯，但每個機會都會增加模型呼叫、工具使用及執行時間。
任務完成後，第二層遞歸會更新持續改進 harness。反思器會儲存採納的 harness，以及描述介入、證據與結果的經驗檔案。後續提案可參考這個資料庫。
這項設計令經驗比完成的提示更具可攜性。儲存的經驗或會指出，文件生成任務可從重新開啟最終檔案並檢查必要章節中受益。即使確切文件不同，這個流程亦可跨領域適用。
這項區別亦將框架連結至日常知識工作。代理在撰寫決策備忘錄前，可能需要結合會議筆記、試算表、政策及項目文件。困難部分往往是追溯不同來源之間的主張，而非生成流暢文字。
團隊現已可透過建立可搜尋的知識庫減輕這種負擔。Harness² 將這個概念延伸至執行政策：代理可為某項任務修訂其收集、檢查及使用這些資料的方式。
不過，該機制仍屬實驗性質。行為對比是證據，並非真相。兩個候選項可能共享同一錯誤前提，而看似完善的軌跡仍可能導向不良交付成果。
基準測試的提升令固定代理 Harness 面臨壓力
報告結果顯示，harness 設計可如更換模型般改變效能，對起點較弱的系統尤其如此。
研究人員在三個專業基準測試上評估 Harness²。WorkBuddy-Bench 涵蓋編程、網絡及辦公室任務。JobBench 測試專業工作，而 Harvey’s Legal Agent Benchmark 則衡量法律任務效能。
測試涵蓋兩種模型與兩種起始 harness 的四個組合。模型為 Gemini 3.5 Flash 及 GLM-5；初始執行 harness 為 OpenCode 及 Codex，而 Claude Opus 4.8 則在主要實驗中擔任預設編輯器。
作者指出，單一步驟改進在全部三項基準測試中，均改善了每個接受測試的模型與 harness 組合。最大的報告增幅在 WorkBuddy-Bench 達 11.5 分、JobBench 達 4.5 分，而法律基準的部分通過率則提升 11.8 個百分點。
WorkBuddy-Bench 最大變化出現在 OpenCode 下的 GLM-5。其平均分數經過一步後由 64.2 升至 75.7。OpenCode 下的 Gemini 3.5 Flash 則由 72.4 升至 77.5。
這些數字支持一項實際推論：harness 可透過修正原始模型能力未能解決的執行行為，縮小部分模型之間的差距。
結果因設定而異。Codex 下的 GLM-5 在 JobBench 僅獲 1.2 分增幅，由 23.6 升至 24.8；OpenCode 下的 Gemini 在同一基準則提升 4.5 分。
這種變化比最高的標題數字更重要。該方法並未在每個模型、harness 及任務中帶來一致改進；其價值取決於起始系統及領域。
研究人員亦提高遞歸預算。對 OpenCode 下的 Gemini 而言，由一步改進轉為 k=5 的並行遞歸後，WorkBuddy-Bench 效能進一步提升。編程達 80.8、網絡達 81.7，而辦公室任務達 83.4。
論文報告指，在選定的 WorkBuddy-Bench 領域中，隨着預算由一增至五，並行及順序分數均有所上升。競爭方法在這些測試中呈現較小或較不一致的變化。
更多探索並非全部解釋。在消融研究中，移除改進資料庫令 WorkBuddy-Bench 平均表現降低 3.1 分。移除範圍化編輯器角色損失 2.9 分，而跳過組合則損失 1.6 分。
JobBench 顯示相似模式。移除資料庫令分數降低 1.8 分，通用編輯器損失 3.7 分，而省略組合則損失 1.9 分。這些結果顯示，保留的經驗、專門化提案及以證據為本的組合，各自均有貢獻。
JobBench 個案研究說明了當中的機制。基礎代理未能整合來源檔案之間的資訊，亦沒有重新開啟最終輸出作驗證，得分為 43.1。
其中一項建議介入措施要求盤點每一項輸入資料，並明確追溯來源。另一項則加入關於日程、場地、勞工及預算核對的領域指引。整合器保留了這些介入措施引入的全部四項修改，而重新執行後得分為 77.8。
這個例子加強了改善代理框架的論點，因為失敗源於程序。模型並不缺乏基本語言能力，也不是無法存取檔案；它缺少的是可靠的操作方法。
固定框架在不同領域的表現仍有差異。論文的比較發現，Claude Code 在固定系統中於程式碼及辦公室任務領先，而 Codex 則在網絡任務領先。沒有任何維持不變的框架可在所有領域領先。
Harness² 以具備較大遞迴預算的 OpenCode 為起點，在程式碼方面比最強固定替代方案高 4.6 分、網絡方面高 5.8 分、辦公室方面高 4.9 分。作者明確指出，這個自適應結果使用了額外的測試時運算資源。
因此，競爭壓力針對的是固定框架方式，而非某一款特定產品。供應商可以改善其模型，但若周邊指示和工具無法適應，使用者仍可能得到不一致的結果。
自我改善代理框架仍需要獨立核查
Harness² 可以改善代理的流程，但其自身證據顯示，遞迴修改有時會選擇較差的行為，或擴散錯誤的假設。
基準測試結果來自專案作者，尚未在獨立部署中證實其生產可靠性。論文報告了三次執行的平均值，這有助衡量變異性，但不能取代外部複現。
該方法亦會在交付最終輸出前消耗額外運算資源。每個建議、探測、整合及重新執行都會消耗 token 和執行時間。當有足夠容量時，平行處理可縮短經過時間，但無法消除根本資源成本。
論文將已評估的配置置於 JobBench 和 WorkBuddy-Bench 的實證運算效能前沿。這表示量度到的提升，相較於已測試的替代方案更具優勢；但不代表遞迴方式對每一種生產工作負載都合乎成本效益。
低價值任務未必值得多次執行模型。法律備忘錄或營運決策或許值得進行更多核查，但這些領域亦需要比基準測試執行器更嚴格的控制。
最重要的警告來自作者自身的失敗分析。他們檢視了九宗效能倒退，並將其歸類為候選選擇失敗、共同的錯誤前提，以及評估或執行不確定性。
在一個程式設計例子中，框架選擇了得分 55 的輸出，而非得分 95 的替代方案。在一項法律任務中，較狹窄的修訂降低了覆蓋範圍，得分由 54 降至 26。
其他失敗始於候選方案共享的錯誤假設。這些錯誤導致 2 至 11 分的損失。若每項建議修改都接受同一個錯誤前提，對比其行為也無法揭示原本的錯誤。
論文亦指出，缺失的評審判決及一般的逐次執行變異，是歸因問題。一項分數變動可能反映修改、隨機執行，或評估雜訊。更多探測有助改善判斷，但會增加成本。
儲存庫活動亦揭示了實作風險。一個公開的 快取識別問題 指出，當任務指示或來源檔案已變更、但任務識別碼維持不變時，恢復執行的實驗可能重用較早的輸出。
該問題作者在沒有模型呼叫的情況下重現了這個行為，並指出輸入內容未包含在已儲存執行識別的部分內容中。該報告未量化對已發表基準分數的任何影響，而在檢視時亦未附有維護者的處理結果。
然而，這個問題說明了更廣泛的營運挑戰。遞迴系統需要為任務、來源材料、框架修訂、快取輸出及評估設定建立可靠的沿革記錄。否則，表面上的改善可能反映過時證據。
安全亦帶來另一項憂慮。八個可編輯元件包括防護措施、腳本、外掛程式及工具指示。這些檔案可以影響代理可存取的內容，以及它執行哪些操作。
自主編輯器不應獲得不受限制的權限，以削弱存取控制、執行未經審核的腳本，或持久保存敏感任務細節。生產環境需要元件層級權限、不可變更的安全邊界、稽核日誌及回復機制。
持久經驗同樣值得審慎處理。從某個客戶、部門或法律事項所得的有用教訓，在為另一個情況檢索時可能洩露機密資訊。因此，改善資料庫不僅需要語意相關性，亦需要資料隔離及保留政策。
團隊亦應區分效能最佳化與安全驗證。基準分數獎勵的是在其評估器下完成任務，並不會自動衡量私隱、授權、事實準確性或對惡意輸入的抵抗能力。
Google Harness2 本身正好示範了這個區別為何重要。其整合器可以偏好行為上看似可信、但客觀上較弱的候選方案。缺乏真實答案正是該框架要處理的問題，但亦是框架無法消除的限制。
合理的生產設計會允許系統修改風險較低的指引，同時保護核心政策。提示詞措辭及工作流程核對清單可以編輯；憑證規則、網絡邊界、審批關卡及破壞性操作限制則應置於代理權限以外。
對於跨任務持續保留的建議修改，人手審核仍然很有價值。該框架可以產生證據，說明為何採納某項修改。操作人員可利用這份記錄，在變更進入共享資料庫前批准、拒絕或限制該變更。
遞迴代理框架正在改變代理工程的發展路線圖
下一項考驗是：組織能否在控制運算成本、效能倒退及持久記憶的同時，複現這些提升。
第一個值得觀察的訊號是獨立基準測試複現。該儲存庫公開了程式碼、配置、提示詞及評估指令，為外部團隊提供了實際起點。複現工作應同時報告最終分數及總模型使用量。
若能在不同供應商之間成功複現，將加強核心主張。這會顯示自適應框架並非緊密依賴於已測試的模型、編輯器或 Google Cloud 環境。
若未能複現這些提升，則會削弱其普遍性的論據。研究人員需要識別差異是否源於模型行為、基準版本、執行環境或評估設定。
第二個訊號是真實任務串流的效能，而不是孤立的基準測試執行。框架層級的遞迴承諾可帶來累積價值，因為早前任務的經驗可引導後續建議。
論文為這種轉移提供了初步證據。建立在 JobBench 之上的經驗資料庫，在 WorkBuddy-Bench 上將單步修訂提升了：程式碼 0.6 分、網絡 0.5 分、辦公室 2.9 分。
這些提升低於最強的任務層級結果，而且其中一項分析以回溯方式使用了後續任務的經驗。實時部署應證明，有用教訓可按時間順序累積，而不會匯入未來資訊。
操作人員應在平均效能以外，同時量度效能倒退比率。他們亦應追蹤介入頻率、延遲、模型消耗，以及通過人手審核的持久修改百分比。
第三個訊號是更強的驗證及管治層。作者建議採用可挑戰共同假設的探測、重複執行以區分修改與變異性，以及在覆蓋範圍與精確度之間取得平衡的更佳選擇方法。
儲存庫修正可以提供另一個指標。內容感知的快取識別、固定的基準修訂版本及可靠的失效機制，將令實驗更易複現。為可編輯元件訂立清晰安全邊界，則可令部署更安全。
更廣泛的研究領域亦會測試其他形式的框架適應。Meta-Harness 在部署前搜尋配置。ReasoningBank 檢索有用的推理經驗，同時保持框架不變。Harness Scaling 則為個別任務修訂框架。
Harness² 將線上任務適應與持久改善機制結合。這個組合是其主要特色，但亦集中風險。一次不良的任務層級修訂只影響一個結果；一項不良的保留經驗則可影響後續任務。
對開發人員而言，實際訊息不是每個代理都應立即自行重寫，而是提示詞、記憶、工具及編排應作為相連系統來評估。
團隊可以從有限制的實驗開始。他們可以選擇具代表性的任務、保留不可變更的基礎框架、只允許在沙盒內作出修訂，並將輸出質素與總運算成本比較。每一項持久變更都應保持可追溯及可逆轉。
知識工作者應關注這一點，因為框架質素塑造了可見的代理行為。當工具指示薄弱、記憶雜亂，或工作流程欠缺驗證時，模型可能顯得不可靠。相反，較佳程序可在不更換模型下改善結果。
這次公開發布令這些假設變得可測試。它為研究人員提供了一個共同實作，以研究代理如何診斷失敗、修訂操作指示及保留經驗。
Google Harness2 最終將自我改善的討論，從抽象的模型智能轉移至可檢視的軟件產物。這是一項有用轉變，因為團隊可以審閱檔案、追蹤修訂及量度執行結果。
它並未解決最困難的問題：在沒有答案鍵時，誰來驗證改善者？該框架以結構化行為證據取代盲目編輯，但證據仍可能誤導。
未來數月，請留意獨立複現、實時跨任務結果，以及對可編輯元件更嚴格的控制。這些訊號將決定遞迴代理框架會成為可靠的工程層，還是僅停留於具前景的研究工作流程。
對目前正在評估 AI 代理的團隊而言，立即行動很直接：分開測試模型及其框架、記錄每項變更，並在保留自動化修訂前要求清晰證據。Google Harness2 為這項實驗提供具體框架，而其報告的失敗亦顯示監督為何仍然重要。
