YouMind
登入

Harness Engineering:如何打造真正可用的 AI Agents

@0xjmori
英語2026年9月27日
328K
196
24
17
638

TL;DR

本文介紹了「Harness Engineering」,主張 AI Agents 的可靠性取決於周邊系統(合約、工具、狀態、驗證),而非僅依賴模型或提示詞。文章提供了建構穩健 Agent 基礎設施的全面指南。

大多數人都在錯誤的層級試圖修復 AI Agent。

當 Agent 失敗時,他們會重寫提示詞。如果再次失敗,他們就加入更多指令、更換模型、擴大上下文視窗,或串接另一個工具。

然後,同樣的問題又回來了。

Agent 忘記了某個重要決策。它用錯了工具。它搞丟了三步之前發生的事。它沒檢查結果就宣稱任務完成。它不斷重試同一個失敗的操作,直到預算燒光。

問題不一定出在模型。

問題出在它周圍的環境。

這個環境就是 harness(執行框架)。

Harness Engineering(框架工程)是一種實踐:圍繞模型建構一套系統,由它來決定模型能看到什麼、能做什麼、記住什麼、怎樣才算成功,以及失敗時該如何處理。

更好的提示詞只能改善單次回應。

更好的 harness 能改善每一次執行。

追蹤我的 Substack,獲取更多關於 AI Agent、自動化與生產系統的實務解析:

substack.com/@lunarresearcher

1. 模型不等於 Agent

模型可以推理、生成、比較和選擇。

但這並不能讓它成為一個可靠的 Agent。

真正的 Agent 還需要找到正確的上下文、使用工具、保存狀態、遵守權限、驗證自己的工作,並在環境表現不如預期時進行恢復。

模型只是推理引擎。

而 harness 是把這份推理轉化為實際執行的一切。

text
1使用者請求
2 |
3 v
4+-----------------------------+
5| HARNESS |
6| |
7| 合約 上下文 |
8| 工具 狀態 |
9| 策略 驗證 |
10| 追蹤紀錄 恢復機制 |
11+-----------------------------+
12 |
13 v
14 模型
15 |
16 v
17 真實環境

把同一個模型放進聊天框裡,它只會回答問題。

Mori - inline image

把它放進一個具備終端機存取權限、測試、瀏覽器工具、專案記憶、受控權限與審查流程的儲存庫中,它就能完成真正的工作。

模型沒有改變。

改變的是 harness。

2. 把每個請求都變成一份合約

自然語言很靈活。

但自主執行不該如此。

像這樣的請求:

改善新手引導流程。

當有人類坐在模型旁邊時,這樣說沒問題。

但作為生產環境的指令,這非常糟糕。

在 Agent 採取行動前,先把請求轉化為有邊界的任務合約。

Mori - inline image
yaml
1objective: 降低新手引導流失率
2
3inputs:
4 - 產品簡介
5 - 分析數據
6 - 程式碼儲存庫
7
8constraints:
9 - 保留身份驗證機制
10 - 不要更改資料庫結構描述
11 - 維持目前的行動裝置行為
12
13deliverable:
14 - 可審查的 pull request
15
16done_when:
17 - 測試通過
18 - 分析事件正確觸發
19 - 桌面版流程通過審查
20 - 行動版流程通過審查
21
22approval_required:
23 - 正式環境部署

關鍵在於 done_when(完成條件)。

沒有它,Agent 可能會去解決一個稍微簡單一點的版本,然後依然自信地宣稱任務已完成。

有了它,「完成」才變得可衡量。

Agent 不該問:

我接下來該做什麼?

它應該問:

哪個動作能讓當前環境更接近合約約定的結果?

這是一個強大得多的循環。

3. 給 Agent 一張地圖,而不是一個巨大的上下文視窗

面對 Agent 犯錯,常見的反應是給模型更多上下文。

更多文件。

更多對話歷史。

更多檔案。

更多工具輸出。

最後,Agent 收到了所有東西,卻理解得更少。

上下文不是儲存空間。

它是注意力預算。

Mori - inline image

別在每次執行時都把整個專案倒進去,而是給 Agent 一張小地圖,告訴它有用的資訊在哪裡。

text
1專案地圖
2
3產品規則 -> docs/product/
4架構設計 -> docs/architecture.md
5前端 -> apps/web/
6後端 -> services/api/
7測試 -> tests/
8指令 -> docs/commands.md
9安全性 -> docs/security.md

然後只在必要時才展開。

