系統拆解 Harness Engineering 5 個產物、3 個學派（OpenAI / Anthropic / ThoughtWorks）、5 條普世原則，以及為什麼「Harness 衰退」逼你每 6 個月就得砍掉一半的設計。本文源自 @sairahul1 所著 X 文章，動區整理、編譯。 （前情提要：Harness Engineering(AI駕馭工程)入門篇:OpenAI最新程式設計標準,教你輕鬆做到Lv.1） （背景補充：YC 執行長分享 AI 秘訣:未來屬於會搭建資訊複利系統的人）
本文目錄
Toggle
2026 年 2 月，OpenAI 一個小團隊出了 100 萬行生產級程式碼。
他們一行手寫的都沒有。
AI agent 寫的。
人類設計的，是讓 agent 可靠的那套系統。
這套系統現在有名字了——Harness Engineering。
幾週內，Anthropic 發了 3 篇相關論文。ThoughtWorks 把它整理成框架。Hugging Face 的 Philipp Schmid 直接稱它是「2026 年最重要的學科」。
90 天內，一個新工程學科就成形了。而 AI infra 團隊之外，幾乎沒人看懂。
這篇文章就是把它講清楚。沒有廢話、沒有學術術語，只有你真的拿來用會需要的心智模型。
ThoughtWorks 給的最簡定義：
Agent = Model + Harness
Harness 就是模型以外的所有東西。
剝掉 harness → 一個在你 codebase 裡瞎猜的原始語言模型。
加上對的 harness → 一個能出生產級程式碼的系統。
這個名字來自馬具。Harness 是韁繩、馬鞍、馬銜——把一頭力量強大但難以預測的動物導向有用的方向。
你不是把馬變聰明，你是設計一套裝備，讓牠的力量變得有用。
Philipp Schmid 給的最好的技術比喻是：把它想成一台電腦。
| 角色 | | --- | 對應 | | --- | --- | | Model | CPU（原始算力） | | Context window | RAM（有限、易揮發的工作記憶） | | Harness | OS（管理 CPU 看到什麼、什麼時候看到） | | Agent | 跑在上面的 App |
你的模型很強。但沒有 OS 來管記憶體、排程任務、執行規則——它就只是一塊矽。
大多數人是在「沒有作業系統」的情況下跑 app。所以他們的 agent 一上生產線就壞。
LangChain 用同一個模型，在 Terminal Bench 2.0 上跑了兩次：
| Harness | | --- | 分數 | | --- | --- | | 舊 harness | 52.8% | | 新 harness | 66.5% |
同樣的模型。不同的 harness。差 13.7 個百分點。
Vercel 反過來做——砍掉 agent 80% 的工具。結果？更好，不是更差。
2026 年最不舒服的真相：
如果 2025 是 AI agent 證明自己會寫程式的一年，2026 就是發現「環境」比「模型」更重要的一年。
最通用的 harness 產物。
散落在 codebase 各處的 markdown 檔案。Agent 每次 session 一開始就讀——像新工程師到職的 onboarding 文件。
裡面寫什麼？
OpenAI 叫它 AGENT.md。 Anthropic 叫它 CLAUDE.md。 Cursor 用 .cursorrules。
不同名字，同一原則。每個主要模組一份。隨專案演進更新。
沒有它：agent 每次 session 都是盲開機。 有了它：agent 每次 session 都帶著情報上工。
當 agent 跨多個 session 蓋一整個 app 時，每次 session 的 context window 都是空的。它怎麼知道哪些已經做完了？
一個 JSON 檔案。
每一筆寫：
Agent session 一開始就讀它——挑最高優先級的 fail → 實作 → 標 pass → commit → 重複。
Anthropic 發現：agent 不小心覆寫 JSON 的機率比覆寫 Markdown 低。
細節很小，但在 6 小時自主跑的場景裡很關鍵。
每一次 session 都用同樣方式開機。每 一 次。
Anthropic 的 7 步開機程序：
沒有它：agent 前 20 分鐘都在搞清楚現有狀態，每個 session 都在重複造輪子。 有了它：agent 一開始就帶著情報直接幹活。
寫任何一行程式碼之前——兩個 agent 先談判。
Generator agent 提案：
Evaluator agent 審查：
兩邊都同意，實作才開始。
是設計審查。只是兩邊都是 AI。
在同一輪裡同時規劃和執行的 agent，產出不可靠。「規劃」這一步——即使是 AI 做的——也會大幅提升輸出品質。
寫任何程式碼之前，harness 先分析真正的 codebase。
它產出一份接地的衝擊地圖（grounded impact map）：
然後實作才開始。
聽起來理所當然。但大多數團隊都跳過這一步。
Agent 猜檔案結構、發明根本不存在的 API、做一個跟 codebase 不搭的東西。
先有接地的 context，再執行 → 輸出品質會差非常多。
OpenAI 的 Codex 團隊有個荒謬的問題：
100 萬行生產級程式碼，零行手寫。
在那個規模，你不可能逐行 code review。所以他們不做。
取而代之——他們把環境設計得徹底到一個程度，讓 agent 從一開始就產出「可被審查的輸出」。
哲學：設計環境。然後放 agent 去跑。
Sora Android app。4 個工程師。28 天。Play Store #1。99.9% crash-free。
Codex 每週處理內部 70% 的 PR。
Anthropic 遇到的是另一個問題：
當他們叫 agent 評估自己的輸出時，它會自信地稱讚自己的作品——即使在人類觀察者眼裡品質明顯平庸。
自評不行。 Agent 同時是學生跟老師，然後給自己打全 A。
| Agent | | --- | 工作 | | --- | --- | | Planner | 把 2 句話的 prompt 變成完整產品規格 | | Generator | 一次一個 sprint 實作 | | Evaluator | 用瀏覽器自動化測試，像真實使用者一樣操作 |
洞察：讓「獨立的 evaluator」變得挑剔，比讓 generator 對自己的作品變得挑剔容易得多。
| 設定 | | --- | 成本 | 時間 | 結果 | | --- | --- | --- | --- | | 單 agent（無 harness） | $9 | 20 分鐘 | 壞掉的 app | | 完整 harness | $200 | 6 小時 | 可運作軟體 + 精緻 UI |
ThoughtWorks 從不同角度切入——他們不是在做產品，而是在看 50+ 個工程團隊在同樣的地方失敗。
軸 1：什麼時候運作？
軸 2：怎麼運作？
| | | --- | Feedforward（指引） | Feedback（感測） | | --- | --- | --- | | Computational | type system、linter、架構規則 | test suite、coverage、mutation test | | Inferential | spec 文件、約束描述 | LLM code reviewer、行為驗證器 |
Feedforward 跟 feedback 哪一邊單獨用都不行。兩邊都要有。
不同團隊，同一發現：
把 agent 接地在「世界當前的狀態」，持續勝過抽象地告訴它要做什麼。
接地在真實檔案路徑 → 適配 codebase 的程式碼。 從含糊描述出發 → 幻覺路徑與發明 API。
在 agent 打字之前，先確保它知道自己在哪裡。
每一個陣營都獨立發現：讓 agent 在同一輪裡規劃和執行，輸出不可靠。
規劃這一步不一定要人類做，但必須是分開的一步，且輸出要被審過才能開工。
三個學派同一原則的三種做法：
| 學派 | | --- | feedback 來源 | | --- | --- | | OpenAI | 自動化測試 + CI | | Anthropic | 另一個 LLM | | ThoughtWorks | 兩者疊用 |
他們在「誰提供 feedback」上有分歧。但他們在「你需不需要 feedback」上沒有分歧。
沒有 feedback 的 harness，只是 prompt 加一些步驟而已。
一次想做太多的 agent 會：
Anthropic 的常規：讀進度 → 挑 ONE feature → 實作 → commit → 重複。
「強制漸進主義」是所有成功 harness 的共通點。
沒人會幫 agent 另外維護一份知識庫。Repo 就是唯一真相。
如果一個慣例、約束、架構決策不在 codebase 裡 → agent 就不會知道。
Anthropic 從 Opus 4.5 升到 Opus 4.6 時——Sprint 拆解（原本是必備的）變成了死重。
模型的規劃能力進步了，讓那塊變多餘。
3 月還在承重的 harness 組件，到 4 月已變成 overhead。
然後 Opus 4.7 上線——模型開始驗證自己的輸出，Evaluator agent 的職責又縮水了。
Harness 裡的每個組件都隱含「模型做不到什麼」的假設。模型進步 → 那些假設過期 → 組件變 overhead。
| 模型版本 | | --- | Harness 樣態 | | --- | --- | | Opus 4.5 | sprint 拆解 + 每 sprint 評估 | | Opus 4.6 | 沒有 sprint 拆解 + 單次評估（省 38% 成本） | | Opus 4.7 | 模型自驗 → evaluator 角色再縮 |
Philipp Schmid 的建議：「Build to delete.」
設計每個 harness 組件時，就設計成可被移除。
定期測試每個組件——把它關掉，量輸出品質有沒有差。沒差 → 刪掉。
| 團隊 | | --- | 6 個月內的重構 | | --- | --- | | Manus | 重構 harness 5 次 | | LangChain | 1 年內重整 3 次 | | Vercel | 砍掉 80% 工具 → 表現變更好 |
這些不是壞工程的徵兆。是「在快速進步的模型上蓋東西」的自然後果。
死掉的 harness 組件每次跑都在燒 token，零品質貢獻——純浪費。
Anthropic A/B test 的誠實數字：
| 設定 | | --- | 成本 | 時間 | 結果 | | --- | --- | --- | --- | | 單 agent（無 harness） | $9 | 20 分鐘 | UI 動了，核心壞 | | 完整 harness（Opus 4.5） | $200 | 6 小時 | 可運作軟體，精緻 UI，正確物理 |
22 倍成本——換到一個真的能跑的產品，而不是「螢幕截圖才對」的 demo。
值不值得？取決於壞掉的 release 對你的團隊代價多大。
Harness + 模型的組合是會演化的。
$200 的 harness，升一個模型版本後變 $124。
| 趨勢線 | | --- | | 更好的模型 = 更簡單的 harness = 更便宜的跑一次 = 更快的輸出 |
2026 年贏的工程師，不是寫最好的程式碼的。 他們是設計最好「約束」的人。 而且願意在那些約束停止賺錢的瞬間，把它們扔掉。
2026 年贏的工程師，不是寫最好的程式碼的。
他們是設計最好「約束」的人。
而且願意在那些約束停止賺錢的瞬間，把它們扔掉。
2026 年贏的工程師，不是寫最好程式碼的。他們是設計最好約束的人——而且願意在那些約束停止賺錢的瞬間，把它們扔掉。
658.36萬 熱度
288.28萬 熱度
10.95萬 熱度
182.21萬 熱度
85.38萬 熱度
為什麼你必須學 Harness Engineering？5 個產物、3 個學派、5 條普世原則全解析
系統拆解 Harness Engineering 5 個產物、3 個學派（OpenAI / Anthropic / ThoughtWorks）、5 條普世原則，以及為什麼「Harness 衰退」逼你每 6 個月就得砍掉一半的設計。本文源自 @sairahul1 所著 X 文章，動區整理、編譯。
（前情提要：Harness Engineering(AI駕馭工程)入門篇:OpenAI最新程式設計標準,教你輕鬆做到Lv.1）
（背景補充：YC 執行長分享 AI 秘訣:未來屬於會搭建資訊複利系統的人）
本文目錄
Toggle
2026 年 2 月，OpenAI 一個小團隊出了 100 萬行生產級程式碼。
他們一行手寫的都沒有。
AI agent 寫的。
人類設計的，是讓 agent 可靠的那套系統。
這套系統現在有名字了——Harness Engineering。
幾週內，Anthropic 發了 3 篇相關論文。ThoughtWorks 把它整理成框架。Hugging Face 的 Philipp Schmid 直接稱它是「2026 年最重要的學科」。
90 天內，一個新工程學科就成形了。而 AI infra 團隊之外，幾乎沒人看懂。
這篇文章就是把它講清楚。沒有廢話、沒有學術術語，只有你真的拿來用會需要的心智模型。
1. Harness 的定義
ThoughtWorks 給的最簡定義：
Harness 就是模型以外的所有東西。
剝掉 harness → 一個在你 codebase 裡瞎猜的原始語言模型。
加上對的 harness → 一個能出生產級程式碼的系統。
這個名字來自馬具。Harness 是韁繩、馬鞍、馬銜——把一頭力量強大但難以預測的動物導向有用的方向。
你不是把馬變聰明，你是設計一套裝備，讓牠的力量變得有用。
2. OS 比喻
Philipp Schmid 給的最好的技術比喻是：把它想成一台電腦。
| 角色 | | --- | 對應 | | --- | --- | | Model | CPU（原始算力） | | Context window | RAM（有限、易揮發的工作記憶） | | Harness | OS（管理 CPU 看到什麼、什麼時候看到） | | Agent | 跑在上面的 App |
你的模型很強。但沒有 OS 來管記憶體、排程任務、執行規則——它就只是一塊矽。
大多數人是在「沒有作業系統」的情況下跑 app。所以他們的 agent 一上生產線就壞。
3. 2026 年到底變了什麼
LangChain 用同一個模型，在 Terminal Bench 2.0 上跑了兩次：
| Harness | | --- | 分數 | | --- | --- | | 舊 harness | 52.8% | | 新 harness | 66.5% |
同樣的模型。不同的 harness。差 13.7 個百分點。
Vercel 反過來做——砍掉 agent 80% 的工具。結果？更好，不是更差。
2026 年最不舒服的真相：
如果 2025 是 AI agent 證明自己會寫程式的一年，2026 就是發現「環境」比「模型」更重要的一年。
4. AGENT.md / CLAUDE.md 檔案
最通用的 harness 產物。
散落在 codebase 各處的 markdown 檔案。Agent 每次 session 一開始就讀——像新工程師到職的 onboarding 文件。
裡面寫什麼？
OpenAI 叫它 AGENT.md。 Anthropic 叫它 CLAUDE.md。 Cursor 用 .cursorrules。
不同名字，同一原則。每個主要模組一份。隨專案演進更新。
沒有它：agent 每次 session 都是盲開機。 有了它：agent 每次 session 都帶著情報上工。
5. JSON Feature Lists（進度追蹤器）
當 agent 跨多個 session 蓋一整個 app 時，每次 session 的 context window 都是空的。它怎麼知道哪些已經做完了？
一個 JSON 檔案。
每一筆寫：
Agent session 一開始就讀它——挑最高優先級的 fail → 實作 → 標 pass → commit → 重複。
為什麼是 JSON 不是 Markdown？
Anthropic 發現：agent 不小心覆寫 JSON 的機率比覆寫 Markdown 低。
細節很小，但在 6 小時自主跑的場景裡很關鍵。
6. Session 初始化常規
每一次 session 都用同樣方式開機。每 一 次。
Anthropic 的 7 步開機程序：
沒有它：agent 前 20 分鐘都在搞清楚現有狀態，每個 session 都在重複造輪子。 有了它：agent 一開始就帶著情報直接幹活。
7. Sprint Contracts（衝刺契約）
寫任何一行程式碼之前——兩個 agent 先談判。
Generator agent 提案：
Evaluator agent 審查：
兩邊都同意，實作才開始。
是設計審查。只是兩邊都是 AI。
為什麼重要
在同一輪裡同時規劃和執行的 agent，產出不可靠。「規劃」這一步——即使是 AI 做的——也會大幅提升輸出品質。
8. Structured Task Templates（結構化任務樣板）
寫任何程式碼之前，harness 先分析真正的 codebase。
它產出一份接地的衝擊地圖（grounded impact map）：
然後實作才開始。
聽起來理所當然。但大多數團隊都跳過這一步。
Agent 猜檔案結構、發明根本不存在的 API、做一個跟 codebase 不搭的東西。
先有接地的 context，再執行 → 輸出品質會差非常多。
9. OpenAI 的學派：環境優先
OpenAI 的 Codex 團隊有個荒謬的問題：
在那個規模，你不可能逐行 code review。所以他們不做。
取而代之——他們把環境設計得徹底到一個程度，讓 agent 從一開始就產出「可被審查的輸出」。
他們的做法
哲學：設計環境。然後放 agent 去跑。
證據
Sora Android app。4 個工程師。28 天。Play Store #1。99.9% crash-free。
Codex 每週處理內部 70% 的 PR。
10. Anthropic 的學派：把「做」和「審」分開
Anthropic 遇到的是另一個問題：
當他們叫 agent 評估自己的輸出時，它會自信地稱讚自己的作品——即使在人類觀察者眼裡品質明顯平庸。
自評不行。 Agent 同時是學生跟老師，然後給自己打全 A。
他們的解法：3 個專責 agent
| Agent | | --- | 工作 | | --- | --- | | Planner | 把 2 句話的 prompt 變成完整產品規格 | | Generator | 一次一個 sprint 實作 | | Evaluator | 用瀏覽器自動化測試，像真實使用者一樣操作 |
洞察：讓「獨立的 evaluator」變得挑剔，比讓 generator 對自己的作品變得挑剔容易得多。
結果（A/B 測試）
| 設定 | | --- | 成本 | 時間 | 結果 | | --- | --- | --- | --- | | 單 agent（無 harness） | $9 | 20 分鐘 | 壞掉的 app | | 完整 harness | $200 | 6 小時 | 可運作軟體 + 精緻 UI |
11. ThoughtWorks 的學派：2×2 框架
ThoughtWorks 從不同角度切入——他們不是在做產品，而是在看 50+ 個工程團隊在同樣的地方失敗。
他們的洞察：用兩個軸分類每一個 harness 控制
軸 1：什麼時候運作？
軸 2：怎麼運作？
2×2 矩陣
| | | --- | Feedforward（指引） | Feedback（感測） | | --- | --- | --- | | Computational | type system、linter、架構規則 | test suite、coverage、mutation test | | Inferential | spec 文件、約束描述 | LLM code reviewer、行為驗證器 |
Feedforward 跟 feedback 哪一邊單獨用都不行。兩邊都要有。
12. 原則 1：Context 勝過 Instruction
不同團隊，同一發現：
接地在真實檔案路徑 → 適配 codebase 的程式碼。 從含糊描述出發 → 幻覺路徑與發明 API。
在 agent 打字之前，先確保它知道自己在哪裡。
13. 原則 2：規劃與執行必須分離
每一個陣營都獨立發現：讓 agent 在同一輪裡規劃和執行，輸出不可靠。
規劃這一步不一定要人類做，但必須是分開的一步，且輸出要被審過才能開工。
14. 原則 3：Feedback 迴路不可妥協
三個學派同一原則的三種做法：
| 學派 | | --- | feedback 來源 | | --- | --- | | OpenAI | 自動化測試 + CI | | Anthropic | 另一個 LLM | | ThoughtWorks | 兩者疊用 |
他們在「誰提供 feedback」上有分歧。但他們在「你需不需要 feedback」上沒有分歧。
15. 原則 4：一次只做一件事
一次想做太多的 agent 會：
Anthropic 的常規：讀進度 → 挑 ONE feature → 實作 → commit → 重複。
「強制漸進主義」是所有成功 harness 的共通點。
16. 原則 5：Codebase 本身就是文件
沒人會幫 agent 另外維護一份知識庫。Repo 就是唯一真相。
如果一個慣例、約束、架構決策不在 codebase 裡 → agent 就不會知道。
實務含意
17. Harness 衰退（Harness Decay）是真的
Anthropic 從 Opus 4.5 升到 Opus 4.6 時——Sprint 拆解（原本是必備的）變成了死重。
模型的規劃能力進步了，讓那塊變多餘。
3 月還在承重的 harness 組件，到 4 月已變成 overhead。
然後 Opus 4.7 上線——模型開始驗證自己的輸出，Evaluator agent 的職責又縮水了。
這就是 Harness 衰退
| 模型版本 | | --- | Harness 樣態 | | --- | --- | | Opus 4.5 | sprint 拆解 + 每 sprint 評估 | | Opus 4.6 | 沒有 sprint 拆解 + 單次評估（省 38% 成本） | | Opus 4.7 | 模型自驗 → evaluator 角色再縮 |
18. 為刪除而建（Build to Delete）
Philipp Schmid 的建議：「Build to delete.」
設計每個 harness 組件時，就設計成可被移除。
定期測試每個組件——把它關掉，量輸出品質有沒有差。沒差 → 刪掉。
| 團隊 | | --- | 6 個月內的重構 | | --- | --- | | Manus | 重構 harness 5 次 | | LangChain | 1 年內重整 3 次 | | Vercel | 砍掉 80% 工具 → 表現變更好 |
這些不是壞工程的徵兆。是「在快速進步的模型上蓋東西」的自然後果。
19. 成本現實
Anthropic A/B test 的誠實數字：
| 設定 | | --- | 成本 | 時間 | 結果 | | --- | --- | --- | --- | | 單 agent（無 harness） | $9 | 20 分鐘 | UI 動了，核心壞 | | 完整 harness（Opus 4.5） | $200 | 6 小時 | 可運作軟體，精緻 UI，正確物理 |
22 倍成本——換到一個真的能跑的產品，而不是「螢幕截圖才對」的 demo。
值不值得？取決於壞掉的 release 對你的團隊代價多大。
但這裡是沒人在講的部分
Harness + 模型的組合是會演化的。
$200 的 harness，升一個模型版本後變 $124。
| 趨勢線 | | --- | | 更好的模型 = 更簡單的 harness = 更便宜的跑一次 = 更快的輸出 |
全文濃縮
什麼是 harness
5 個 harness 產物
3 個學派
5 條普世原則
弔詭之處
2026 年贏的工程師，不是寫最好程式碼的。他們是設計最好約束的人——而且願意在那些約束停止賺錢的瞬間，把它們扔掉。