Harness engineering（駕馭工程）是 2026 年 AI agent 開發的核心紀律。 Mitchell Hashimoto（HashiCorp 創辦人、Terraform 共同開發者）在 2026 年 2 月 5 日的部落格文章首次定義了這個概念：每次 agent 犯錯，就把修正方案永久工程化進 agent 的運作環境裡，讓同樣的錯誤不會再發生。幾天後，OpenAI 在 2 月 11 日發表了他們的百萬行程式碼實驗報告，Anthropic 也跟著發布了長時間運行 agent 的 harness 設計研究。到了 4 月，Martin Fowler 在 martinfowler.com 發表了系統性的分類框架，把 harness 元件分成 guides（前饋控制）和 sensors（反饋控制），整個領域的理論基礎算是正式建立。
這篇文章完整拆解 harness engineering 的技術架構、實戰案例、開源生態和導入策略，幫你釐清它跟 prompt engineering 和 context engineering 的差異。
三層模型：從 Prompt 到 Context 到 Harness
AI agent 開發經歷了三個明確的階段。2022-2024 年是 prompt engineering 的全盛期，工程師花大量時間優化指令措辭來改善單次輸出品質。2025 年 mid，Andrej Karpathy 公開談到他的工作流已經從「手動寫程式為主、agent 輔助」翻轉成「agent 驅動為主、手動編輯為輔」，context engineering 這個詞開始被廣泛討論——LangChain 和 Anthropic 都發表了正式定義。
到了 2026 年初，問題變了。模型能力夠強了，但在生產環境不夠穩定。Hashimoto 的 harness engineering 概念填補了這個缺口。
三層的差異可以這樣理解：
| 層級 | 關注什麼 | 解決什麼問題 | 時間範圍 |
|---|---|---|---|
| Prompt engineering | 怎麼問 | 單次輸出品質 | 2022–2024 |
| Context engineering | 給模型看什麼 | 資訊充足性 | 2025 |
| Harness engineering | 整個系統怎麼運作 | 多步驟可靠性 | 2026– |
用一個比喻來說：模型是引擎，context 是燃料和儀表板資訊，harness 是整台車的其餘部分——方向盤、煞車、車道邊界、保養排程、警示燈。只顧引擎和燃料，還是可能造出一台爛車。
需要釐清的一點是，這三層不是互相取代的關係。隨著 agent 能力增長，同一個團隊在同一個專案裡會經歷這三層——harness 建立在前兩層之上，但把焦點從「單次回覆品質」移到「agent 自主運作數小時的可靠性」。
OpenAI 的百萬行實驗：Harness 的實戰驗證
OpenAI 的 Codex 團隊在 2025 年 8 月底從一個空的 repository 開始，花了五個月，用三個工程師（後來擴展到七人）建出一個超過一百萬行程式碼的正式產品。整個過程零行手寫程式碼——所有的 application logic、測試、CI 配置、文件、可觀測性設定和內部工具都由 Codex agent 生成。
幾個關鍵數據：約 1,500 個 pull request 合併完成，平均每位工程師每天 3.5 個 PR，而且產量隨團隊擴張還在增加。產品有數百位內部使用者，包含每天重度使用的 power user。
他們踩過的坑特別有參考價值：
團隊一開始嘗試把所有規範塞進一個巨大的 AGENTS.md 檔案。結果 context 被擠爆、內容很快過時、而且無法用程式驗證。後來改成約 100 行的目錄導覽，指向結構化的 docs/ 資料夾——這跟 matklad 在 2021 年提出的 ARCHITECTURE.md 概念直接對齊。
另一個發現：從 agent 的角度看，它讀不到的東西等於不存在。Google Docs、Slack 對話、團隊成員腦中的知識都不算數。團隊逐步把更多知識推進 repo 裡。
他們還編碼了「黃金原則」——有明確立場、可機械驗證的規則——然後跑背景清理 agent（類似 garbage collection 機制），定期掃描 codebase 裡的規則違反和文件不一致，自動提交修復 PR。多數 PR 在一分鐘內自動合併。
工程師 Ryan Lopopolo 在報告中點出了核心轉變：工程師的工作不再是寫程式碼，而是設計環境、定義意圖、建立 feedback loop 讓 agent 能可靠地工作。
LangChain 的證明：模型不變，Harness 改了就從第 30 名跳到前 5
如果 OpenAI 的實驗說明 harness engineering 能做到什麼，LangChain 在 2026 年 2 月 17 日發表的 Terminal Bench 2.0 實驗則證明了一件更根本的事：模型不是瓶頸，harness 才是。
LangChain 用固定的 GPT-5.2-Codex 模型，只調整 harness 的三個面向——system prompt、工具集和 middleware hooks——把他們的 coding agent deepagents-cli 從 52.8% 提升到 66.5%，在排行榜上從前 30 名之外跳到前 5 名。
他們發現的三個關鍵失敗模式：
第一，agent 不會自主驗證。最常見的失敗是 agent 寫完程式碼後，重新看自己的程式碼，覺得「看起來沒問題」就停了。沒有跑測試。LangChain 把 build-verify 迴圈工程化進 system prompt，強制四步流程：規劃、建置（含寫測試）、對照任務規格驗證、修正錯誤。
第二，agent 浪費大量精力在搞清楚工作環境。目錄結構、可用工具、Python 安裝位置——這些環境資訊如果不事先提供，agent 會花大量 token 自己摸索，然後出錯。LangChain 的 LocalContextMiddleware 把這些環境資訊在起始階段就注入。
第三，agent 會卡在重複循環裡。有時候 agent 對同一個檔案做 10 次以上的微小修改，每次都是同樣的失敗路徑。LoopDetectionMiddleware 追蹤每個檔案的編輯次數，超過閾值就注入提示讓 agent 重新思考策略。
LangChain 團隊用 Claude Opus 4.6 做了一次測試，在早期版本的 harness 下跑出 59.6%——有競爭力但不如 Codex。原因不是模型差，而是 harness 還沒跑過同樣的迭代改善循環。這再次印證 harness 的品質比模型更決定最終表現。
Martin Fowler 的分類框架：Guides 和 Sensors
Martin Fowler（透過 Thoughtworks 的 Distinguished Engineer Birgitta Böckeler）在 2026 年 2 月 17 日首發備忘錄，4 月 2 日發表完整文章，提供了目前最嚴謹的 harness 元件分類。
核心架構分兩大類：
Guides（前饋控制）——在 agent 行動之前引導它，提高第一次就做對的機率。包含 AGENTS.md / CLAUDE.md 專案指引、linter 規則、架構約束、dependency 邊界定義。
Sensors（反饋控制）——在 agent 行動之後觀測結果，幫助它自我修正。包含測試套件、LLM-as-judge 評估、自訂 linter 訊息（包含修正指示的正面 prompt injection）。
每一類又分成兩種執行方式：
| 類型 | 特性 | 成本 | 適用場景 |
|---|---|---|---|
| Computational（確定性） | 快速、便宜、可預測 | 低 | Linter、結構測試、格式檢查 |
| Inferential（推理性） | 語意理解更強、較慢 | 高 | LLM-as-judge、風格審查、需求符合度 |
Fowler 指出，只有 guides 沒有 sensors 的 harness，agent 會遵守規則但不知道規則是否有效。只有 sensors 沒有 guides 的 harness，agent 會一直重複犯同樣的錯再修正。兩者要搭配才有效果。
他還提出了一個延伸概念：harness templates。多數企業只有兩三種主要的服務拓撲——業務 API 服務、事件處理服務、資料儀表板。這些拓撲可以對應預建的 harness 模板，包含配套的 guides 和 sensors。未來團隊選技術棧時，可能會把「有沒有現成的 harness 模板」當作考量因素之一。
Anthropic 的三方 Agent Harness 實驗
Anthropic 從另一個角度驗證了 harness 的必要性。他們在 2026 年 3 月發表了長時間 agent 的 harness 設計研究，核心發現是：模型系統性地無法可靠評估自己的輸出。
問題有兩種表現形式。第一種是 context anxiety：隨著 context window 被填滿，agent 會開始提前收尾任務——不是因為做完了，而是因為它「感覺到」window 快滿了就開始抄捷徑。Cognition 團隊（AI coding agent Devin 背後的公司）在用 Claude Sonnet 4.5 重建 Devin 時記錄了這個行為。
第二種是自我評估偏差：agent 審查自己的程式碼時，傾向認為自己做得不錯就停下來，跳過實際測試。
Anthropic 的解法是一個受 GAN 啟發的三方 harness 架構——Planner、Generator、Evaluator——用它來建構一個 2D 復古遊戲引擎。Planner 把簡短提示擴展成完整產品規格，刻意不指定實現細節（過早指定會在下游產生連鎖錯誤）。Generator 以 sprint 為單位實作功能，但開始寫程式碼之前，必須跟 Evaluator 簽署「sprint contract」——對「完成」的共同定義。Evaluator 用 Playwright（Microsoft 的開源瀏覽器自動化框架）像真實使用者一樣點擊應用程式，測試 UI、API 和資料庫行為。任何測試失敗，整個 sprint 就判定失敗。
跟 solo agent 相比，三方 harness 產出的遊戲功能完整且可通過所有測試。Solo agent 產出的遊戲雖然可以啟動，但實體和 runtime 的連接在程式碼層級是斷開的——只有讀原始碼才發現。
開源生態：值得追蹤的 Repo
Harness engineering 的開源生態在 2026 年 Q1 快速成形。以下是目前社群最活躍討論的幾個專案：
Awesome Lists（入門起點）
walkinglabs/awesome-harness-engineering 是策展型的工具和指南集合，包含一個以專案為基礎的課程，教你怎麼讓 Codex 和 Claude Code 更可靠。ai-boost/awesome-harness-engineering 涵蓋面更廣，包含框架、評估工具、安全性和學術論文。
自我改進型 Harness
kevinrgu/autoagent 是一個 meta-agent，可以在夜間自動迭代改進自己的 harness。你寫 program.md 來引導 meta-agent，它會自主修改 agent.py。在 SpreadsheetBench 上拿到 96.5% 的成績（排名第一），在 TerminalBench 上拿到 55.1%（超越 GPT-5）。MIT 授權。
治理框架
aiming-lab/AutoHarness 是輕量級治理框架，提供三層管線模式、六步治理管線、YAML 基礎的 constitution 設定，以及一行指令安裝的 Claude Code hook。
開放 Agent Runtime
HKUDS/OpenHarness 是開源 Python harness，內建 43 種工具、54 個指令、多 agent 協調、skill 載入、MCP 整合和持久記憶。設計定位是可檢視的參考實作。
生產管線
從 awesome lists 裡延伸出來的生產級管線包括 Symphony（OpenAI 的參考實作，輪詢 Linear issues 後對每個任務生成獨立的 Codex agent 並產出 PR）、Baton（Go 語言的 Symphony 實作），和 Chorus（從需求到交付的完整管線，含任務 DAG、sub-agent 協調和人工審核節點）。
實務導入：三個立即可行的起點
對於已經在用 Claude Code、Cursor 或 Codex 的團隊，Martin Fowler 和 OpenAI 團隊都建議不需要一次建完所有機制。以下三個起點通常回報最快：
第一，建立專案根目錄的 CLAUDE.md 或 AGENTS.md。 內容包含專案結構、build 指令和 coding 規則，控制在 100 行左右當目錄導覽用，指向 docs/ 資料夾裡的詳細文件。每次 agent 反覆犯同樣的錯，就加一條阻止那個錯誤的規則——這就是 Hashimoto 說的核心迴圈。
第二，把驗證迴圈工程化進 agent 的工作流程。 不靠 agent 自己決定要不要跑測試，而是用 pre-commit hook 或 CI pipeline 強制要求。LangChain 的經驗顯示，光是這一步就能顯著減少「agent 覺得自己做完了但其實沒做完」的問題。
第三，跑背景清理 agent 來對抗 entropy。 Agent 生成的程式碼會隨時間產生架構漂移——命名不一致、dependency 違規、文件過時。定期排程一個清理 agent 掃描並修復這些問題，比等到問題堆積了再處理便宜得多。OpenAI 團隊說他們的清理 PR 多數在一分鐘內自動合併——小額持續付出勝過偶爾的大清掃。
這跟你的 AI 開發工作流有什麼關係
如果你已經在用 Claude Code 或 Cursor 開發專案，你某種程度上已經在做 harness engineering——可能只是還沒用這個名字。你的 .cursorrules 或 CLAUDE.md 就是 guides。你的 CI pipeline 和 linter 就是 computational sensors。
Harness engineering 把這些零散的做法收斂成一個有系統的工程紀律：先觀察 agent 哪裡會失敗，然後把防止失敗的機制永久化進環境裡。重點是環境的品質，不是模型的品質。LangChain 用同一個模型跑出前 30 名之外和前 5 名的差異，就是最直接的證據。
對企業團隊而言，這意味著幾件事。選技術棧時，「agent 用這套技術棧生成的程式碼品質好不好」會變成考量因素。無聊但穩定的技術——有大量 Stack Overflow 答案、API 穩定、訓練資料裡充分呈現的——反而對 agent 最友善。OpenAI 團隊發現，有時候自己重新實作一個 library 的子集功能，比讓 agent 跟一個文件不全的流行框架搏鬥更便宜。
Harness engineering 跟 prompt engineering 有什麼不同？
Prompt engineering 優化你對模型說什麼，目標是改善單次回覆品質。Harness engineering 設計模型運作的整個環境——工具權限、驗證迴圈、架構約束、狀態管理——目標是讓 agent 在沒有人類監看的情況下，跨數百個決策步驟都能可靠運作。前者是輸入面的優化，後者是系統面的工程。
為什麼 2026 年 harness engineering 突然變重要？
因為模型能力跨過了一個關鍵門檻：強到可以做有用的事，但不夠穩定到可以自主信任。2025 年底 Karpathy 描述的工作流翻轉——coding 從手動為主變成 agent 為主——暴露了這個問題。Agent 做得越多，它在真實環境裡的脆弱性就越明顯。Harness engineering 是對這個問題的系統性回應。
現在開始做 harness engineering 要投入多少資源？
起步幾乎不需要額外資源。在專案根目錄寫一份 100 行的 CLAUDE.md 或 AGENTS.md、加幾條 pre-commit hook、在 CI 裡加結構測試——這些用現有工具就能做。OpenAI 團隊強調，harness 不是一次性建好的大工程，而是每次 agent 犯錯就加一條規則的持續累積。
Harness engineering 會淘汰開發者嗎？
OpenAI 百萬行實驗的三位工程師沒有寫程式碼，但他們的工作量沒有減少——轉移到設計環境、定義架構約束和建立 feedback loop。工程師的角色從「寫程式碼」轉變為「設計讓 AI 寫好程式碼的系統」，需要的技能組合不同但需求沒有消失。
哪些開源工具適合入門 harness engineering？
如果在 GitHub 上找資源，walkinglabs/awesome-harness-engineering 和 ai-boost/awesome-harness-engineering 是兩個好的起點。想體驗自動化 harness 迭代，kevinrgu/autoagent 的 meta-agent 概念值得嘗試。如果需要治理框架，aiming-lab/AutoHarness 提供即用的 Claude Code hook 和 YAML constitution 設定。
引用來源
- OpenAI — Harness engineering: leveraging Codex in an agent-first world
- LangChain — Improving Deep Agents with harness engineering
- Anthropic — Effective Harnesses for Long-Running Agents
Author Insight
我們團隊在協助企業客戶導入 Claude Code 和多 agent 系統的過程中，最大的體悟跟 LangChain 的數據一致：模型換來換去的效果遠不如把 harness 做好。我們替一家金融服務客戶建了結構化的 SKILL.md 模組化系統（其實就是 OpenAI 所說的結構化 docs/ 資料夾），搭配自動化的 linting 和驗證迴圈，agent 的任務完成率從不到六成穩定到八成以上。讓我印象深刻的是 Fowler 提出的 harness templates 概念——這跟我們已經在做的 SKILL.md 模板化策略完全對齊。對多數企業來說，harness engineering 不需要從零開始，而是把你已經在做的零散實踐（CI rules、coding standards、agent 指引文件）收斂成一個有意識、可迭代的系統。
如果你的團隊正在評估 AI agent 的生產部署策略，或想把現有的 vibe coding 工作流升級為結構化的 harness engineering 流程，歡迎跟 Tenten 團隊預約諮詢。我們可以從你現有的技術棧出發，幫你設計第一版 harness 並建立迭代改善機制。