text
1任務
2 |
3 v
4專案地圖
5 |
6 v
7相關系統
8 |
9 v
10確切檔案
11 |
12 v
13本地指令

原始文獻將此稱為漸進式揭露(progressive disclosure):harness 應該因為任務需要才載入更多資訊,而不是單純因為這些資訊存在就載入。

目標不是最大化上下文。

目標是最大化有用的訊號。

4. 在模型與工具之間設置一道閘門

擁有二十個工具的模型,能力不會自動提升二十倍。

它可能只是多了二十種失敗的方式。

每個工具都應該有一份合約。

text
1工具:edit_file
2
3輸入
4path
5patch
6
7前置條件
8path 存在
9path 位於工作區內
10
11成功
12patch 已套用
13回傳 diff
14
15失敗
16結構化錯誤
17不允許部分覆寫
18
19風險
20可逆

接著,執行路徑會變成:

text
1模型提出方案
2 |
3 v
4閘門進行驗證
5 |
6 v
7策略授權許可
8 |
9 v
10工具執行操作
11 |
12 v
13HARNESS 記錄結果

模型決定它想執行什麼動作。

harness 決定該動作是否有效、被允許且安全。

Mori - inline image

當工具可以發送訊息、修改正式環境、花錢或刪除資料時,這個區別至關重要。

一個好的工具閘門還能加入逾時機制、驗證參數、限制檔案路徑、標準化錯誤,並讓重試變得安全。

好的工具能減少模型必須猜測的事情。

5. 把記憶移出對話之外

對話不該成為系統的正式紀錄。

長時間運行的 Agent 最終會撞上上下文上限、崩潰、重新啟動,或把工作交接給另一個 session。

如果每個重要決策都只存在於對話紀錄中,這個工作流程就會非常脆弱。

請另外儲存持久化狀態。

Mori - inline image
json
1{
2 "task_id": "feature_042",
3 "status": "verifying",
4 "current_step": "mobile_check",
5
6 "completed": [
7 "implementation",
8 "unit_tests",
9 "desktop_check"
10 ],
11
12 "decisions": [
13 "reuse existing export endpoint",
14 "preserve current date format"
15 ],
16
17 "artifacts": [
18 "export.csv",
19 "desktop-after.png"
20 ],
21
22 "open_risks": [
23 "mobile toolbar may overflow"
24 ],
25
26 "next_action": "render mobile viewport"
27}

一個實用的系統會把記憶分成四類:

text
1事實
2穩定的知識
3
4決策
5選了什麼、為什麼這樣選
6
7狀態
8目前這次執行走到哪了
9
10教訓
11哪些失敗應該影響未來的執行

下一個 Agent session 應該繼承工作的狀態,而不是一段關於前次對話的壓縮故事。

6. 讓證據成為完成的門檻

Agent 說「完成了」,並不代表工作真的完成了。

Mori - inline image

那只是另一段模型輸出。

harness 需要可觀察的證據。

text
1主張 證據
2
3「bug 已修復」 原本失敗的測試現在通過了
4
5「頁面正常運作」 瀏覽器流程跑完了
6
7「資料正確」 數值與來源相符
8
9「遷移是安全的」 模擬執行 + 回滾測試通過
10
11「任務完成」 所有驗收檢查都通過

優先使用確定性檢查。

text
1語法
2 |
3 v
4型別
5 |
6 v
7針對性測試
8 |
9 v
10整合測試
11 |
12 v
13視覺 / 語意審查
14 |
15 v
16人工核准

編譯器、測試、結構描述或資料庫查詢就能證明的事情,不要叫另一個模型來回答。

用模型做判斷。

用確定性系統確認事實。

模型產出成果。

環境產生關於該成果的證據。

harness 決定證據是否充分。

7. 把建造者與驗證者分開

自我審查還有另一個問題。

製造錯誤的那個 Agent,往往會把同樣的假設帶進審查過程。

Mori - inline image

更穩健的架構會把執行者與驗證者分開。

text
1建造者
2 |
3 v
4建立候選方案
5 |
6 v
7驗證者
8 |
9 +-- 檢查合約
10 +-- 搜尋遺漏的案例
11 +-- 測試未經支持的主張
12 +-- 嘗試破壞結果
13 |
14 +------ 通過 ------> 接受
15 |
16 +------ 失敗 ------> 回傳證據

驗證者不該問:

這看起來好嗎?

它應該問:

什麼情況會讓這個結果無法被接受?

