Harness Engineering 是什麼？AI 代寫程式時代你也該懂的工程觀念

2026 年 2 月，OpenAI 丟出一篇深水炸彈：三個工程師、五個月、跑 Codex agents 寫出大約一百萬行程式碼，沒有一行是人手寫的。

三個月後 Anthropic 跟進兩篇，把這套打法推到 planner + generator + evaluator 三層架構，做出能在四小時內自己跑完一個 DAW（數位音樂工作站）的 agent harness。整個矽谷半個工程圈都在傳同一個詞——harness engineering。

中文世界這個詞還沒翻譯定名，但它已經是 2026 年所有要用 AI 認真做事的人，最該認識的那個概念。這篇文章會涵蓋：harness 在 prompt → context → harness 的進化軸上是什麼位置、OpenAI 和 Anthropic 的兩個關鍵實驗、一個好的 harness 由哪些部件組成、以及創作者怎麼把這個概念套用在自己的 AI 工作流上。我經營 RAR 設計攻略十年，每天都在實作這套東西，所以這篇不是翻譯整理，是一份「現場觀察」。

直譯叫「框架工程」或「載具工程」。harness 這個字本意是馬具、挽具、安全帶——把一頭強悍但難以控制的力量，固定在能做有用功的方向上。

放到 AI 圈，意思就很精準了：模型本身是引擎，但引擎不會自己變成一台車。它需要方向盤、輪胎、儀表板、煞車、油箱、底盤——這些「模型外部、但讓模型能跑起來的東西」加總起來，就叫 harness。

這個詞為什麼是現在才冒出來，要從 AI 工程的三階段進化看：

當你只跟模型講一次話，prompt 就是全部。當你要餵它一份長文件、一段程式碼、一份品牌指南，context 變成全部。當你要它幫你做完一個橫跨好幾天的專案，模型自己會撞牆——它會忘記前一次做了什麼、會宣稱完成但其實沒完成、會自評過度寬鬆。這時 harness 變成全部。

每個階段不是取代前一個，是疊加上去。你還是要會寫 prompt、還是要懂 context window，但這些已經是基本功。決勝點移到外面那一圈了。

時間軸很乾淨：

2025 年 11 月，Anthropic 工程部落格發表〈Effective harnesses for long-running agents〉，第一次系統性提出「harness」這個概念可以被獨立工程化。

2026 年 2 月，OpenAI 跟進〈Harness engineering: leveraging Codex in an agent-first world〉。這篇是真正的引爆點——他們公布了一個五個月、三人小團隊、用 Codex agents 寫出約一百萬行程式碼的內部實驗，整套產品零人手寫。

2026 年 3 月，Anthropic 再發第二篇〈Harness design for long-running application development〉，把架構從雙 agent 推到三 agent，並做出 solo agent 對比實驗——同樣的 prompt、同樣的模型，跑 20 分鐘 vs 跑 6 小時，差距不是品質高低，是「核心功能根本不能用」vs「真的能玩」。

三篇文章疊在一起，把一個原本只有少數人在私下討論的工程實踐，推成了 2026 年 AI 圈的顯學。Thoughtworks、LangChain、HumanLayer、Martin Fowler 全部跟進寫文。GitHub 上開始出現 awesome-harness-engineering 這種 repository。Claude Code、Codex CLI 這些工具的設計哲學，都被重新解讀為 harness 的具現。

OpenAI 的實驗故事很簡單：八月底開始，三個工程師、一個空 repo，給自己一個任務——做一個正式的 beta 產品出來，但不准手寫任何一行程式碼。所有 code 都得由 Codex agents 自己寫、自己測、自己 review、自己 PR。

五個月後，他們交出來的東西大約一百萬行 code。包含應用邏輯、文件、CI 設定、observability 配置、各種內部工具。人類工程師的角色從「寫程式碼」變成「設計讓 agent 寫得出程式碼的環境」。

關鍵原則他們在文章裡講得很直接：「從 agent 的視角，任何它在執行時 in-context 看不到的東西，本質上不存在。住在 Google Docs、Slack 對話、人腦袋裡的知識，對系統來說是不可見的。」

所以他們要做的第一件事是把所有上下文塞進 repo 本身——包含架構決策、API 設計理由、團隊共識，全部變成 markdown 文件、JSON schema、可執行的 plan 檔案。然後用 background tasks 自動掃描偏離規則的 PR、自動修回來。架構約束是「機械式」的，不是靠人去 review。

▲ OpenAI 工程師 Ryan Lopopolo 在 AI Engineer 大會上的演講，原汁原味講這套實驗怎麼做的。寫文章那位本人。

Anthropic 的角度比較工程師思維。他們不講百萬行 code，他們講一個非常具體的失敗模式——

「想像一個軟體專案由一群輪班工程師組成，每個來上班的工程師都對前一班發生的事完全沒有記憶。」

