Agent Harness 正在定義 AI 工程

2026 年 2 月，Martin Fowler 給了一個名字：Harness Engineering。這不是新玩具。這是很多團隊早就在做的事，只是現在終於有共同語言。

同一時間，Anthropic 公布 long-running agent 的 harness 指南。OpenAI 也提到，Codex 團隊已經產出超過 100 萬行 production code，而且沒有人工逐行輸入。講白了，模型很重要，但外層系統更決定結果能不能落地。

如果你在做 agent，這件事很值得盯。像 Claude Code 這種工作流，或你自己做的 agent stack，都可能讓同一個模型表現差很多。包得好，像樣。包得爛，像昂貴的重試機器。

Agent harness 到底是什麼

Agent harness，就是包在 LLM 外面的控制層。它決定 agent 看得到什麼、能做什麼、什麼時候停、出錯後怎麼回來。你可以把模型當成推理引擎，把 harness 當成外面的操作系統。

這個分工很重要。因為原始輸出通常不能直接上 production。模型可以寫 code、摘要文件、規劃任務，但真正能跑的流程，需要一層層控制。沒有這層，agent 很容易飄掉。

實作上，harness 通常會包這些東西：

• 工具呼叫，像檔案、搜尋、API、執行環境
• 狀態管理，讓 agent 記得任務進度
• 驗證點，先檢查再往下走
• 重試邏輯，處理 timeout 和工具失敗
• 權限控制，避免亂動 production 資料
• log 和 trace，方便事後追查

很多 demo 很會演。你看到的是 agent 一路順順跑。你沒看到的是工具壞掉、上下文遺失、還有它差點把錯誤操作送進正式環境。真正難的地方，通常都藏在 harness 裡。

Martin Fowler 會提這個詞，不是沒原因。他長期在講軟體系統怎麼在真實世界壞掉。這種人一出手，通常代表產業已經從玩票，走到工程化。

為什麼模型只算一半

現在很多人還在用「模型更強，所以產品更好」這種線性思維。說真的，這只對一半。模型分數變高，不代表長任務就會穩。只要工具鏈不行，整個 agent 一樣會翻車。

Anthropic 對 long-running agents 的討論，把這點講得很清楚。任務一拉長，漂移、忘記、誤操作的機會就會增加。harness 的工作，就是把 agent 拉回來，讓它不要一直偏題。

OpenAI 提到 Codex 團隊產出超過 100 萬行 production code，這個數字很有意思。這不是玩具 demo。這代表一套周邊流程，已經能吞下大量真實工程工作。重點不是模型自己多神，而是整個執行層夠不夠穩。

“The most important thing is to be able to understand what the model is doing.” — Dario Amodei

這句話很直白。你如果看不懂 agent 在做什麼，就談不上工程。那只是把一個機率黑盒，包成很會聊天的介面。

現在做得認真的團隊，都在往同一個方向走。可觀測性、工具紀律、失敗回復，這些才是可靠性的核心。不是祈禱模型今天心情好一點。

好的 harness 現在長什麼樣

目前還沒有單一標準答案。可是真的看幾個做得好的系統，結構都很像。它們不是靠一句 prompt，而是靠一堆小控制點，把 agent 限制在可預期範圍內。

你可以把常見層級分成這樣：

• 基本 chat wrapper： 一個 prompt 接一個回應，狀態很少，變動很大
• Task agent： 有工具、短期記憶、基本重試，適合範圍明確的工作
• Production harness： 有驗證、audit log、policy check、sandbox、rollback
• Long-running agent system： 有持久狀態、評估迴圈、人工審核、失敗復原

從第一層跳到第四層，差很多。chat wrapper 一個下午就能做。production harness 不是。因為每一次 tool call，都可能新增一種失敗模式。

這也是為什麼現在團隊開始看營運指標，而不是只看模型指標。像 task completion rate、tool error rate、time to recovery、unsafe action blocked 次數，這些都比單純 benchmark 更接近真實世界。

如果 agent 會碰 codebase、客服系統、或客戶資料，這些數字比模型分數更有用。分數高，不代表能少出事。出事少，才是真的。

我覺得這裡還有一個文化轉變。早期 AI 產品是「模型本身就是產品」。現在更像是「工作流才是產品」。agent 能做什麼、不能做什麼、出錯怎麼救，這些才是核心。

競品怎麼比，差距在哪

如果只看表面，大家都在做 agent。可是底下的 harness 差很多。有人只做一層 prompt，有人把 sandbox、verifier、policy、trace 全包進去。這差距會直接反映在穩定性上。

先看最簡單的比較：

• 單純聊天介面： 成本最低，但狀態弱，容易失控
• 內建工具的 IDE agent： 適合 coding，能做檔案操作和測試
• 企業級 agent 平台： 強調權限、稽核、資料隔離、流程控管
• 自建 harness： 彈性最高，但工程成本也最高

Cursor 這類產品，讓很多開發者第一次感受到 agent 工作流的效率。但你一旦進到企業環境，就會碰到權限、稽核、資料界線。這時候，單靠好 prompt 根本不夠。

另一個現實是，模型越強，不代表你可以少做控制。反而常常是模型越強，越要管住它。因為它能做的事更多，出錯的代價也更高。

如果拿 coding agent 來比，差異通常在這幾點：

• 是否有測試先行，而不是直接改檔
• 是否能回滾，而不是一改到底
• 是否有權限邊界，而不是全開
• 是否有 trace，而不是只看最後答案

OpenAI、Anthropic、還有一堆新創，現在其實都在往同一個方向走。差別只在包裝。核心都一樣：把不穩定的模型，放進能管理失誤的系統裡。

這背後其實是軟體工程回歸

這波 agent 熱潮，看起來像 AI 新玩意。其實很像軟體工程老問題回來了。只是以前我們管的是服務、queue、job、worker。現在要管的是會推理的工作者。

這件事讓很多 AI 團隊開始補以前沒補好的基本功。像 permissioning、observability、testing、rollback、audit trail。這些名詞聽起來很老派，但它們才是 production 的底線。

台灣很多團隊很愛先問模型選哪個。這題不是不能問，但順序常常錯了。你應該先問，這個任務能不能切成可驗證步驟。再問，哪一段要人工審核。最後才是模型選型。

如果你把 agent 當成一個會犯錯的 junior engineer，很多設計就合理了。你不會讓新人直接改 production database。你也不該讓 agent 這樣做。這不是保守。這是正常。

我覺得 2026 年開始，真正成熟的 AI 團隊會長得很像傳統平台團隊。只是他們多了一層 model orchestration。表面在做 AI，骨子裡還是在做工程紀律。

接下來該怎麼看

如果你現在在做 agent，我的建議很直接：先做 harness，再談聰明。先把工具邊界、驗證流程、失敗回復、權限控管弄好，再去追更大的模型。順序錯了，後面會很痛。

我也押一個判斷。接下來 12 個月，harness 會變成架構審查裡的固定項目，像 auth、logging、testing 一樣。不是因為它潮，而是因為沒有它，agent 很難進正式環境。

所以問題不是「哪個模型最強」。問題是「你的 harness 能不能讓它穩定做完 100 次任務」。如果答案還不行，那就先補系統。別急著怪模型。