AI Coding Harness Engineering（AI 編碼的牽引工程）

概述

這個概念最早從 Thoughtworks 的 Birgitta Boeckeler 與 Chris Ford 對談延伸而來。 核心思想不是靠大量規則檔「嘮叨」AI Coding Agent，而是建立一套可回饋的環境，讓 agent 從結果中學習。

侯智薰（雷蒙）的個人 AI Agent 七層文章把同一個 harness 概念延伸到個人助理：規則、技能、記憶、使用者畫像、對話歷史、hooks 與多平台入口共同決定助理是否可靠。這補上一個非 coding 場景的切法：coding harness 更看重 verification / scope / CI，個人助理 harness 更看重偏好沉澱、SOP 可攜性、生活與工作 API，以及跨平台觸達。

2026 年 AI Engineer Europe 的演講把這條線再推進一步：Ryan Lopopolo 直接用「Humans steer, Agents execute」描述工作方式，重點不是盯著編輯器，而是把 prompt、guardrails、skills、lint/test/review 包成可重播的 loop-engineering 單位。這和 prompt-debugging-eval-checklist、agent-trace-observability 的方向一致。

核心架構

2026-06-26 的 AIHAO 駕馭工程第 1 篇把 Deep Agent 拆成六項能力：Plan & Todos、Filesystem & Bash、Sub-Agent、Memory、Skills 與外部工具。這些能力解決的是 agent「能不能做、能不能撐長任務、能不能跨 context 維持狀態」，但不等於 harness；harness 要回答的是結果是否正確、何時停止、失敗如何回饋。對 AI Ark 的最小 loop 來說，這是 ponytail 式邊界：先確認任務真的需要哪一項能力，再加工具或子代理，不為通用 Deep Agent 清單預先堆滿 scaffolding。

2026-06-26 的 AIHAO 駕馭工程系列把 harness engineering 的邊界講得更明確：Prompt Engineering 管單次模型呼叫，Context Engineering 管 context window 內該放什麼資訊，Harness Engineering 則管 agent 在行動迴圈中如何被約束、檢查、修正。它的主張是「先 generate，再 verify」：模型本身有自我修正能力，但必須由 harness 把 plan → implement → verify → fix 變成會實際發生的流程，而不是只寫在 prompt 裡求模型自律。

這篇也補上判斷標準：好的 harness 同時提高「一次做對」的機率，並在出錯後逼 agent 回到迴圈。前者靠 guides（AGENTS.md、skills、架構慣例、範例），後者靠 sensors（測試、linter、type checker、hook、AI review、LLM judge）；其中 sensors 才能把 prompt-debugging-eval-checklist 和 agent-trace-observability 看到的失敗變成 loop-engineering 裡的強制 gate。對 aiark-loop-engineering 來說，這也支持目前的最小閉環：每次 ingest 後必須跑 hash、wikilink、index、log、queue sanity check，而不是只靠摘要看起來合理。

AIHAO 對 AGENTS.md / CLAUDE.md 的整理補上 guide 層的成本邊界：指令檔應只寫 agent 從程式碼推不出的 WHAT / WHY / HOW，尤其是非預期工具鏈、驗證指令、歷史包袱與硬邊界；重述 README、目錄列表、風格標語或 formatter 已能處理的規則，只會增加 context 成本與遵守負擔。這也讓 agent-instruction-files 成為 harness 的「輕量前饋」頁：紅線仍要交給 hooks / CI / 權限，不能只靠長 prompt。

Agent Skills 則是比常駐指令檔更窄的 guide：只把重複任務、工具步驟、範例與驗收條件封裝起來，並用任務級 eval 檢查是否真的提升成功率。這能把 loop-engineering 中反覆出現的操作沉澱成可載入能力，但不應取代 sensors；若 skill 只是讓 context 變長或增加誤用，就該刪減。

系列第三篇把 feedback loop 再縮到 tool call 內部：工具回傳值不能只給 stdout/stderr，而要把 exit code、耗時、檔案變更、測試摘要、失敗原因與下一步建議整理成 agent 可直接修正的訊號。這讓最便宜的 deterministic feedback 先攔下錯誤，避免問題擴散到整輪任務；對 coding agent 來說，工具不是被動 API，而是 dynamic-agent-workflows 裡的即時感測器與教練。

