AI Agent 多工具調度教學：MCP 多 Server 整合與 Token 成本優化實戰

當你的 AI Agent 從「會用一兩個工具」成長到「需要調度十幾個 MCP Server」的階段，你會突然發現一個殘酷的現實——光是把所有工具的定義塞進 system prompt，Token 就先燒掉一大截了。這篇文章就是我在生產環境踩過坑之後，整理出來的多工具調度實戰心得。

為什麼需要多 MCP Server 架構

一個成熟的 AI Agent 系統通常不會只連一個 MCP Server。想像一下，你的 Agent 需要同時存取資料庫、呼叫外部 API、操作檔案系統、查詢向量資料庫，每一種能力背後都是獨立的 Server。單一 Server 塞所有工具會造成耦合度太高、部署困難、單點故障等問題。

在實際專案中，我通常會按照「能力域」來拆分 Server，例如：

• Data Server：負責資料庫查詢、CRUD 操作
• Search Server：負責向量搜尋、全文檢索
• Integration Server：負責第三方 API 串接（Slack、GitHub、Jira）
• File Server：負責檔案讀寫與轉換

這種拆法的好處是每個 Server 可以獨立擴展、獨立部署，團隊分工也更清楚。如果你還沒接觸過 MCP Server 的基礎概念，建議先看看 MCP Server 開發實戰教學 打好基礎。

工具定義的 Token 開銷問題

這是很多人忽略的隱形成本。每個工具的 JSON Schema 定義大約消耗 100-300 tokens，當你有 50 個工具時，光工具定義就吃掉 5,000-15,000 tokens。以 Claude 的定價來算，每次對話還沒開始回答就先花掉一筆錢了。

我做過一個實際測量，分享給大家參考：

# 工具定義 Token 消耗實測
單一工具（簡單參數）：~120 tokens
單一工具（複雜巢狀參數）：~350 tokens
10 個工具：~1,800 tokens
30 個工具：~6,200 tokens
50 個工具：~12,500 tokens

# 以 Claude Sonnet 計算（每百萬 input tokens $3）
# 50 工具 × 每天 10,000 次呼叫
# = 12,500 × 10,000 / 1,000,000 × $3 = $375/天

每天 375 美金，光在工具定義上。這就是為什麼 Token 優化不是可選的，而是必要的。

多 Server 整合架構設計

我推薦的架構是在 Agent 和多個 MCP Server 之間加一層 Tool Router，負責工具的發現、選擇和路由：

// mcp-config.json — 多 Server 註冊設定
{
  "servers": {
    "data": {
      "url": "http://localhost:3001",
      "capabilities": ["database", "sql"],
      "priority": 1,
      "healthCheck": "/health",
      "timeout": 5000
    },
    "search": {
      "url": "http://localhost:3002",
      "capabilities": ["vector-search", "fulltext"],
      "priority": 1,
      "healthCheck": "/health",
      "timeout": 8000
    },
    "integration": {
      "url": "http://localhost:3003",
      "capabilities": ["slack", "github", "jira"],
      "priority": 2,
      "healthCheck": "/health",
      "timeout": 10000
    }
  },
  "routing": {
    "strategy": "capability-match",
    "fallbackOrder": ["data", "search", "integration"]
  }
}

Tool Router 的核心工作有三件：第一，啟動時從各 Server 蒐集可用工具清單；第二，根據使用者意圖選擇性載入工具；第三，處理 Server 故障時的 fallback。

動態工具載入策略

這是降低 Token 成本最關鍵的技巧。與其一次載入所有工具定義，不如根據對話的上下文，動態決定這一輪需要哪些工具。

// dynamic-tool-loader.ts
import { ClassifyResult } from './intent-classifier';

const TOOL_GROUPS: Record<string, string[]> = {
  'data-query': ['sql_query', 'get_schema', 'list_tables'],
  'content-search': ['vector_search', 'fulltext_search'],
  'project-mgmt': ['create_issue', 'list_issues', 'update_status'],
  'communication': ['send_message', 'list_channels'],
};

