模型持續進步時，代理程式 harness 工作有哪些仍能長久發揮作用？

簡答#

耐久的 harness 工作仍位於模型行為與外部現實的邊界：儲存庫本地的事實來源、機械式驗證、脈絡視窗預算、隔離／安全邊界、工具契約，以及人類決策介面。會逐漸縮減的是提示鷹架：教模型做出下一代模型原生就能做到的行為，例如強力要求列待辦清單、明確呼叫迴圈、脆弱的狀態機編排，以及建議性提醒。

原則是：**能力鷹架會縮減；邊界執行會持續存在。**更好的模型能學會自行選用待辦清單、啟動迴圈，或遵循工作流程，不必再三提醒。但它仍需要一個可供讀取的最新儲存庫、必須通過的測試、具備權限的工具、脈絡預算，以及可寫入耐久狀態的位置。

哪些東西無法長久維持#

模型進步時的 Harness 縮減呈現了負面的界線。早期的 Claude Code 需要強力提示才會使用待辦清單；後來的模型會自發使用，因此提示輔助逐漸淡出，但這項工具仍保留，讓使用者看見進度。Boris Cherny 所說「一年後每年只寫 100 行程式碼」雖然言過其實，但大方向有根據：當模型原生就能處理某種行為時，提示段落、備援邏輯和安全提醒便會被刪除。

迴圈也有相同的模式。/loop 這種原語一開始可能是 harness 功能，之後則可能內化為模型行為：Opus 4.7 注意到資料有變動後，即使沒有人明確交代，也會主動提出定期回報。耐久的部分不是「教模型執行迴圈」，而是讓迴圈實用且受限的基礎：工作區、排程、輸出位置、權限和驗證。

因此，可拋棄的 harness 層包括：

能力注入：教導通用行為的提示，而下一代模型可能會自行內化這些行為。
過度明確的工作流程：對更強的代理程式而言，「目標＋工具」就已足夠，僵化的狀態轉移便不再必要。
一律載入的說明：龐大的 CLAUDE.md / AGENTS.md 內容會在工作開始前耗掉脈絡視窗智慧區的空間。
假裝是執行機制的建議性規則：應該改由 hooks、測試、linters、schemas 或權限邊界落實的提醒。

耐久層 1：儲存庫本地的事實來源#

Agent Harness Engineering 與程式碼作為事實來源都指向同一項不變原則：代理程式只能可靠地使用它能讀取、且位於儲存庫或檔案系統中的內容。Slack 討論串、過時的 Google Docs，以及未記錄的架構記憶都不是 harness；它們是缺失的輸入。

OpenAI 的 Codex harness 將 AGENTS.md 視為目錄，而不是百科全書。Fiona Fung 的 AI 原生組織規則更嚴格：程式碼變動迅速時，外部文件會逐漸失效，因此規格和 skills 必須簽入程式碼庫。這項工作具有耐久價值，因為模型進步會提高程式碼產出速度，讓程式碼庫以外的文件更快過時，而不是更慢。

即使模型變得聰明得多，以下工作仍有價值：

將專案脈絡維持精簡、可版本控管且放在本地。
將規格、skills、工作流程規則和架構決策存放在可隨差異更新的地方。
讓 Claude 能從程式碼庫中學會如何工作，而不是依賴同事重述隱性脈絡。
採用漸進式揭露：頂層脈絡指向更深入的檔案；需要時再載入巢狀脈絡。

更聰明的模型能從程式碼推斷更多事情，但無法推斷從未記錄的當前決策。

耐久層 2：機械式驗證#

最有力的耐久性主張是驗證。模型進步時的 Harness 縮減明確區分了逐漸縮減的提示鷹架與不可或缺的機械式驗證。Claude Code 最佳實務則將其化為實際做法：提供測試、截圖、預期輸出、linter 指令和錯誤訊息給 Claude，否則人類就會成為唯一的回饋迴路。

Agent Harness Engineering提出一般原則：執行不變條件，而非限定實作方式。耐久的 harness 工作會定義模型必須遵守的邊界，並允許模型在邊界內變換實作方式。文中介紹的頁面包含以下例子：

JSON 功能清單：代理程式只有在驗證通過後，才能將 passes: false 改為 true。
結構式 linters：強制執行相依方向、命名、記錄方式和檔案大小限制。
用於確定性動作的 hooks，因為 CLAUDE.md 只能提出要求，無法強制執行。
對照已提交規格的規格偏移檢查。
使用全新脈絡的審查工作階段，而不是要求疲憊的實作者工作階段自我審查。

這不是弱模型的拐杖，而是與現實的契約。更好的模型會降低驗證抓出錯誤的頻率，但不會讓驗證變得過時。

耐久層 3：脈絡視窗的經濟效益#

只要底層注意力／記憶架構沒有改變，脈絡視窗智慧區就是耐久的限制。維基上的證據並不是「長脈絡毫無用處」，而是更精確地指出：長脈絡可以檢索資訊，但工作階段跨過智慧區門檻後，推理能力會退化。因此，脈絡預算是 harness 工作，不是提示裝飾。