系列第四篇補上「兩次 model request 之間」的 mid-run injection：harness 不能在 tool call 結果尚未補齊時任意插入 user message，否則 OpenAI / Anthropic API 會因未配對的 tool result 直接失敗。可行做法是等當前 tool calls 全部回傳、對話狀態合法後，才把人類 steering、interrupt 後的新指令，或背景工具 / webhook / 告警的程式化訊息排進下一次 request。這讓 loop-engineering 多了一個比外層 loop 更輕的即時介入點：不必重啟整輪任務，也能在 agent 還沒輸出終局答案前修正方向。

系列第五篇補上單輪結束時的驗收層：每個 tool call 都正確，不代表整輪任務真的完成，因此 Goal / Outcome 應被寫成可驗證停止條件，包含終態、證據與限制。文章比較三種實作：Codex Goals 讓主模型自我審計並重播 goal contract，Claude Code /goal 讓獨立 Haiku 只看 transcript 判斷是否滿足停止條件，Managed Agents Outcome 則用全新 context 的 grader 操作 artifact、逐條 rubric 驗收。這補上 loop-engineering 最常見的 false success 缺口：驗證強度不是非黑即白，而是隨任務風險、成本、延遲與模型自我驗證能力調整。

Feedforward（引導）vs Feedback（回饋）

Feedforward（引導）── 事前給規則、指南、限制條件（如同教騎車時先扶著）
Feedback（回饋）  ── 讓環境自動回饋行為結果（如同裝輔助輪讓小孩感受傾斜）

兩者需並用，缺一不可。單靠 feedforward（寫一堆規則）會變成 nagging（嘮叨）。

Sensors（感測器）分類

• Linter：ESLint、Ruff、pylint
• Static Analysis：SonarQube、CodeQL
• Test Coverage：Jest、pytest-cov
• Mutation Testing：Stryker、PIT
• Dependency Scanning：Dependabot、Snyk
• Architecture Testing：ArchUnit
• AI Code Review：LLM-as-Judge

CPU vs GPU 工具分類

• CPU tools：確定性、快速、低成本（linter, type checker, unit tests）
• GPU tools：非確定性、慢、高成本（AI code review, LLM as judge）

Shift-Left 策略

Pre-commit (最快/便宜) → Pipeline (較慢/昂貴) → Continuous Monitoring
   Linter, Type Checker       整合測試, Mutation        長期監控
   Quick Tests                 AI Review

SDLC / CI 的重詮釋

Denny Huang 的投影片把這個概念往 SDLC 拉開：CI 不只是「push code、run tests、deploy」，而是跨階段的 harness。

• 需求與分析：保護問題定義，避免文件入口漂移，並讓 ADR 可追溯
• 設計：把架構判斷變成可檢查邊界，例如 schema、shared value governance、artifact boundary
• Coding：固定執行環境與依賴，讓變更進入系統時不靠個人環境運氣
• Testing：定義採用邊界，讓候選輸出能被使用、審查、或阻擋
• Maintenance：把依賴更新、變更合併、試跑與權限交接流程化

這個角度把 harness engineering 從「AI coding assistant 的輔助工具」擴展成「整個軟體生命週期的檢查與回饋系統」。

Skill 作為可預測的 guides

AIHAO 2026-07-25 整理 Matt Pocock 的 Skill 設計哲學，補上 guides 本身的工程品質判準：Skill 應讓 agent 重複走可預測的流程，而非承諾每次得到相同答案。user-invoked 與 model-invoked 是 context load 和 cognitive load 的取捨；steps、references、completion criteria 與 leading words 則是把流程導向可觀察行為的最小結構。

這不會降低 sensors 的必要性。no-op、重複、沉積與過長內容要靠刪除與分支化維護，leading word 是否有效要回看 reasoning trace，completion criterion 是否足夠則要用任務執行驗證；因此 agent-skills 是 feedforward guide，agent-trace-observability、測試與 review 才是 feedback。這也支持 ponytail-loop-review-gate 的最小原則：先證明某行真的改變 agent 行為，再保留它。

和 Loop Engineering 的關係

2026-06-26 的 ihower 投影片把 harness 和 loop 放在同一條主線上：harness 提供檢查點、否決點與修正訊號，loop engineering 則把這些訊號包成可持續運轉的流程。換句話說，harness 是回饋面，loop-engineering 是迴圈面；前者回答「怎麼知道對不對」，後者回答「怎麼一直做下去」。