export function selectTools(intent: ClassifyResult): string[] {
  // 只載入該意圖需要的工具群組
  const groups = intent.relevantGroups; // e.g. ['data-query']
  const tools = groups.flatMap(g => TOOL_GROUPS[g] || []);
  
  // 上限控制：最多 10 個工具
  return tools.slice(0, 10);
}

實務上我會先用一個輕量的分類模型（甚至用 regex 規則）判斷使用者意圖，再決定要載入哪組工具。這樣做可以把每次對話的工具數從 50 個降到 5-10 個，Token 成本直接砍掉 80%。

如果你想更深入了解不同 Agent 框架怎麼處理工具載入，可以參考 2026 AI Agent 開發框架比較。

Fallback 與容錯機制

生產環境一定會遇到 Server 掛掉的情況，你需要設計好 fallback 策略：

// fallback-handler.ts
async function executeWithFallback(
  tool: string,
  params: Record<string, unknown>,
  servers: ServerConfig[]
): Promise<ToolResult> {
  for (const server of servers) {
    try {
      const health = await checkHealth(server);
      if (!health.ok) continue;
      
      const result = await callTool(server, tool, params);
      return result;
    } catch (err) {
      console.warn(
        `Server ${server.name} failed for ${tool}:`, err
      );
      // 標記這個 Server 短暫不可用
      markUnhealthy(server, 30_000); // 30 秒冷卻
      continue;
    }
  }
  // 所有 Server 都失敗
  return {
    error: true,
    message: `工具 ${tool} 目前無法使用，請稍後再試`,
  };
}

幾個關鍵設計原則：設定合理的 timeout（不要讓使用者等太久）、失敗的 Server 要有冷卻期避免重複嘗試、最終失敗要回傳友善的錯誤訊息讓 Agent 可以優雅地告知使用者。

Token 成本優化實戰

除了動態載入之外，還有幾個我實測有效的優化手段：

1. 精簡工具描述

很多人的工具 description 寫得像小作文。其實 LLM 不需要那麼冗長的說明，把描述控制在一兩句話，參數用簡潔的名字，就能省下可觀的 Token。

2. 工具結果壓縮

工具回傳的結果也會消耗 Token。如果資料庫查詢回傳了 100 筆資料，先在 Server 端做摘要或分頁，不要全部丟回給 LLM。

3. 快取工具清單

同一個 session 內，如果使用者意圖沒有變化，就重複使用上一輪的工具組合，不需要每次都重新分類和載入。

4. 分層 Token 預算

# Token 預算分配建議
System Prompt：20%
工具定義：15%（動態載入後）
對話歷史：40%
模型回覆：25%

我個人的經驗是，把工具定義控制在總 Token 預算的 15% 以內是比較健康的比例。超過這個數字就該考慮是不是工具太多了。

生產環境部署模式

分享三種我在不同規模專案用過的部署模式：

小型專案（5 個以下工具）：直接單一 MCP Server，所有工具全量載入，不需要搞動態載入那套，保持簡單就好。

中型專案（10-30 個工具）：2-3 個 MCP Server 按能力域拆分，加上基本的意圖分類做動態載入。這是最常見的架構。

大型專案（50+ 個工具）：完整的 Tool Router + 動態載入 + 健康檢查 + 自動 fallback。考慮用 Redis 做工具清單快取，用 Prometheus 監控各 Server 的回應時間和錯誤率。

如果你打算自己搭建 MCP Server，Claude MCP Server 自建教學 有完整的 Python 實作範例可以參考。

結語與下一步

AI Agent 多工具調度這件事，說穿了就是在「功能豐富」和「成本可控」之間找平衡。動態工具載入是最有效的單一優化，但完整的方案需要從架構設計、Server 拆分、容錯機制到 Token 預算管理全盤考量。

我建議的行動順序是：先測量你目前的工具 Token 消耗、再實作意圖分類和動態載入、最後加上監控和 fallback。不要一開始就追求完美架構，先解決最痛的問題，再逐步迭代。