這篇文章是《Harness Engineering：讓自主 AI 軟體工程可被信任的治理方法論》系列的總覽，也可以獨立閱讀。本篇先從問題與整體框架出發，整理出「合約、證據、見證、授權」四個治理支柱。

前言

用過 Claude Code、Codex 或 GitHub Copilot 這類 coding agent 的人，大概都有過一種矛盾的感受：它產出程式碼的速度快得驚人，快到你根本來不及一行一行看完。

一開始會覺得：這太讚了吧，工作速度與效率都明顯提高了。

但問題是，AI 產 code 的速度實在太快了，人類 review 的速度根本跟不上。為了維持產出的速度，最後常常乾脆選擇相信 AI，直接 approve 或 merge，但內心總是忍不住懷疑：這樣真的對嗎？

  • 這段程式碼真的是照當初講好的需求做的嗎？
  • 出事的時候，責任算誰的？
  • 它有沒有悄悄違反我們的架構決策？
  • 到底什麼時候才能安全地把它合併、上線？

先前介紹 WebMCP 時有提到：涉及交易或破壞性的重要操作，一定要設計「Human-in-the-loop」的最後確認機制。那句話其實只是冰山一角。當 AI 從「幫你查資料的聊天機器人」變成「幫你動手改 code 的 agent」，我們需要的就不再只是「一個確認按鈕」，而是一整套讓機器產出可被信任的工程方法。

這套「讓機器產出可被信任」的工程方法，最近開始被稱作 harness engineering。這個詞會廣為人知，很大一部分要歸功於 OpenAI 的一篇文章 《Harness engineering: leveraging Codex in an agent-first world》：他們分享了一種「工程師幾乎不親手寫 code，而是去打造讓 agent 不出錯的結構、文件與自動檢查」的 agent-first 開發實踐。而這個系列想談的，不是怎麼操作某個工具，而是它背後的治理方法論。

什麼是 harness engineering？

先講「harness」這個字。它原本是「馬具、輓具」的意思 —— 套在馬身上、讓馬的力氣能被駕馭、用在對的方向上的那組裝備。

放到 AI 的世界，harness 指的是「讓一個語言模型變成可靠 agent 的那層骨架」：工具（tools）、流程（workflow）、驗收（verification）、授權（authorization）。模型負責「產出」，harness 則決定「這份能力怎麼被安全地使用」。

這種模式，可以使用一個公式來表示：

Agent = Model + Harness

這個講法最早出自 LangChain 的 〈The Anatomy of an Agent Harness〉（2026），而 Thoughtworks 的 Birgitta Böckeler 在 Martin Fowler 網站的一篇專文（2026）裡把它闡述得最清楚。

她把 harness 拆成前後呼應的兩個部分：

  • 導引（guides）：agent 執行前的規範、範本，以及要餵給它的 context，負責界定「該做什麼」。
  • 感測（sensors）：agent 執行後的測試、靜態檢查、驗收，負責驗證「有沒有做對」。

導引在前、感測在後，一前一後，構成一個能讓 agent 持續自我修正的回饋迴路。

怎麼讓 agent 跑得動、測得過，這部分 OpenAI 和 Thoughtworks 大致都示範過了。這個系列想補的是另一塊：真實團隊在導入時，最後真正卡關的那道門檻 —— 「敢不敢採用」。而這道門檻，恰恰也是整個 harness 裡最硬、最難被複製的一層 —— 驗證與治理（governance）。

用開車來比喻：

base model 是引擎，harness 是整台車。

引擎（模型）決定你能跑多快；但煞車、儀表板、安全帶、方向盤（harness）決定你敢不敢上路。一顆再強的引擎，如果沒有這些，沒有人敢開它上高速公路。

過去兩年，大家的注意力幾乎都在引擎上：誰的模型參數量大、誰的 benchmark 跑分漂亮。但真正決定「能不能拿去做正事」的，往往是車子的其他部分。

AI 賦能軟體工程的重心，正從「模型能力」轉移到 harness

