Harness 工程：迴圈外的執行環境

一個 agent 本質上就是一個迴圈：模型觀察自己的脈絡，決定要做什麼動作，透過工具執行，再觀察結果，然後做下一個決定。大部分注意力都落在這個迴圈上——框住它的提示詞、跑它的模型。但對一個正式環境的 agent 來說，迴圈只是看得見的那一半。另一半是 harness：承載這個迴圈的執行環境，負責供應工具、約束行為、記錄一切，並在出錯時把它救回來。

業界的詞彙也正在追上這個現實。過去大家談的是 prompt engineering（提示詞工程），現在比較資深的人開始談 harness engineering——把工夫下在迴圈外的執行環境，而不只是迴圈裡的那些字。一個聰明的提示詞配上一個糟糕的 harness，做出來的是 demo；一個普通的提示詞配上一個紮實的 harness，做出來的是一套你週一敢上線、週五還信得過的系統。

在我們實際進駐的經驗裡，這個模式一再出現：團隊花好幾週調模型、調提示詞，卻只花一個下午處理 harness。等到 agent 真的上了正式環境，出問題的幾乎從來不是提示詞，而是逾時、重複的副作用、失控的工具迴圈、看不到的錯誤，以及一條從沒劃清楚的權限界線。harness 才是讓 agent 在正式環境可靠的大部分原因，卻一直是整個技術堆疊裡投資最少的一塊。

本文把 harness 當成第一級的工程產物來看待，逐一說明它的組成——工具層、執行沙箱、脈絡與狀態管理、調節器、可觀測性，以及復原機制——以及把這些組件綁在一起的可靠度特性。最後，附上一套參考架構，讓你拿來對照自己的 agent。