過去是提示詞工程，未來是編排工程 Agent Harness Engineering

Claude 4.7 出來了，GPT 5.5 又推了新版，每隔幾週就有人喊模型又進步了，但你有沒有發現一件怪事：高手用同樣的模型，做出來的成果天差地遠，差的不是模型，是模型外面那層東西。

那層東西，國外開發者圈最近開始有名字了，叫 Agent Harness Engineering，直譯是代理外殼工程，講的是把模型外面的工具、記憶、驗證、權限、上下文管理、子代理協作這些東西，當成一個完整的工程系統來設計。

我做 AI 動畫導演四年，過去兩年一直在講 AIGC 工作流 這個概念，當時技術不成熟，工具還在拼湊，能教的就是流程心法。

現在 Claude Code、Codex 把整套自動化做進去了，這件事終於可以用工程語言講清楚。

這篇文章帶你看懂 Agent Harness Engineering 是什麼，為什麼它比追新模型重要。

什麼是 Agent Harness Engineering？

Agent Harness Engineering 是一個工程實踐，把 AI agent 模型外面的所有東西當成可設計的系統來工程化。

LangChain 工程師 Vivek Trivedy 在〈The Anatomy of an Agent Harness〉中提出最簡潔的定義：Agent = Model + Harness。

如果你不是模型本身，你做的就是 Harness。

最經典的案例就是 Manus，他們不訓練模型，而是把別人的模型用到極致。業界把 Manus 視為極致的套殼案例：不做引擎，專注在引擎外面的工程。

Harness 到底包含哪些東西？

Harness 在英文裡原本是馬具、韁繩的意思。一隻馬光是有體力跑不出成績，需要有韁繩控制方向、有馬鞍坐人、有蹄鐵保護，整套系統才能贏比賽。

AI agent 也一樣，光是有強大的模型不會自動變成可用的工具，還需要工具呼叫、記憶系統、權限控制、驗證機制、子代理協作這些外掛在模型上的工程。

用車子比喻更直接：模型是引擎，harness 是底盤、剎車、變速箱、方向盤、儀表板。

引擎再強，沒有好的底盤跟剎車也跑不快，Antigravity、Cursor、Cline 這些工具，底下的模型很多時候是同一顆，但用起來感受差很多，差的就是 Harness 的設計。

跟 Prompt Engineering、Context Engineering 差在哪？

過去三年，AI 工程的詞彙進化過兩次。

先是 Prompt Engineering 教大家怎麼措辭，然後是 Context Engineering 教大家怎麼組織上下文。

Harness Engineering 是更上一層的系統設計，把 prompt 和 context 都當成元件，加上工具、記憶、驗證、編排，組成完整的執行系統。

過去是比 Prompt Engineering（提示詞工程），未來是比 Harness Engineering（編排工程）。

工程層級	負責什麼	主要工作
Prompt Engineering 提示詞工程	單次提問	措辭、句式、範例
Context Engineering 上下文工程	上下文注入	資訊組織、長度管理、檢索
Harness Engineering 編排工程	完整執行系統	工具、記憶、驗證、權限、編排

順帶一提，Claude Code 用 CLAUDE.md、Codex 用 AGENTS.md，這兩個檔名是同一個概念在不同工具的命名，都是寫給 AI 看的規則手冊。它是 harness 的記憶層元件之一，後面會講。

為什麼 Harness 比模型本身更重要？

因為在多數日常任務裡，旗艦模型的差距正在縮小，但工作流、工具配置與驗證機制的差距正在放大。

但同一顆模型套上不同的 harness，最終做出來的結果可以差到天差地遠。

同模型只改 Harness，從 Top 30 衝到 Top 5

LangChain 的 Vivek Trivedy 團隊在 Terminal Bench 2.0 這個編碼能力評測上參賽，沒有換模型，只重新設計 harness，名次從 Top 30 衝到 Top 5。同一顆腦，給它不同的工具跟流程，輸出的水平完全不同。

Anthropic 在另一份官方部落格也強調，給 AI agent 一個能驗證自己工作的機制，是品質倍數成長的關鍵。

不是讓模型更聰明，是讓 agent 在交件前自己回頭檢查。這件事不是模型內建的，要靠 harness 設計出來。

不是模型問題，是配置問題

HumanLayer 這家專注做 AI agent 工程的公司，一句話講穿了現況：「It’s not a model problem. It’s a configuration problem.」翻成白話就是，當你覺得 AI agent 表現不好，先別急著等下一代模型，先檢查你的配置有沒有問題。

