AI Agent 的擴展陷阱：為何分散的工具入口，是壓垮使用者體驗的最後一根稻草？

在 AI Agent 系統的擴展之路上，一個看似無害的決策——為每個模組獨立配置工具入口——卻是壓垮使用者體驗的潛在元兇。這種分散式架構會導致設定成本指數級增長、使用者心智負擔超載，最終讓產品的核心價值徹底崩壞。因此，無論是為了確保系統的可擴展性，還是為了提供流暢的使用者體驗，統一的工具入口策略都至關重要。這不僅是架構選擇，更是決定 AI Agent 產品能否成功規模化的關鍵。

當 AI Agent 系統從單一功能走向多模組協作，其擴展性面臨的最大挑戰，往往不在於底層模型，而是工具入口（Tool Entrypoint）的設計。許多團隊直覺地為每個模組配置獨立的工具集，然而，這種分散式架構看似能加速開發，實則累積了巨大的技術債。它不僅讓設定成本呈指數級增長，更讓使用者心智負擔超載，最終徹底破壞產品的核心體驗。這不單是介面設計的考量，更是決定 AI Agent 產品能否成功規模化的關鍵架構選擇。

AI Agent 擴展的真實案例：當統一入口走向分裂，發生了什麼？

在深入探討理論之前，我想從一個我觀察到的實際案例開始。一個名為 Codens 的 AI Agent 產品線，其架構最初設計得相當清晰。它由五個核心模組構成：

• Purple：核心的 Orchestrator，負責任務的協調與分派。
• Red：專注於程式碼自動修復（auto-fix）。
• Blue：負責端到端（E2E）的品質保證（QA）。
• Green：用於生成產品需求文件（PRD）。
• Auth：處理計費與驗證。

在初始版本中，整個系統的工具入口是統一的。只有 Purple 模組擁有一個所謂的 MCP（Model-Controller-Peripheral）介面，它透過一個名為 purple-codens-mcp 的 PyPI package，將 16 個精心設計的工具（Tools）提供給底層的大語言模型（在這個案例中是 Claude 3 系列模型）。在這種架構下，使用者只需要在一個地方進行設定，例如在 .claude/settings.json 檔案中指定 Purple 的 MCP 即可。整個體驗是單純、可預測且易於管理的。

當入口開始四散時，體驗如何崩壞？

問題發生在產品迭代的過程中。為了追求更快的開發速度與模組獨立性，團隊決定讓 Red、Blue 和 Green 各自擁有獨立的 MCP。從開發者的角度來看，這似乎是個合理的決定——每個團隊可以獨立管理自己的工具集，互不干擾。然而，這個決定卻在使用者端引發了一場災難。

一夜之間，使用者的設定變得極其複雜。原本只需要一行設定，現在卻需要在同一個設定檔中，為不同的模組指定不同的 MCP。這不僅增加了設定的步驟，更帶來了潛在的衝突與不一致性。

我們可以想像一下設定檔的變化：

統一入口時期：

{
  "tools": {
    "provider": "purple-codens-mcp",
    "version": "1.0.0"
  }
}

分散入口時期：

{
  "tools": {
    "red_module": {
      "provider": "red-mcp",
      "version": "0.8.1"
    },
    "blue_module": {
      "provider": "blue-mcp",
      "version": "1.1.0"
    },
    "green_module": {
      "provider": "green-mcp",
      "version": "0.5.0",
      "some_specific_flag": true
    }
    // Purple 模組的設定可能還在這裡，也可能被遺忘了
  }
}

這種改變直接導致了幾個嚴重的問題：

1. 設定成本劇增：使用者需要理解每個模組的 MCP 是什麼、如何設定、版本之間是否有依賴關係。除錯的難度也大幅提高。
2. 心智負擔超載：原本清晰的「一個 Agent，一套工具」的心智模型被打破。使用者現在必須像系統工程師一樣，思考不同模組之間的工具協調問題。這完全違背了 Agent 產品旨在降低使用者負擔的初衷，也違反了最小化認知負荷的基本設計原則。
3. 體驗碎片化：不同模組可能因為各自的 MCP 而有不同的行為模式與能力邊界，使得整個產品的體驗不再連貫一致。

系統的複雜度應該由建構者吸收，而不是轉嫁給使用者。當產品將架構的複雜性暴露給使用者時，失敗幾乎是注定的。

為什麼統一入口是唯一的出路？

從 Codens 的案例中，我們可以得到一個清晰的教訓：對於一個多模組的 AI Agent 系統，一個統一的、由 Orchestrator 控管的工具入口，是維持系統可擴展性與使用者體驗的關鍵。

這背後的邏輯與軟體工程中的「單一事實來源（Single Source of Truth）」原則如出一轍。一個統一的 MCP 扮演了工具集的「單一事實來源」，它確保了：

• 一致性：所有模組都從同一個來源獲取工具定義與執行邏輯，確保了行為的一致性。
• 可管理性：工具的增減、版本升級都在一個地方集中管理，大幅降低了維護成本與出錯機率。
• 簡易性：使用者永遠只需要與一個入口互動，無需關心底層的複雜模組劃分。

這並不意味著犧牲模組的獨立性。各個模組（如 Red、Blue）當然可以開發和貢獻自己的專屬工具，但這些工具最終應該被註冊到中央的 Orchestrator（Purple）中，由它統一提供給語言模型。這種「集中管理，分佈貢獻」的模式，才能在開發效率與使用者體驗之間取得平衡。

當前的 Agent 研究，例如 Toolformer 或 AutoGen 等多 Agent 協作框架，都隱含了對工具進行某種形式的集中管理與調度的思想。讓模型或 Agent 自行決定使用哪些工具，前提是存在一個穩定、一致的工具庫，而不是讓它們在一個混亂、分散的環境中無所適從。

延伸閱讀

• Anthropic: Tool Use with Claude
• Schick, et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." (arXiv:2302.04761)
• Nielsen Norman Group: Minimize Cognitive Load to Maximize Usability

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。