耐久的脈絡管理工作包括：

讓一律載入的檔案保持精簡。
使用 skills／隨需載入的文件，而不是把每條規則都塞進 system prompt。
如果能從書面紀錄恢復狀態，就在不相關的任務之間清除脈絡。
將廣泛調查交給子代理程式，只帶回摘要。
將工作切成垂直切片和迴圈，讓每個工作階段都能從乾淨狀態開始。
在乾淨的脈絡中審查。
透過狀態列或同等方式呈現 token 用量。

模型進步或許能讓較差的區域沒那麼差，但也會增加輸出量和代理程式自主性。限制每個工作階段必須推理的內容，仍然不可或缺。

耐久層 4：隔離、權限與部署邊界#

耐久的安全邊界不是「模型承諾不做某件事」，而是決定哪些事能發生的環境。Hermes Agent對此有明確說明：使用容器後端時，會略過危險命令檢查，因為容器本身被視為安全邊界。這會將負擔從逐一命令的核准提示，轉移到映像檔管理和沙箱品質。

在 Agent Harness Engineering、Claude Code 最佳實務和 Hermes Agent中，穩定不變的工作包括：

依使用者或議題隔離工作區。
使用容器、VM 或作業系統層級的沙箱。
針對多人部署設定允許清單／配對授權。
限定工具和憑證的範圍。
使用權限模式和分類器，在執行前落實邊界。
管理常駐代理程式的 daemon 生命週期。
透過追蹤器與檔案系統狀態，在重新啟動後恢復工作。

模型進步時，建議性的權限文字應會減少；限制影響範圍的邊界需求卻不會消失。

耐久層 5：工具契約與編排基礎#

用提示引導工具派送的做法可能逐漸縮減，但工具契約仍然重要。模型可以更擅長選用 MCP、shell、browser 或子代理程式，但這些動作仍需要 API、憑證、schemas、沙箱和結果介面。

因此，耐久的編排工作著重於基礎，而不是編排步驟：

穩定的非互動式進入點（claude -p、Hermes CLI、Codex App Server 風格的協定）。
用於排程或團隊規模工作的 daemon 優先執行環境。
依任務或使用者區隔租用範圍。
不需要編排器資料庫時，使用以檔案系統為基礎的狀態。
透過 cron 或議題追蹤器派送工作，並為全新工作階段提供完整脈絡。
使用包裝憑證的工具，讓子代理程式能執行動作而不接觸密鑰。

Agent Harness Engineering中的 Symphony，從僵化狀態機節點轉向「目標＋工具」，是很清楚的例子。脆弱的狀態機會縮減；追蹤器、工作區生命週期、重試／退避、停滯偵測和協調處理則會保留下來。

耐久層 6：人類決策介面#

在 Agent Harness Engineering中，人類的角色不是輸入更多程式碼，而是排定工作優先順序、將回饋轉化為驗收條件、設計回饋迴路、驗證成果，並找出缺少的工具或防護措施。更好的模型不會消除這道邊界，而是讓更多工作經由它處理。

耐久的 harness 工作也與程式碼作為事實來源相交：人類的決策必須成為儲存庫本地的產物，而不是聊天中的直覺。否則，每個全新的工作階段都得重新推導架構，並累積代理程式債務。

耐久、面向人類的工作包括：

代理程式能夠測試的驗收條件。
簽入儲存庫的規格。
切分待辦清單，讓每個任務都能獨立驗證。
呈現差異、截圖、失敗測試和規格偏移的審查介面。
精簡管理：在模型啟動時檢視提示／脈絡，刪除不再值得耗用 token 的內容。

人類不應出於懷舊而保留舊的 harness。人類應保留那些能讓更強模型以更高吞吐量安全運作的邊界產物。

實用測試#

針對任何 harness 元件，問一個問題：

如果下一代模型變得聰明得多，這項元件會變得不必要，還是會因代理程式現在能更快造成更大損害而變得更重要？

可能會縮減的項目：

提醒模型進行一般規劃的提示。
強制使用工具的提示。
僵化的逐步編排。
重複的安全說明文字。
大量一律載入、說明程式碼中已可見內容的文件。

可能耐久的項目：

測試、linters、schemas、hooks 和規格偏移檢查。
儲存庫版本控管的脈絡檔案和 skills。
工作區隔離和憑證邊界。
token／脈絡用量核算。
子代理程式與全新脈絡審查模式。
工具協定和 daemon 生命週期。
驗收條件和人類審查介面。

結語#

耐久的代理程式 harness 工作，是將模型能力轉化為受限、可檢視、可在現實世界中重複產生的效果。提示鷹架是會貶值的資產；每次啟動模型時都應重新檢視。邊界設計不會貶值。模型越強，就越需要讓狀態、驗證、工具、權限和人類決策存在於模型可讀取、系統可強制執行的結構中。