這對台灣企業主很重要，我看過太多老闆說現在 AI 還不行，問下去發現他們連最基本的 CLAUDE.md 都沒寫，工具沒設好，上下文塞滿一堆無關資料，agent 當然表現差。模型不是萬能藥，工程才是。

一個 Harness 由哪六層組成？

綜合 Addy Osmani、HumanLayer、Anthropic 工程部落格與 Avi Chawla 的觀點，先列出模型自己做不到的事，每一條對應一個 harness 元件，我把它歸納成六層。

執行層、記憶層、長任務層

執行層解決動手做事這件事，模型只會生成文字，要讓它真的改檔案、跑指令、開瀏覽器，得有 Filesystem、Git、Bash、Sandbox 這些工具。Claude Code 預設給的那組工具，就是執行層的設計。

記憶層解決記住規則這件事，模型每次對話都是從零開始，要讓它記住專案的規範、語氣、禁忌，得寫成 CLAUDE.md 或 AGENTS.md 這份規則手冊，每次對話自動注入。MCP 伺服器、向量資料庫、長期記憶檔案也屬這一層。

長任務層解決跨 session 持續工作這件事，一個任務做不完、context 爆了，要怎麼接續下去？做法是把工作切成計畫者、執行者、評估者三個 agent，狀態寫在檔案裡，每次 session 從檔案讀回繼續做。Anthropic 把這套叫 long-running agent 設計。

驗證層、上下文層、編排層

驗證層解決不要說謊這件事，AI agent 最大的問題是它會自信地宣稱「已修好」但其實沒驗證。解法是設 hook，在每次任務完成前自動跑 type-check、跑測試、回讀檔案。

成功靜默、失敗大聲，這是 harness 設計的黃金原則。

上下文層解決不要爆窗這件事，長對話、大量工具輸出，會把 context window 塞爆。解法是 compaction（自動摘要）、tool-call offloading（把大型工具輸出寫進檔案，主對話只保留指標）、progressive disclosure（按需載入，不要預載一堆）。

編排層解決多代理協作這件事，一個任務太大，主 agent 會被細節淹沒。解法是開 subagent 平行處理、用 git worktree 做檔案系統隔離、用信箱機制做 agent 間通訊。Boris Cherny（Claude Code 作者）特別強調 subagent 的 context firewall 效果，把研究、debug 這類重活包進子代理，主線程保持乾淨。

層級	解決的問題	代表機制
執行層	動手做事	Filesystem、Git、Bash、Sandbox
記憶層	記住規則	CLAUDE.md / AGENTS.md、MCP、長期記憶
長任務層	跨 session 持續	Plan / Generator / Evaluator 三角架構
驗證層	不要說謊	Hooks、self-check、type-check
上下文層	不要爆窗	Compaction、tool offloading、progressive disclosure
編排層	多代理協作	Subagent、Worktree、Mailbox

Anthropic 官方的長任務架構

Anthropic 工程部落格分享過一套 long-running agent 的標準做法，把六層整合在一起。流程是：先派一個初始化 agent，建立 init.sh 開發環境腳本、claude-progress.txt 進度追蹤檔、列出 200 個功能測試清單。然後派一個 coding agent，每個 session 只做一個小功能，做完更新進度檔，下個 session 從進度檔讀回繼續。

這套架構厲害的地方在於：(1) 進度持久化在檔案，不依賴對話記憶；(2) 200 個測試清單同時是驗收標準，agent 不能含糊地宣稱做完了；(3) 每個 session 從乾淨狀態開始，不會被歷史污染。

台灣企業主該從哪四步開始？

講概念講到這裡，問題是：作為一個沒寫過 code 的台灣企業主、或剛開始用 Claude Code 的工作者，第一步該做什麼？

以下四步老闆不一定要自己動手，但你要懂得「派誰去做、用什麼標準驗收」。第一步老闆可以親自做（寫核心規則），二到四步至少要能跟內部技術同事講清楚需求。

第一步：寫一份 60 行以內的 CLAUDE.md

這是門檻最低、效果最大的一步。

在你的專案根目錄建一個 CLAUDE.md 檔案，寫下這個專案的核心規則：用什麼語言、命名慣例、禁止的操作、必做的驗證。Claude Code 每次對話會自動讀進去當系統提示。

HumanLayer 給的黃金原則是：每一行規則都該追溯到一次具體的失敗。

不要憑想像寫一堆應該、最好的廢話，那只會把 context 塞滿廢話讓 agent 變鈍。等 agent 真的犯了一次錯，再加一條規則進去，這份檔案會越用越精準。

