Harness Engineering 入門：當模型不再是瓶頸，工程師真正該設計的是 AI 周圍的系統
核心觀點
這篇文章真正值得記下來的，不是 OpenAI「五個月產出百萬行程式碼、零行人類手寫 code」這種 headline，而是它把一件事講得非常清楚：
當 AI coding agent 越來越強，真正的瓶頸開始從模型本身，轉移到模型周圍的系統設計。
這個系統設計，OpenAI 用一個新詞來命名：Harness Engineering。
如果要用最白話的一句話解釋它，大概就是：
不是去教 AI 更會寫 code，而是設計一套環境，讓 AI 能穩定、可靠、持續地寫出可合併的 code。
為什麼需要一個新名詞
過去兩年，AI 輔助開發的敘事大致經歷了三個階段：
- Copilot 式補全
- Cursor / Claude Code 式互動式助手
- 現在的 agent：能自己開分支、跑測試、開 PR
當 agent 能力上來之後，問題開始變了。
以前大家會問：
- 模型夠不夠強？
- 會不會寫這個框架？
- 能不能解 LeetCode？
但現在更關鍵的問題反而是：
- 它知道專案規則嗎？
- 它有正確上下文嗎？
- 它會不會把架構越寫越亂？
- 它犯錯後有沒有回饋機制？
也就是說：
模型已經不是唯一限制，harness 才是。
Harness 是什麼意思
「Harness」原意是馬具、韁繩。
這個比喻很準：
- AI 模型像一匹很強但不完全可預測的馬
- 工程師不是繼續手動拉每一步
- 而是設計整套韁繩、軌道、限制與回饋系統
OpenAI 給的核心哲學可以濃縮成一句：
Humans steer, agents execute.
人類掌舵，代理執行。
這意味著工程師的角色不再是直接寫每一行程式，而是設計一個讓 agent 可以在裡面自主運作的控制系統。
Harness Engineering 的四個核心功能
從文章的定義來看，Harness Engineering 至少包含四件事：
1. 約束（Constraining）
定義代理能做什麼、不能做什麼。
2. 告知（Informing）
把任務目標、架構規範、專案知識放進代理能讀到的上下文。
3. 驗證（Verifying）
透過測試、檢查、review 系統，確認代理產出是否正確。
4. 修正（Correcting）
代理犯錯時，不是靠人類手動補洞，而是透過回饋迴圈讓系統自我修復或避免重犯。
所以它不是單一 prompt 技巧，也不是單純開更多工具權限，而是：
把 AI 代理放進一個可控、可驗證、可回饋的工程系統。
三根真正的支柱
這篇文章最有價值的部分，是把 Harness 拆成三根支柱。這三個概念非常值得長期記住。
一、Context Engineering：代理看不到的東西，就等於不存在
這幾乎是 AI coding 時代最重要的原則之一。
如果某條規則只存在於：
- 某個工程師腦中
- 三個月前的 Slack 討論
- 沒更新的 Wiki
那 agent 幾乎等於不知道它存在。
所以 Context Engineering 的重點是：
- 所有代理需要知道的事，都要寫進 repo
- repo 要成為 single source of truth
AGENTS.md應該像目錄，不是百科全書- 用結構化 docs 讓 agent 先知道知識地圖，再按需深入
這個觀念其實跟我們前面一直在整理的 skill / memory / docs 觀念高度一致：
好的 AI 工作流，不是把所有資訊塞爆上下文，而是把知識結構化，讓代理知道去哪裡找。
二、Architectural Constraints：限制解題空間，反而提升 agent 生產力
這個點非常反直覺，但很重要。
一般人可能以為： AI 很聰明，應該讓它自由發揮。
但現實常常相反。
如果沒有足夠約束，agent 會：
- 探索過多解法
- 複製 repo 裡次優模式
- 把局部可行解寫成長期技術債
所以真正好的 harness 會明確限制：
- 模組依賴方向
- 命名規則
- 允許的架構層次
- pre-commit / linter / structural test
- 甚至用另一個 LLM 做 LLM audit
這不是在壓制 AI，而是在縮小它的錯誤搜尋空間。
三、Entropy Management：AI 會製造一種新型態的混亂
這點也非常值得記。
AI 生成程式碼累積的混亂，和傳統人類技術債不完全一樣。
它更常來自：
- 文件漂移
- 命名分歧
- 架構規則逐漸鬆掉
- 已過時知識再次被 agent 拿來複製
所以 Harness 不只要讓 agent 產出，還要讓 agent 自己當清潔工：
- 定期掃描 repo
- 比對 docs 與實作是否一致
- 找出死 code / 壞依賴 / 不一致命名
- 自動開 PR 修正
這幾乎就是把「技術債清理」常態化、自動化。
也就是說，Harness 不只是生產系統，還是維護系統。
工程師角色真的變了：從寫 code，到設計環境
這篇最該被記住的，不只是工具流程，而是角色變化。
傳統工程師的工作重心大概是：
- 寫 code
- debug
- review
- 維護文件
Harness Engineering 下，重心會變成：
- 設計讓 AI 寫 code 的環境
- debug agent 的行為模式
- 設計 review / feedback loop
- 把文件當成機器可讀基礎設施來維護
這不是降低門檻，反而是把工程能力往更高層抽象推。
因為你不再只需要知道語法，而要知道：
- 系統的依賴關係
- 哪些規則必須 machine-enforce
- 哪些知識必須持續保鮮
- 哪些錯誤值得變成永久 guardrail
所以這篇其實不是在說「工程師要消失」，而是在說：
工程師的價值正在從直接產出 code，轉向設計讓 AI 持續產出好 code 的系統。
最值得抄下來的一句：每次 agent 犯錯，都是 harness 還能再升級的訊號
文章裡那個觀念我覺得非常對：
當代理犯了一個錯，不要只想「AI 好笨」，而要問：
- 缺了什麼上下文？
- 約束不夠明確嗎？
- 文件過時了嗎？
- feedback loop 斷了嗎？
也就是把每次錯誤都視為：
把一次性修補，升級成永久性系統改進的機會。
這才是 Harness Thinking。
要保留的現實感
當然，文章裡像「百萬行程式碼、零行人類手寫」這些敘事，很容易被拿來當神話。
更務實的理解應該是：
- 這不是說人類從此不用碰 code
- 而是說在特定條件下，人的工作重心可以大幅上移
- 前提是你真的投入大量精力在 docs、constraints、tests、feedback loops、observability
換句話說，Harness Engineering 不是偷懶捷徑，而是：
把原本零散、靠人記住的工程紀律，轉成 machine-readable、machine-enforced 的系統。
結論
這篇最值得記住的不是某個 OpenAI headline，而是它重新定義了一個工程判斷：
未來 AI coding 的競爭力，不只看模型有多強，更看誰能把模型放進一個更好的 harness 裡。
所以如果你真的想把 agent 用到深水區，關鍵不只是換模型，而是開始認真處理：
- context engineering
- architectural constraints
- entropy management
- feedback loops
- docs as infrastructure
這些東西，才是真正能把 agent 從「偶爾有用的寫碼助手」推到「可持續產出的工程系統」的核心。