Harness 工程：不是新詞，而是 Agent 工程終於被講明白了

同步至個人站點：Harness 工程：不是新詞，而是 Agent 工程終於被講明白了

這兩天，Agent 圈突然開始密集討論一個詞：Harness。

很多人第一次看到它，會覺得這是個新框架、新範式，甚至像是什麼「下一代 Agent 技術名詞」。

但我看了一圈後，第一反應其實很簡單：

這不就是我之前在做 memo code 時，一直在做的那套東西嗎？

更準確一點說：

Harness 不是一個新技術發明。它更像是 Agent 工程裡那部分一直存在、但過去沒有被完整命名的「軟體工程現實」。

前段時間我去高校做 Agent 開發交流時，也一直在講一個非常樸素的判斷：

Agent = Loop(LLM + Context + Tools)

這個 loop 本身並不複雜。

真正難的，還是 軟體工程。

現在回頭看，所謂 Harness，某種意義上就是把我當時說的「軟體工程」這件事，具象化了、命名了、體系化了。OpenAI 在 2026 年 2 月發布的官方文章裡，幾乎就是這麼描述的：工程師的工作正從「寫程式碼」轉向「設計環境、指定意圖、建立回饋迴路，讓 agent 能可靠工作」；他們甚至用小團隊在幾個月裡借助 Codex 產出約百萬行程式碼作為案例。

所以這篇文章，我不想把 Harness 當作一個「熱詞解讀」。

我更想做另一件事：

把 Harness 這件事，從 Agent 工程的角度，完整講明白。

Harness 到底是什麼？

先說我的定義：

Harness 不是模型。不是提示詞。不是工具呼叫。不是框架。Harness 是 Agent 運行時的「工程環境總和」。

這個「環境總和」裡包含什麼？

至少包括這幾類東西：

1. 任務如何被表達
2. 上下文如何被組織
3. 工具如何被暴露、治理、攔截
4. 狀態如何被保存、恢復、裁剪
5. 回饋如何回流給模型
6. 錯誤如何被分類、重試、升級
7. 安全邊界如何被建立
8. 系統如何驗證 agent 真的把事做好了

如果你把 Agent 想成一個「會呼叫工具的大腦」，那 Harness 就是：

你給這個大腦配的身體、感測器、護欄、操作台、流程制度、回執系統，以及出事後的保險。

所以我更願意把它翻成：

Harness = 駕馭系統或者更工程一點：

Harness = 讓 Agent 能被穩定駕馭的環境系統

OpenAI 後續關於 Codex App Server 的文章也把這件事說得更具體：所謂 harness，不只是「使用者–模型–工具」的核心 loop，還包括執行緒生命週期與持久化、配置與鑑權、工具執行與擴展、用戶端與執行時之間的協定層。也就是說，真正的 harness 不是一個提示詞檔案，而是一個完整的執行時。

為什麼這個詞現在突然火了？

因為業界終於開始承認一件事：

Agent 的問題，越來越不是「模型夠不夠聰明」，而是「環境夠不夠好」。

同一個模型，放到不同系統裡，表現會差得非常大。

有的 agent：

• 會亂調工具
• 會丟上下文
• 會把安全邊界踩穿
• 會在長任務裡越來越漂
• 會越來越像「有工具的聊天機器人」

而有的 agent：

• 能持續做事
• 能沿著目標推進
• 能利用回饋修正自己
• 能在複雜任務裡保持結構感
• 甚至能讓一個不算新的模型，也表現得很像樣

這也是我當時做 memo code 時非常在意的一點。

我故意沒有把測試重心放在「最新最強模型」上。相反，我很長一段時間都在用一個已經發布將近一年的 DeepSeek 模型來測。原因很簡單：

我想驗證的不是「模型天賦有多高」，而是「環境設計能把一個普通模型托到什麼程度」。

如果一個相對古早的模型，在這套環境裡仍然能做成事，那說明這套工程方向是對的。這比「換個新模型突然變強」更有價值。

這也和最近公開的一些工程經驗是對齊的。OpenAI 把重點放在支架（scaffolding）、環境約束、回饋迴路和可讀程式碼庫上；OPENDEV 那篇論文則把重點放在安全控制、上下文壓縮、工作負載路由、記憶系統和事件驅動提醒上。兩邊說法不同，但本質一致：