長度建議控制在 60 行以內。多篇指令遵循研究都指出，過長、互相競爭的規則會稀釋模型注意力，規則少而精比多而雜更有效。

第二步：強迫 AI 自我驗證

這是品質躍升的關鍵，在 CLAUDE.md 裡明確寫一條規則：每次任務完成前必須做下列驗證之一才能宣稱完成，例如跑 build、跑 test、curl API 回讀、讀回修改後的檔案。

這條規則會逼 agent 不得自信地說已修好就交件。

我自己在科技翰林院的工作流就有一條鐵律：「驗證才能說完成」，改完 WordPress 文章 MUST API 回讀，改完 CSS MUST curl 前端確認生效，這種 back-pressure 機制是 harness 設計裡槓桿最高的一環。

第三步：設 hook 防呆

第三步是用 Claude Code 的 hook 功能，在危險操作前自動攔截。

例如：刪檔前要確認、推 main 前先跑 lint、改 prod 環境變數前要二次確認。

這些不是讓 AI 變聰明，是讓 AI 在你不在場時不會搞砸。

HumanLayer 公開過一個簡單的 bash hook：agent 停止時自動跑 Biome 格式化跟 TypeScript 型別檢查，成功不出聲、失敗才把錯誤丟回給 agent 修。這就是「成功靜默、失敗大聲」原則的實作。

第四步：用 subagent 隔離污染

當你的任務需要做研究、爬資料、debug 一個複雜問題時，不要讓主對話自己去做，要開一個 subagent 處理。

子代理會把幾十次工具呼叫、上萬字的中間結果壓縮成一段摘要回給主線程，主線程只看到結論，context 保持乾淨。

這個設計叫 context firewall，一個專案只要養成研究、debug、長任務都丟 subagent 的習慣，主線程就不會被污染，連續工作幾小時也不爆窗。

不只工程師：企業主的 Harness 長什麼樣？

上面講的案例偏工程師，但 Harness 的核心概念對任何用 AI 做重複性工作的人都適用。

企業主的 harness 不是 CLAUDE.md，而是把你腦袋裡的判斷標準寫成 AI 可以反覆執行的規則系統：

• 品牌語氣規則檔：讓 AI 產出的文案永遠符合你的品牌調性
• 客服回覆審核規則：哪些問題可以自動回、哪些必須轉人工
• 提案書格式規範：格式、用語、報價邏輯的標準化
• SEO 文章檢查表：標題結構、關鍵字密度、內連外連的驗收標準
• 報價單風險檢查流程：自動比對利潤率、付款條件、歷史客訴紀錄

Harness 不只是工程師的事，而是把「老闆腦袋裡的判斷標準」寫成 AI 可以反覆執行的系統。

企業導入 Harness 的安全底線

企業導入 Harness，不只是讓 AI 更會做事，也要讓 AI 不該做的事做不了。這是老闆真正該在意的：

• 不能直接刪正式資料（資料庫、客戶名單）
• 不能直接推送到正式環境（production deploy 需人工確認）
• 不能未經審核寄出客戶信件
• 不能把內部資料丟到未授權的外部工具
• 不能把 AI 產出直接當成最終決策

這些規則在 Claude Code 裡可以用 hook 和權限設定實作，在非工程場景則是寫進 SOP 跟審核流程。做好這一層，Harness 不只是效率工具，也是企業的 AI 治理框架。

Harness 是新的護城河

2026 年的 AI 競爭格局有一個沒人明說的真相：模型每三個月升一次，但你寫的 harness 跟著你越用越強。

更精確地說：模型升級你跟著換，但你累積的規則、驗證、流程、失敗教訓會跟著你。換模型時要重新適配 harness 細節（CLAUDE.md vs AGENTS.md），但你建立的工程思維和規則資產不會歸零。

Harness 也會折舊：模型變強，部分腳手架會退役

但這裡要講一個反向觀點：harness 不是一勞永逸的。Addy Osmani 在原文裡提到，他六個月前針對模型弱點寫的防護腳手架，在 Opus 4.6 出來後整批變成了廢碼。模型變強，某些 harness 設計會直接過時。

但 harness 的「天花板」會跟著模型一起移動：新模型開啟了新任務，又有新的失敗模式要 harness 補。所以企業主該有的心理準備不是「蓋一套系統用十年」，而是「建立持續迭代 harness 的能力」。這個能力本身，才是真正的複利。

HaaS 正在興起：從寫 prompt 到組 harness

業界已經出現一個新詞：HaaS（Harness-as-a-Service）。