這就是 long-running agent 的本質困境。context window 有限，複雜專案做不完，每個 session 之間 agent 的記憶會斷。Anthropic 觀察到兩個典型 failure：第一，agent 想一次做完整個 app（一發 prompt 就試圖蓋整棟），結果 context 燒光、留下半成品，下一個 session 的 agent 看不懂前一個做到哪。第二，「context anxiety」——Sonnet 4.5 接近 context 上限時會緊張，自己宣布「任務完成！」然後收工，但其實啥也沒完。

他們的解法分兩階段，每一階段都是一次工程觀念的升級。

PHASE 01

雙 agent：initializer + coding agent

第一篇文章的解法是把任務拆成兩個 agent：

Initializer agent 只跑一次。它讀完使用者的 prompt 後，產出三樣東西：一個列出所有功能需求的 JSON 檔（他們做 claude.ai clone 那次，這個檔案裡有超過 200 條功能定義）、一個 init.sh 開發腳本、一個初始 git commit。

Coding agent 之後每次 session 跑都讀同一份 JSON、git log、claude-progress.txt 這些檔案——「先搞清楚自己是誰、現在做到哪裡」——然後挑一個未完成的 feature 做，做完留下乾淨的 commit、寫進度筆記，下班。

▲ Anthropic 的 coding agent 透過 Puppeteer MCP 自己用瀏覽器測試 app。沒有這層自動測試，agent 經常說「做完了」但其實壞掉。

就這個拆分本身就解決了一大半問題。但他們還做了一件事很關鍵：把 feature list 用 JSON 而不是 markdown 寫，因為「模型比較不會去亂改 JSON 檔」。這種小細節是真的在現場跟模型對打過才會知道。

PHASE 02

三 agent：planner + generator + evaluator

第二篇是 2026 年 3 月發的，做法更激進。靈感來自 GAN（生成對抗網路）——用一個 agent 生成、另一個 agent 嚴厲挑剔，逼前者改進。

Planner 把使用者一句話的 prompt 擴展成完整產品規格。一兩百字 → 16 個 feature、十個 sprint。

Generator 一次做一個 feature，自己用 git 管版本，自評沒問題後交給下一個 agent。

Evaluator 用 Playwright MCP 真的去點開那個 app、按按鈕、查看 API 回應、驗 database state。每個 sprint 開始前還跟 generator「談合約」——先講清楚這次什麼算「做完」，雙方達成共識，再開始寫 code。

這個架構解決了 Anthropic 觀察到的另一個關鍵問題：agent 不會嚴肅評估自己的作品。讓同一個 agent 既寫又打分，它會說「不錯不錯，過關」。把 evaluator 拆出來、單獨調教成「你的工作就是挑毛病」，輸出品質才真的拉得動。

真正讓我看完不能呼吸的，是他們做的對比實驗。

同一個 prompt：「做一個 2D retro 遊戲編輯器，要有關卡編輯、sprite 編輯、entity behaviour、可玩測試模式。」

兩種跑法：

表面看就是「貴 22 倍」。但實際打開兩個 app：

Solo 那個 app 開起來看似有那麼回事——sprite 編輯器有了、關卡編輯器有了、play 按鈕也有了。但你按 play，角色出現在畫面上但鍵盤怎麼按都沒反應。挖開 code 看，entity 定義跟 game runtime 之間的 wiring 是斷的，從介面上完全看不出來。

▼ Solo Agent · 看起來像那回事，但角色不能動

▲ 開機畫面：介面看起來像那回事，固定高度的 panel 把空間浪費掉了

▲ 試玩：角色出現了，但怎麼按都沒反應。介面完全看不出來核心 wiring 是斷的。

Full harness 那個 app 是一個你真的能玩的遊戲。版面用滿整個視窗，sprite editor 有像樣的調色盤、縮放工具，還有一個內建的 Claude AI 助手可以幫你生成關卡。

▼ Full Harness · 真的能玩，還內建 AI 生關卡

▲ 開機畫面：版面用滿視窗，視覺語言一致——這是 planner 從一開始就帶進設計規格的成果

▲ 內建 Claude 助手：planner 自動把 AI feature 編進產品規格，user 直接用對話生成關卡

▲ 試玩：角色能跳、能撞牆、有重力。physics 有點小毛病但核心 loop 是通的。

同一個一句話 prompt、同一個底層模型（Opus 4.5），差別只在於外面那一圈架構。

▲ 這個更狠：同一套三 agent harness 跑「在瀏覽器裡做一個完整的 DAW」這個 prompt，跑了 3 小時 50 分、$124，產出一個能編曲、能加 reverb、能用 AI agent 自動編曲的數位音樂工作站。Anthropic 官方 demo。

差別不是 22 倍價錢，差別是「能用」與「不能用」。這個實驗第一次把 harness engineering 的價值用一個畫面講清楚了。