這背後其實是因為現在正在發生的現實：頂尖模型正變得又便宜又普及（也就是所謂的 commoditization）—— 能力持續提高，價格卻一路走低；就連能在自己電腦上跑的開源 LLM，也越來越強，需要的算力越來越親民。

原本只有少數大戶可以負擔得起的 AI 或 Token，漸漸變成大家都負擔得起的服務。

各家頂尖模型的能力越來越接近、越來越可以互相替換。今天你用這家、明天換那家，對多數應用來說差異沒有想像中大。當「引擎」趨於同質，差異化自然就從「模型多聰明」，往上移到「模型外的骨架多可靠」。

而在整個 harness 裡，有些東西相對容易做（接個工具、串個流程），有些則又難做、又極度需要信任。最難做好、也最需要被信任的那一層，就是「驗證與治理」：

  • 怎麼證明 agent 的產出符合當初的約定？
  • 怎麼讓這個「證明」可以被重現、被稽核、甚至被別人拿去挑戰？
  • 誰有權說「這個可以放行」？

這些問題沒有一個是靠「把 prompt 寫得更好」能解決的。它們需要的是工程紀律，而不是更聰明的模型。

工程師的工作，從「寫 code」變成「打造環境」

前面提到 OpenAI 那篇文章，其實記錄的是一場很極端的實驗：他們用五個月、從一個空的 Git 程式碼庫開始，做出一個真的有人在用的內部產品 —— 大約一百萬行程式碼、約 1,500 個 PR，全部由 Codex 產生，人類一行 code 都沒有親手寫，而推動它的核心團隊只有三個工程師。

不過真正值得注意的，是他們對「工程師該做什麼」的重新定義。當人類不再親手寫 code，團隊的主要工作就變成了 設計環境、把意圖講清楚、建立回饋迴路，好讓 agent 能穩定地把事情做完。他們用一句話總結：「人類掌舵，代理程式執行。」 這種模式下，稀缺資源已經不是算力，而是人的時間與注意力。

這個轉變，在處理失敗的方式上最明顯。當 agent 出錯時，這個團隊通常不會急著叫它再跑一次，也不會回頭把 prompt 改得更詳細，而是先退一步問：是不是環境少給了它什麼？這條規則，有沒有辦法寫成 agent 讀得懂、又能被自動強制執行的形式？ 對這個團隊來說，agent 失敗不是「再補一次 prompt」的理由，而是「環境該補強了」的訊號。

這個轉變，其實就是這個系列想談的核心：治理靠的不是更會講話的 prompt，而是固化在環境裡、能被機器強制執行的結構。信任不是一句提示，而是一條可以被驗證的鏈。

核心轉向：從「相信 agent」到「驗證結果」

如果這系列文章要用一句話來表達：

判斷「能不能信任」的依據，要從「模型的意圖」移到「可重現的結果」。

早期我們很自然地會「相信 agent」：它說做完了，我們就當它做完了；它說測試過了，我們就當它測過了；甚至讓另一個 LLM 去幫忙「評分」第一個 LLM 的產出。

問題是，模型的自評無法被重現、也無法被稽核。同樣一段輸入，今天說 OK、明天可能說不 OK；被使用者稍微「說服」一下，結論就變了。把治理建立在這種東西上，等於把公司的責任邊界，交給一個會隨機飄動的判斷。

真正能當依據的，是這些不會飄的東西：

  • 一份被鎖定、無法事後偷改的合約（規格與架構決策）。
  • 從確切版本導出、可以重跑的Git 事實與 evidence chain（證據鏈）。
  • 明確落在某個人類或政策主體身上的授權。

換句話說：

Trust is a chain, not a prompt.（信任是一條鏈，不是一句提示。）

這個轉向還有一個很現實的推力：逐行 code review 正在破產。 當 agent 一天開出幾十個 PR、動輒上千行，要人類逐行讀完、讀懂、還讀得出問題，根本不可能 —— 硬撐下去只有兩種結局：盲目按 approve（引狼入室），或審查塞車（卡死交付）。

