八個檔案先被掛上了執行環境：Harness² 把代理的成長，設計成一層可編輯的設定

2026 年 10 月 20 日，APPI News 刊出對 Harness² 論文的長文介紹。這份研究由 Google 研究人員與西北大學研究者共同提出，並公開了程式碼；GitHub 專案頁特別註明，這並非 Google 官方支援的產品。論文處理的問題聽起來工程味十足：當 AI 代理表現不佳時，問題究竟出在模型本身，還是包在模型外面的那一層設定？

從介面設計的角度看，這份論文其實在回答一個更普遍的問題：一個系統的「可修改面」被切在哪裡，決定了它累積經驗的方式。

模型是引擎，harness 是駕駛艙

Harness² 的前提很乾淨：模型權重不動。權重決定語言與推理的底層能力，改動牽涉大規模訓練資源，不會因為單次任務失敗就調整。而模型實際上線時依附的「代理執行框架」（harness），才是每次任務真正被閱讀、被執行的那層介面：系統提示怎麼下指令、有哪些工具可呼叫、護欄怎麼設、過去任務的記憶要不要帶進來。

論文把這層框架拆成八個可編輯元件：系統提示、護欄、記憶、工具指引、子代理、技能、腳本與外掛，每個元件以檔案形式掛載在執行環境中。這個拆法本身就是一種設計決定。把設定檔案化，意味著每次修改都有版本可對照，退回前一版不需要重新訓練，只需比對版本差異。相較之下，改權重的可回復性要靠保留舊快照，成本結構完全不同。

如果代理在某個領域反覆漏看一個步驟，原因常常是系統提示沒把那個步驟講清楚，或工具指引的上下文不足。模型未必不懂，是說明書沒寫好。

Propose-Probe-Compose：一套沒有標準答案的驗收流程

論文最有趣的部分，是它在缺乏地面真值的前提下，設計了一套判斷「修改是否值得採用」的流程，稱為 Propose-Probe-Compose。

流程先取得一次參考執行，再提出兩種候選修改：一種針對可能跨領域重複出現的能力缺陷，另一種針對當前領域特有的知識與限制。接著在相同任務、相同模型與環境設定下分別執行，把產出與參考執行比較，形成行為對比。最後一步讀取所有版本之間的差異與執行證據，決定合併、修正、採用，或者保留原設定。

這與我們先前觀察過的AI 代理錯誤揭露介面屬於同一類設計課題：當沒有外部裁判時，驗收標準只能內建在流程裡。Harness² 的做法是把「採用與否」變成一次需要證據的決策，而非憑感覺的調參。

研究團隊自己也說明了限制。Probe 階段若缺少可驗證的真值，精煉只能依靠行為對比與模型自身的判斷，而執行隨機性與模型之間共有的偏誤，都會削弱證據的可靠性。這也是作者不把 Harness² 包裝成「保證代理持續變好」的原因。這句誠實的保留，在一片宣稱自我進化代理的論述裡反而少見。

經驗沉澱在哪一層

遞迴被切成兩層。任務層的遞迴只精煉眼前這個任務的框架，執行期間用來做改進決策的框架維持固定，不會邊做邊換。任務結束後，才由另一層機制把這次採用的設定與背後證據，寫進一份持續累積的經驗記錄，供下一個任務參考。

論文特別區分：這份記錄與代理的對話記憶是兩回事。對話記憶服務單次對話，這裡累積的是跨任務、經過驗證的設定調整經驗。換句話說，經驗被存放的位置，從模型內部的權重或對話窗，移到了檔案系統裡一份可審閱、可回溯的記錄。這個位置的選擇，本身就是整個設計最有說服力的一步。

省下的成本與留下的成本

不改權重確實省下大規模訓練資源，影響範圍也可控制在單一任務或單一客戶。但論文沒有迴避另一面：推論呼叫、候選測試、審核與維護仍然有開銷，能否降低特定流程的總成本，需要實測推論、測試、整合與維護的實際數字，論文並未給出保證。

成本結構從一次性的巨額訓練，換成持續性的測試與審核。這種交換是否劃算，取決於任務的重複頻率與對穩定性的要求，沒有通用答案。

Harness² 提出的並不是一個更聰明的模型，而是一份關於「代理的成長應該發生在哪一層」的具體提案：把經驗放進可編輯、可比對、可退回的設定檔裡，並要求每次修改都附帶證據。至於這套對比流程在真實部署中能否累積出可信的經驗，仍是論文自己承認的開放問題。