這篇文章是《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 則決定「這份能力怎麼被安全地使用」。

LangChain 在 〈The Anatomy of an Agent Harness〉（2026）中，將這個概念濃縮成一個很直觀的公式：

Agent = Model + Harness

Thoughtworks 的 Birgitta Böckeler 則在 Martin Fowler 網站的一篇專文（2026）裡，進一步整理了 harness 的組成與作用。

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

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

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

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

用開車來比喻：

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

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

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

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

這背後其實是因為現在正在發生的現實：大語言模型正逐漸普及，使用門檻也持續降低—— 能力持續提高，價格卻一路走低；就連能在自己電腦上跑的開源 LLM，也越來越強，需要的算力越來越親民。

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

對部分軟體工程任務而言，模型之間的能力差距正在縮小，模型替換的門檻也比過去低。但在 coding、long-context、tool use、computer use 與 reasoning 等面向，模型之間仍然可能存在明顯差異。當「引擎」在可明確驗收的任務上變得更容易替換，差異化自然就從「模型多聰明」，往上移到「模型外的骨架多可靠」。

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

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

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

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

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

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

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

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

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

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

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

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

問題在於，LLM review 可以協助找問題，但判斷可能受到模型版本、context 與推論結果影響，不能只憑一句「通過」就成為放行依據。同樣一段輸入，今天說 OK、明天可能說不 OK，被使用者稍微「說服」一下，結論也可能改變。

測試與靜態檢查的優勢，是能明確描述檢查條件並留下執行結果；但它們也不會天然保證可重現。工具與依賴版本、時間、亂數、網路服務和執行環境，都可能影響結果。因此證據需要綁定確切的程式版本與執行條件，讓別人知道該如何重跑，以及結果可以支持多大的結論。

必要檢查缺失、失敗或狀態不明時，不能把未知當成通過。即使所有檢查都通過，也只能支持被覆蓋的條件，不能直接推論整個系統完全正確。

真正能拿來對帳的，是這些有明確版本與適用範圍的紀錄：

  • 一份已確認、具備版本快照的合約，讓後續變更可以和當初同意的規格及架構決策比對。
  • 從確切版本導出、記錄執行條件並可重新執行的 Git 事實與 evidence chain（證據鏈）。
  • 可追溯到人類或經核准政策的授權依據，以及每次決策的紀錄。

合約建立版本基準後，工作中的檔案仍可能被修改。若要防止執行者連同比對基準一起重寫，就需要把信任根放在執行者無法控制的邊界，例如受保護的版本紀錄，或搭配可信金鑰與授權政策的數位簽章。Hash 負責辨識內容；來源是否可信、誰有權核准，還需要各自的驗證機制。

換句話說：

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

這個轉向還有一個很現實的推力：逐行 Code Review 正在成為專案交付的瓶頸。 當 agent 一天開出幾十個 PR、動輒上千行，人類逐行讀完、讀懂並找出問題的速度，很快就會跟不上產出速度。繼續使用同一套審查方式，結果不是降低審查深度，就是讓交付排隊等待。

出路不是叫人讀得更快，而是把人類的角色往上搬：從「審查每一行 code」，變成「審查合約與證據」。人類的注意力可以更多放在合約、證據、風險與放行判斷。格式、型別、已知規則與可明確定義的行為，適合交給自動化檢查；需求意圖、設計取捨，以及工具尚未覆蓋的風險，仍需要審查者判斷。

這不代表人類從此不看程式碼。涉及權限、安全性、資料遷移或其他高風險變更時，仍可能需要深入檢視實作。治理要做的是讓人知道哪些地方已有證據、哪些地方仍有不確定性，據此分配審查深度。而要讓「審查合約與證據」這件事可行，就需要一整套結構 —— 這就帶到本系列的骨架。

治理的四個問題

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

  1. 它到底要做什麼？ 先把需求、限制，以及「什麼情況算完成」寫清楚。這份規格就是 Contract（合約），也要把「這次不做什麼」一起說明，避免 agent 自行擴大範圍。
  2. 怎麼證明它真的做到了？ 透過測試、靜態檢查等機械化、在固定條件下可重跑的檢查，產出 Evidence（證據）。Evidence 還要綁定實際被驗收的確切版本與執行條件，不能拿舊結果來替新版本背書。
  3. 誰來確認結果符合需求？ 機器檢查通過，只能代表檢查有跑完，不能代表整體方向一定正確。因此還需要 Attestation（獨立確認）：由與產出角色分離、並具備必要權限隔離的審查者或審查機制，根據合約逐條確認機器產出的證據是否足以支持需求已被滿足，並留下具體的問題、引用位置與處理結果。換一個 agent 名稱或另一個模型，不會自動建立獨立性；仍要確認產出方能否改寫審查紀錄、控制審查者的憑證，或替自己核准。需要更高保證的環境時，還必須隔離執行環境與簽署權限。
  4. 誰有權讓它繼續往下走？ 通過檢查、完成審查，不代表任何人都能合併、發布或上線。這些動作需要清楚的 Authority（授權）；一次 commit 或 push，本身不會自動取得放行的權限。

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

四支柱信任鏈：Contract 合約 → Evidence 證據 → Attestation 獨立確認 → Authority 授權

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

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

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

如果所有事情都套用最複雜的流程，團隊很容易覺得治理只是負擔，最後反而想辦法繞過它；但如果所有事情都用最寬鬆的方式處理，又失去了治理的意義。

風險等級越高，把關要求越嚴格；風險等級可以往上調高，但不能在沒有理由的情況下被偷偷調低。 如果要降回簡易流程，必須重新評估並留下清楚的理由。

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

低風險工作在必要的 Evidence 與 Attestation 完成後，可以依事先核准的政策自動往下走，但政策本身也要有明確的制定者、修改權限與適用範圍。人類仍需要能看到例外，並在風險改變時暫停流程、撤銷權限或切回人工核准。這是 Human-on-the-loop 的前提，也會在後續的授權邊界文章中展開。

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

總結

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

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

當大語言模型逐漸普及，在部分可明確驗收的任務上也變得更容易替換，真正稀缺、真正需要長期累積的，就變成模型外那層讓產出「可被信任」的骨架 —— 而骨架裡最硬的一塊，就是驗證與治理。整個系列的主線只有一個轉向：從相信 agent，走向驗證結果。

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

參考資料