2026 年 2 月，一個小型 OpenAI 團隊交付了 100 萬行生產級程式碼。
他們一行程式碼都沒親手寫。
是 AI Agent 寫的。
人類設計了讓這些 Agent 變得可靠的系統。
這個系統現在有個名字。
「Harness 工程」
幾週內，Anthropic 發表了 3 篇相關論文。
ThoughtWorks 將其正式化為一套框架。
Hugging Face 的 Philipp Schmid 稱其為「2026 年最重要的學科」。
一個新的工程學科在 90 天內誕生了。
而 AI 基礎架構團隊以外的人，幾乎還不了解它。
這篇文章會解釋一切。
不廢話。沒有學術術語。只有你實際運用時需要的思維模型。
請收藏這篇。你會讀兩次。
第一部分：Harness 到底是什麼（一個改變你對 AI 看法的概念）
1. Harness 的定義
最簡單的定義來自 ThoughtWorks：
→ Agent = 模型 + Harness
Harness 就是模型以外的一切。
那些讓 Agent 保持在正軌上的限制條件。那些能捕捉錯誤的回饋迴路。那些告訴 Agent 身在何處的文件。那些它被允許使用的工具。
拿掉 Harness → 原始語言模型在你的程式碼庫中瞎猜。
加上正確的 Harness → 能夠交付生產級程式碼的系統。
這個名字來自馬具。
Harness 就是韁繩、馬鞍和馬銜，用來引導一頭強大但難以預測的動物往有用的方向前進。
你不是讓馬變得更聰明。你是設計讓牠的力量得以發揮的裝備。
2. 作業系統的比喻
Philipp Schmid 給出了最好的技術框架：
把它想成一台電腦。
→ 模型 = CPU（原始運算能力）
→ 上下文視窗 = RAM（有限、易失的工作記憶體）
→ Harness = 作業系統（管理 CPU 看到什麼以及何時看到）
→ Agent = 在上面運行的應用程式
你的模型很強大。
但如果沒有作業系統來管理記憶體、排程任務和執行規則——它就只是塊矽晶片。
大多數人都在沒有作業系統的情況下運行應用程式。
這就是他們的 Agent 在生產環境中失敗的原因。
3. 2026 年發生了什麼改變
LangChain 在 Terminal Bench 2.0 上對同一個模型測試了兩次。
同一個模型。不同的 Harness。
→ 舊 Harness：52.8% 分數
→ 新 Harness：66.5% 分數
Vercel 則走了相反的方向。
他們移除了 Agent 80% 的工具。
結果呢？效能更好了。
不是更差。
2026 年令人不安的真相：
→ Agent 從來都不是最難的部分。
→ Harness 才是。
如果說 2025 年是 AI Agent 證明自己能寫程式碼的一年……
那麼 2026 年就是我們發現環境比模型更重要的一年。
第二部分：5 種 Harness 產出物（Harness 在實務上長什麼樣子）
4. AGENT.md / CLAUDE.md 檔案
最普遍的 Harness 產出物。
分散在程式碼庫各處的 Markdown 檔案。
Agent 在每次工作階段開始時讀取它們——就像新工程師加入團隊時的入職文件。
裡面包含什麼：
→ 專案背景
→ 編碼慣例
→ 架構決策
→ 「我們這裡怎麼做事」的指引
→ 目前正在進行的事項
OpenAI 稱它們為 AGENT.md。
Anthropic 稱它們為 CLAUDE.md。
Cursor 使用 .cursorrules。
名稱不同。原理相同。
每個主要模組一個檔案。隨著專案演進而更新。
沒有它們：Agent 每次工作階段都從零開始，一無所知。有了它們：Agent 每次工作階段都資訊充足地開始。
5. JSON 功能列表（進度追蹤器）
當 Agent 跨越多個工作階段建立一個完整應用程式時，它每次工作階段開始時，上下文視窗都是空白的。
它怎麼知道哪些已經完成了？
靠一個 JSON 檔案。
每個條目定義了：
→ 一個功能
→ 如何驗證它是否正常運作
→ 通過 / 失敗狀態
Agent 在工作階段開始時讀取這個檔案。挑選優先級最高且狀態為失敗的功能。實作它。將其標記為通過。提交。重複。
為什麼用 JSON 而不是 Markdown？
Anthropic 發現 Agent 意外覆寫 JSON 的可能性比覆寫 Markdown 低。
小細節。在長達 6 小時的自動運行中影響巨大。
6. 工作階段初始化流程
每次工作階段都以相同方式開始。
每一次。毫無例外。
Anthropic 的 7 步驟啟動順序：
- 確認工作目錄
- 讀取 git 日誌和進度檔案
- 檢查功能列表，找出優先級最高的未完成項目
- 啟動開發伺服器
- 執行基本端到端驗證
- 實作一個功能
- 提交並附上描述性訊息 + 更新進度
沒有這個流程：
Agent 會浪費前 20 分鐘搞清楚已經存在什麼。
每次工作階段都在重新發明輪子。
有了它：
Agent 立即資訊充足地開始，並直接投入工作。
7. Sprint 合約
在 Agent 寫下任何一行程式碼之前：
兩個 Agent 會進行協商。
生成 Agent 提議：
→ 它將要建置什麼
→ 如何驗證成功
評估 Agent 審查：
→ 提案是否完整？
→ 成功標準是否明確？
只有在雙方都同意之後，實作才開始。
這是一場設計審查。
只不過參與雙方都是 AI。
為什麼這很重要？
在同一次執行中同時規劃和執行的 Agent，會產出不可靠的輸出。
規劃步驟——即使是由 AI 完成——也能顯著提升輸出品質。
8. 結構化任務模板
在任何編碼開始之前：
Harness 會分析真實的程式碼庫。
它會產出一個基於實際情況的影響圖：
→ 真實的檔案路徑（不是幻覺產生的）
→ 實際存在的真實符號名稱
→ 要遵循的現有模式
→ 具體的驗收標準
然後才開始實作。
這聽起來很理所當然。
但大多數團隊都跳過這一步。
Agent 猜測檔案結構。發明不存在的 API 端點。建置出不符合程式碼庫的東西。
在執行之前提供基於實際情況的上下文 → 輸出品質大幅提升。
第三部分：三大陣營（三個團隊撞上同一堵牆——並建造了三種不同的梯子）
9. OpenAI：環境優先
OpenAI 的 Codex 團隊遇到了一個荒謬的問題。
100 萬行生產級程式碼。沒有一行是手寫的。
在那樣的規模下，你不可能審查每一行程式碼。
所以他們沒有這麼做。
取而代之的是：
他們如此徹底地設計了環境，以至於 Agent 一開始就能產出可審查的輸出。
他們的做法：
→ 嚴格的依賴流程（類型 → 設定 → 儲存庫 → 服務 → 執行環境 → UI）
→ 整個程式碼庫中的 AGENT.md 檔案
→ Agent 直接整合到 CI/CD 管線中
理念是：設計好環境。然後放 Agent 出去。
證明：Sora Android 應用程式。4 名工程師。28 天。Play Store 排名第一。99.9% 無崩潰率。
Codex 每週處理了 70% 的內部 Pull Request。
10. Anthropic：將執行者與評判者分開
Anthropic 遇到了不同的問題。
當他們要求 Agent 評估自己的輸出時：
它會自信地讚揚自己的工作。
即使，在人類觀察者看來，品質明顯平庸。
自我評估行不通。
Agent 同時是學生和老師。
而且它給自己打的全是 A。
他們的解決方案：三個專門的 Agent。
→ 規劃者 — 將 2 句話的提示轉換成完整的產品規格
→ 生成者 — 一次一個 Sprint 地實作功能
→ 評估者 — 使用瀏覽器自動化來像真實使用者一樣測試運行中的應用程式
關鍵洞察：讓一個獨立的評估者保持懷疑，遠比讓生成者對自己的工作保持批判要容易得多。
結果：單一 Agent（無 Harness）：9 美元，20 分鐘 → 壞掉的應用程式。完整 Harness：200 美元，6 小時 → 可運作的軟體，精美的 UI。
11. ThoughtWorks：2×2 框架
ThoughtWorks 從不同的角度切入。
他們不是在建置產品。
他們在觀察 50 多個工程團隊在同樣的事情上失敗。
他們的洞察：沿著兩個軸線對每個 Harness 控制項進行分類。
軸線 1： 它何時運作？
→ 前饋 = 在 Agent 行動之前（引導）
→ 回饋 = 在 Agent 行動之後（感測器）
軸線 2： 它如何運作？
→ 計算型 = 確定性，毫秒級（linter、型別檢查器、測試套件）
→ 推論型 = 使用 LLM，秒級（程式碼審查 Agent、語意分析）
2×2 矩陣：
→ 計算型前饋：型別系統、linter、架構規則
→ 計算型回饋：測試套件、覆蓋率分析、突變測試
→ 推論型前饋：規格文件、約束描述
→ 推論型回饋：LLM 程式碼審查者、行為驗證器
單靠前饋或單靠回饋都行不通。
你需要兩者兼備。
第四部分：每個陣營都同意的 5 項原則（三個團隊從未協調過。他們獨立得出了相同的結論。）
12. 原則 1：上下文勝過指令
OpenAI：「給一張地圖，而不是一本 1000 頁的操作手冊。」
Anthropic：JSON 功能列表和進度檔案，讓 Agent 永遠知道自己的位置。
Red Hat：在生成任何任務之前，先分析真實的程式碼庫。
ThoughtWorks：「前饋。」
不同的詞彙。同樣的發現。
向 Agent 展示世界的當前狀態，始終優於抽象地告訴它該做什麼。
→ 基於真實檔案路徑 → 符合程式碼庫的程式碼
→ 根據模糊描述工作 → 幻覺產生的檔案路徑和發明的 API
教訓：在 Agent 輸入任何東西之前，確保它確切知道自己在哪裡。
13. 原則 2：規劃與執行必須分離
OpenAI：人類設計環境，Agent 執行。
Anthropic：專職的規劃者 Agent 在生成者接觸任何程式碼之前運行。
ThoughtWorks：在規劃和實作之間設置強制的人工審查檢查點。
Red Hat：第一階段（影響圖）和第二階段（實作）之間設有嚴格的關卡。
每個陣營都獨立發現了這一點：
讓 Agent 在同一次執行中規劃和執行，會產出不可靠的輸出。
規劃步驟不一定得由人類完成。
但它必須是一個獨立的步驟，並且在實作開始之前，其輸出需要經過審查。
14. 原則 3：回饋迴路是無可妥協的
OpenAI：Agent 整合到 CI/CD 和可觀測性系統中。
Anthropic：使用瀏覽器自動化的專職評估者 Agent。
ThoughtWorks：將其正式化為「感測器」。警告說，僅前饋的方法永遠無法確認引導是否真的有效。
同一原則的三種方法：
→ OpenAI 使用自動化測試和 CI
→ Anthropic 使用另一個 LLM
→ ThoughtWorks 說兩者都用，分層實施
他們在由誰提供回饋這點上意見不一。
但他們對於是否需要回饋這一點上並無分歧。
沒有回饋的 Harness 只是一個多了幾個步驟的提示詞。
15. 原則 4：一次只做一件事
OpenAI：將目標分解成較小的建構區塊，深度優先地工作。
Anthropic：強制每個 Sprint 只做一個功能，並在每個功能後提交。
ThoughtWorks：分階段的生命週期（整合前 → 整合後 → 持續監控）。
試圖一次做太多事的 Agent：
→ 耗盡上下文
→ 失去連貫性
→ 默默地遺漏需求
Anthropic 的例行程序：
讀取進度 → 挑選一個功能 → 實作 → 提交 → 重複
強制性的漸進主義是所有成功的 Harness 中普遍存在的原則。
16. 原則 5：程式碼庫本身就是文件
OpenAI：將 AGENT.md 檔案嵌入儲存庫中。
Anthropic：將功能列表、進度檔案和 git 歷史作為 Agent 的連續性機制。
ThoughtWorks：衡量「Harness 適應性」——程式碼庫對 Agent 而言的可讀性。
沒有人為 Agent 維護一個單獨的知識庫。
儲存庫是唯一的真相來源。
如果一個慣例、約束或架構決策不在程式碼庫中——Agent 就不會知道它。
實際影響：
→ 投資於程式碼組織的團隊，可以免費獲得更好的 Agent 效能。
→ 混亂的儲存庫 + AI Agent = 混亂，而且是規模化的混亂。
第五部分：悖論——為了刪除而建置（Harness 工程中最反直覺的真相）
17. Harness 衰減是真實存在的
當 Anthropic 從 Opus 4.5 升級到 Opus 4.6 時：
Sprint 分解——之前至關重要的步驟——變成了累贅。
模型改進後的規劃能力使其變得冗餘。
一個在三月份還是承重結構的 Harness 組件，到了四月份就成了開銷。
然後 Opus 4.7 來了。
模型開始驗證自己的輸出。
評估者 Agent 的工作描述開始縮減。
這就是 Harness 衰減。
Harness 中的每個組件都編碼了一個關於模型無法做到什麼的假設。
隨著模型改進 → 這些假設過期 → 該組件變成開銷。
Opus 4.5：Sprint 分解 + 每個 Sprint 評估
Opus 4.6：無 Sprint 分解 + 單次評估（節省 38% 成本）
Opus 4.7：模型開始自我驗證 → 評估者角色進一步縮減
18. 為了刪除而建置
Philipp Schmid 的建議：
「為了刪除而建置。」
將每個 Harness 組件設計成可移除的。
定期測試每個組件：關閉它，並衡量輸出品質是否改變。
如果沒有改變：刪除它。
Manus 在 6 個月內重構了他們的 Harness 5 次。LangChain 在 1 年內重組了 3 次。Vercel 移除了 80% 的工具 → 獲得了更好的效能。
這些不是工程品質差的跡象。
它們是在快速改進的模型之上建置的自然結果。
攜帶無用的 Harness 組件會在每次運行中消耗 Token。零額外品質。純粹的浪費。
19. 成本現實
來自 Anthropic A/B 測試的真實數據：
→ 單一 Agent（無 Harness）：9 美元，20 分鐘 → 可運作的 UI，損壞的核心功能
→ 完整 Harness（Opus 4.5）：200 美元，6 小時 → 可運作的軟體，精美的 UI，正確的物理效果
這是 22 倍的成本增加。
換來一個功能完整的產品，對比一個只在螢幕截圖中看起來不錯的展示品。
這算是昂貴還是便宜，完全取決於一次有問題的發布會讓你的團隊付出什麼代價。
但這裡有件沒人談論的事：
Harness + 模型的組合會演進。
那個 200 美元的 Harness，在一次模型升級後變成了 124 美元。
趨勢線：
→ 更好的模型 = 更簡單的 Harness = 更便宜的運行 = 更快的輸出
2026 年勝出的工程師，不是寫出最好程式碼的人。
他們是設計出最佳限制條件的人。
並且願意在這些限制條件不再值得保留的那一刻，就將它們拋棄。
結語
你剛剛學到的一切：
什麼是 Harness：
→ 1. Agent = 模型 + Harness
→ 2. 模型 = CPU。Harness = 作業系統。
→ 3. 同一個模型，更好的 Harness = +13% 效能
5 種 Harness 產出物：
→ 4. CLAUDE.md / AGENT.md — Agent 的入職文件
→ 5. JSON 功能列表 — 進度追蹤器 + 測試套件二合一
→ 6. 工作階段初始化流程 — 每次都執行相同的 7 步驟啟動
→ 7. Sprint 合約 — Agent 在編碼前進行協商
→ 8. 結構化任務模板 — 真實的檔案路徑，真實的模式
三大陣營：
→ 9. OpenAI：設計環境，放 Agent 出去
→ 10. Anthropic：將執行者與評判者分開
→ 11. ThoughtWorks：2×2 前饋/回饋框架
5 項普遍原則：
→ 12. 上下文勝過指令
→ 13. 規劃與執行必須分離
→ 14. 回饋迴路是無可妥協的
→ 15. 一次只做一件事
→ 16. 程式碼庫本身就是文件
悖論：
→ 17. Harness 衰減 — 上個月有效的東西，這個月可能有害
→ 18. 為了刪除而建置 — 測試並移除無用的組件
→ 19. 成本現實 — 更好的模型 = 更簡單的 Harness = 更便宜的運行
2026 年勝出的工程師，不是寫出最好程式碼的人。
他們是設計出最佳限制條件的人。
並且願意在這些限制條件不再值得保留的那一刻，就將它們拋棄。
如果這篇文章對你有幫助：
→ 轉發給你的社群，讓更多建構者看到
→ 追蹤 @sairahul1 每週獲取更多類似內容
→ 收藏這篇 — 當你的 Agent 開始出問題時，你會回來參考它
我撰寫關於 AI、產品建置，以及 2026 年真正有效的方法。
