Harness Engineering

概述

Harness Engineering 是一套為 Coding Agent 使用者設計的心智模型與工程方法，目的是提升對 AI 生成程式碼的信任度、減少人工審查負擔，同時維持系統品質。

核心公式：

Agent = Model + Harness

名詞釐清：「Harness」在不同脈絡下有廣狹兩義

用法 定義 來源
廣義 Harness AI Agent 中除了模型本身以外的所有部分，包含 Skills、提示詞、協調機制、驗證系統等 Martinfowler Harness Engineering（2026-04-05）
狹義 Harness（Thin Harness, Fat Skills 架構） 僅指約 200 行的薄執行層，負責在迴圈中執行模型、讀寫檔案、管理上下文、強制安全規則；Skills 是獨立的可重用工作流程檔案，明確與 Harness 分開，「90% 的價值在此」 Y Combinator 總裁 Garry Tan

兩種定義並不矛盾：廣義定義劃定系統邊界（Model vs. 其他一切），狹義定義是廣義 Harness 內部的次架構原則——強調執行層要精簡（Thin Harness），領域知識與判斷力集中在 Skills（Fat Skills）。詳見 Thin Harness, Fat Skills — Garry Tan AI 效能架構。

Coding Agent 通常內建部分 Harness（如系統提示、程式碼檢索機制、協調系統），但也允許使用者為特定專案與系統建立外層 Harness（Outer Harness）。

來源：https://martinfowler.com/articles/harness-engineering.html, 2026-04-05

為何需要 Harness：LLM 的「可信性偏差」

LLM 的根本特性是優化可信性（plausibility）而非正確性（correctness）。這不是 bug，而是訓練目標所致。

具體案例：SQLite Rust 重寫

一個由 LLM 主導生成的 SQLite Rust 重寫項目（576,000 行 Rust、625 個檔案），表面上看起來完整：

  • ✅ 程式碼可編譯
  • ✅ 通過所有測試
  • ✅ 正確讀寫 SQLite 格式
  • ✅ README 聲稱支援 MVCC 並發寫入、C API 相容
  • ✅ 架構命名正確（parser、planner、VDBE、B-tree、pager、WAL）

實際效能與原版 SQLite 的比較：

操作 效能差距
批次 INSERT（基準） 298x 慢
單筆 INSERT（無 transaction） 1,857x 慢
SELECT BY PRIMARY KEY 20,171x 慢
UPDATE / DELETE 2,800x+ 慢

根本原因是兩個具體 bug：

  1. INTEGER PRIMARY KEY 未被識別為 rowid 別名：SQLite 的 WHERE id = 5 應觸發 B-tree 直接查找（O(log n)），但重寫版退化為全表掃描（O(n)）
  2. WAL checkpoint 過度觸發：每次寫入後都觸發完整 checkpoint，磁碟 I/O 爆炸

這些 bug 不影響「功能正確性」，只影響效能——而一般的功能測試根本抓不到它們。

來源：https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code, 2026-03-06

系統性問題，非個案

外部研究支持此為普遍模式：

  • METR 隨機對照研究：未經充分驗證的 LLM 輸出存在系統性錯誤
  • GitClear 大規模 repo 分析：在大量真實程式碼庫中觀察到相同失敗模式

實踐推論：驗收標準（acceptance criteria）必須在第一行程式碼生成之前就定義好。這正是 Harness Engineering 中「Guides（前饋控制）」的核心應用場景。

來源：https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code, 2026-03-06

範式演進脈絡

從 Prompt Engineering（2023-2024）→ Context Engineering（2025）→ Harness Engineering（2025+）：

階段 核心問題 解法
Prompt Engineering 怎麼把話說對 優化提示詞
RAG 讓模型知道更多 外掛知識庫
Harness Engineering 模型不可靠的前提下讓系統可靠 結構化約束與驗證系統

重心已從「優化模型」轉移到「重新定義系統設計」。不再假設 AI 會給出正確答案，而是把它當成「可能產出不錯候選解」的元件——真正的核心是系統如何限制它能做的事、驗證它的輸出、出錯時如何修正或回滾。

來源：2026-04-05-Harness-Engineering-閱讀筆記與延伸思考

Harness 的兩個互補機制

Harness 拆成兩個方向，缺一不可：

Feedforward（前饋控制 / 引導）

在模型行動「之前」預防問題。

  • 明確的規範、架構約束、coding conventions
  • 讓模型一開始就往正確方向走
  • 驗收標準必須在第一行程式碼生成前就定義好

缺點：只有 Feedforward，永遠不知道規則有沒有真的被遵守。

Feedback（回饋控制 / 感測）

在模型行動「之後」偵測問題並觸發修正。

  • Linter、自動測試
  • 讓另一個 LLM 做 code review
  • 把路徑修正回來

缺點：只有 Feedback，Agent 會一直重複犯同樣的錯。

來源：https://martinfowler.com/articles/harness-engineering.html, 2026-04-05

設計哲學類比

這種設計思維更接近：

  • 資安的縱深防禦（Defense in Depth）：多層防線，任一層失效不影響整體
  • 分散式系統的容錯設計：假設節點會失敗，設計系統使其依然可靠

而非傳統應用開發的「假設元件正確運作」思維。

來源：2026-04-05-Harness-Engineering-閱讀筆記與延伸思考

真實世界案例：Claude Code 原始碼外洩

Claude Code 原始碼外洩事件中，研究者從外洩程式碼發現大量用來限制、驗證、修正模型輸出的機制——這是 Harness 概念的絕佳現實案例。Coding Agent 的可靠性，根本上依賴這些圍繞模型的結構化控制系統，而非模型本身的「聰明程度」。

來源：2026-04-05-Harness-Engineering-閱讀筆記與延伸思考

競爭意涵

在大家都使用類似基礎模型的時代，AI 產品的信任度與競爭力，越來越取決於 Harness 的設計能力。

模型會持續進步，但真正拉開差距的，是誰能打造出讓模型在現實世界中「不會出事」的系統設計。系統架構師的核心價值，在 AI 時代反而更加凸顯。

來源：2026-04-05-Harness-Engineering-閱讀筆記與延伸思考

反向連結

以下頁面引用了本頁：