把 OpenAI、Anthropic、LangChain、Thoughtworks 這幾家的整理綜合起來，一個成熟的 harness 大致包含五件事：

寫到這裡你可能覺得「這是給工程師看的」。我從另一個角度切：如果你過去半年用 Claude / Cursor / Cowork 做過任何稍微長一點的事，你已經是個正在學 harness engineering 的人，只是還沒人告訴你這件事有名字。

舉幾個我自己在做的：

SKILL.md 就是 harness

我替 RAR 部落格寫的 rar-blog-article、ghost-blog-article、daily-figma-article 這些 SKILL.md 檔，本質上就是給 Claude 看的 employee handbook。每次叫它寫文章，它先讀 skill 檔再動手——這就是 OpenAI 講的「把上下文寫進 repo」的縮小版。

Notion 是我的 source of truth

RAR 所有 Teachify 自訂 JS 我都同步到一份 Notion 頁。為什麼？因為 Notion 那份頁面 Claude 看得到、可以用 MCP 撈、可以版本對照。藏在我腦袋的決策，agent 看不到等於不存在——Anthropic 那句話直接適用。

Make.com 排程任務 = initializer + coding agent 的縮影

每天早上跑的 Figma 部落格抓取、Adobe 新文翻譯、NN/g 文章改寫——這些 cron job 觸發 Claude，本質上就是「每天早上派一個工程師上班、給他足夠 context 讓他繼續做事」。我沒在跑單線 prompt，我在跑一個小型 harness。

這個視角的轉換很重要。當你開始把 AI agent 當成「需要工程化的系統」而不是「比較聰明的 chatbot」，你會做的事很不一樣：

如果你是一人經營者、或正在用 AI 做內容、做課程、做產品，harness 這條路是你接下來最值得花時間的方向。不是因為它流行，是因為它把「AI 偶爾能用」變成「AI 真的能交付」之間那道牆，描述清楚了。

最低投入版的 harness 起手式很簡單：找一個你常做的工作流（比如寫 IG 貼文、剪片、整理研究），把所有規則寫成一份 SKILL.md，然後讓 Claude 每次先讀那份檔案再動手。這 30 分鐘的投資會永久提升你跟 AI 的協作品質。

✦ Subscription Plan

AI 覺醒設計應用攻略

每週幫你過濾 AI × 設計領域的雜訊，只整理對設計師、創作者、知識型工作者真正有用的東西。Harness、MCP、agent 工作流的實戰拆解全在裡面。

了解訂閱方案 →

Harness Engineering 跟 Prompt Engineering 差在哪？

Prompt engineering 處理「一次對話內」的事——怎麼把任務描述清楚、怎麼設定角色。Harness engineering 處理「對話之外」的事——repo 結構、工具設定、評估機制、跨 session 的記憶交接。一個是溝通技巧，一個是基礎建設。

我又不是工程師，這跟我有關係嗎？

有。任何用 AI 做超過五分鐘工作的人都會撞到 harness 問題——AI 忘記前面講過的事、做的東西品質不穩、要重複交代規則。學會把規則寫成檔案、把工作拆成更小的 session，這些都是 harness 思維，不需要寫一行 code。

一個最低限度的 harness 至少要有什麼？

三樣東西：一份規則檔案（SKILL.md / CLAUDE.md / AGENTS.md，名字隨意但格式要穩定）、一份進度檔案（每次做完寫一段，下次來讀）、一個檢查機制（讓 AI 自己或另一個 AI 檢查作品）。三個檔案就能解決八成痛點。

Harness 會不會被新模型淘汰？

會、但不是被取代。Anthropic 自己講過：每個 harness 元件都隱含一個「模型自己做不到的假設」，模型變強這些假設會過期。Sonnet 4.5 需要的 context reset 在 Opus 4.6 上就不需要了。但同時，模型變強也代表你可以拿 harness 做更複雜的事，整體市場是擴張的。

怎麼判斷我的 harness 設計得好不好？

最簡單的測試：丟同一個任務給 AI，分別在「有 harness」跟「沒 harness」兩種情況下跑，比對結果。如果差異不明顯，代表你的 harness 沒在發揮作用，可以拆掉。如果差異巨大，那就是它在做事。Anthropic 那個 solo $9 vs harness $200 的對比實驗就是這個邏輯。

SKILL 跟 Agent Skill 算 harness 嗎？

算。Anthropic 的 Skill 系統、Claude Code 的 plugins、Cursor 的 .cursorrules、OpenAI 的 AGENTS.md——這些都是 harness 的元件。它們的共同特徵是：把規則和上下文預先寫好，agent 在執行時自動載入，不用每次重新解釋。

2026 年最沒意義的問題是「最強的模型是什麼」。最有意義的問題是「我的模型外面那一圈，長什麼樣子」。

前者每三個月就過期，後者是你能累積的資產。