企業級 AI Agent 的擴展瓶頸：為何我們需要以合約為中心的架構？
當企業導入 AI Agent 時，真正的挑戰並非模型本身，而是如何管理、擴展與治理這些日益複雜的系統。本文從一篇近期研究出發，探討為何將能力、容量與責任邊界混為一談是擴展的瓶頸，並闡述如何透過「以合約為中心」的架構，為企業級 AI 部署帶來穩定的演進路徑。
企業 Agent 要能可靠擴展，必須先拆開能力、容量與責任，而不是讓模型、工具與執行環境彼此綁死。以明確合約界定 Skill、Harness 與 Scaffold 的輸入、輸出與責任，才能讓部署、治理和擴容沿著可驗證的介面演進，並保留可追溯責任。
為什麼當前的 Agent 架構難以擴展？
在許多概念驗證（PoC）或早期專案中，開發者傾向於將所有功能直接寫入 Agent 的核心邏輯。例如，一個能查詢訂單狀態的 Agent，其程式碼可能同時包含了呼叫內部 API 的商業邏輯、處理 API 金鑰與認證的細節、管理 API 呼叫頻率限制（rate limiting）的邏輯，以及記錄稽核日誌的程式碼。
這種「大泥球」（Big Ball of Mud）式的架構，雖然在初期開發時能快速推進，卻很快就會遭遇擴展的瓶頸。試想以下情境：
- 升級能力：後端訂單系統 API 從 v1 升級到 v2，開發者必須修改 Agent 的核心程式碼，並承擔改動可能破壞其他功能的風險。
- 擴展容量：業務量成長，需要將 API 呼叫的速率限制從每分鐘 100 次提高到 500 次。這個變更可能深埋在程式碼的某個角落，甚至需要重新部署整個 Agent。
- 強化治理：法遵部門要求所有查詢客戶資料的行為，都必須經過新的資料脫敏（data masking）流程。這意味著要回頭檢視所有相關的 Agent 程式碼，確保無一遺漏。
當能力、容量與治理的邊界糾纏不清，任何單一維度的變動，都可能引發跨越多個責任邊界的連鎖反應。這就像在現代雲端架構中，要求開發者在修改一段 Python 商業邏輯時，還得親自去調整 Kubernetes 的 pod 數量與網路防火牆規則。這種做法不僅效率低落，更充滿潛在風險。
「以合約為中心」的架構如何解構 Agent 的能力、容量與治理？
這篇論文的核心洞見，正是借鏡軟體工程領域行之有年的「Design by Contract」思想，將 Agent 的運行環境（runtime）拆解成三個獨立卻透過形式化合約緊密協作的角色：Skill、Harness 與 Scaffold。
這個架構的目標，是建立穩定的介面，讓各個元件得以獨立演進與擴展。它們的職責劃分清晰明確：
- Skill（能力）：代表一項純粹的業務能力，例如「查詢特定 ID 的訂單狀態」。Skill 只專注於「做什麼」，它不關心如何認證、流量限制或資源調度。它就像一個純粹的函數，只定義了輸入、輸出與其核心邏輯。
- Harness（容量）：這是 Skill 的「執行載具」或「適配器」。它負責管理執行 Skill 所需的資源與環境，也就是處理「能做多少」的問題。這包括 API 金鑰管理、連線池、快取策略（例如：結果快取 30 秒）、速率限制與重試機制。同一個 Skill 可以由不同的 Harness 承載，以滿足不同服務等級協議（SLA）的需求。
- Scaffold（治理）：這是整個 Agent 系統的「鷹架」與協調者。它負責執行整體的治理策略，確保所有互動都符合規範。Scaffold 的職責包括身份驗證、權限控管（例如：只有客服部門的 Agent 才能調用訂單查詢 Harness）、成本追蹤、日誌記錄與可觀測性。
簡單來說：Skill 是工具箱裡的工具，Harness 是使用工具的手與體力，而 Scaffold 則是確保一切安全合規的工場規則與監視系統。
這三者之間的互動，完全透過形式化的「合約」來定義。這些合約不僅僅是 API 的簽名，更明確規範了前置條件、後置條件、預期的錯誤類型，甚至是資源消耗模型。這種嚴謹的作法，讓系統的行為變得可預測、可驗證，也為未來的自動化部署與擴容提供了堅實的基礎。
這套架構在實務上如何運作？
讓我們回到電商客服 Agent 的例子。在一個以合約為中心的架構下，工作流程會是這樣的：
Agent 接收到使用者「查詢訂單 #12345 狀態」的請求。Agent 的規劃器（Planner）判斷需要使用 `query_order_status` 這項能力。此時，它不會直接呼叫底層程式碼，而是向 Scaffold 發出一個明確的意圖：「我想使用具備 `query_order_status` 能力的 Skill，參數是 `order_id=12345`。」
Scaffold 隨即展開治理流程：
- 權限檢查：Scaffold 驗證此 Agent 的身份與角色，確認它有權限查詢訂單資料。如果沒有，請求會立即被拒絕。
- Harness 選擇：Scaffold 根據合約與當前系統負載，選擇一個合適的 Harness 來執行這個 Skill。也許有一個是給 VIP 客戶用的高優先級 Harness，另一個是給一般用戶的標準 Harness。
- 執行與監控：Harness 接收到請求，它負責從金鑰庫提取 API token，向後端系統發出請求。如果請求失敗，Harness 會根據預先設定的重試策略進行處理。所有操作的資源消耗（例如 API 呼叫次數、執行時間）都會被詳實記錄，並回報給 Scaffold。
- 結果回傳：Harness 將執行結果（訂單狀態）回傳給 Scaffold，Scaffold 再將結果安全地傳遞給 Agent。
在這個模型下，先前遇到的挑戰迎刃而解。後端 API 升級，只需要開發一個新的 Skill 並更新合約，對 Harness 與 Scaffold 完全透明。需要調整速率限制，只需調整 Harness 的設定，無需重新部署 Agent。新的法遵稽核要求，則可在 Scaffold 層統一實施，確保所有通過它的請求都符合規範。
這種關注點分離的作法，與 Microservices 架構、Kubernetes 的資源管理哲學，以及 LangChain 或 LlamaIndex 等框架中將工具（Tools）與執行器（Executors）分離的趨勢不謀而合。它將軟體工程的最佳實踐，應用在充滿不確定性的 AI Agent 領域，為我們提供了一條從混亂走向秩序的清晰路徑。
最終，企業級 AI 系統的成功，將不再僅僅取決於模型本身的聰明才智，更關鍵的是我們能否建立一個穩定、可預測且可治理的運行環境。以合約為中心的架構，正是實現這一目標的關鍵一步，它讓我們能將精力專注於打造真正有價值的業務能力，而非深陷於基礎設施的泥淖之中。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。