大多數人都在錯誤的層級試圖修復 AI Agent。
當 Agent 失敗時,他們會重寫提示詞。如果再次失敗,他們就加入更多指令、更換模型、擴大上下文視窗,或串接另一個工具。
然後,同樣的問題又回來了。
Agent 忘記了某個重要決策。它用錯了工具。它搞丟了三步之前發生的事。它沒檢查結果就宣稱任務完成。它不斷重試同一個失敗的操作,直到預算燒光。
問題不一定出在模型。
問題出在它周圍的環境。
這個環境就是 harness(執行框架)。
Harness Engineering(框架工程)是一種實踐:圍繞模型建構一套系統,由它來決定模型能看到什麼、能做什麼、記住什麼、怎樣才算成功,以及失敗時該如何處理。
更好的提示詞只能改善單次回應。
更好的 harness 能改善每一次執行。
追蹤我的 Substack,獲取更多關於 AI Agent、自動化與生產系統的實務解析:
1. 模型不等於 Agent
模型可以推理、生成、比較和選擇。
但這並不能讓它成為一個可靠的 Agent。
真正的 Agent 還需要找到正確的上下文、使用工具、保存狀態、遵守權限、驗證自己的工作,並在環境表現不如預期時進行恢復。
模型只是推理引擎。
而 harness 是把這份推理轉化為實際執行的一切。
1使用者請求2 |3 v4+-----------------------------+5| HARNESS |6| |7| 合約 上下文 |8| 工具 狀態 |9| 策略 驗證 |10| 追蹤紀錄 恢復機制 |11+-----------------------------+12 |13 v14 模型15 |16 v17 真實環境
把同一個模型放進聊天框裡,它只會回答問題。

把它放進一個具備終端機存取權限、測試、瀏覽器工具、專案記憶、受控權限與審查流程的儲存庫中,它就能完成真正的工作。
模型沒有改變。
改變的是 harness。
2. 把每個請求都變成一份合約
自然語言很靈活。
但自主執行不該如此。
像這樣的請求:
改善新手引導流程。
當有人類坐在模型旁邊時,這樣說沒問題。
但作為生產環境的指令,這非常糟糕。
在 Agent 採取行動前,先把請求轉化為有邊界的任務合約。

1objective: 降低新手引導流失率23inputs:4 - 產品簡介5 - 分析數據6 - 程式碼儲存庫78constraints:9 - 保留身份驗證機制10 - 不要更改資料庫結構描述11 - 維持目前的行動裝置行為1213deliverable:14 - 可審查的 pull request1516done_when:17 - 測試通過18 - 分析事件正確觸發19 - 桌面版流程通過審查20 - 行動版流程通過審查2122approval_required:23 - 正式環境部署
關鍵在於 done_when(完成條件)。
沒有它,Agent 可能會去解決一個稍微簡單一點的版本,然後依然自信地宣稱任務已完成。
有了它,「完成」才變得可衡量。
Agent 不該問:
我接下來該做什麼?
它應該問:
哪個動作能讓當前環境更接近合約約定的結果?
這是一個強大得多的循環。
3. 給 Agent 一張地圖,而不是一個巨大的上下文視窗
面對 Agent 犯錯,常見的反應是給模型更多上下文。
更多文件。
更多對話歷史。
更多檔案。
更多工具輸出。
最後,Agent 收到了所有東西,卻理解得更少。
上下文不是儲存空間。
它是注意力預算。

