很多人第一次把 Agent 跑起來時，直覺都會想：是不是 prompt 還不夠好？於是開始補規則、加限制、改語氣、塞更多範例。可是真正讓系統變穩的，往往不是把 prompt 寫到更像考試答案，而是讓 Agent 在執行過程中「被看著做事」。
這就是 Harness Engineering 的重點。它關心的不是單次輸出，而是 Agent 從開始做、做到一半、做到結束的整個流程，有沒有持續朝目標前進、能不能驗證、出了錯能不能修正。換句話說，prompt 影響的是「這次怎麼答」，harness 管的是「整段執行怎麼不跑偏」。
Harness Engineering 是什麼
Harness Engineering 可以理解成：在 Agent 執行迴圈裡加入約束、檢查與動態修正的工程。常見說法是 Agent = Model + Harness。模型負責生成，而 harness 則包住模型外圍的 system prompt、工具、編排、hooks、judge 與外層流程，讓 Agent 不只是會講，而是會做、會驗證、會改。
它的核心不是「多寫一點規則」，而是建立一套在執行期間持續提供回饋的環境。這些回饋可以來自測試、linter、type checker、靜態分析，也可以來自 LLM judge、review skill、stop hook，甚至是外層 loop 的重新排程。目標很單純：讓 Agent 持續、正確地動作。
為什麼它比改 prompt 更關鍵
Prompt Engineering 主要處理的是單次回答：怎麼讓模型這一次答得更好。Context Engineering 則處理 context window 裡該放什麼資訊。但只靠這兩者，常見問題還是會發生：模型自信地輸出、看起來完成、實際上卻沒有驗證。
Harness Engineering 之所以更關鍵，是因為它把「驗證」變成工程流程，而不是靠模型自覺。真正可靠的做法通常是：
- generate：先產生答案、程式碼、SQL、報告或其他產物。
- verify：用測試、規則、judge 或外部環境檢查。
- fix：把回饋送回去，讓 Agent 修正。
也就是說，重點不是相信模型會自動檢查自己，而是讓 verify 一定會發生。這一點，通常比把 prompt 再修飾一次更能決定系統品質。
Guides 與 Sensors：一個負責帶路，一個負責把關
Harness 常被拆成兩個面向：Guides 與 Sensors。
Guides：提高一次做對的機率
Guides 是行動前的引導，例如 system prompt、AGENTS.md、skills、bootstrap instructions、how-to 文件、架構規則、程式產生的 metadata。它們要說清楚三件事：
- 什麼是好的結果。
- 驗證流程是什麼。
- 哪些工具與限制必須遵守。
這類內容能讓 Agent 一開始就走對方向，但它仍然只是引導，不保證一定照做。
Sensors：把驗證變成自動執行
Sensors 則是用程式把檢查做實，不靠模型自覺。例如 tool call 內檢查輸入與結果、在 request 之間注入新事件、用 stop hook 擋下未完成輸出，或讓外層 loop 重新啟動乾淨 context。它們的價值在於：即使模型想偷跑，也會被攔下來。
好的 harness 不是只靠 Guides，也不是只靠 Sensors，而是兩者一起用：前者讓 Agent 更容易做對，後者讓出錯時真的能被抓到。
回饋要放在哪裡，差很多
Harness 的回饋可以放在四個時機點，越內層越快、越便宜，越外層越能處理大任務。
- 工具執行內：每次 tool call 就檢查，修正粒度最小、成本最低。
- request 之間注入：在下一次 model request 前插入訊息，調整當前方向。
- 單輪結束：用 Goal、Outcome 或 Stop Hook 驗收整輪產出。
- 外層 Loop：跨 session 管理排程、重跑、平行任務與外部狀態。
實務上最重要的原則是：能在工具層擋下的錯誤，不要拖到最後才處理；能在單輪內驗證的，就不要只靠外層暴力重跑。越早發現錯誤，代價越小。
Harness 也會過期，模型變強後要重新看
另一個常被忽略的點是：Harness 不是一次設好就永久有效。Model-Harness-Fit 指的是模型與 harness 之間有配適關係。換不同模型，同一套 harness 的效果可能差很多；模型升級後，原本用來補強弱點的 prompt、workflow、judge 或工具限制，可能反而變成拖累。
所以，過度冗長的 prompt、手工規則、繁瑣流程、額外 judge、context 膨脹的指南，都需要定期回顧。真正不會過期的不是某個 workaround，而是你怎麼定義「好」、怎麼驗證「好」、怎麼設計 eval 與停止條件。
結語
如果把 Agent 比作一個人，那 prompt 像是交代任務，harness 則像是工作現場的流程、工具、檢查表與主管回饋。前者決定他「先怎麼想」，後者決定他「能不能真的把事做好」。
所以，當你發現 prompt 已經越改越長，卻還是常出錯，不妨換個問題：不是要怎麼再補一句，而是要在哪個環節讓系統看得見、擋得住、改得回來。