AI Agent 的治理陷阱：我們是否正用自然語言打造下一代單體巨獸？

企業導入 AI Agent 時，常傾向將所有業務邏輯集中於一個「萬能」的中央 Agent，期望它能處理所有需求。然而，這種看似高效的單一入口策略，正悄悄地用自然語言重塑一個難以維護的單體巨獸（Monolithic Architecture）。當不同領域的業務規則與邏輯被塞進同一個 System Prompt，不僅權責模糊，更可能抵銷微服務架構的優勢。真正的挑戰不在於 AI 能力，而是我們如何避免重蹈覆轍，建構一個無法治理的系統。

單一入口的 AI Agent，為何既是誘惑也是詛咒？

想像一個雲端廚房系統，它由多個微服務構成：訂單、菜單、配送、支付。最直覺的 AI Agent 整合方式，就是在最前端放一個大型的 Agent，作為所有自然語言指令的統一入口。使用者說：「幫我訂一份宮保雞丁，送到信義路五段，用 Apple Pay 結帳。」這個 Agent 必須理解指令、拆解意圖，然後依序呼叫對應的 API。

初期，這套系統運作得很好。但隨著業務擴展，複雜性開始失控。

行銷團隊想加入優惠券邏輯、營運團隊需要處理尖峰時段的特殊配送規則、法務要求在支付流程中新增使用者條款確認。這些來自不同領域（Domain）的業務邏輯，最終都只能被塞進那個唯一的 System Prompt。很快地，這個 prompt 就會膨脹到數千甚至上萬個 token，變成一團誰也看不懂、誰也不敢改的「義大利麵式程式碼」（Spaghetti Code）。

當一個 System Prompt 承載了橫跨多個業務領域的邏輯時，它就失去了模組化的精神，成為一個脆弱且高風險的單點故障（Single Point of Failure）。

問題的核心在於所有權的模糊化。當訂單邏輯與支付邏輯在同一個 prompt 內互相影響時，一旦出錯，該由哪個團隊負責？是負責訂單的團隊，還是負責支付的團隊？當初我們採用微服務架構，就是為了讓每個團隊能獨立擁有、開發和部署自己的服務。現在，這個自然語言入口卻成了一個新的戰場，所有團隊的邏輯都被迫在此糾纏不清。

為什麼這會成為「自然語言版的單體巨獸」？

單體架構的根本問題在於「高耦合」與「低內聚」。所有功能模組緊密地綁在一起，修改一處可能引發無法預期的連鎖反應。而一個包山包海的 AI Agent，正透過 System Prompt 完美複製了這個問題：

• 邏輯高度耦合： 為了讓 Agent 能處理跨領域的複雜指令，prompt 內勢必會包含大量「如果...那麼...」的條件分支，讓訂單、支付、配送的規則互相牽制。
• 語意邊界模糊： 在自然語言中，業務邊界的定義比程式碼更困難。例如，「取消訂單」這個動作，究竟該在何時觸發支付服務的退款流程？這些細膩的商業規則在一個巨大的 prompt 中極易產生衝突。
• 維護與測試的災難： 對 prompt 的任何微小修改，理論上都需要對所有相關業務領域進行完整的迴歸測試，這使得迭代速度大幅減慢，也增加了線上出錯的風險。根據 一份針對大型語言模型自主 Agent 的調查，Agent 的可靠性與可預測性至今仍是重大挑戰，而一個混亂的 prompt 只會加劇這個問題。

我們等於是用最新的 AI 技術，重現了 20 年前的軟體工程困境。這個「自然語言單體」甚至比傳統的程式碼單體更難治理，因為它的行為更不確定，除錯也更加困難。

如何用領域驅動設計（DDD）重新思考 Agent 架構？

解方早已存在於軟體工程的最佳實踐中，那就是領域驅動設計（Domain-Driven Design, DDD）。DDD 的核心精神是將複雜的系統，按業務領域劃分成一個個權責分明的「限界上下文（Bounded Context）」。我們應該將同樣的原則應用在 AI Agent 的設計上。

與其打造一個萬能 Agent，不如建立一個由多個小型、專業 Agent 組成的協作系統。在這個架構下：

1. 建立領域 Agent (Domain Agent)： 為每一個核心業務領域（如訂單、支付、使用者帳戶）建立專屬的 Agent。每個 Agent 都有自己精簡、專注的 System Prompt，只包含該領域的業務邏輯。例如，PaymentAgent 只需知道如何處理付款、退款與查詢交易狀態。
2. 引入路由 Agent (Router Agent)： 在最前端設置一個輕量的「路由 Agent」或「協調者（Orchestrator）」。它的唯一職責是理解使用者意圖，並將請求轉發給對應的領域 Agent。它不處理任何具體的業務邏輯。
3. 定義清晰的溝通協議： 各 Agent 之間透過結構化的資料（如 JSON）溝通，而非模糊的自然語言。這確保了系統的穩定性與可預測性。這種類似微軟 AutoGen 框架中多 Agent 對話的設計，能有效管理複雜的工作流程。

舉例來說，當使用者發出「我要訂餐並付款」的指令時，路由 Agent 會先將請求交給 OrderAgent 處理訂餐環節，待 OrderAgent 完成後，再將支付任務交給 PaymentAgent。每個 Agent 各司其職，系統的權責劃分一目了然。

這種設計不僅解決了單體 prompt 的治理問題，也讓系統更具擴展性。當需要新增「會員點數」功能時，我們只需開發一個新的 MembershipAgent，並讓路由 Agent 知道它的存在即可，完全不會影響到既有的 Agent。這才是真正能與微服務架構相輔相成的 AI 系統設計。

我們正處於將 AI 從實驗品轉化為可靠生產力工具的關鍵時期。若只是將所有複雜性丟給一個黑盒子般的「超級 Agent」，我們很快就會發現自己陷入了新的技術債泥沼。唯有回歸軟體工程的嚴謹思維，將 AI Agent 視為系統中的一等公民，並用經得起考驗的架構原則來約束它，我們才能真正釋放其潛力，而不是打造出一個更難馴服的巨獸。

延伸閱讀

• マイクロサービスにおける AI エージェントの責務分割 (原文參考)
• Putting Domain-Driven Design into Practice
• A Survey on Large Language Model based Autonomous Agents

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