Harness Engineering - 如何對 Coding Agent 的程式碼建立信任

打開 PR review，看到 800 行 AI 產出的變更。你盯著螢幕三十秒，腦袋浮出那個每次都會出現的問題：這東西能信嗎？

Thoughtworks 的 Distinguished Engineer Birgitta Bockeler 在 Martin Fowler 網站上丟出了一篇重量級文章（2026-04-02 發表），直接正面回答這個問題。她的答案不是「可以」或「不可以」，而是：你需要建構一套系統化的控制機制，叫做 Harness。

Harness 是什麼？一句話講完

Harness = AI Agent 中除了模型本身以外的所有東西。

人類工程師寫 code 的時候，其實自帶一套「隱性 harness」——多年累積的編碼慣例、對複雜度的直覺痛感、「這段寫太爛了我自己看不下去」的美學標準。Agent 沒有這些。它能吐出幾乎任何程式碼，但沒有品味判斷、沒有組織記憶、沒有那種「雖然能跑但三個月後一定出事」的第六感。

所以你得把這些隱性知識外顯化成可執行的控制系統。人類的角色從「寫程式碼」變成「迭代改進 harness」——harness 的品質直接決定你能對 Agent 輸出建立多少信任。

雙向控制：事前引導 + 事後檢查

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

Guides（Feedforward）：Agent 動手之前先給它教材。像是 AGENTS.md、Skills、編碼慣例文件、OpenRewrite recipes。

Sensors（Feedback）：Agent 交出成果之後拿去考試。像是 tests、linters、type checkers、AI code review 指令。

Bockeler 講了一句蠻精準的話：

「只有 feedback 的 Agent 會不斷重複同樣的錯誤；只有 feedforward 的 Agent 則編碼了規則卻永遠不知道它們是否有效。」

每個方向又分兩種執行類型：Inferential（語義分析，靠 AI 判斷，較慢）和 Computational（確定性計算，毫秒級，像 linter 和 type checker）。四個象限交叉出來，就是完整的控制矩陣。

The Steering Loop：核心工作流

整篇文章最值錢的概念在這裡——轉向迴圈（Steering Loop）：

Agent 產出程式碼
Sensors 檢測到問題
人類分析問題模式
改進 feedforward 或 feedback 控制
同類問題未來不再（或較少）發生

關鍵洞察是：Agent 本身也能協助建構這些控制。讓它寫 structural tests、從重複模式中產生規則草稿、建立 how-to 指南。工程師不再是逐行寫 code 的人，而是不斷調校 harness 的系統設計師。

三個調控維度

文章把 harness 比喻為 cybernetic governor（控制論調節器），定義三個維度：

Maintainability Harness（可維護性）——最容易做，因為工具成熟。重複程式碼偵測、cyclomatic complexity、缺少測試覆蓋率、architecture drift，這些都有現成的 computational sensors 可以接。inferential 層面則是偵測語義重複、冗餘測試、暴力修復、過度設計。

Architecture Fitness Harness（架構適應度）——基於 Fitness Functions 概念。用 Skills 提供效能需求（feedforward），再用 performance tests 提供回饋（feedback）。這層需要你對系統架構有清晰定義才做得起來。

Behaviour Harness（行為正確性）——目前最不成熟的維度。Bockeler 很坦白地承認：

「這種方法過度信任 AI 產生的測試，這還不夠好。在行為正確性的 harness 方面，我們還有很多工作要做。」

這段話值得記下來。很多人在吹 AI 能自己寫測試自己驗證，但如果測試本身也是 AI 寫的，你只是在用一個你不完全信任的東西去驗證另一個你不完全信任的東西。

Keep Quality Left：越早擋越便宜

源自 CI/CD 的經典概念——品質左移。

Pre-commit：快速檢查。Linter、基本測試、code review agent，在 commit 之前就擋掉低級錯誤。

Post-integration pipeline：昂貴檢查。Mutation testing、大範圍 code review，放在 CI pipeline 裡跑。

持續漂移偵測：dead code detection、test coverage 品質、dependency scanning。不是一次性的，是持續在背景跑的。

對 AI 產出的 code 來說，左移策略特別重要。Agent 可以在幾分鐘內產出幾百行，如果等到 PR review 才發現方向不對，浪費的不只是 token 費用，還有 reviewer 的腦力。

真實案例：OpenAI 和 Stripe 怎麼做

文章引用了兩個大公司的做法：

OpenAI 團隊用分層架構，透過 custom linters 和 structural tests 強制執行。定期做「garbage collection」掃描偵測 drift。他們的結論很有意思：「我們現在最困難的挑戰集中在設計環境、反饋迴路和控制系統。」注意，不是模型本身，是 harness。

Stripe 的 “Minions” 則是用 pre-push hooks 執行 heuristic-selected linters，強調 shift feedback left。他們用 “Blueprints” 把 feedback sensors 整合到 Agent workflows 裡。

兩間公司殊途同歸：問題不在 Agent 夠不夠聰明，在於你的控制機制夠不夠完整。

Harnessability：你的 codebase 準備好了嗎？

有個容易被忽略的概念是 Harnessability——codebase 適合被 harness 控制的程度。

Strong typing 能啟用 type-checking sensors、清晰的模組邊界能啟用架構約束規則、Framework 的使用能抽象化 Agent 不需要處理的細節。反過來說，一堆 any type、沒有模組邊界、到處都是 magic string 的 codebase，harness 根本建不起來。

弔詭的是：Harness 最被需要的地方（legacy codebase），恰恰是最難建構的地方。 這大概是整篇文章最讓人無奈的洞察。