AI Agent 的下一步：從聰明模型到可信賴的系統契約

當前的自律 coding agent，在處理特定、封閉的任務時效率驚人，但若要將其用於長時間、無人監督的「夜間值班」，則顯得力不從心。這背後的瓶頸並非模型不夠聰明，而是我們缺乏一套能約束、管理其行為的軟體化「運作契約」。要將 AI 從一個聰明的「工具」提升為一個可長時間託管、可信賴的「系統」，我們需要將重心從模型本身，轉向其運作的控制平面（control plane）與治理政策（governance policy）。這不僅是技術上的演進，更是我們能否真正將 AI 整合為核心生產力的關鍵一步。

當前的 AI Coding Agent：聰明，但像個「日薪實習生」

近來的 AI Agent，特別是在程式碼生成與軟體工程領域，其能力確實令人印象深刻。無論是透過 OpenAI 的 Assistants API 或是像 Devin 這樣的整合式代理人，它們都能夠理解相對複雜的指令、進行網路搜尋、閱讀文件、編寫程式碼、執行測試，甚至解釋自己產出的程式碼變更。在一些定義明確的小型任務上，它們的效率甚至可能超過人類工程師。

然而，這些 agent 的工作模式，很像一個能力極強、但缺乏職場訓練的「日薪實習生」。你交辦一項任務，它會全力以赴去完成，但過程中可能會出現意想不到的狀況。它可能會鑽牛角尖，在一個錯誤的方向上耗費大量運算資源；可能會因為一個小小的環境設定錯誤而卡關數小時；也可能在沒有明確指示的情況下，做出超出授權範圍的操作。例如，在 SWE-bench 這類真實世界軟體問題的基準測試中，目前最頂尖的 agent 解決率也僅在 13.86% 左右，這說明了它們雖然有能力，但離完全可靠還有很長一段路。

這種「日薪」模式的根本問題在於缺乏一個長期、穩定的合作框架。我們可以輕易地啟動一個 agent 來解決單一問題，卻無法放心地讓它在無人看管的情況下，持續運作 8 個小時處理一個待辦清單。問題的核心，已不再是模型推理能力（reasoning）的極限，而是系統治理（governance）的缺位。

為什麼我們無法放心讓 AI Agent「獨自值夜班」？

想像一下，如果要聘用一位人類員工來值夜班，我們會需要一份雇用合約，清楚載明他的職責、權限、緊急狀況的處理流程，以及工作的終止條件。目前的 AI agent 恰恰缺少了這樣一份軟體化、可強制執行的「運作契約」。這份契約的缺席，體現在幾個關鍵層面：

• 工作範圍（Scope of Work）不明確：Agent 雖然有初始目標，但其探索路徑是發散的。如果沒有嚴格限制，它可能會為了修復一個前端 bug，最終試圖去修改底層的資料庫 schema。
• 資源預算（Resource Budget）無上限：一次 API 呼叫、一次程式碼編譯、一次測試執行，都需要花費運算資源與時間。一個失控的 agent 可能在幾小時內就燒掉數百甚至數千美元的雲端預算，卻沒有產出任何有效結果。
• 錯誤處理與上報機制（Error Handling & Escalation）付之闕如：當 agent 陷入死胡同或連續失敗時，它該怎麼辦？是無止盡地重試，還是應該暫停任務，並向人類監管者發出警報？現行的 agent 大多缺乏這種「舉手求救」的機制。
• 績效指標與終止條件（Performance Metrics & Termination Clause）模糊：我們如何判斷 agent 的工作是否「走在正軌上」？如果連續 30 分鐘沒有任何進展，或程式碼測試覆蓋率不升反降，是否應該自動終止其任務？這些都需要預先定義好的規則。

這些問題的本質，都指向同一個解決方案：我們需要一個駕馭在 AI Agent 之上的「管理平面」（Management Plane），或稱「控制平面」（Control Plane）。

The goal is not to micromanage the agent's every thought, but to establish clear, enforceable boundaries for its autonomous operation. It's the shift from being a "model user" to a "system operator."

我們該如何為 AI Agent 建立「運作契約」與「管理平面」？

將 AI agent 從一個「會動的模型」轉變為「可託管的系統」，意味著我們要用軟體工程的思維來設計其運作框架。這個框架的核心，就是一個定義了「運作政策」（Run Policy）的控制平面。正如 Zenn.dev 上的文章所探討的 Hermess Autopilot 概念，這個控制平面負責監督 agent 的整個生命週期，而不是讓模型自由發揮。

一個有效的控制平面，至少應該包含以下幾個組件：

1. 政策引擎（Policy Engine）：這是「運作契約」的具體實現。我們可以在這裡用程式碼定義 agent 的行為邊界，例如：API 呼叫次數上限為 500 次、總執行時間不得超過 3 小時、禁止存取 `production` 資料庫、程式碼變更必須包含單元測試等。
2. 狀態監控器（State Monitor）：它會持續追蹤 agent 的內部狀態與外部進展。這不僅是簡單的日誌紀錄，而是結構化的事件流，讓我們可以判斷 agent 目前是處於「研究階段」、「編碼階段」還是「卡關」。這也為後續的介入提供了依據。
3. 干預與斷路器（Intervention & Circuit Breaker）：當監控器偵測到 agent 違反了政策（例如預算超支）或陷入無效迴圈時，斷路器機制會被觸發，自動暫停或終止 agent 的運作，並通知人類。這確保了系統的穩定性與成本可控。

這種架構的設計理念，與經典的 ReAct (Reason, Act) 框架 並不衝突，而是在其上增加了一層治理與監督。Agent 依然可以在其思考與行動的循環中自主決策，但這個循環本身，是被一個更高層級的系統所監管的。這讓我們能夠在賦予 agent 自主性的同時，確保其行為始終在我們預設的安全軌道內。

最終，AI agent 的成熟度，將不再僅由其模型版本（如 GPT-4o 或 Claude 3.5 Sonnet）或在基準測試上的分數來衡量。更重要的指標將是：它能否在一個明確的運作契約下，穩定、可預測地長時間工作？它的控制平面是否足夠強健，能夠應對各種預期外的狀況？這才是將 AI agent 從有趣的實驗品，轉變為企業級生產力工具的真正挑戰。

延伸閱讀

• 自律 AI エージェントの無人夜勤を可能にする運用契約と管理平面
• ReAct: Synergizing Reasoning and Acting in Language Models
• SWE-bench: Can Language Models Solve Real-World Software Engineering Problems?

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。