AIHAO 系列第 6 篇補上一個反過度自動化的限制：外層 loop 只在單一 context 裝不下、任務彼此獨立，或外部事件必須自動觸發時才值得加入。Ralph 式重跑、Symphony 式看板協調、Cron 式排程都仍要依賴內層 harness 的 sensors；否則只是把未驗證輸出放進更快的迴圈，變成「slop in a loop」。

系列第 7 篇再把 harness 本身納入改進迴圈，形成 self-improving-harness：agent 可以根據 production trace、eval、regression set 與版本化 prompt / tool / schema 提出 harness 變更，但必須經過 promotion gate、rollback 與高風險人工 review。這條線把 coding-agent-as-optimizer 從「改程式」延伸到「改 harness」，也提醒團隊先建立可信 eval，再談自動爬坡。

Model-Harness-Fit 與過期風險

系列第 8 篇補上 model-harness-fit：模型不是只針對 API 訓練，而是針對特定 harness 的工具格式、tool loop、citation 標籤、skill 契約與回饋節奏做 post-training。同一個模型換 harness，或同一段對話中途切換模型，都可能讓工具形狀、prompt cache 與 transcript 分布失配；因此 agent 評估應比較「模型 + harness」配對，而不是把模型分數視為獨立常數。

這也表示 harness 會過期：memory、todo、grader、特殊 edit tool 可能只是補某一代模型的短處，模型升級後就要用 test-time-compute-evaluation 與任務級 eval 確認是否仍有淨效益。對 AI Ark 的 loop 來說，最小做法是先固定任務分布與主模型，量測實際 wiki ingest / verify 成果；不要在沒有失配證據前先做跨模型 adapter 或大框架。

系列第 9 篇把這個原則落到 agent-framework-selection：自建 agent 時先判斷要從全套 Deep Agent 改起，還是用基礎框架自己組裝。六項能力、核心 loop 是否開源、部署授權、任務分布穩定度都比框架名氣重要；沒有反覆的任務級失配證據時，不要先做跨框架抽象層。

LLM × Harness × Data × Task 的 fit

AIHAO 2026-07-25 的 Agent Harness 四部曲導讀把 harness 判斷再往外推一層：一個 LLM application 的穩定性不是只由模型或工具決定，而是 LLM × Harness × Data × Task 四者互相 fit。LLM 有 context、格式與熟悉介面的限制；Harness 提供工具、狀態、記憶、權限與錯誤恢復；Data 決定結構、切分方式、更新頻率與 ACL；Task 則決定是一次查詢、多步探索、跨文件綜合或數值計算。這補強 model-harness-fit 的判準：只優化 LLM + Harness，仍可能被 Data + Task 的錯配擋在 production 之外。

Function call 失敗先分層

同一篇導讀把 function call 失敗分成 Decision、Serialization、Guarantee 三層：Decision 是未呼叫或選錯工具，Serialization 是外層結構無法解析，Guarantee 則是合法結構違反 schema。provider 的 structured output 或推論引擎 parser 主要處理後兩層，工具的命名、數量與粒度才是工程師能直接改善 Decision 的地方；因此不應把所有失敗都統稱為 hallucination，也不應在未分辨失敗層次前一律 retry。這與 agentic-search-tool-curation 的「工具失敗訊號要能指導下一步」相連。

Agentic Engineering Patterns 的 evidence layer

AIHAO 對 Simon Willison guide 的導讀補上一個 user-facing 的 harness pattern：First run the tests、red/green TDD、手動探索、以真實輸出生成 walkthrough，以及小 PR 的 evidence。這些不是另一套 orchestration framework，而是把 agentic-engineering-patterns 的工程紀律接到本頁的 sensors：測試、CLI／瀏覽器觀察、可追溯檔案片段與人工 review 一起降低 agent 自我宣稱完成的空間。

它也提供一個 ponytail 邊界：subagent 主要用來保護頂層 context、處理高 token 探索，不是把每個小工作都拆成代理群；pattern、skill 與 harness 只有在任務證據顯示能改善結果時才保留。

從長規則到可驗收的工作流

BusinessNext 2026-07-29 的兩篇 Claude／Skills 整理補上 model-harness-fit 的遷移訊號：新模型若能自行判斷，過度約束、重複範例與無條件的「再檢查」可能只增加 context、工具呼叫與 token 成本；但這不代表刪掉 sensors 或高風險護欄。