出路不是叫人讀得更快，而是把人類的角色往上搬：從「審查每一行 code」，變成「審查合約與證據」。人只需要看「當初約定了什麼、機器產出的證據對不對、誰有權放行」，把逐行檢查交給確定性的工具。而要讓「審查合約與證據」這件事可行，就需要一整套結構 —— 這就帶到本系列的骨架。

治理的四個問題

要讓 agent 的產出值得信任，不能只看它最後交出了多少 code，還要依序回答四個問題：

  1. 它到底要做什麼？ 先把需求、限制，以及「什麼情況算完成」寫清楚。這份規格就是 Contract（合約），也要把「這次不做什麼」一起說明，避免 agent 自行擴大範圍。
  2. 怎麼證明它真的做到了？ 透過測試、靜態檢查等確定性的檢查，產出可以重新執行的 Evidence（證據）。證據還要綁定產生它的那個確切版本，不能拿舊結果來替新版本背書。
  3. 誰來確認結果符合需求？ 機器檢查通過，只能代表檢查有跑完，不能代表整體方向一定正確。因此還需要獨立的 Attestation（見證）：審查者逐條確認需求，並留下具體的問題、引用位置與處理結果。
  4. 誰有權讓它繼續往下走？ 通過檢查、完成審查，不代表任何人都能合併、發布或上線。這些動作需要清楚的 Authority（授權）；一次 commit 或 push，本身不會自動取得放行的權限。

這四個問題是一層一層接起來的：先定義要做什麼，再證明做到了；確認結果符合需求後，最後才判斷誰有權放行。少了其中任何一步，後面的結論都不完整。

四支柱信任鏈：Contract 合約 → Evidence 證據 → Attestation 見證 → Authority 授權

風險管理：先評估，再決定治理方式

治理不代表每一個變更都要經過同樣嚴格的流程。比較好的做法是先進行風險評估，再依照風險等級決定要採取簡易或嚴格的治理手段。

例如，修改文件中的錯字，通常只會造成很小的影響，可以採用簡單的檢查流程；但如果變更會影響系統架構、權限或資料，甚至可能造成難以回復的結果，就需要完整的測試、審查與人工核准。

換句話說，風險等級較低的工作要能快速完成，風險等級較高的工作則要提高把關強度。如果所有事情都套用最複雜的流程，團隊很容易覺得治理只是負擔，最後反而想辦法繞過它；但如果所有事情都用最寬鬆的方式處理，又失去了治理的意義。

這裡還有一個很重要的原則：風險等級可以往上調高，但不能在沒有理由的情況下被偷偷調低。

風險等級越高，就應該使用越嚴格的治理方式；除非重新評估並留下清楚的理由，否則不能任意降回簡易流程。

這項原則在 agent 的工作流程中特別重要。Agent 能快速產生大量變更，過程中也可能讓原本看似簡單的任務逐漸擴大。這時候應該依照重新評估後的風險等級，改用更嚴格的治理方式，而不是因為「檢查太麻煩」就把它當成低風險處理。

因此，風險管理可以濃縮成兩個步驟：先評估變更可能造成的影響，再依風險等級選擇相應的治理強度；風險等級越高，把關要求就越嚴格。

先評估風險，再依風險等級選擇治理強度；風險等級越高，治理要求越嚴格，若要降級則必須重新評估並留下理由

總結

Harness engineering 想解決的，其實不是「怎麼讓 AI 更像魔法」，而是相反的方向：

怎麼讓自主軟體工程，更像一套可以被稽核、被授權、被規模化的工程基礎設施。

當基礎模型逐漸商品化，真正稀缺、真正難被複製的，是模型外那層讓產出「可被信任」的骨架 —— 而骨架裡最硬的一塊，就是驗證與治理。整個系列的主線只有一個轉向：從相信 agent，走向驗證結果。

如果想把這套方法落地，可以依序從「規格即合約」、「驗收即證據」與「授權邊界」三個實務問題深入；但這篇總覽本身不依賴其他文章才能成立。

參考資料