YouTube 高贊視頻分享：到底什麼是Harness Engineering？一次講清楚
整理版優先睇
Harness Engineering：AI 工程重心從模型轉向系統穩定
呢篇文章係子昕基於一條YouTube高讚視頻嘅再理解，講嘅係最近爆紅嘅 Harness Engineering 概念。作者指出，好多開發者用同一個模型，Agent 成功率卻差好遠，問題唔喺模型本身，而係模型之外嘅系統結構。
文章回顧咗 AI 工程嘅三次重心轉移：先係 Prompt Engineering，靠語言設計侷限概率空間；然後係 Context Engineering，要喺啱嘅時機俾啱嘅資訊，連埋檢索、對話歷史、系統規則等；最新就係 Harness Engineering，即係用調度、約束、糾偏機制嚟「駕馭」模型，確保穩定可控。
核心結論係：Demo 成功靠模型，產品成功靠 Harness。當你嘅系統開始跑流程、出現成功率唔穩定、難 Debug 或者改一處全局崩，就要諗 Harness 層嘅結構補強。一線公司好似 Anthropic 同 OpenAI 都已經咁樣做，將唔確定嘅模型行為包裝喺確定嘅系統結構入面。
- AI 工程重心由 Prompt 轉向 Context，再轉向 Harness，模型以外嘅系統結構先係成敗關鍵。
- Harness 本質係「調度 + 約束 + 糾偏」，目標係令 Agent 穩定、可控、可複用。
- Context Engineering 嘅難點係「俾得啱」而唔係「俾得多」，需要動態注入、分層提供。
- 工業級 Harness 可以拆成六層：從調度到糾偏，每層負責唔同嘅穩定性需求。
- 判斷標準：成功率唔穩定、偶爾抽風、難 Debug、改一處全局崩，就應該補 Harness。
三次中心遷移：由 Prompt 到 Harness
過去兩年，AI 工程經歷咗三次明顯嘅重心轉移，表面係新名詞，實質對應唔同階段嘅系統問題。呢三次轉移係：Prompt Engineering、Context Engineering 同 Harness Engineering。
第一階段係 Prompt Engineering，重點係「把話說明白」。大模型係對上下文高度敏感嘅概率生成系統，你俾乜身份佢就跟嗰個身份答。Prompt 嘅本質係 塑造局部概率空間，核心能力係語言設計而唔係系統設計。
第二階段係 Context Engineering，當 Agent 開始執行真實任務，模型未必知道所有事實，系統必須喺正確時機送入正確資訊。Context 包括用戶輸入、歷史對話、檢索結果、工具返回、任務狀態同系統規則——Prompt 只係 Context 嘅子集。難點係「俾得啱」而唔係「俾得多」：文檔點切塊、結果點排序、長文點壓縮、歷史對話點保留或摘要，呢啲都係 Context Engineering 嘅範疇。
- 1 Prompt Engineering：語言設計，限制定義域。
- 2 Context Engineering：資訊注入，動態提供。
- 3 Harness Engineering：系統結構，確保穩定可控。
第三階段 Harness Engineering 解決更難問題：模型連續執行時，誰嚟監督、約束、糾偏？Harness 原意係繮繩，強調模型唔係放養，而係需要駕馭。關鍵理解公式：Agent = Model + Harness，Harness = Agent − Model。
一個更直觀嘅比喻：新員工見客
作者用派新員工見客嚟比喻三層：Prompt 係叫佢表現專業，Context 係俾客戶資料，Harness 係安排流程、設檢查點、出錯兜底</highlight>。真正決定結果嘅，往往係公司有冇機制保證佢唔會搞砸。
成熟 Harness 嘅六個層次
一個工業級 Harness 系統可以拆成六層，但更工程化嘅理解係：Harness = 調度 + 約束 + 糾偏。佢解決嘅唔係「聰唔聰明」，而係穩定、可控、可複用。
- 1 任務調度：決定邊個 Agent 做咩、點樣排隊。
- 2 狀態管理：追蹤執行進度同中間產物。
- 3 資訊路由：確保正確 Context 送達正確 Agent。
- 4 約束規則：限制模型行為範圍（例如輸出格式、動作白名單）。
- 5 錯誤處理：偵測異常並執行補救策略（如重試、降級、人類介入）。
- 6 監控記錄：完整 Logging 同可觀測性，方便 Debug 同改進。
一線公司嘅真實實踐
Harness 最近突然火，因為 Anthropic 嘅 Agent 設計 同 OpenAI 嘅工具調用體系 都係做同一件事：將唔確定嘅模型行為包裹喺確定嘅系統結構入面。關鍵工程原則係：當 Agent 出問題時，解決方案幾乎從來唔係「令模型更努力」，而係喺 Harness 層補結構。
幾時必須考慮 Harness？
三種範式對應三個階段：簡單單輪生成 用 Prompt；依賴外部知識、多步推理 要 Context；長鏈路、低容錯真實執行 就 Harness 不可避免。一旦系統開始跑流程，Harness 就係必選項。
最後總結：決定 Demo 嘅係模型，決定產品嘅係 Harness。
大家好，我係子昕。
同樣嘅模型，人哋嘅 Agent 跑到 95% 成功率，自己嗰個就成日喺 70% 上下浮動——問題出喺邊度？
最近睇到 YouTube 一個講解《最近爆紅嘅 Harness Engineering 到底係乜嘢？》嘅影片。
睇完之後，我更加肯定一件事：
AI 工程嘅瓶頸，已經唔係喺模型本身，而係喺模型之外。
呢篇文章，係我喺原片基礎上嘅一次「再理解」。
如果你最近喺度做 Agent，或者關注 AI 應用落地，呢件事，可能會直接影響你接下來半年嘅方向。
一、三次重心遷移：由 Prompt 到 Harness
過去兩年，AI 工程經歷咗三次明顯嘅重心轉移。
表面上係換咗幾個新名詞，實質上對應咗 AI 系統發展嘅三個階段性問題：
階段一：Prompt Engineering——將說話講清楚
大模型本質上係一個對上下文高度敏感嘅概率生成系統。
你俾佢咩身份，佢就沿住嗰個身份回答；你俾佢咩範例，佢就沿住嗰個範式補全。
所以 Prompt Engineering 嘅本質，唔係「馴服」模型，而係：
塑造一個局部嘅概率空間。
呢個階段嘅核心能力係語言嘅設計，唔係系統嘅設計。
階段二：Context Engineering——將資訊俾啱
當 Agent 開始流行，模型唔再係淨係回答問題，而係進入真實環境執行任務。
呢個時候，一個關鍵變化出現咗：
模型未必知道所有事實，系統必須喺正確時機將正確資訊送過去。
工程意義上嘅 Context，其實係：
用戶輸入 歷史對話 檢索結果（RAG） 工具返回 當前任務狀態 中間產物 系統規則
👉 Prompt 只係 Context 嘅一個子集。
成熟嘅上下文工程關注嘅遠遠唔止檢索本身，仲包括：文件點樣切塊、結果點樣排序、長文點樣壓縮、歷史對話幾時保留幾時摘要、多個 Agent 之間傳原文定係結構化字段……
真正嘅難點在於：
唔係「俾得多啲」，而係「俾得啱啱好（按需俾、分層俾、喺正確時機俾）」。
呢個都係近年來「Agent Skills」（漸進式披露）概念爆紅嘅底層邏輯：先只俾最少嘅索引資訊，當 Agent 真正觸發某項能力時，再將詳細嘅 SOP 同參考資料動態注入。
呢個都係點解：
長上下文唔一定更好 RAG（Context Engineering 嘅典型實踐之一）成日都「越做越亂」
階段三：Harness Engineering——令系統運行穩定
前兩步解決嘅係：
Prompt：表達意圖 Context：提供資訊
但複雜任務入面仲有一個更難嘅問題：
模型一旦開始連續執行，邊個嚟監督佢、約束佢、糾正佢？
Harness 呢個詞，原本意思係「韁繩、馬具、約束裝置」。
放到 AI 入面，佢其實喺度強調一件好樸素嘅事：
模型唔係用嚟「放養」嘅，而係需要被「駕馭」嘅。
一個非常關鍵嘅理解係：
Agent = Model + Harness
Harness = Agent − Model
👉 換句話講：
除咗模型本身之外，所有決定佢係咪穩定嘅嘢，都屬於 Harness。
二、一個更直觀嘅比喻
可以將呢三層理解做：
👉 派一個新員工去見客
Prompt：你同佢講「表現專業啲」 Context：你俾佢客戶資料、背景資訊 Harness：你安排流程、設檢查點、出錯有得兜底
👉 真正決定結果嘅，往往唔係佢講咩，而係：
公司有冇一套機制，保證佢唔會搞砸。
三、成熟 Harness 嘅六個層次
一個工業級嘅 Harness 系統，通常可以拆解成六層：
但呢度我俾你一個更「工程化」嘅理解方式：
Harness 本質上 = 調度 + 約束 + 糾正
佢解決嘅，唔係「聰唔聰明」，而係：
穩唔穩定 可唔可控 能唔能夠複用
四、一線公司嘅真實實踐
Harness 之所以最近突然爆紅，唔係因為概念，而係因為：
👉 一線公司已經係咁樣做緊。
比如：
Anthropic 嘅 Agent 設計 OpenAI 嘅工具調用體系
本質都係做緊一件事：
將「唔確定嘅模型行為」，包裹喺「確定嘅系統結構」入面。
呢度有一個非常關鍵嘅工程原則：
當 Agent 出問題時，解決方案幾乎從來都唔係「令模型更努力」，
而是：而係喺 Harness 層補結構。
五、總結：幾時你一定要考慮 Harness？
呢三種範式，其實對應三個階段：
任務係簡單嘅單輪生成 → Prompt 係關鍵 任務開始依賴外部知識、需要多步推理 → Context 變得關鍵 模型進入長鏈路、低容錯嘅真實執行場景 → Harness 幾乎不可避免
👉 即係話：
只要你嘅系統開始「行流程」，Harness 就已經不可避免㗎喇。
最後俾你一個判斷標準：
如果你而家嘅系統出現：
成功率唔穩定 間中「抽風」 好難 debug 改一個地方，全局冧
👉 咁基本可以肯定：
問題唔係喺模型，而係喺 Harness。
寫喺最後
AI 落地嘅核心挑戰，正在發生一個變化：
由「令模型更聰明」→ 到「令模型穩定工作」
呢個都係點解：
同樣嘅模型，唔同產品表現差距好大。
最後一句話總結：
決定你能唔能夠做出 Demo 嘅，係模型；
決定你能唔能夠做成產品嘅，係 Harness。
畀個關注啦，我會繼續用我呢啲半桶水水平為大家帶嚟更多 AI 編程工具嘅第一手體驗～
「點讚、轉發、睇緊」
同大家一齊睇
大家好，我是子昕。
同樣的模型，別人的 Agent 能跑到 95% 成功率，自己的總在 70% 上下搖擺——問題出在哪裏？
最近看到 Youtube 一個講解《最近爆火的 Harness Engineering 到底是個啥？》視頻。
看完之後，我更加確定了一件事：
AI 工程的瓶頸，已經不在模型本身，而在模型之外。
這篇文章，是我在原視頻基礎上的一次“再理解”。
如果你最近在做 Agent，或者關注 AI 應用落地，這件事，可能會直接影響你接下來半年的方向。
一、三次中心遷移：從 Prompt 到 Harness
過去兩年，AI 工程經歷了三次明顯的重心轉移。
表面上是換了幾個新名詞，實質上對應了 AI 系統發展的三個階段性問題：
階段一：Prompt Engineering——把話說明白
大模型本質上是一個對上下文高度敏感的概率生成系統。
你給它什麼身份，它就沿着那個身份回答；你給它什麼樣例，它就沿着那個範式補全。
所以 Prompt Engineering 的本質，不是“馴服”模型，而是：
塑造一個局部的概率空間。
這個階段的核心能力是語言的設計，不是系統的設計。
階段二：Context Engineering——把信息給對
當 Agent 開始流行，模型不再只是回答問題，而是進入真實環境執行任務。
這時候，一個關鍵變化出現了：
模型未必知道所有事實，系統必須在正確時機把正確信息送進去。
工程意義上的 Context，其實是：
用戶輸入 歷史對話 檢索結果（RAG） 工具返回 當前任務狀態 中間產物 系統規則
👉 Prompt 只是 Context 的一個子集。
成熟的上下文工程關注的遠不止檢索本身，還包括：文檔怎麼切塊、結果怎麼排序、長文怎麼壓縮、歷史對話何時保留何時摘要、多個 Agent 之間傳原文還是結構化字段……
真正的難點在於：
不是“給得更多”，而是“給得剛剛好(按需給、分層給、在正確時機給)”。
這也是近年來“Agent Skills”（漸進式披露）概念走紅的底層邏輯：先只給最少量的索引信息，當 Agent 真正觸發某項能力時，再把詳細的 SOP 和參考資料動態注入。
這也是為什麼：
長上下文不一定更好 RAG(Context Engineering 的典型實踐之一) 也經常“越做越亂”
階段三：Harness Engineering——讓系統跑穩
前兩步解決的是：
Prompt：表達意圖 Context：提供信息
但複雜任務裏還有一個更難的問題：
模型一旦開始連續執行，誰來監督它、約束它、糾偏它？
Harness 這個詞，原意是“繮繩、馬具、約束裝置”。
放到 AI 裏，它其實在強調一件很樸素的事情：
模型不是用來“放養”的，而是需要被“駕馭”的。
一個非常關鍵的理解是：
Agent = Model + Harness
Harness = Agent − Model\
👉 換句話說：
除了模型本身以外，所有決定它是否穩定的東西，都屬於 Harness。
二、一個更直觀的比喻
可以把這三層理解成：
👉 派一個新員工去見客戶
Prompt：你跟他說“表現專業一點” Context：你給他客戶資料、背景信息 Harness：你安排流程、設檢查點、出錯能兜底
👉 真正決定結果的，往往不是他說什麼，而是：
公司有沒有一套機制，保證他不會搞砸。
三、成熟 Harness 的六個層次
一個工業級的 Harness 系統，通常可以拆解成六層：
但這裏我給你一個更“工程化”的理解方式：
Harness 本質上 = 調度 + 約束 + 糾偏
它解決的，不是“聰不聰明”，而是：
穩不穩定 可不可控 能不能複用
四、一線公司的真實實踐
Harness 之所以最近突然火，不是因為概念，而是因為：
👉 一線公司已經在這麼幹了。
比如：
Anthropic 的 Agent 設計 OpenAI 的工具調用體系
本質都在做一件事：
把“不確定的模型行為”，包裹在“確定的系統結構”裏。
這裏有一個非常關鍵的工程原則：
當 Agent 出問題時，解決方案几乎從來不是“讓模型更努力”，
而是：在 Harness 層補結構。
五、總結：什麼時候你必須考慮 Harness？
這三種範式，其實對應三個階段：
任務是簡單的單輪生成 → Prompt 是關鍵 任務開始依賴外部知識、需要多步推理 → Context 變得關鍵 模型進入長鏈路、低容錯的真實執行場景 → Harness 幾乎不可避免
👉 也就是說：
只要你的系統開始“跑流程”，Harness 就已經不可避免了。
最後給你一個判斷標準：
如果你現在的系統出現：
成功率不穩定 偶爾“抽風” 很難 debug 改一個地方，全局崩
👉 那基本可以確定：
問題不在模型，而在 Harness。
寫在最後
AI 落地的核心挑戰，正在發生一個變化：
從“讓模型更聰明”→ 到“讓模型穩定工作”
這也是為什麼：
同樣的模型，不同產品表現差距巨大。
最後一句話總結：
決定你能不能做出 Demo 的，是模型；
決定你能不能做成產品的，是 Harness。
點個關注唄，我會繼續用我這半吊子水平為大家帶來更多AI編程工具的第一手體驗～
「點贊、轉發、在看」
和大家一起看