2026年2月，OpenAI在官方博客發佈了一篇文章，標題是Harness Engineering: leveraging Codex in an agent-first world。文章講了一件聽起來相當瘋狂的事：他們用Codex Agent從零構建了一個軟件產品，五個月交付上線，代碼量約一百萬行——沒有一行是人寫的。
這不是概念演示，不是Demo，而是真實上線的產品。
這意味着什麼？意味着AI編程已經從"幫我寫幾行代碼"的輔助工具，進化成了可以獨立完成整個軟件項目的生產力系統。但問題也隨之而來：當編碼行爲本身可以被系統化委託時，真正的稀缺資源從"寫代碼的能力"變成了什麼？
答案是：設計和構建這個"系統"的能力——也就是Harness Engineering。
如果你對AI編程還停留在"用ChatGPT幫我寫函數"的理解上，這篇文章會刷新你的認知。我們系統性地拆解Harness Engineering的來龍去脈、核心方法和真實價值，不管你是軟件工程師、技術管理者還是AI從業者，看完都會有實質收穫。
AI軟件工程的三次範式躍遷
過去三年，AI編程領域經歷了三次認知升級，每一次都在回答同一個問題："AI的問題到底出在哪裏？"
1.1 Prompt Engineering：教AI說話
2022-2024年，AI編程的主流範式是Prompt Engineering。
這個階段的核心邏輯是：通過精心設計提示詞，讓AI在單次交互中給出更好的代碼。代表性技術包括Chain-of-Thought（思維鏈）、Few-Shot Learning（少樣本學習）、Role Prompting（角色扮演）等。
這個階段的侷限性也很清晰：單次交互能處理的任務複雜度有上限。AI會"遺忘"對話早期的重要上下文，會在長任務中逐漸漂移，也會在面對需要多步驟推理的工程問題時給出邏輯連貫但局部錯誤的答案。
Prompt Engineering解決的是"怎麼說"的問題，但解決不了"說什麼"的問題——因爲當任務本身需要跨文件、跨模塊理解時，單次Prompt的上下文窗口根本不夠用。
1.2 Context Engineering：給AI正確的上下文
2024年下半年，Context Engineering（上下文工程）開始崛起。
這個階段的核心邏輯變了：AI表現不好，不是因爲"說錯了話"，而是因爲"沒有正確的信息"。所以關鍵從"怎麼說"轉向了"給AI什麼信息"。
代表性技術包括：RAG（檢索增強生成）、向量知識庫、AGENTS.md文檔系統、以及各種記憶機制。開發者開始意識到，當AI能穩定訪問項目文檔、代碼結構、歷史決策這些上下文時，它的輸出質量會顯著提升。
Context Engineering解決的是"說什麼"的問題——但很快人們又發現，光有上下文還不夠。AI拿到正確的上下文後，還是會漂移、會生成風格不一致的代碼、會在複雜任務中執行路徑混亂。
也就是說，AI的問題不只是"不知道"，還有"不穩定"。
1.3 Harness Engineering：爲AI構建運行環境
2026年2月，Mitchell Hashimoto（HashiCorp聯合創始人、Terraform創作者）在博客中首次明確命名了Harness Engineering，OpenAI緊接着發佈百萬行代碼實驗報告，Martin Fowler跟進深度分析——這個概念迅速成爲AI工程領域最熱的話題。
Harness Engineering的核心問題變成：不是"怎麼跟AI說話"，而是"在什麼環境裏讓AI跑"。
如果說Prompt Engineering研究的是"怎麼駕駛"，Context Engineering研究的是"地圖和導航"，那麼Harness Engineering研究的則是整條賽道的設計——包括彎道、護欄、反饋系統、以及賽車本身的工程結構。
Martin Fowler提出了一個很有說服力的比喻：
如果AI是一個精力充沛但不知道往哪跑的馬，那麼Harness（駕馭具）不是騎師的鞭子，而是整條賽道的工程設計——你設計的是馬必須跑在哪條路上、遇到什麼障礙會觸發什麼反應、以及整個系統如何保證馬最終跑向終點
爲什麼HarnessEngineering纔是答案
2.1 Agent最大的問題不是"不夠聰明"，而是"不可預測"
讓我們直接看OpenAI的實驗數據：
5個月從零構建一個完整軟件產品
0行人工編寫的代碼
約100萬行代碼全部由Codex Agent生成
每天約3.5個PR（Pull Request）的產出速度
最終成功上線並穩定運行
但問題也隨之出現：當AI的產出速度遠超人類的審查能力時，傳統的代碼質量控制方式完全失效了。
在沒有約束的情況下，Agent會漂移——代碼風格逐漸混亂，同一個功能出現多種不同實現，架構決策被反覆推翻，註釋和代碼不一致。OpenAI把這種現象稱爲"熵增"：代碼庫在沒有系統性約束的情況下，自然地趨向混亂和無序。
這不是AI能力的問題，這是系統的問題。當產出速度超過人工審查能力時，必須用系統而非人工來保證質量。
2.2 流程管行爲，環境管認知
Harness Engineering領域有一個核心洞察，來自Anthropic和OpenAI的實踐經驗：
"Agents aren't hard; the Harness is hard."（Agent本身不難，構建Harness纔是難點。）怎麼理解這句話？我們來看兩個不同思路的對比。
Anthropic的思路：管行爲。 他們設計了Sprint Contract機制——每輪迭代開工前，Generator（生成者）和Evaluator（評估者）兩個Agent先協商"做完長什麼樣"，像甲方和施工隊籤驗收標準。不是人類定的標準，是兩個Agent自己談出來的。這種機制管住的是Agent的具體行爲模式。
OpenAI的思路：管認知。 他們提出了"Repo-as-truth"（代碼倉庫即真相源）的概念——不是告訴Agent"你不能做什麼"，而是確保Agent感知到的整個世界都是準確的、可執行的、自動維護的。整個代碼倉庫的架構約束、依賴規則、Linter配置、CI管線，都是Agent認知環境的組成部分。環境對了，Agent的行爲自然不會漂移。
流程管住的是行爲，環境管住的是認知。 這是兩種不同層次的控制論解決方案，而Harness Engineering更側重的是後者。
2.3 與其調教Agent，不如升級環境
Harness Engineering有一句話被開發者社區廣泛引用：
"每當發現Agent犯錯，就花時間設計一個解決方案，確保Agent永遠不會再犯同樣的錯誤。"這不是在調教Agent，這是在升級環境。當一個錯誤被環境約束解決掉之後，所有未來經過這個環境的Agent都會自動受益——不需要逐個修復Prompt，不需要逐個更新指令。
這個思路的顛覆性在於：你不是在"用AI"，你是在"建設AI能夠穩定工作的系統"。
HarnessEngineering五大核心實踐
這一章我們來看Harness Engineering在工程層面具體是怎麼做的。基於 OpenAI、Anthropic、LangChain、Cursor等團隊的實踐經驗，我們提煉出五個最核心的實踐方向。
實踐一：AGENTS.md不是規則文檔，而是目錄地圖
很多團隊踩過的坑：一開始把AGENTS.md寫成了一本超長的規則手冊，把所有代碼規範、架構決策、技術約定全部塞進去。結果文件越來越長，AI開始"讀不進去"或者"讀了但執行不一致"。
正確的思路是：AGENTS.md是一張目錄地圖，不是規則本身。
OpenAI在他們的實驗中將AGENTS.md控制在約100行，內容是"去哪裏找什麼"——告訴Agent要找架構文檔去哪個目錄，要找API規範去哪個文件，要了解團隊的代碼風格去哪個規則庫。
核心原則：按需加載，永不預加載。 記憶量可以無限增長，但上下文開銷恆定，AI每次只讀取跟當前任務相關的部分。
實踐二：Repo-as-truth——所有架構約束必須編碼進代碼倉庫
在傳統開發中，架構文檔是給人看的。但在Harness Engineering中，架構文檔是給AI看的——所以必須編碼進代碼倉庫，讓AI能夠感知和遵守。
具體做法包括：
依賴方向由CI自動驗證。 如果Agent寫了一段UI代碼直接調用了Repo層（違反了分層架構），CI直接報錯，PR過不了。
錯誤信息本身就是Prompt。 當Agent看到"你在這一層調用了那一層的模塊，請修正"時，不需要額外的上下文就知道怎麼改。
文檔結構和代碼結構同等重要。 AI不僅讀代碼，也讀文檔——文檔是AI理解架構意圖的核心渠道。
這樣做的好處是：架構約束不再依賴人類的持續監督，而是被嵌入到了系統的每一次檢查和驗證中。
實踐三：Linter + CI自動化反饋循環
Harness Engineering的核心工程閉環是：
Agent寫代碼 → Linter檢查 → 發現違規 → 錯誤消息包含修復指引 → Agent讀取指引 → 修復代碼 → 再次檢查 → 通過這個循環的神奇之處在於：人類品味被編碼一次，然後持續強制執行於每一行新代碼。
OpenAI團隊在實踐中發現，到後來每週五不再需要人工清理代碼風格問題——Agent每天自己掃一遍，發現問題自己修。人類的審美偏好變成了一次性的工程投入，然後由系統持續回收回報。
LangChain在Terminal Bench 2.0上的評測數據也驗證了這一點：同一個模型，換一套更精巧的Harness架構，成績從52.8%跳到66.5%，排名從Top 30躍升到Top 5。模型沒變，分數大幅提升——這就是Harness的力量。
實踐四：併發Agent的隔離與協調機制
當多Agent並行工作成爲常態時，新的工程問題出現了。
Cursor團隊在《Scaling long-running autonomous coding》中記錄了一次失敗實驗：他們嘗試讓數百個Agent同時處理一個大型項目。結果，當20個Agent併發工作時，有效吞吐量急劇下降——因爲鎖機制成了瓶頸，多個Agent互相等待。更糟糕的是，等待中的Agent爲了顯示自己"還在工作"，開始大量修改無關緊要的內容（註釋、格式、空格），整個代碼庫被迅速污染。
解決方案是Coordinator Mode（協調者模式）：一個主Agent充當工頭，派出多個Worker執行具體任務。Worker要執行危險操作（比如刪文件、跑腳本），必須向Coordinator申請許可。同一時間同一操作只有一張許可單，系統自動防止衝突。
這是Harness Engineering在併發場景下的典型工程挑戰：不僅要保證單個Agent的行爲可控，還要保證多個Agent並行工作時不會互相干擾。
實踐五：多輪對抗評估與快速糾正機制
Anthropic在Agent評測中設計了一種"Sprint Contract"機制：Generator寫代碼，Evaluator對抗驗收，兩個Agent進行多輪博弈，直到Generator的產出被Evaluator接受。
他們在實驗中觀察到一個有趣的現象：經過九輪對抗後，Generator推翻了最初的所有設計方案，做出了一個3D CSS透視環境加空間導航的實現——這是被對抗壓力逼出來的創造力，不是人類設計師提出的。
這揭示了Harness Engineering的一個核心信仰：出錯了能快速被發現和糾正，比"保證Agent不出錯"更現實，也更有效。
傳統開發中，代碼質量靠Code Review保證，但當Agent每天產出3.5個PR時，人工逐行審查成了瓶頸。Harness Engineering的解法是用系統化的對抗和評估機制替代人工審查，讓問題在CI管線中被自動捕獲，而不是等到上線後才發現。
HarnessEngineering的侷限性
沒有任何工程方法論是銀彈，Harness Engineering也不例外。在擁抱這個新範式之前，有必要清醒地認識它的侷限。
侷限一：高度定製，難以遷移
OpenAI自己在實驗報告中明確寫道：
"This behavior depends heavily on the specific structure and tooling of this repository and should not be assumed to generalize without similar investment."翻譯過來就是：這套能力高度依賴特定倉庫的結構和工具配置，換一個項目基本等於重建。
這意味着Harness Engineering的初期投入是巨大的——可能需要數月的沉澱才能建立起一套穩定運轉的環境系統。這和傳統軟件開發中"寫好代碼就能複用"的邏輯完全不同。
侷限二：初期投入巨大，ROI週期長
對於只有幾個人的創業團隊或小型項目來說，花兩個月構建Harness可能比直接寫代碼的成本還高。Harness Engineering目前更適合代碼量大、團隊規模大、迭代頻率高的中大型項目。
侷限三：模型能力決定天花板
再精巧的Harness架構，也沒法讓一個能力不足的模型產出高質量代碼。這條限制對所有Harness實踐都是通用的——Harness解決的是系統可靠性問題，不是模型智能問題。
Cursor團隊在實踐中總結出一句話："影響系統行爲最大的因素是prompt，其次是harness結構，最後纔是模型本身。" 但這句話有一個隱藏前提：Cursor的harness已經過了多輪迭代優化，達到了一個相當高的水準。在那個水準之上，prompt的邊際影響力才凸顯出來。
侷限四：對工程師能力提出新要求
Harness Engineering對"軟件工程師"的定義提出了新要求：不再只是"能寫代碼"，而是要理解系統設計、反饋機制、約束構建。Martin Fowler說得直接：
"What they describe sounds like much more work than just generating a bunch of Markdown rules files."翻譯：他們做的事比你寫一堆Markdown規則文件要複雜得多。 需要真正理解"工程"而非僅僅擅長"編碼"的人才能做好Harness Engineering。
結語
從Prompt Engineering到Context Engineering，再到Harness Engineering，過去三年AI編程領域的三次認知躍遷，回答的是同一個問題：AI的問題到底出在哪裏？
Prompt Engineering說：是Prompt說得不夠清楚。Context Engineering說：是上下文給得不夠完整。Harness Engineering說：是環境設計得不夠系統。
每一次躍遷都在擴大"環境"二字的邊界。當我們把環境從單次對話擴展到整個代碼倉庫、CI管線、反饋系統、併發協調機制時，我們實際上是在把對AI的信任從個人能力轉移到系統設計。
這也許是Harness Engineering最深刻的價值：它不是在加速"寫代碼"這件事，它是在重新定義"軟件工程"本身。
2026年，Harness Engineering剛剛開始走進主流視野。不管你是主動擁抱還是被動接受，AI編程的遊戲規則已經變了。你準備好嗎？