Agent 的能力，不只是模型能力，而是模型 × 環境。

為什麼我一直說：Agent 的核心很簡單，難點仍然是軟體工程？

因為從原理上講，Agent 真的不複雜。

我在分享裡說過：

Agent = Loop(LLM + Context + Tools)

或者更直白一點：

在一個迴圈裡，提供一些工具、維護一個上下文，再呼叫大型語言模型（LLM）。

這件事的抽象層面，你甚至十幾分鐘就能給它寫個最小版本。你給模型一個系統提示詞，給它幾個工具，讓它在迴圈裡不斷決定「要不要繼續做事」，這就已經是 agent 了。

所以真正的問題不在「能不能做出一個 loop」。

真正的問題在於：

一個 loop，為什麼會在生產環境裡爛掉？

答案通常不是因為模型突然變笨了，而是因為下面這些工程問題開始集中出現：

• 上下文越來越髒
• 工具越來越多，但沒有治理
• 狀態沒有結構化
• 安全邊界靠「相信模型懂事」
• 錯誤沒有歸類，回饋也不可消費
• 長任務沒有階段性 checkpoint
• 文件和規則堆成一坨，模型根本吃不動
• 人和 agent 的協作邊界不清晰

這些問題，全部都不是「模型理論問題」。

它們是徹頭徹尾的軟體工程問題。

而 Harness，這個詞的價值就在這裡：

它提醒你，Agent 專案的真正主戰場，不是模型層，而是運行環境層。

Harness 和 Context Engineering 的區別是什麼？

我看到不少討論會把 Harness 和 Context Engineering 混在一起。

我覺得可以這樣區分：

1）Prompt Engineering（提示詞工程）

關注的是：怎麼說

比如系統提示詞怎麼寫，few-shot 怎麼擺，措辭怎麼調。

2）Context Engineering（情境工程 / 上下文工程）

關注的是：給模型什麼資訊

比如：

• 放哪些文件
• 怎麼裁剪歷史
• 怎麼組織 AGENTS.md
• 怎麼做記憶注入
• 怎麼避免 context bloat（情境膨脹）

3）Harness Engineering（駕馭系統工程）

關注的是：模型在什麼環境裡做事

它比 Context 更大一層。

因為它不只管「餵什麼」，還管：

• 什麼時候能動手
• 動手時有哪些工具
• 工具是否需要審批
• 輸出太長怎麼辦
• 危險操作怎麼攔
• 會話如何恢復
• 中間產物如何持久化
• 任務失敗後如何回路修復
• 用戶端如何即時展示 agent 的狀態

所以我會說：

Context Engineering 是 Harness 的一個組成部分，但 Harness 不等於 Context。

OpenAI 官方中文頁裡有一句話我很認同：情境是一種稀缺資源，巨大指令文件會擠掉任務、程式碼和相關文件，導致 agent 開始圍繞錯誤約束優化。這個觀察本身說的是 context，但他們整篇文章講的解決方式，其實已經進入 harness 級別了：程式碼庫結構、AGENTS.md、審閱回路、驗證手段、倉庫作為紀錄系統、熵管理。

從 memo 的實踐看，Harness 具體長什麼樣？

如果讓我用 memo code 的經驗來拆，我會把 Harness 至少拆成五層。

第一層：上下文裝配系統

很多人以為系統提示詞就是一份大 Markdown。

其實不是。

在 memo 裡，我更在意的是：提示詞不是靜態文件，而是動態拼裝系統。

我在那篇《系統提示詞架構解析》裡把它拆成六層：

1. 基礎模板
2. 使用者偏好（SOUL.md）
3. 專案上下文（AGENTS.md）
4. Skills
5. 工具描述
6. 工具定義 JSON

這個拆法的重點不是「層多」，而是：

不同來源的資訊，有不同優先級、不同新鮮度、不同職責。

它們不能全塞進一個大 prompt 裡，然後指望模型自己理解層級關係。你必須先在工程上把層級關係建好，再交給模型。

