Software Engineering

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