Matt Pocock 的五站工作流則把 guide 與 feedback 接起來：先用 grill-me 外化決策，再以規格、vertical-slice tickets、TDD、獨立 review 與 Wayfinder 控制長任務；測試與規格 evidence 才是停止條件。這讓 agent-skills 負責 feedforward，loop-engineering 負責持續推進，sensors / review 負責否決錯誤，而不是把所有責任塞進更長的 prompt。

瀏覽器控制面也是 Harness

BusinessNext 對 ChatGPT Chrome、桌面版 Work / Codex 與 CDP 的整理，提供一個把 agent 帶出純文字對話的 harness 案例：瀏覽器 extension 是觀察與操作 sensor，桌面版是連接 terminal／filesystem 的執行層，Work / Codex 則依任務分配研究或程式修改。跨分頁研究、來源查核、GitHub repo 檢查與 localhost UI 重現，都應將瀏覽器觀察接回 loop-engineering 的「執行 → 驗證 → 修正」閉環，而不是只把 click automation 視為完成。

這個案例也補上安全與證據邊界：陌生 repo 先檢查 License、README、安裝腳本與遠端指令；登入狀態、表單、本機檔案與 CDP 權限要明確授權；修改後用 Console、lint、test、實際輸出與人工核對確認結果。產品文章中的功能與模式是 attributed claims，不是獨立 benchmark；可重用的 harness pattern 是把低摩擦瀏覽器 context capture 與 deterministic／human verification gate 綁在一起。

Cross-model review

Gary Chen 的影片把這個概念落到一個很實作化的版本：Claude 負責起草 implementation plan，Codex 負責 review，stop hook 負責攔截收工，marker 負責當放行暗號。更重要的是，審核不依賴人類手動複製貼上，而是靠同一個 Codex 對話持續收斂，避免每一輪都冷啟動後重新發明新問題。這是一個很典型的 solo developer harness：把容易偷懶的動作直接系統化。

BusinessNext 對 Fiona Fung 的整理補上團隊尺度的 ai-code-validation-bottleneck：當 Claude Code 讓程式碼供給成倍增加，瓶頸會從寫 code 移到驗證 code 是否符合 spec、架構與團隊共識。因此 harness 不能只停在測試與 review bot，還要把 spec 放進 repo、讓 agent 可比對意圖，並把人類審查留給高風險整合判斷。

BusinessNext 2026-07-28 對 Graph Engineering 的整理，補上 harness 之上的編排層：harness 負責工具介面、護欄、觀測與驗收，Graph 則把多個 agent／loop 接成有向圖或狀態機。可重用的最小要求是讓每個節點單一責任、在交棒處區分 deterministic rule 與模型判斷，並把進度、成本、產出、來源與預算上限外部化；這讓失敗可以局部重做，也讓長任務能暫停等待人核准。術語層級仍未形成業界共識，因此不把 Graph Engineering 當成新的標準框架。

這個分工也限制過度自動化：小任務不需要圖編排，只有在平行分支、跨 session 狀態、局部恢復或模型接手真的降低重做成本時才值得增加一層。dynamic-agent-workflows 負責依回饋改變策略，loop-engineering 負責持續推進，而 graph-engineering 負責把多個 loop 的依賴、交棒與成本邊界攤開。

多模態產物的 feedback gap

Karpathy 的 3D world 實驗提供一個 coding harness 的邊界案例：agent 能寫出大量 JavaScript、配置三維座標並生成動畫，卻不能自然地觀看影片或親自玩遊戲；它只能週期性截圖，再從靜態畫面猜測動態錯誤。這表示對互動式產物，deterministic test 不足以覆蓋感知與操作品質，harness 必須把 render、截圖、操作 replay 或人工接手做成可觀察 sensor。

可重用判準是把「能產生」與「能驗收」分開：先讓 agent 得到低成本、可重播的觀察，再依風險加入視覺比對、互動測試與人工 review；不要把 1M token 預算或長時間執行當成完成證據。這與 loop-engineering、agent-trace-observability 和 agent-experience 相連。

未解決的問題

• 功能正確性驗證：當 AI 自己寫測試時，如何確保測試本身是對的？
• 人類角色轉變：從「審查 AI 寫的程式」轉向「設計讓 AI 能自我審查的系統」

相關連結

• davidko — 以台灣社群脈絡介紹 Harness Engineering 的另一篇整理
• denny-huang — 以 SDLC / 教學投影片把 Harness Engineering 拉到整個開發生命週期
• ai-capability-perception-gap — AI 能力落差為何會影響人對 agent 工程邊界的期待