這就是 Harness。因為你不是在「寫提示詞」，你是在「設計上下文的注入機制」。

第二層：工具治理系統

一個 agent 只要開始接工具，複雜度會立刻上升。

因為工具不是「多幾個 function call」這麼簡單。工具系統背後至少有四個問題：

1. 模型如何發現工具
2. 參數如何驗證
3. 風險如何分級
4. 呼叫如何被統一攔截

我在 memo 的工具系統設計裡，把這件事拆成三層：

• 工具定義層：宣告式 DSL
• 風險與審批層：read / write / execute / critical 分級
• 編排層：統一入參驗證、審批攔截、結果裁剪、錯誤歸類

這個設計的重點不是「優雅」，而是：

讓工具呼叫成為一個可治理系統，而不是一堆裸奔介面。

很多 Agent 專案為什麼一開始能跑，後來越來越不穩？

因為它們的工具系統不是「系統」，只是「工具列表」。

而 Harness 的一個核心任務，就是把工具從「模型可以呼叫的能力」提升成「可控、可審計、可演化的執行時能力」。

第三層：安全與審批系統

只要 agent 能寫檔案、跑 shell、改設定，它就不再是一個「聊天模型」。

它已經是個作業系統參與者了。

這時候安全問題不是「以後再說」，而是第一天就存在。

我在 memo 的安全設計裡，最後收斂成了三道防線：

1. 子程序管理：會話池、數量限制、輸出截斷、超時終止、自動清理
2. 命令守衛：命令解析、危險命令黑名單、system hint 回傳
3. 審批系統：風險分級、審批模式、指紋快取、dangerous 模式兜底

這裡最關鍵的一點是：

安全不能只靠模型自覺。

你不能把「請不要執行危險命令」寫在提示詞裡，然後假裝問題解決了。真正的安全邊界，必須落在執行時。

這也是 Harness 和很多「Demo Agent」的根本差別。

Demo 級別的 agent 靠的是「模型大概會乖」。Harness 級別的 agent 靠的是「即便模型不乖，系統也有邊界」。

第四層：回饋與狀態系統

Agent 之所以能持續做事，不是因為它會一直「想」。

而是因為它會不斷收到回饋。

比如：

• 工具執行結果
• 審批是否通過
• 輸出是否被截斷
• 查找結果是否過多
• 命令是否被拒絕
• 當前任務計畫是否已更新
• 會話是否可恢復

在 memo 的提示詞架構裡，我專門用 XML system_hint 去承載一些異常狀態，比如：

• 輸出過長
• 查找結果過多
• 危險呼叫被攔截

很多人會覺得這只是「小技巧」。

但我不這麼看。

這其實是 Harness 裡非常重要的一件事：

你要把系統內部發生的事，翻譯成模型能消費的回饋語言。

如果沒有這層翻譯，模型只能看到「失敗了」。而有了這層翻譯，它才能理解：

• 失敗是因為權限問題
• 失敗是因為輸出被裁剪
• 失敗是因為查找範圍太大
• 失敗是因為命令危險而被拒絕

這直接決定了 agent 是否能做出下一步正確行動。

第五層：熵管理系統

這是我覺得很多人會忽略，但其實特別關鍵的一層。

Agent 一旦持續運行，系統一定會逐漸「變髒」。

表現形式包括：

• prompt 越來越長
• rules 越來越舊
• AGENTS.md 越來越像垃圾場
• 工具定義越來越多但沒人維護
• 會話歷史越來越重
• memory 裡混入大量無效資訊

OpenAI 在那篇文章裡其實已經非常明確提到了這件事：當一切都重要時，一切都不重要；大而全的說明文件會迅速腐爛。

所以 Harness 不是「搭完就完了」。

Harness 還有一個長期任務：

持續做熵管理。

也就是：

• 讓過期規則失效
• 讓長上下文壓縮
• 讓低價值歷史退出上下文
• 讓專案知識以可維護方式沉澱
• 讓系統不斷回到「對模型友好」的狀態

如果沒有這層意識，再強的 agent 也會越跑越歪。

那麼，Harness 的本質到底是什麼？

如果一定要我用一句話概括，我會這麼說：

