Harness Engineering 是最近我有興趣的主題，因此想請 AI 整理一下相關的文章或是 video，讓我可以快速理解他們是什麼。這份是 youtube 上面的一個 video：
Harness：AI 時代工程師的救命藥
https://www.youtube.com/watch?v=vr_Stw60lkQ
深度解析 Harness Engineering：AI 時代工程師的救命藥與系統自癒之道
在當前人工智慧飛速發展的時代，「Harness Engineering」這個詞彙近期在科技界與開發者社群中引起了廣泛的討論與刷屏。然而，這並非媒體憑空炒作出來的新穎「黑話」，而是第一線軟體工程師在嚴苛的生產環境中，被無數痛點與失敗經驗「逼出來的血淚史」。
本文將綜合 OpenAI 團隊、Anthropic 團隊，以及頂尖 AI 編程專家（如 M Hashimoto 等人）的實戰經驗總結，為您全面且深入地剖析：當 AI 代理（Agent）真正落地到真實業務場景時，我們面臨了什麼樣的深淵？而 Harness Engineering 又如何作為一套控制系統，引領軟體工程走向下一個典範轉移。
第一章：從「Demo 的短跑」到「生產環境的馬拉松」
要理解 Harness Engineering 的重要性，首先必須認清當前 AI 開發所面臨的殘酷現實。
1.1 溫室裡的 Agent 與真實世界的殘酷
在概念驗證（Demo）階段，AI Agent 往往表現得像個無所不能的天才。這是因為 Demo 的環境被極度簡化了，沒有歷史包袱，沒有複雜的依賴關係。然而，這只是一場「短跑」。
一旦將 Agent 投入到真實的生產環境中——這是一場漫長且充滿變數的「馬拉松」——情況便會急轉直下。在真實的程式碼倉庫（Repository）中，Agent 必須面對動輒萬行級別的龐大程式碼庫、各種不一致的程式碼風格、以及歷經多年累積下來的技術債。在這種高複雜度的環境下，任何微小的決策偏差，都會在後續的執行中被指數級別地放大。此時，你會發現問題的癥結點已經不再是「AI 模型夠不夠強大」，而是你的系統架構中，到底有沒有把「糾錯」這件事情給徹底工程化。
1.2 崩壞循環與「AI 垃圾」的擴散
如果開發團隊已經開始嘗試使用 Agent 來編寫真實業務的程式碼，大概率會陷入一個被稱為「崩壞循環」的夢魘中：
- 第一次運行：程式碼順利跑通，開發者驚呼模型的強大與無敵。
- 第二次迭代：當系統需要新增功能或修改時，程式碼的實作開始變形，原有的系統架構遭到侵蝕與破壞。
- 第三次執行：Agent 開始在同一個錯誤或邏輯坑洞裡反覆跌倒，完全沒有記取教訓（不長記性）。
- 第四次檢視：整個程式碼倉庫裡堆滿了半成品，以及邏輯互相衝突、打架的技術文件。
到了這個階段，工程師會痛苦地發現，自己的時間並沒有被解放，反而全部花在了幫 Agent「收拾爛攤子」上。更可怕的是，AI 不僅僅會創造價值，它「製造垃圾」的速度遠比人類快得多，這種現象甚至被業界稱為「AIO」。
OpenAI 團隊在早期實踐時就深刻體會過這個痛點，他們每週必須花費高達 20% 的時間，專門用來清理這些由 AI 產生的「廢料」。人類寫出來的程式碼固然也會有錯，但 Agent 具備 7 乘 24 小時不間斷高速生產的能力，一旦系統中缺乏有效的清理與糾錯機制，這些「壞味道（Bad Smell）」和錯誤程式碼就會以機器的速度在系統中瘋狂擴散。因此，Harness 的核心任務之一，就是針對這種系統熵增（混亂度增加）進行管理。
第二章：AI 時代工程師的「控制論」典範轉移
在真實的戰場上，單純依靠生成正確的程式碼已經不再是突破瓶頸的關鍵。Harness Engineering 將 AI 的競爭，從玄學般的「提示詞玄學」拉回到了嚴謹的「控制論（Cybernetics）」。
專家們達成了一個高度共識：未來的軟體工程，必須經歷從「怎麼說（溝通）」到「怎麼控（管理）」的徹底典範轉移。這可以分為三個進化的層次：
2.1 第一層：Prompt Engineering（提示詞工程）
這是大眾目前最熟悉的領域，其本質是「表達工程」。過去工程師研究如何下「咒語」，現在則研究如何套用「模板」。Prompt 工程解決的是「怎麼說」的問題，它只負責管理模型在「單次呼叫（呼吸）」中的意圖精準度與輸出正確性。
然而，如果開發者只停留在糾結如何撰寫更好的 Prompt，這就像是在一輛沒有煞車系統的高鐵上，卻只顧著糾結座椅的顏色。
2.2 第二層：Context Engineering（上下文工程）
這一層解決的是「Agent 為什麼強」的問題。一個 Agent 的能力高低，不在於它本身（模型）讀過多少訓練資料，而在於它「幹活時手邊有什麼資料」。
真正的高手不再浪費時間去微調提示詞，而是專注於「資訊供給工程」：如何動態地餵給 Agent 最相關的程式碼片段？如何有效地隔離那些已經過時、會產生誤導的垃圾文件？ 這一層確保了模型能夠在擁有「正確資訊」的基礎上做出決策。
2.3 第三層：Harness Engineering（系統控制與閉環工程）
這才是 AI 軟體工程的終局。Harness 預設了你的 Prompt 已經寫對了，上下文的資訊也餵得非常準確，但 Agent 還是會跑偏。為什麼？因為在處理「長任務」的過程中，系統會不斷積累「熵（混亂）」，Agent 也會發生「換班失憶（忘記前面的上下文）」。
Harness 就是那個能夠敏銳感知到偏差，並自動將 Agent「拽回來」的控制系統。它不追求在單次操作中「一把賭對」，它追求的是透過系統機制「持續逼近正確」。
絕不能將 Harness 降維打擊地稱為「Prompt 2.0」。Prompt 是「溝通」，Harness 則是「管理」。Prompt 是教員工怎麼說話，而 Harness 是給員工定 KPI、安裝監控系統、設定審計流程。只有當你開始設計「反饋迴路」時，你才算真正進入了 AI 代理工程的深水區。未來的頂級工程師，必定會將 80% 的精力，從打磨單次的表達，遷移到設計系統的閉環上。
第三章：Harness 的本質與歷史映射
Harness Engineering 之所以能讓頂級科技大廠集體倒戈並投入其中，是因為它精準地解決了 Agent 落地時最痛的問題。它的核心理念是：Harness 不是讓 Agent 變得更聰明，而是讓系統更懂得如何糾錯。
這並不是什麼「新瓶裝舊酒」的技術黑話，它的座標系建立在「控制論」之上，是軟體工程在 AI 時代的一次自我救贖。我們可以從歷史上的兩次重大技術變革中看到 Harness 的影子：
3.1 18 世紀的蒸汽機調速器
在 18 世紀蒸汽機發明初期，還沒有「調速器」這個裝置。當時的工人必須死死盯著蒸汽機，憑藉經驗手動調節閥門，以防止機器轉速過快而爆炸。在這個階段，「人」就是那個即時的控制器。
後來，離心式調速器被發明出來，它能夠感知轉速，當轉速過快時，機械裝置會自動關小閥門。有了這個裝置後，工人去哪裡了？工人不再需要手動轉閥門，他們的工作變成了「定義機器的目標轉速」以及「調整裝置的靈敏度」。這就是 Harness 的原始雛形：把「糾錯」這件事情，從極度依賴「人肉操作」，轉變成了系統自帶的「反饋迴路」。
3.2 雲原生時代的 Kubernetes (K8s)
在雲端運算早期，當伺服器當機時，工程師必須半夜起床手動重啟服務。而現在，有了 Kubernetes 之後，工程師只需要寫一份宣告式文件（例如：聲明「我需要這支程式維持三個副本」），剩下的工作就交由 K8s 的控制器自動去盯著。少了就自動補充，服務掛了就自動重啟，版本錯了就自動回退。工程師的工作，從「手動按按鈕」，變成了「撰寫系統規範」。
這套「聲明式控制」的邏輯，就是 Agent Harness 在軟體架構上的直接祖先。
3.3 Harness 在 AI 時代的意義
現在，將這套控制論的邏輯套用在 AI Agent 身上，就能解釋為什麼 OpenAI 能夠在短短五個月內，利用 AI 寫出 100 萬行程式碼。因為他們的工程師不再死死盯著 Agent 輸出的每一行改動。他們將精力花在「定義什麼叫做完成」，以及「定義哪些架構的紅線絕對不能碰觸」。
當 Agent 跑偏時，Harness 系統裡內建的測試和程式碼分析工具（Linter）會立刻將它拽回來。記住這個核心分工：Agent 負責執行，而 Harness 負責決定這些執行的結果能不能被留下來。
這是一個跨越時代的共同模式：只要系統的複雜度上升到一定程度，依賴人肉操作的模式就一定會失效。這時，你不能指望招募更多的人，或者換一個更聰明的大腦，你必須把「判斷」和「糾偏」的機制，深深固化到系統本身的基礎設施裡。
第四章：解構 Harness 控制迴路（四大核心元件）
Harness 的本質，可以被拆解為一個完美的控制迴路方程式：目標 + 傳感器 + 執行器 + 反饋。這四個板塊必須全數湊齊，才能稱得上是一個完整的工程系統。
如果說 AI 模型是運算能力強大的 CPU，那麼 Harness 就是套在這個 CPU 外面的那層「作業系統（OS）」。沒有作業系統，再強的算力也無法穩定轉化為生產力。
4.1 目標狀態（目標）
沒有目標，Agent 就會盲目地生成內容。 目標狀態絕對不能寫得空泛或追求「優雅」，那對機器來說毫無用處。你必須寫下 Agent 能夠精準理解的「硬標準」。對於 Agent 來說，「凡是沒有明確寫進程式碼倉庫（Repository）的規則，一律等於不存在」。
開發者必須將自己腦海中對於程式碼的「品味（Taste）」、對功能的預期、對品質的要求、架構的規範以及整潔度的標準，全部具象化，轉化為倉庫裡的標準資產，這幾項標準缺一不可。
4.2 傳感器（眼晴）
有了目標之後，你還得給 Agent 裝上「眼睛」，讓它能看見自己正在做什麼，這就是傳感器。沒有傳感器，Agent 就算做錯了，它自己也渾然不知。
千萬不要只把目光侷限在狹隘的「單元測試（Unit Test）」上。OpenAI 的絕招，是給 Agent 配備了一套極度完整、一體化的「觀測站」。這包含了：系統日誌（Logs）、效能指標（Metrics）、甚至鏈路追蹤（Trace）。Agent 甚至被賦予了權限，可以自己去查閱 Log，就像一位資深的 SRE（網站可靠性工程師）一樣，能夠自我診斷問題。只有當 Agent 真實「看見」了偏差，它才具備自我修復的基礎。
4.3 執行器（雙手）
光有眼睛能看見錯誤還不夠，Agent 必須還得有「手」去解決問題，這就是執行器。沒有執行器，Agent 發現了錯誤也無能為力。
執行器的權限範圍不應該僅限於「修改程式碼」。一個健全的系統，其執行器還應包含：修改技術文件、動態調整系統配置、開啟 Pull Request (PR)，甚至在系統評估風險過高時，Agent 應該有能力自主執行 Git Revert（版本回退）。記住一個原則：執行器的工具箱越豐富，整個系統的自我修復能力就越強大。我們要打造的，是一個能自己動手解決問題的 Agent，而不是一個只會瘋狂發出報警信號的復讀機。
4.4 反饋迴路（靈魂）
這是 Harness 系統中最為靈魂的一環。沒有反饋，系統就只是在「盲目地壯大運氣」。
有了反饋，系統就能在「執行 -> 感知 -> 對比目標 -> 進行修正」的閉環中不斷循環。在這種機制下，哪怕 Agent 在第一次嘗試時嚴重跑偏，在經歷了 100 次的自動循環修正後，其結果也必然會逼近真正的正確。Harness 的偉大意義，從來不在於追求某一次的 AI 呼叫有多麼完美，而在於這套反饋循環系統，到底能不能讓系統完成「自我校準」。
第五章：Harness 的實戰落地大體系
理解了理論架構後，我們來看看頂尖團隊（如 OpenAI 和 Anthropic）是如何將 Harness 實際落地，解決專案開發中的痛點的。核心的指導原則只有一句話：「Human steer, agents execute.」（人類掌舵，Agent 執行）。
在 OpenAI 的一項瘋狂實驗中，他們在五個月內完成了 100 萬行程式碼的專案，期間人類工程師「一行程式碼都沒寫」。不僅是業務邏輯，連 CI/CD 流程、文件撰寫、工具配置，全部由 Agent 獨立搞定。這使得開發速度直接暴增了 10 倍，平均每個工程師每天能合併 3.5 個 PR，而且打破了傳統軟體工程「人越多越容易混亂」的定律：Agent 越多，專案跑得越快。
他們是如何做到的？以下是具體的實戰策略：
5.1 知識與規範的徹底「外化」
Agent 無法像人類員工一樣，透過「耳濡目染」來學習團隊的開發品味。因此，工程師必須將存在於 Slack 對話紀錄中的討論、腦袋裡的架構偏好，全部「外化」並寫入倉庫，讓程式碼倉庫成為系統唯一的「事實來源（Single Source of Truth）」。只有這樣，Agent 才能像個老員工一樣，完全遵守你的開發規矩。
5.2 漸進式披露的文件管理（防止模型淹死）
絕對不能讓 Agent 一口氣閱讀幾千行的詳細說明書，那樣會導致模型的上下文視窗超載，直接「淹死」在資訊海裡。 正確的做法是採用「漸進式披露」：給 Agent 的指示檔（Agent Rules）只是一個大綱目錄，只寫出最核心的導航地圖。至於具體的實作細節，則是設定機制，讓 Agent 在需要時「按需」自己去 docs 目錄裡面深挖。這樣既節省了 Token 成本，又不容易讓規則因系統龐大而迅速過期。
5.3 文件衛生的自動化（抵抗文件過期）
「文件過期」是導致 Agent 判斷失誤的頭號殺手。OpenAI 解決這個問題的招數是：維護文件不靠開發者的良心，而是靠 CI（持續整合）機制。他們配置了專門的「文件園丁 Agent」，它會作為一個後台任務，定期掃描並清理過時的文件，將文件衛生變成一種自動化的流程。因為只有「活著的、準確的文件」對系統才是有價值的。
5.4 讓 Agent 看見「活」的系統
OpenAI 給 Agent 配備了全套的「可觀測性工具」。除了看日誌和指標，Agent 甚至可以透過自動化瀏覽器，去觀看 UI 界面的真實截圖。這讓 Agent 不僅僅是在真空中寫程式，它能像資深工程師一樣自己診斷視覺與邏輯上的錯誤，看見偏差才能自我修復。
5.5 硬性架構紅線與「帶路式報錯」
別指望 Agent 會靠「自覺」來遵守系統架構。你必須把架構規範設定為堅不可摧的「硬紅線」。例如，OpenAI 嚴格定義了模組間的依賴方向，並用 Linter 工具死死守住這條底線。
更重要的是，當 Agent 踩到紅線時，系統回傳的不能只是冷冰冰的錯誤代碼。最頂級的錯誤訊息，會明確寫出「你違反了哪一條具體規則，並且你應該怎麼去修復它」。這被稱為「帶路式報錯」，本質上就是把老師傅的除錯經驗，直接寫進了編譯器與工具鏈中。
5.6 建立強大的「垃圾回收機制」
由於 AI 製造垃圾的速度極度驚人，系統必須有垃圾回收機制。團隊需要提煉出幾條黃金原則（例如：優先使用團隊現有的共享工具，絕對禁止 Agent 自己瞎猜或重新發明資料結構）。然後，安排後台 Agent 每天進行掃描、每天進行重構，將技術債消滅在萌芽狀態，防止整個軟體系統腐爛。
5.7 根治長任務的爛尾病（失憶與撐爆）
當 Agent 執行長篇幅的開發任務時，常常會爛尾。病根有兩個：
- 換班失憶：新的 Agent 接手時，根本不知道前一任 Agent 到底做了什麼決策。
- 貪多嚼不爛：Agent 試圖一次性搞定整個 App 的架構，結果上下文（Context）直接爆掉，留下滿地無法運行的爛攤子。
Anthropic 團隊對此的解法非常聰明，他們將任務拆解為兩個階段：
- 先遣隊 Agent：負責搭好專案的基礎骨架，並寫好詳細的進度表。
- 主力部隊 Agent：每次只專注攻克「一個單一功能」。而且規定，幹完活之後必須把現場環境收拾乾淨，確保下一班接手的 Agent 都能在一個清爽的環境下繼續工作。這叫「拒絕在廢墟上蓋大樓」。
5.8 將標準「寫死」與建立記憶橋樑
絕對不要讓 Agent 自己主觀決定什麼叫做「做完了」。專案的完成標準必須「寫死」在 JSON 狀態檔裡。例如，上百個功能點的初始狀態全都是 false。Agent 只有在程式碼真正跑通了嚴格的端到端測試（End-to-End Test）後，才能將狀態改為 true。這些狀態不准刪除、不准修改描述，這就是不可妥協的「硬指標」。
為了解決換班失憶，必須建立「記憶橋樑」。每一輪開發結束，都必須留下詳盡的進度日誌和清晰的 Git Commit。下一個 Agent 上工的第一件事，不是盲目寫程式，而是讀日誌、看 Commit、跑腳本，花三分鐘先「對齊專案現狀」，堅決拒絕「盲猜」。這確保了工程化的連續性。
5.9 環境恢復與端到端驗證（防止紙面勝利）
如果開發環境壞了，Agent 程式碼寫得再好也是徒勞。因此，必須把「環境恢復」寫成自動化腳本。每次 Agent 啟動前，先跑一遍心跳檢查，如果環境不通，優先修復環境，絕不在廢墟上施工，這是長任務能夠順利跑下去的基礎底線。
最後，一定要有端到端驗證。絕對不能只聽信 Agent 單方面宣稱「程式碼寫好了」。必須讓 Agent 自己開啟瀏覽器，像真實使用者一樣去點擊、去測試。只有 UI 真實跑通了，才叫真正的完成。這是 Harness 裡面最硬核的一道傳感器，專門用來打擊 Agent 虛報的「紙面勝利」。
第六章：未來工程師的終極走向與護城河
聊到這裡，我們其實已經不再只是單純討論 Harness Engineering 這個技術詞彙了，而是在探討「軟體工程師」這份職業在未來幾年的終極發展走向。
人類在技術系統裡的位置，正在經歷一次關鍵的「上移」。在沒有 Agent 的年代，工程師的價值取決於你寫了多少行程式碼。但在 OpenAI 這種百萬行程式碼零手寫的案例出現後，這種價值定義已經徹底失效了。
未來，市場上最昂貴、最有價值的工程師，是那個「能管理會寫程式的機器」的人。工程師必須從「踩油門的人（執行者）」，徹底蛻變為「設計賽道和護欄的人（控制系統設計師）」。你能為系統定義出多麼精準的「對（正確性）」，你的 Agent 就能爆發出多麼龐大的生產力。
6.1 提升閉環的層級
站在控制論的角度來看，軟體工程以前也有閉環，但層級太低了。過去的編譯器只能管語法錯誤，測試只能管執行邏輯，這些都是底層的閉環。至於系統的架構會不會逐漸腐壞？設計風格符不符合團隊的品味？這些高層次的判斷，以前只能依賴資深工程師用「肉眼」去盯、去 Review。
現在，大型語言模型（LLM）第一次讓這些「高層次的判斷」，也能夠形成自動反饋的閉環系統。
6.2 結語：選擇你的未來賽道
時代已經變了，未來的競爭，拼的不再是誰寫程式碼的速度快，而是誰能把「品味」與「架構規範」精準地寫成機器的「規則」。
我們可以用一句話總結這場變革：AI 模型會不斷進化，算力也會持續暴漲；但當模型強大到一定程度時，真正拉開團隊差距的，不再是誰使用的模型參數比較多，而是誰能把「正確」這個概念，定義得更深、更嚴謹。同一個強大的模型，在不同的 Harness 系統控制下，專案的成功率甚至可以相差一倍以上。
Harness Engineering 的核心使命，不是把 Agent 訓練成一個聽話的乖寶寶，而是把「系統糾錯能力」打造成一個可以長期穩定運行的基礎設施。AI 模型會不斷迭代，開發框架遲早會過時，但只要你的系統裡缺乏有效的反饋迴路，它遲早都會走向失控。
作為這個時代的工程師，你正面臨一個關鍵的抉擇：你是想繼續跟在瘋狂產出的 Agent 後面，疲於奔命地「撿玻璃渣」？還是選擇主動出擊，開始為你的團隊設計那套能夠自我感知、自我糾錯的 Harness 系統？
你選擇了哪一條路，將徹底決定在即將到來的 AI 工程春天裡，你將站在什麼樣的位置。
發表迴響