這會把審查從「尋求認同」變成「嘗試推翻」。

原始文獻明確建議,要為驗證環節設定專屬的拒絕標準,並給予足夠的獨立性,去挑戰產出第一個結果時所依據的假設。

8. 把權限移出模型之外

有些規則永遠不該依賴模型去記住。

text
1未經核准絕不發布
2絕不洩露機密
3絕不超出支出上限
4絕不在工作區外寫入
5除非真的跑過測試,否則絕不聲稱測試通過

這些不是提示詞裡的建議。

Mori - inline image

它們是政策。

一個簡單的權限階梯:

text
1低風險
2
3讀取
4搜尋
5檢查
6
7-> 自動放行
8
9可逆操作
10
11編輯工作區
12執行測試
13建立草稿
14
15-> 自動放行 + 記錄追蹤
16
17外部影響
18
19發送
20部署
21購買
22
23-> 需要核准
24
25不可逆 / 敏感操作
26
27刪除資料
28輪替憑證
29全域發布
30
31-> 硬性阻擋或禁止

後果越嚴重,控制就要越嚴格。

模型可以建議動作。

harness 負責授權。

工具負責執行。

自主性不是缺乏控制。

而是在強制邊界內的自由。

9. 停止盲目重試

最糟糕的恢復策略之一是:

有東西失敗了。再試一次。

如果什麼都沒改變,系統只是在花錢重現同一個錯誤。

失敗應該先被分類。

Mori - inline image
text
1工具逾時
2-> 採用退避機制重試
3
4參數無效
5-> 修復工具呼叫
6
7缺少上下文
8-> 取得缺失的來源
9
10測試失敗
11-> 檢查失敗的行為
12
13權限遭拒
14-> 請求核准
15
16需求互相衝突
17-> 向上回報
18
19重複失敗且狀況未變
20-> 停止

一個實用的 Agent 循環長這樣:

text
1觀察
2 |
3 v
4決策
5 |
6 v
7行動
8 |
9 v
10衡量
11 |
12 +---- 接受
13 |
14 +---- 修復
15 |
16 +---- 上報
17 |
18 +---- 停止

每個循環都應該對嘗試次數、時間、花費和破壞範圍設定上限。

可靠的 Agent 需要知道如何繼續。

它也需要知道什麼時候再試一次已經不值得了。

10. 把重複出現的指令變成基礎設施

假設提示詞裡寫著:

一定要執行格式化工具。

如果格式化工具會自動執行,這條規則會更有力。

假設指令寫著:

UI 程式碼不得直接存取資料庫。

把它做成一個架構測試,一旦違反規則就報錯,會更有力。

演進過程長這樣:

text
1說明
2 |
3 v
4檢查清單
5 |
6 v
7模板
8 |
9 v
10自動化檢查
11 |
12 v
13強制執行的政策

提示詞應該解釋判斷邏輯。

harness 應該強制執行不變量。

每一個反覆出現的錯誤,都應該在這個階梯上往下推進一步。

最終,模型不再需要記住這個教訓。

環境會替模型記住它。

11. 記錄執行過程

完美的最終成果,可能掩蓋了一條糟糕的執行路徑。

也許 Agent 存取了錯誤的來源。

也許它忽略了失敗的指令。

也許它把某個外部動作重複執行了兩次。

也許它花了預期十倍的預算。

也許它用錯誤的理由得到了正確的答案。

請記錄足夠的資訊,以便重建發生了什麼事。

text
109:14 建立任務合約
209:15 載入 architecture.md
309:17 編輯 checkout.ts
409:18 針對性測試失敗
509:21 修復實作
609:22 針對性測試通過
709:24 整合測試通過
809:25 部署受阻:需要核准

有用的追蹤紀錄包括:上下文來源、工具呼叫、狀態變更、驗證結果、重試原因、核准決策、成本與延遲。

重點不是為了好玩而收集日誌。

重點是把失敗侷限在局部。

如果第 18 步壞了,你應該只需要修復第 18 步。

你不該需要重播整次執行。

12. 給每次執行一張收據

別逼人類去審查一段四十則訊息的對話紀錄。

把結果彙整成一張簡短的收據。

text
1目標
2
3修復優惠券重複套用的問題。
4
5已變更
6
7結帳驗證
8迴歸測試
9
10已驗證
11
12lint 通過
13單元測試通過
14整合測試通過
15
16未驗證
17
18正式環境付款服務商
19
20風險
21
22舊版行動用戶端無法使用
23
24需要核准
25
26部署到 staging