別在每次執行時都把整個專案倒進去,而是給 Agent 一張小地圖,告訴它有用的資訊在哪裡。
1專案地圖23產品規則 -> docs/product/4架構設計 -> docs/architecture.md5前端 -> apps/web/6後端 -> services/api/7測試 -> tests/8指令 -> docs/commands.md9安全性 -> docs/security.md
然後只在必要時才展開。
1任務2 |3 v4專案地圖5 |6 v7相關系統8 |9 v10確切檔案11 |12 v13本地指令
原始文獻將此稱為漸進式揭露(progressive disclosure):harness 應該因為任務需要才載入更多資訊,而不是單純因為這些資訊存在就載入。
目標不是最大化上下文。
目標是最大化有用的訊號。
4. 在模型與工具之間設置一道閘門
擁有二十個工具的模型,能力不會自動提升二十倍。
它可能只是多了二十種失敗的方式。
每個工具都應該有一份合約。
1工具:edit_file23輸入4path5patch67前置條件8path 存在9path 位於工作區內1011成功12patch 已套用13回傳 diff1415失敗16結構化錯誤17不允許部分覆寫1819風險20可逆
接著,執行路徑會變成:
1模型提出方案2 |3 v4閘門進行驗證5 |6 v7策略授權許可8 |9 v10工具執行操作11 |12 v13HARNESS 記錄結果
模型決定它想執行什麼動作。
harness 決定該動作是否有效、被允許且安全。

當工具可以發送訊息、修改正式環境、花錢或刪除資料時,這個區別至關重要。
一個好的工具閘門還能加入逾時機制、驗證參數、限制檔案路徑、標準化錯誤,並讓重試變得安全。
好的工具能減少模型必須猜測的事情。
5. 把記憶移出對話之外
對話不該成為系統的正式紀錄。
長時間運行的 Agent 最終會撞上上下文上限、崩潰、重新啟動,或把工作交接給另一個 session。
如果每個重要決策都只存在於對話紀錄中,這個工作流程就會非常脆弱。
請另外儲存持久化狀態。

1{2 "task_id": "feature_042",3 "status": "verifying",4 "current_step": "mobile_check",56 "completed": [7 "implementation",8 "unit_tests",9 "desktop_check"10 ],1112 "decisions": [13 "reuse existing export endpoint",14 "preserve current date format"15 ],1617 "artifacts": [18 "export.csv",19 "desktop-after.png"20 ],2122 "open_risks": [23 "mobile toolbar may overflow"24 ],2526 "next_action": "render mobile viewport"27}
一個實用的系統會把記憶分成四類:
1事實2穩定的知識34決策5選了什麼、為什麼這樣選67狀態8目前這次執行走到哪了910教訓11哪些失敗應該影響未來的執行
下一個 Agent session 應該繼承工作的狀態,而不是一段關於前次對話的壓縮故事。
6. 讓證據成為完成的門檻
Agent 說「完成了」,並不代表工作真的完成了。

那只是另一段模型輸出。
harness 需要可觀察的證據。
1主張 證據23「bug 已修復」 原本失敗的測試現在通過了45「頁面正常運作」 瀏覽器流程跑完了67「資料正確」 數值與來源相符89「遷移是安全的」 模擬執行 + 回滾測試通過1011「任務完成」 所有驗收檢查都通過
優先使用確定性檢查。
1語法2 |3 v4型別5 |6 v7針對性測試8 |9 v10整合測試11 |12 v13視覺 / 語意審查14 |15 v16人工核准
編譯器、測試、結構描述或資料庫查詢就能證明的事情,不要叫另一個模型來回答。
用模型做判斷。
用確定性系統確認事實。
模型產出成果。
環境產生關於該成果的證據。
harness 決定證據是否充分。
7. 把建造者與驗證者分開
自我審查還有另一個問題。
製造錯誤的那個 Agent,往往會把同樣的假設帶進審查過程。

更穩健的架構會把執行者與驗證者分開。
1建造者2 |3 v4建立候選方案5 |6 v7驗證者8 |9 +-- 檢查合約10 +-- 搜尋遺漏的案例11 +-- 測試未經支持的主張12 +-- 嘗試破壞結果13 |14 +------ 通過 ------> 接受15 |16 +------ 失敗 ------> 回傳證據
驗證者不該問:
這看起來好嗎?
它應該問:
什麼情況會讓這個結果無法被接受?
這會把審查從「尋求認同」變成「嘗試推翻」。
原始文獻明確建議,要為驗證環節設定專屬的拒絕標準,並給予足夠的獨立性,去挑戰產出第一個結果時所依據的假設。
8. 把權限移出模型之外
有些規則永遠不該依賴模型去記住。
1未經核准絕不發布2絕不洩露機密3絕不超出支出上限4絕不在工作區外寫入5除非真的跑過測試,否則絕不聲稱測試通過
這些不是提示詞裡的建議。

