Day 17｜為什麼需要 Harness Engineering

昨天已經分享完工具迴圈，現在該來檢視一個問題，如果 agent 在某一步犯了錯，呼叫錯工具、用錯參數、格式寫歪了，通常能做的就是回頭改 prompt、換個說法再試一次。這次也許矯正過來了，但下一次遇到類似的情況，它還是可能用一模一樣的方式再犯。今天要談的，就是怎麼跳出這個「一犯再犯、一直重試」的迴圈。

Prompt / Context Engineering 有一個共同的天花板

回頭看前面分享的內容：Part 2 的 Prompt Engineering，是靠語言把話講清楚；Part 3 的 Context Engineering（Write／Select／Compress／Isolate），是管理模型看得到哪些資訊。這兩者的本質都是機率性的，把話講得更清楚、把資訊餵得更精準，能讓模型「這一次」比較容易做對，但沒有辦法從機制上保證它不會再犯。同一個 prompt，換一個情境、換一次抽樣結果，模型還是有可能重蹈覆轍。

Harness Engineering：把環境改造到錯誤不可能再發生

這個概念是 Mitchell Hashimoto（HashiCorp 創辦人、Terraform 的創造者）在 2026 年 2 月發表的一篇文章〈My AI Adoption Journey〉裡明確提出的。他描述自己在跟 AI agent 協作時養成的一個習慣：

每次發現 agent 犯了錯，就花時間工程化一個解法，讓它不會再用同樣的方式犯這個錯。

他舉了自己維護的 Ghostty 專案為例，做法很直接：agent 重複執行錯誤的指令、找錯 API，他就更新專案裡的指令檔案（AGENTS.md），把這個壞行為對應的規則寫進去。他提到，這份檔案裡幾乎每一行規則，背後都對應著一次真實觀察到的壞行為，而這個做法幾乎完全解決了那些重複發生的問題。

這跟 Prompt Engineering 的差別在於：Prompt Engineering 讓模型「這次」更容易做對；Harness Engineering 讓這個錯「以後」不可能再用同樣的方式發生。 一個是機率上的優化，一個是結構上的防堵。

三層定位：Prompt、Context、Harness

到這裡，這個系列前面的三個概念可以放進同一張圖裡看：

• Prompt Engineering：一次呼叫內，怎麼把話講清楚
• Context Engineering：一次呼叫內，讓模型看到哪些資訊
• Harness Engineering：從系統設計的層次，讓某一類錯誤變得結構上不可能發生

前兩者處理的是「一次」，Harness Engineering 處理的是「以後每一次」。這也是為什麼昨天那個工具呼叫迴圈只是起點，而不是終點，迴圈能動，只代表機制存在，不代表這個機制被工程化到足夠可靠。

小結

今天的重點是建立一個判斷基準：如果一個修法只是讓模型「這次」比較可能做對，那還是 Prompt/Context Engineering 的範疇；如果這個修法讓某一類錯誤從此結構上不可能再發生，才算真正踏進 Harness Engineering。

明天要把這個抽象的「改造環境」拆開來看——具體來說，可以動手改造的是哪些東西？