Anthropic 推 Claude Agent SDK、OpenAI 推 OpenAI Agents SDK、Codex 也有對應 SDK，這些工具把 harness 的標準元件（迴圈、工具呼叫、上下文管理、hook、sandbox）打包成可直接用的框架，工程師不用從零造輪子。

這個轉變的意義是：未來 AI 工程的競爭，不是比誰能 fine-tune 出更聰明的模型，是比誰能組出更好的 harness。

模型 API 在標準化、harness 設計變成差異化來源。

我們的實踐：從觀點到工程系統

問題不是每家公司都要自己從零開發一套 Claude Code 等級的系統，而是能不能擁有一層屬於自己的工作流記憶與驗證機制。

我做 AIGC 工作流多年的觀察是：模型一升級，很多團隊的工作流就要重做一次，配置、提示詞、工具串接全部從頭來過。這是台灣團隊浪費時間最多的環節，也是 harness 工程沒做好的代價。

所以我們在做一個實驗叫 Hermes Agent，嘗試解決記憶層和編排層的問題：底層模型可以隨時換成 Claude、GPT、Gemini 任何一個當下最強的，外面這層 Hermes Agent 負責保存你的規則、記憶、驗證邏輯與工作流。引擎可以換，駕駛習慣跟著你。

完整教學、跟 OpenClaw 龍蝦的差別、本地離線怎麼跑，寫在另一篇文章：Hermes Agent 自我學習代理人教學：龍蝦比較、安裝到離線指南。

給台灣老闆的三句話

第一：模型差距會繼續縮小。在多數日常任務裡，旗艦模型的差距正在收斂，等下一代模型不會自動給你競爭優勢。

第二：harness 差距會繼續放大。會設計 harness 的人，和只會打 prompt 的人，產出差距正在快速拉開。LangChain 在 Terminal Bench 上只改 harness 就從 Top 30 衝到 Top 5，這不是個案。

第三句：越早動手越有複利，每一份 CLAUDE.md、每一條 hook、每一個 subagent 設計，都會在你接下來的每個專案重複領利息。

結論：別追模型，把 AIGC 工作流寫成編排工程

Agent Harness Engineering 編排工程，很可能是 2026 年 AI 工程與企業導入裡最被低估的能力。

它不是程式語言、不是模型架構，是把模型外面的所有東西當成可工程化的系統來設計：執行、記憶、長任務、驗證、上下文、編排，六層加起來，決定一個 AI agent 真正的表現。

我兩年前在課程裡講的 AIGC 工作流，是這個概念的工作者版本。當時工具不成熟，能教的是流程心法：分析、定義、創意、執行四階段。

現在 Claude Code、Cursor、Codex 把整套工程基礎設施做進去了，工作流不再是手工心法，是可寫進檔案、可被 AI 自動執行的 harness。

對台灣企業主、對工作者、對任何想用 AI 真正做事的人，現在最該做的不是繼續追模型新聞，是打開你的編輯器，寫下你的第一份 CLAUDE.md。從 60 行起步，每犯一次錯加一條規則，配上自我驗證、hook 防呆、subagent 隔離三招。

用最簡單的對比來說：

• 以前問「我要怎麼下提示詞？」現在問「我要怎麼讓 AI 每次都照我的標準完成任務？」
• 以前是單次輸出，現在是可重複流程
• 以前是問得好，現在是驗證得好
• 以前是人記得規則，現在是系統記得規則
• 以前是換模型重來，現在是換引擎但保留自己的工作流底盤

Prompt Engineering 解決的是一次怎麼問，Harness Engineering 解決的是一家公司如何讓 AI 持續照自己的標準工作。

模型只是引擎，Harness 才是底盤，這就是 Agent Harness Engineering。

---

推薦閱讀

我用 AI 三天蓋了一個 iPAS 備考平台，Vibe Coding 完整紀錄

Claude Opus 4.7 更新比較：4 大模型企業主怎麼分配最划算

MCP 是什麼？AI 巨頭全押注的萬能接口，告別傳統 API

Hermes Agent 自我學習代理人教學：龍蝦比較、安裝到離線指南

---

參考資料

Addy Osmani (2026). “Agent Harness Engineering”

HumanLayer (2026). “Skill Issue: Harness Engineering for Coding Agents”

Anthropic Engineering (2026). “Effective Harnesses for Long-Running Agents”

Avi Chawla (2026). “The Anatomy of an Agent Harness”

Vivek Trivedy / LangChain (2026). “The Anatomy of an Agent Harness”

MindStudio (2026). “Agent Harnesses Beat Model Upgrades: 5 Benchmarks That Prove the Harness Is Now the Product”

---

FAQ