它們是政策。
一個簡單的權限階梯:
1低風險23讀取4搜尋5檢查67-> 自動放行89可逆操作1011編輯工作區12執行測試13建立草稿1415-> 自動放行 + 記錄追蹤1617外部影響1819發送20部署21購買2223-> 需要核准2425不可逆 / 敏感操作2627刪除資料28輪替憑證29全域發布3031-> 硬性阻擋或禁止
後果越嚴重,控制就要越嚴格。
模型可以建議動作。
harness 負責授權。
工具負責執行。
自主性不是缺乏控制。
而是在強制邊界內的自由。
9. 停止盲目重試
最糟糕的恢復策略之一是:
有東西失敗了。再試一次。
如果什麼都沒改變,系統只是在花錢重現同一個錯誤。
失敗應該先被分類。

1工具逾時2-> 採用退避機制重試34參數無效5-> 修復工具呼叫67缺少上下文8-> 取得缺失的來源910測試失敗11-> 檢查失敗的行為1213權限遭拒14-> 請求核准1516需求互相衝突17-> 向上回報1819重複失敗且狀況未變20-> 停止
一個實用的 Agent 循環長這樣:
1觀察2 |3 v4決策5 |6 v7行動8 |9 v10衡量11 |12 +---- 接受13 |14 +---- 修復15 |16 +---- 上報17 |18 +---- 停止
每個循環都應該對嘗試次數、時間、花費和破壞範圍設定上限。
可靠的 Agent 需要知道如何繼續。
它也需要知道什麼時候再試一次已經不值得了。
10. 把重複出現的指令變成基礎設施
假設提示詞裡寫著:
一定要執行格式化工具。
如果格式化工具會自動執行,這條規則會更有力。
假設指令寫著:
UI 程式碼不得直接存取資料庫。
把它做成一個架構測試,一旦違反規則就報錯,會更有力。
演進過程長這樣:
1說明2 |3 v4檢查清單5 |6 v7模板8 |9 v10自動化檢查11 |12 v13強制執行的政策
提示詞應該解釋判斷邏輯。
harness 應該強制執行不變量。
每一個反覆出現的錯誤,都應該在這個階梯上往下推進一步。
最終,模型不再需要記住這個教訓。
環境會替模型記住它。
11. 記錄執行過程
完美的最終成果,可能掩蓋了一條糟糕的執行路徑。
也許 Agent 存取了錯誤的來源。
也許它忽略了失敗的指令。
也許它把某個外部動作重複執行了兩次。
也許它花了預期十倍的預算。
也許它用錯誤的理由得到了正確的答案。
請記錄足夠的資訊,以便重建發生了什麼事。
109:14 建立任務合約209:15 載入 architecture.md309:17 編輯 checkout.ts409:18 針對性測試失敗509:21 修復實作609:22 針對性測試通過709:24 整合測試通過809:25 部署受阻:需要核准
有用的追蹤紀錄包括:上下文來源、工具呼叫、狀態變更、驗證結果、重試原因、核准決策、成本與延遲。
重點不是為了好玩而收集日誌。
重點是把失敗侷限在局部。
如果第 18 步壞了,你應該只需要修復第 18 步。
你不該需要重播整次執行。
12. 給每次執行一張收據
別逼人類去審查一段四十則訊息的對話紀錄。
把結果彙整成一張簡短的收據。
1目標23修復優惠券重複套用的問題。45已變更67結帳驗證8迴歸測試910已驗證1112lint 通過13單元測試通過14整合測試通過1516未驗證1718正式環境付款服務商1920風險2122舊版行動用戶端無法使用2324需要核准2526部署到 staging
這不是模型聲稱發生之事的摘要。
這是 harness 能證明確實發生之事的摘要。
這個區別讓收據在審查、交接與未來的 Agent session 中變得實用。
13. 讓每次失敗都能改進 Harness
多數團隊只會修復失敗的輸出。
更好的做法是修復那個允許失敗發生的系統。
1缺少上下文2-> 改善專案地圖34用錯工具5-> 改善路由或工具合約67輸出品質差8-> 加入驗證器910無限循環11-> 加入重試上限1213不安全的動作14-> 加入權限閘門1516決策遺失17-> 持久化狀態1819未知錯誤20-> 改善追蹤紀錄
這就是 harness 工程開始產生複利效應的地方。
修復一次輸出,只能幫助一次執行。
修復一次 harness,能改善之後的每一次執行。
最優秀的 Agent 系統之所以越來越可靠,是因為錯誤會留下基礎設施。
14. 從最小可用的 Harness 開始
你不需要一個龐大的調度平台才能起步。
分層建構。
1第 0 層23提示詞4模型56第 1 層78任務合約9專案地圖10工具1112第 2 層1314結構化狀態15驗證16有邊界的循環1718第 3 層1920權限21追蹤紀錄22恢復機制23人工閘門
一個簡短的研究任務,可能只需要提示詞和一次審查。
一個長達六小時、具備檔案存取、網路存取與部署能力的程式開發任務,就需要多得多的東西。
當失敗面大到值得時,再加入複雜度。
而不是因為 Agent 架構看起來很酷。
Harness 工程檢查清單
在賦予 Agent 實質的自主權之前,先問問:
1[ ] 成功的定義是否在執行前就已確立?23[ ] Agent 能否在不載入所有內容的情況下4 找到正確的上下文?56[ ] 每個工具是否都有明確的目的、7 結構描述與失敗狀態?89[ ] 重要決策是否儲存在10 對話之外?1112[ ] 完成任務是否需要證據?1314[ ] 高風險動作是否受到政策保護?1516[ ] 每個循環是否有重試上限?1718[ ] 執行中斷後能否恢復?1920[ ] 你能否重建每個重要動作?2122[ ] 失敗是否能改進某項規則、工具、23 測試、地圖或權限?2425[ ] 最終的變更能否回滾?
如果有好幾個答案都是「否」,那麼換一個更強的模型也不會自動讓 Agent 變得可靠。
它可能只會讓失敗來得更快、更昂貴。
真正的轉變
提示詞工程問的是:
我該告訴模型什麼?
上下文工程問的是:
模型現在應該知道什麼?
Harness 工程問的是:
什麼樣的系統能讓模型採取行動、驗證工作成果、從失敗中恢復並安全運作?
1提示詞2-> 指令34上下文5-> 工作視圖67HARNESS8-> 運行環境910循環11-> 局部修正1213圖譜14-> 協調合作
模型會不斷改變。
持久的優勢存在於它們周圍。
你的合約會越來越好。
你的工具會越來越好。
你的測試會越來越好。
你的狀態會越來越乾淨。
你的權限會越來越安全。
你的恢復邏輯會越來越聰明。
你的失敗會轉化為基礎設施。
這就是強大的模型蛻變為可靠 Agent 的方式。
這就是 Harness Engineering。
如果你看到了這裡
把這篇指南加入書籤。
在 X 上追蹤我: x.com/0xjmori
訂閱我的 Substack: substack.com/@lunarresearcher
把這篇文章分享給那些還在試圖用更長的提示詞來修復每個 Agent 錯誤的人。



![[致歉] 我不再推薦自由職業者追求獨立。](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1790615558140_ndvona_HTQ9s6laYAAX4J7.jpg)

