AI 已經能大量寫程式，但真正該解的問題正在改變。當 Claude Code、Codex 這類 AI 寫程式代理快速普及，軟體團隊很快發現一件事：讓代理產出更多程式碼，並不等於交付更好的軟體。OpenAI 一支內部團隊曾以 Codex 在 5 個月內寫出約 100 萬行、全程無人手寫的產品，這類案例說明 AI 會不會寫程式已不再是重點，接下來要解的，是怎麼讓它在真實、大型的專案裡穩定、安全又可重複地交付。
而這個問題的答案，正凝聚成一個新的關鍵字：Harness Engineering，它指的是模型以外的那整層工程環境。技術社群 HackerNoon 進一步把它整理成 Context、Skills、Boundaries、Verification、Learning 五項控制，主張 AI 軟體交付真正的持久優勢，不在模型本身，而在你替模型打造的這層「支架」。這五項能力，究竟各自要建什麼？
Harness 是什麼？為什麼決勝點從模型移到模型外圍
Thoughtworks 傑出工程師 Birgitta Böckeler 在 Martin Fowler 的網站上定義，harness 指的是「一個 AI 代理裡除了模型以外的一切」，也就是 Agent = Model + Harness。在寫程式代理裡，一部分支架是內建的，例如系統提示或程式碼檢索機制；但代理也讓使用者能為自己的系統，再打造一層專屬的「外層支架」。
她指出，一個好的外層支架有兩個作用：一是提高代理「第一次就做對」的機率，二是提供回饋迴路，讓問題在送到人類眼前之前就先自我修正，從而減少審查負擔、提升系統品質。
這兩個作用，對應 Böckeler 拆出的兩種控制方向：指引（guides，前饋控制）在代理動手之前就先引導它，提高第一次就做對的機率；感測器（sensors，回饋控制）則在代理動手之後觀察結果、協助它自我修正。她進一步以執行方式區分：確定性（computational）控制由 CPU 執行,像測試、lint、型別與結構分析，快且可靠；推論式（inferential）控制則是語意分析、AI 程式碼審查這類「以 LLM 當裁判」的做法，較慢、較貴也較不穩定，但能提供更豐富的引導與語意判斷。她也提醒，只有回饋、沒有前饋，代理會不斷重犯同樣的錯；只有前饋、沒有回饋，代理則永遠不知道規則到底有沒有用——兩者缺一不可。這組框架，正是理解底下五項控制的透鏡。
HackerNoon 則把 harness 描述為「代理的運作環境」，它決定了代理能找到什麼、能用哪些工具、有哪些權限、要走哪些流程、必須通過哪些檢查。關鍵在於，這套環境的目標不是給代理無限自主，而是讓對的事更容易做、危險的事更難做。該文也強調，這不是把 prompt engineering 換個名字：提示詞只告訴代理「這一次」該做什麼，支架則是打造出一種讓「好行為」成為預設值的環境。
1. Context（脈絡）：讓系統可被讀懂
第一項是 Context（脈絡），核心是讓系統可被讀懂。HackerNoon 指出，代理無法使用它找不到的知識；埋在聊天紀錄、過期 wiki 或某位工程師腦中的架構決策，對代理而言等於不存在。因此程式碼庫應該把服務邊界、負責人、API、資料契約、操作手冊、限制與現行計畫都攤開來。
做法上，該文建議別寫一份上千行的指令檔，而是用一個精簡的入口，連向結構化、有版本控管的真實來源。這一點與實務經驗相呼應：OpenAI 團隊也採取「給代理一張地圖，而不是一本千頁手冊」的做法，用約 100 行的入口檔指向更深入的文件。
2. Skills（技能）：把專家做法變成可重用能力
第二項是 Skills（技能），把專家做法變成可重用的能力。HackerNoon 說明，技能不只是可重用的提示詞，而是把一套程序、相關脈絡、核可的工具、預期產出的證據與品質檢查一起打包。像資料庫遷移、API 變更、相依套件升級、事故調查、發布就緒檢查、雲端成本審視，都適合做成技能。以資料庫遷移為例，這個技能應該要求相容性分析、回滾計畫、遷移測試與可觀測性檢查，如此便把原本靠口耳相傳的「部落知識」，變成可重複使用的工程基礎設施。
3. Boundaries（邊界）：給代理有用但受限的權限
第三項是 Boundaries（邊界），重點是給代理「有用但受限」的權限。HackerNoon 主張，最好的代理不是擁有最多權限的那個，而是握有「剛好符合任務所需」權限的那個：事故排查代理可能只需要唯讀的遙測資料，程式碼生成代理可以寫入分支但不能合併，部署代理可以備妥變更、但改動正式環境前必須經過人工核准。換句話說，最小權限原則不只套用在人的身分上，也要套用在代理的能力上。
4. Verification（驗證）：先用確定性檢查
第四項是 Verification（驗證），原則是「先用確定性檢查」。HackerNoon 建議，測試、型別檢查、lint、政策即程式碼（policy-as-code）、安全掃描與架構規則這類又快又可重複的檢查，應該及早、且在每次變更時都執行；至於「設計是否符合意圖」「文件有沒有說明風險」這類確定性工具答不出來的問題，再交給 AI 審查。整體順序是：先跑確定性檢查，再讓代理自我修正，最後由人負責判斷與當責。
這正是前面「確定性／推論式」控制的落地：又快又可靠的確定性檢查打前鋒，推論式的 AI 審查補上語意判斷。Böckeler 還點出一個實用技巧：把自訂 lint 的錯誤訊息寫成夾帶修正指示的形式，等於是一種「正向的提示注入」，讓感測器直接餵給代理該怎麼改。她並主張把檢查盡量「往左移」(keep quality left），因為問題發現得越早，修起來越便宜。
5. Learning（學習）：把重複失敗變成系統改善
第五項是 Learning（學習），把重複出現的失敗變成系統性的改善。HackerNoon 強調，一個反覆發生的代理錯誤，不該一直停留在「反覆的對話」裡：如果代理一再誤用某個 API，就做一條技能或驗證規則；如果它老是違反模組邊界，就加一個結構測試；如果審查一再抓到同一種部署風險，就改善發布流程。每一次重複的失敗，都應該變成更好的規則、測試、工具或脈絡。
這也對應 Böckeler 所說的「操舵迴路」：人的工作是透過不斷迭代支架來引導代理，而且現在用 AI 來改善支架本身，例如協助撰寫結構測試、從觀察到的模式產生規則草稿，也變得更便宜。
別再用「程式碼行數」衡量成效
當代理能大量產出，衡量方式也得跟著換。HackerNoon 明確主張，不要再把程式碼行數、提示詞數量或代理開出的 PR 數，當成 AI 成功的主要指標，而要衡量「交付系統本身有沒有變好」。
它列出的指標包括首次通過驗證率（代理的變更不需大改就通過檢查的比例）、人工介入率、逃逸缺陷或回滾率、架構違規率、從核可計畫到安全合併所花的時間、證據覆蓋率（變更是否附上測試與風險說明），以及支架本身的新鮮度。這套思路正好收束回 DORA 的提醒：真正該問的，不是誰寫得多，而是整個交付系統是否更穩、更可靠。
人退到哪裡？把判斷力編碼進系統
如果檢查與修正都能交給系統，人還剩下什麼？Böckeler 的答案是，人帶來的是代理沒有的東西：對組織目標的對齊、對「什麼叫好」的品味，以及「我的名字掛在這次提交上」的當責感。
代理沒有社會性的當責、不會對一個 300 行的函式感到不適、也沒有「我們這裡不這樣做」的直覺與組織記憶。她因此把支架定位為，試著把資深工程師的經驗外顯、寫成明確的規則，但這件事只能做到一定程度。也正因為建立一套彼此協調的指引、感測器與自我修正迴路成本高昂，好的支架不該以「完全消除人力」為目標，而是把人的心力導向最需要判斷的地方。
這也說明了為什麼持久的競爭優勢會落在支架、而非模型本身：模型會越來越強、也越來越可替換，但一套「讓代理可靠交付」的環境，是團隊自己長出來的資產。不過這條路仍有明顯未解的部分。
Böckeler 坦言，最難的是「行為支架」，也就是如何確認應用程式在功能上真的照需求運作；目前多數高自主度的團隊，仰賴的是一份功能規格加上 AI 生成的測試，但把信任押在 AI 自己寫的測試上，她認為「還不夠好」。換句話說，Harness Engineering 已經清楚指出下一階段該練的能力，但要練到能大幅減少人為監督，軟體團隊要補的課還沒上完。
【推薦閱讀】
◆ Loop Engineering 崛起：當 AI Agent 能自己工作，Google 工程師點人類三大職責
＊本文開放合作夥伴轉載，資料來源：HackerNoon、OpenAI、Martin Fowler，首圖來源：Unsplash
