系統拆解 Harness Engineering 5 個產物、3 個學派(OpenAI / Anthropic […] 〈為什麼你必須學 Harness Engineering?5 個產物、3 個學派、5 條普世原則全解析〉這篇文章最早發佈於動區BlockTempo《動區動趨-最具影響力的區塊鏈新聞媒體》。系統拆解 Harness Engineering 5 個產物、3 個學派(OpenAI / Anthropic […] 〈為什麼你必須學 Harness Engineering?5 個產物、3 個學派、5 條普世原則全解析〉這篇文章最早發佈於動區BlockTempo《動區動趨-最具影響力的區塊鏈新聞媒體》。

為什麼你必須學 Harness Engineering?5 個產物、3 個學派、5 條普世原則全解析

2026/06/09 12:33
閱讀時長 20 分鐘
如需對本內容提供反饋或相關疑問,請通過郵箱 crypto.news@mexc.com 聯絡我們。

系統拆解 Harness Engineering 5 個產物、3 個學派(OpenAI / Anthropic / ThoughtWorks)、5 條普世原則,以及為什麼「Harness 衰退」逼你每 6 個月就得砍掉一半的設計。本文源自 @sairahul1 所著 X 文章,動區整理、編譯。
(前情提要:Harness Engineering(AI駕馭工程)入門篇:OpenAI最新程式設計標準,教你輕鬆做到Lv.1
(背景補充:YC 執行長分享 AI 秘訣:未來屬於會搭建資訊複利系統的人

本文目錄

Toggle
  • 1. Harness 的定義
  • 2. OS 比喻
  • 3. 2026 年到底變了什麼
  • 4. AGENT.md / CLAUDE.md 檔案
  • 5. JSON Feature Lists(進度追蹤器)
    • 為什麼是 JSON 不是 Markdown?
  • 6. Session 初始化常規
  • 7. Sprint Contracts(衝刺契約)
    • 為什麼重要
  • 8. Structured Task Templates(結構化任務樣板)
  • 9. OpenAI 的學派:環境優先
    • 他們的做法
    • 證據
  • 10. Anthropic 的學派:把「做」和「審」分開
    • 他們的解法:3 個專責 agent
    • 結果(A/B 測試)
  • 11. ThoughtWorks 的學派:2×2 框架
    • 他們的洞察:用兩個軸分類每一個 harness 控制
    • 2×2 矩陣
  • 12. 原則 1:Context 勝過 Instruction
  • 13. 原則 2:規劃與執行必須分離
  • 14. 原則 3:Feedback 迴路不可妥協
  • 15. 原則 4:一次只做一件事
  • 16. 原則 5:Codebase 本身就是文件
    • 實務含意
  • 17. Harness 衰退(Harness Decay)是真的
    • 這就是 Harness 衰退
  • 18. 為刪除而建(Build to Delete)
  • 19. 成本現實
    • 但這裡是沒人在講的部分
  • 全文濃縮
    • 什麼是 harness
    • 5 個 harness 產物
    • 3 個學派
    • 5 條普世原則
    • 弔詭之處

2026 年 2 月,OpenAI 一個小團隊出了 100 萬行生產級程式碼。

他們一行手寫的都沒有。

AI agent 寫的。

人類設計的,是讓 agent 可靠的那套系統。

這套系統現在有名字了——Harness Engineering

幾週內,Anthropic 發了 3 篇相關論文。ThoughtWorks 把它整理成框架。Hugging Face 的 Philipp Schmid 直接稱它是「2026 年最重要的學科」。

90 天內,一個新工程學科就成形了。而 AI infra 團隊之外,幾乎沒人看懂。

這篇文章就是把它講清楚。沒有廢話、沒有學術術語,只有你真的拿來用會需要的心智模型。

1. Harness 的定義

ThoughtWorks 給的最簡定義:

Harness 就是模型以外的所有東西。

  • 把 agent 釘在軌道上的約束
  • 抓錯誤的回饋迴路
  • 告訴 agent 它在哪裡的文件
  • 它有權限使用的工具

剝掉 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 年最不舒服的真相:

  • Agent 從來不是難的部分
  • Harness 才是

如果 2025 是 AI agent 證明自己會寫程式的一年,2026 就是發現「環境」比「模型」更重要的一年

4. AGENT.md / CLAUDE.md 檔案

最通用的 harness 產物。

散落在 codebase 各處的 markdown 檔案。Agent 每次 session 一開始就讀——像新工程師到職的 onboarding 文件

裡面寫什麼?

  • 專案 context
  • 程式碼慣例
  • 架構決策
  • 「我們這邊都怎麼做」的指引
  • 目前正在進行的事

OpenAI 叫它 AGENT.md。 Anthropic 叫它 CLAUDE.md。 Cursor 用 .cursorrules

不同名字,同一原則。每個主要模組一份。隨專案演進更新。

沒有它:agent 每次 session 都是盲開機。 有了它:agent 每次 session 都帶著情報上工。

5. JSON Feature Lists(進度追蹤器)

當 agent 跨多個 session 蓋一整個 app 時,每次 session 的 context window 都是空的。它怎麼知道哪些已經做完了?

一個 JSON 檔案。

每一筆寫:

  • 一個 feature
  • 怎麼驗它有沒有過
  • Pass / Fail 狀態

Agent session 一開始就讀它——挑最高優先級的 fail → 實作 → 標 pass → commit → 重複。

為什麼是 JSON 不是 Markdown?

Anthropic 發現:agent 不小心覆寫 JSON 的機率比覆寫 Markdown 低。

細節很小,但在 6 小時自主跑的場景裡很關鍵。

6. Session 初始化常規

每一次 session 都用同樣方式開機。每 一 次。

Anthropic 的 7 步開機程序:

  1. 確認工作目錄
  2. 讀 git log 和進度檔
  3. 從 feature list 抓最高優先級的未完成項
  4. 啟動 dev server
  5. 跑基本 E2E 驗證
  6. 實作一個 feature
  7. 用描述性訊息 commit,並更新進度

沒有它:agent 前 20 分鐘都在搞清楚現有狀態,每個 session 都在重複造輪子。 有了它:agent 一開始就帶著情報直接幹活。

7. Sprint Contracts(衝刺契約)

寫任何一行程式碼之前——兩個 agent 先談判

Generator agent 提案:

  • 要做什麼
  • 怎麼驗證成功

Evaluator agent 審查:

  • 提案完整嗎?
  • 成功標準清楚嗎?

兩邊都同意,實作才開始。

是設計審查。只是兩邊都是 AI。

為什麼重要

在同一輪裡同時規劃和執行的 agent,產出不可靠。「規劃」這一步——即使是 AI 做的——也會大幅提升輸出品質。

8. Structured Task Templates(結構化任務樣板)

寫任何程式碼之前,harness 先分析真正的 codebase。

它產出一份接地的衝擊地圖(grounded impact map):

  • 真實的檔案路徑(不是幻覺的)
  • 真實存在的 symbol 名稱
  • 既有的 pattern 可遵循
  • 具體的驗收標準

然後實作才開始。

聽起來理所當然。但大多數團隊都跳過這一步

Agent 猜檔案結構、發明根本不存在的 API、做一個跟 codebase 不搭的東西。

先有接地的 context,再執行 → 輸出品質會差非常多。

9. OpenAI 的學派:環境優先

OpenAI 的 Codex 團隊有個荒謬的問題:

在那個規模,你不可能逐行 code review。所以他們不做

取而代之——他們把環境設計得徹底到一個程度,讓 agent 從一開始就產出「可被審查的輸出」

他們的做法

  • 嚴格的依賴流(Types → Config → Repo → Service → Runtime → UI)
  • 整個 codebase 散布 AGENT.md
  • Agent 直接接進 CI/CD pipeline

哲學:設計環境。然後放 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:什麼時候運作?

  • Feedforward = 在 agent 動作之前(指引)
  • Feedback = 在 agent 動作之後(感測器)

軸 2:怎麼運作?

  • Computational = 確定性、毫秒級(linter、type checker、test suite)
  • Inferential = 用 LLM、秒級(code review agent、語意分析)

2×2 矩陣

Feedforward(指引) Feedback(感測)
Computational type system、linter、架構規則 test suite、coverage、mutation test
Inferential spec 文件、約束描述 LLM code reviewer、行為驗證器

Feedforward 跟 feedback 哪一邊單獨用都不行。兩邊都要有。

12. 原則 1:Context 勝過 Instruction

不同團隊,同一發現:

  • OpenAI:給一張地圖,不要給 1,000 頁手冊
  • Anthropic:JSON feature list + 進度檔,讓 agent 永遠知道自己在哪
  • Red Hat:產出任何任務前,先分析真實 codebase
  • ThoughtWorks:稱為「Feedforward」

接地在真實檔案路徑 → 適配 codebase 的程式碼。 從含糊描述出發 → 幻覺路徑與發明 API。

在 agent 打字之前,先確保它知道自己在哪裡。

13. 原則 2:規劃與執行必須分離

  • OpenAI:人類設計環境,agent 執行
  • Anthropic:專責 Planner agent 在 Generator 動工前先跑
  • ThoughtWorks:強制人類審查 checkpoint 卡在規劃和實作之間
  • Red Hat:Phase 1(衝擊地圖)和 Phase 2(實作)之間有硬閘

每一個陣營都獨立發現:讓 agent 在同一輪裡規劃和執行,輸出不可靠

規劃這一步不一定要人類做,但必須是分開的一步,且輸出要被審過才能開工。

14. 原則 3:Feedback 迴路不可妥協

  • OpenAI:agent 接進 CI/CD 與 observability
  • Anthropic:專責 Evaluator agent + 瀏覽器自動化
  • ThoughtWorks:形式化為「感測器」,警告只靠 feedforward 永遠無法確認指引到底有沒有效

三個學派同一原則的三種做法:

學派 feedback 來源
OpenAI 自動化測試 + CI
Anthropic 另一個 LLM
ThoughtWorks 兩者疊用

他們在「提供 feedback」上有分歧。但他們在「你需不需要 feedback」上沒有分歧。

15. 原則 4:一次只做一件事

  • OpenAI:把目標拆成更小的積木,深度優先
  • Anthropic:強制「每個 sprint 只做一個 feature」,做完就 commit
  • ThoughtWorks:分階段生命週期(pre-integration → post-integration → continuous monitoring)

一次想做太多的 agent 會:

  • Context 用完
  • 失去連貫性
  • 安靜地丟掉需求

Anthropic 的常規:讀進度 → 挑 ONE feature → 實作 → commit → 重複

「強制漸進主義」是所有成功 harness 的共通點。

16. 原則 5:Codebase 本身就是文件

  • OpenAI:AGENT.md 內嵌在 repo
  • Anthropic:feature list、progress 檔、git 歷史就是 agent 的連續性機制
  • ThoughtWorks:衡量「harnessability」——codebase 對 agent 的可讀性

沒人會幫 agent 另外維護一份知識庫。Repo 就是唯一真相。

如果一個慣例、約束、架構決策不在 codebase 裡 → agent 就不會知道

實務含意

  • 願意投資在程式碼組織的團隊,免費得到更好的 agent 表現
  • 髒 repo + AI 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

  1. Agent = Model + Harness
  2. Model = CPU、Harness = OS
  3. 同模型,更好的 harness → +13% 表現

5 個 harness 產物

  1. CLAUDE.md / AGENT.md —— agent 的 onboarding 文件
  2. JSON feature list —— 進度追蹤 + 測試套件二合一
  3. Session 初始化常規 —— 同樣的 7 步開機
  4. Sprint contract —— agent 寫碼前先談判
  5. Structured task template —— 真實檔案路徑、真實 pattern

3 個學派

  1. OpenAI:設計環境,放 agent 跑
  2. Anthropic:把「做」和「審」分開
  3. ThoughtWorks:2×2 feedforward/feedback 框架

5 條普世原則

  1. Context 勝過 instruction
  2. 規劃與執行必須分離
  3. Feedback 迴路不可妥協
  4. 一次只做一件事
  5. Codebase 就是文件

弔詭之處

  1. Harness 衰退 —— 上個月有效的,這個月在扣分
  2. 為刪除而建 —— 定期測試並移除死組件
  3. 成本現實 —— 更好的模型 = 更簡單的 harness = 更便宜的跑一次

2026 年贏的工程師,不是寫最好程式碼的。他們是設計最好約束的人——而且願意在那些約束停止賺錢的瞬間,把它們扔掉。

📍相關報導📍

OpenAI Codex 的 Chrome 擴充功能上線,可以登入狀態操作你的電腦

慢霧專欄:資金交給「龍蝦」AI Agent 真的安全?聯合 Bitget 報告揭露五大風險

PrimePiper:AI agent 交易的 prime broker,讓 AI agent 安全地在全球交易市場交易

Harness Engineering(AI駕馭工程)入門篇:OpenAI最新程式設計標準,教你輕鬆做到Lv.1

Sam Altman 傳承諾砸 6,000 億美元擴張算力「加速 OpenAI 年底 IPO」,財務長憂 5 年後現金耗盡

完成預測交易,解鎖大獎資格

完成預測交易,解鎖大獎資格完成預測交易,解鎖大獎資格

獎金池高達 $500,000,100% 中獎!

免責聲明: 本網站轉載的文章均來源於公開平台,僅供參考。這些文章不代表 MEXC 的觀點或意見。所有版權歸原作者所有。如果您認為任何轉載文章侵犯了第三方權利,請聯絡 crypto.news@mexc.com 以便將其刪除。MEXC 不對轉載文章的及時性、準確性或完整性作出任何陳述或保證,並且不對基於此類內容所採取的任何行動或決定承擔責任。轉載材料僅供參考,不構成任何商業、金融、法律和/或稅務決策的建議、認可或依據。

真實美股已上線

真實美股已上線真實美股已上線

透過持牌券商,用 USDT 交易真實美股