Harness 工程，就是把 Agent 從「會呼叫工具的模型」，變成「能在約束中穩定完成任務的系統」。

這裡面最重要的詞不是 Agent，也不是模型。

是三個詞：

• 約束
• 回饋
• 穩定

因為真實世界裡的 agent，不是靠「聰明」活下來的。

是靠：

• 有邊界
• 有結構
• 有狀態
• 有回饋
• 有兜底

活下來的。

所以我一直覺得，Agent 的重點從來都不在模型。

模型當然重要。但模型更像引擎。

真正決定這台車能不能上路、能不能跑長途、會不會翻車的，是底下那整套工程環境。

也就是 Harness。

一個我更願意推廣的公式

如果以前我會說：

Agent = Loop(LLM + Context + Tools)

那現在我會更進一步，把它升級成：

Agent = Loop(Model + Harness)

為什麼我要這麼改？

因為 Context 和 Tools 其實都已經屬於 Harness 的一部分了。

真正決定 agent 上限的，越來越不是「你有沒有這些元件」，而是：

你有沒有把這些元件工程化成一個可以長期運轉的環境。

同樣是：

• 一個模型
• 一個工具列表
• 一個上下文視窗

有人做出來的是玩具。有人做出來的是生產系統。

差別就在 Harness。

如果你要開始做 Harness 工程，先抓什麼？

我給一個非常實用的落地順序。

1. 先別急著追最強模型

先把環境搭起來。

因為環境是可複用資產，換模型能繼承；但只靠換模型，通常不能替你補環境債。

2. 先把工具系統做成「系統」

至少做到：

• 可發現
• 可驗證
• 可分級
• 可攔截
• 可審計

3. 上下文不要寫成一坨

把 prompt 當成裝配系統，不要當成單文件。

4. 安全邊界必須在執行時

不要把安全寄託在提示詞上。

5. 所有失敗都盡量可解釋

讓系統錯誤能回流成模型能理解的回饋。

6. 給長任務設計狀態與恢復機制

沒有狀態管理，就沒有真正的持續執行。

7. 定期做熵管理

規則、記憶、會話、文件，會腐爛。你不清理，系統就會慢慢失控。

為什麼我會說：Harness 不是新東西，但它是一個重要命名

我很少會因為一個新詞本身而興奮。

但這次我覺得 Harness 這個詞是有價值的。

因為它終於把很多 Agent 開發者長期在做、但總說不清的事情，命名清楚了：

• 為什麼提示詞調半天沒用
• 為什麼換模型只能解決一部分問題
• 為什麼工程化之後效果會突然穩定
• 為什麼長任務能力往往取決於環境，而不是參數量
• 為什麼真正的瓶頸常常是軟體工程，不是模型 API

它把這些零散經驗，收束成了一個更明確的討論入口。

所以我不認為 Harness 是什麼「橫空出世的新發明」。

我更願意說：

Harness 讓 Agent 工程這門課，終於有了一個更準確的詞。

最後說回 memo，也說回我自己的判斷

回頭看 memo code，我越來越確認一件事：

我當時真正做的事情，不只是「做一個 coding agent」。

我其實一直在做一套 Harness。

我做的那些看起來很「工程瑣事」的東西：

• prompt 分層裝配
• AGENTS.md / SOUL.md
• skills 自動發現
• 工具 DSL
• 風險分級
• 審批快取
• 危險命令攔截
• 子程序管理
• system hint 回饋
• 輸出裁剪
• 多 workspace / web 控制台

這些東西單拿出來都不性感。

但正是這些東西，決定了一個 agent 最後到底是：

• 一個 demo
• 一個玩具
• 一個會寫幾段程式碼的聊天機器人
• 還是一个真的能在環境裡持續做事的系統

所以如果今天再讓我用一句最簡短的話來講 Agent，我可能會這麼說：

Agent 的核心很簡單，真正難的是 Harness。

或者更直白一點：

Agent 的重點不在模型，而在環境。

這句話，我之前是這麼想的。現在我只是終於有了一個更流行的詞，來把它說得更完整一點。

（完）

原文出處：https://juejin.cn/post/7620226704209592360