![[代理程式設計 #1] 什麼是 Harness Engineering？Prompt 之後的下一步 封面圖](/assets/images/posts/e5b7d384-3107-41fb-a62e-34369bc15f27/harness-engineering-1.jpg)
使用相同模型，團隊之間的產出品質卻不同。一邊能讓 AI 完成整套重構，另一邊連簡單的修改都得由人員全部重寫。
差異不在 Prompt 文字，而在包覆模型的執行環境，也就是 Harness。
用一句話說，Harness Engineering 就是設計整個迴圈，讓模型使用工具、驗證結果並持續工作。Prompt Engineering 是「如何好好溝通」，Harness Engineering 則是「如何打造一個能把工作做好工作場所」。
本文將整理 Harness 的確切定義、組成要素，以及判斷優良 Harness 的標準。
先從重點摘要開始。
- Harness 是包覆模型的執行迴圈。組成要素包括工具、權限、情境管理與回饋。
- 代理程式的效能取決於模型智慧 × Harness 品質。
- 優良 Harness 的核心，是讓模型能自行確認結果的回饋迴圈。
- Claude Code、Cursor 等程式碼代理程式的本質，就是 Harness。
Harness 究竟是什麼
Harness 原本指馬匹使用的馬具。它不會提升馬本身的力量，而是將力量轉換成拉車等有用的工作。
測試 Harness 這個術語也源自相同脈絡。
LLM Harness 也是如此。它不改變模型（智慧）本身，而是指包覆模型、讓智慧連結到實際工作的所有軟體。
具體來說，包括以下內容。
- 工具層：模型可呼叫的函式，例如讀寫檔案、執行 Shell、搜尋。
- 權限層：關於要詢問並執行哪些操作，以及哪些操作可自動核准的政策。
- 情境層：要讓模型看到什麼、隱藏什麼，以及何時摘要。
- 迴圈層：接收工具結果並銜接至下一個動作的重複結構與結束條件。
雖然我們稱 Claude Code 或 Cursor 為「AI 程式碼工具」，但模型本身是 API 背後的同一個模型。產品的本質是 Harness。
效能 = 模型 × Harness
即使使用相同模型，基準測試分數大幅分歧的案例已很常見。從代理程式基準測試排行榜可看到，即使是相同模型，成功率也會因 Harness 而相差數十個百分點。
原因很簡單。代理程式工作是由數十次工具呼叫串成的鏈，而 Harness 會介入每一個步驟。
| Harness 不佳時 | Harness 良好時 |
|---|---|
| 將完整工具結果倒入情境 | 只摘要並傳遞必要部分 |
| 即使失敗也重複相同嘗試 | 將錯誤訊息作為下一次嘗試的輸入 |
| 依模型的宣稱判定工作完成 | 以測試與建置驗證，通過後才結束 |
模型會以機率方式犯錯。Harness 的作用不是消除錯誤，而是讓錯誤在驗證階段被攔截，並由模型自行修正。
優良 Harness 的三個條件
從實務角度來看，區分 Harness 品質的條件可歸納為三項。
第一，可驗證的回饋迴圈。模型修改程式碼後，必須執行測試並顯示結果。
就像人不會相信未經編譯的程式碼一樣，沒有回饋的代理程式只會累積自信。測試完善的程式碼庫最能發揮導入代理程式效益，原因正在於此。
第二，情境預算管理。情境視窗有限，但工具結果會無止境地湧入。
截短長輸出、摘要舊內容，以及將探索工作隔離到子代理程式，都是 Harness 的責任。
第三，安全的失敗路徑。必須透過權限政策與沙盒定義「即使出錯也能復原的範圍」。
例如自動核准可復原的操作，只向人員詢問具破壞性的操作。
與 Prompt Engineering 的關係
這不是說 Prompt Engineering 已經失去用途，只是所處的層次不同。
Prompt 最佳化單次請求；Harness 最佳化數十次請求接續而成的迴圈。撰寫系統 Prompt 會成為 Harness 設計的子集。
關注重心已從「要說什麼」轉向「要提供什麼環境」。模型越好，這種趨勢越明顯。因為指示可以縮短，但工具與驗證迴圈的價值反而會提高。
總結
如果代理程式的產出不如預期，請先檢查 Harness，再調整 Prompt。模型是否有確認結果的手段？情境是否塞滿雜物？失敗是否會銜接到下一次嘗試？
下一篇文章將深入探討情境層，也就是情境工程。