這不是模型聲稱發生之事的摘要。

這是 harness 能證明確實發生之事的摘要。

這個區別讓收據在審查、交接與未來的 Agent session 中變得實用。

13. 讓每次失敗都能改進 Harness

多數團隊只會修復失敗的輸出。

更好的做法是修復那個允許失敗發生的系統。

text
1缺少上下文
2-> 改善專案地圖
3
4用錯工具
5-> 改善路由或工具合約
6
7輸出品質差
8-> 加入驗證器
9
10無限循環
11-> 加入重試上限
12
13不安全的動作
14-> 加入權限閘門
15
16決策遺失
17-> 持久化狀態
18
19未知錯誤
20-> 改善追蹤紀錄

這就是 harness 工程開始產生複利效應的地方。

修復一次輸出,只能幫助一次執行。

修復一次 harness,能改善之後的每一次執行。

最優秀的 Agent 系統之所以越來越可靠,是因為錯誤會留下基礎設施。

14. 從最小可用的 Harness 開始

你不需要一個龐大的調度平台才能起步。

分層建構。

text
1第 0 層
2
3提示詞
4模型
5
6第 1 層
7
8任務合約
9專案地圖
10工具
11
12第 2 層
13
14結構化狀態
15驗證
16有邊界的循環
17
18第 3 層
19
20權限
21追蹤紀錄
22恢復機制
23人工閘門

一個簡短的研究任務,可能只需要提示詞和一次審查。

一個長達六小時、具備檔案存取、網路存取與部署能力的程式開發任務,就需要多得多的東西。

當失敗面大到值得時,再加入複雜度。

而不是因為 Agent 架構看起來很酷。

Harness 工程檢查清單

在賦予 Agent 實質的自主權之前,先問問:

text
1[ ] 成功的定義是否在執行前就已確立?
2
3[ ] Agent 能否在不載入所有內容的情況下
4 找到正確的上下文?
5
6[ ] 每個工具是否都有明確的目的、
7 結構描述與失敗狀態?
8
9[ ] 重要決策是否儲存在
10 對話之外?
11
12[ ] 完成任務是否需要證據?
13
14[ ] 高風險動作是否受到政策保護?
15
16[ ] 每個循環是否有重試上限?
17
18[ ] 執行中斷後能否恢復?
19
20[ ] 你能否重建每個重要動作?
21
22[ ] 失敗是否能改進某項規則、工具、
23 測試、地圖或權限?
24
25[ ] 最終的變更能否回滾?

如果有好幾個答案都是「否」,那麼換一個更強的模型也不會自動讓 Agent 變得可靠。

它可能只會讓失敗來得更快、更昂貴。

真正的轉變

提示詞工程問的是:

我該告訴模型什麼?

上下文工程問的是:

模型現在應該知道什麼?

Harness 工程問的是:

什麼樣的系統能讓模型採取行動、驗證工作成果、從失敗中恢復並安全運作?

text
1提示詞
2-> 指令
3
4上下文
5-> 工作視圖
6
7HARNESS
8-> 運行環境
9
10循環
11-> 局部修正
12
13圖譜
14-> 協調合作

模型會不斷改變。

持久的優勢存在於它們周圍。

你的合約會越來越好。

你的工具會越來越好。

你的測試會越來越好。

你的狀態會越來越乾淨。

你的權限會越來越安全。

你的恢復邏輯會越來越聰明。

你的失敗會轉化為基礎設施。

這就是強大的模型蛻變為可靠 Agent 的方式。

這就是 Harness Engineering。

如果你看到了這裡

把這篇指南加入書籤。

在 X 上追蹤我: x.com/0xjmori

訂閱我的 Substack: substack.com/@lunarresearcher

把這篇文章分享給那些還在試圖用更長的提示詞來修復每個 Agent 錯誤的人。

一鍵儲存

使用 YouMind AI 深度閱讀爆款文章

保存原文、追問細節、總結觀點,並在一個 AI 工作空間裡把爆款文章沉澱成可複用筆記。

了解 YouMind
寫給創作者

把你的 Markdown 變成乾淨的 𝕏 文章

圖片上傳、表格、程式碼區塊,往 𝕏 上手動重排太痛苦。YouMind 把整篇 Markdown 一鍵轉成乾淨、可直接發佈的 𝕏 文章草稿。

試試 Markdown 轉 𝕏

更多可拆解樣本

近期爆款文章

探索更多爆款文章