Tool Router（工具路由器）
3 秒看懂
一句話： Tool Router 是 AI Agent 系統中的”排程中樞”——當大型模型需要呼叫外部工具（API、資料庫、搜尋引擎、程式碼執行器等）時，Tool Router 負責理解意圖 → 匹配工具 → 分發呼叫，類似於作業系統中的中斷路由表。
類比： 如果 LLM 是大腦，工具是手和腳，Tool Router 就是小腦——它不做深度推論，但決定”現在該用手還是腳、用哪隻手”。
3 分鐘產業解釋
為什麼 Tool Router 突然重要？
2023 年以前，LLM 主要靠單次推論回答問題。2023-2024 年起，行業共識轉向：LLM 必須能呼叫外部工具才能完成真實任務（訂機票、查資料庫、執行程式碼、操控裝置）。
但問題來了：
- 一個成熟的 Agent 系統可能註冊 幾十到上百個工具/API
- 每個工具有不同的輸入 schema、能力邊界、呼叫成本
- 暴露所有工具定義給 LLM 會導致 上下文視窗膨脹、推論延遲增加、選擇準確率下降
Tool Router 的核心價值：在 LLM 推論之前或之中，高效篩選並路由到正確的工具子集。
產業位置
使用者輸入
│
▼
┌─────────────┐
│ Intent │ ← 意圖分類/語義理解
│ Classifier │
└──────┬──────┘
│
▼
┌─────────────┐
│ TOOL ROUTER │ ← 核心：工具選擇 + 引數提取 + 衝突消解
│ (本文主角) │
└──────┬──────┘
│
▼
┌─────────────┐
│ Tool │ ← 具體工具執行（API call / DB query / Code exec）
│ Executor │
└──────┬──────┘
│
▼
┌─────────────┐
│ Response │ ← 結果聚合 + 生成最終回答
│ Synthesizer │
└─────────────┘關鍵玩家（截至 2024-2025 年，基於公開資訊）
| 層級 | 代表 |
|---|---|
| 基座 LLM 內建路由 | OpenAI Function Calling / Tool Use、Anthropic Tool Use、Google Gemini Function Calling |
| 中介軟體/架構層 | LangChain（Tool/Agent 模組）、Semantic Kernel（Microsoft）、LlamaIndex |
| 專項研究 | Gorilla LLM（UC Berkeley）、ToolLLM（Tsinghua）、NexusRaven |
15 分鐘專家深入
Tool Router 的三種架構範式
範式一：LLM-Native Routing（原生函式呼叫路由）
機制： LLM 本身經過微調，直接輸出結構化的工具呼叫指令（tool name + arguments JSON）。Router 邏輯隱含在 LLM 的引數中。
代表： OpenAI GPT-4 Function Calling、Anthropic Claude Tool Use
優點： 端到端、無需額外模組、對引數提取質量高 缺點： 工具定義佔用上下文視窗、工具集過大時準確率下降、推論成本隨工具數線性增長（每次呼叫都需要完整 prompt + 所有工具 schema）
規模約束（定性估算）： 當前主流實踐表明，單次推論暴露 ~50-100 個工具定義 是經驗可行的上限。超過此數，模型選擇準確率顯著下降且 token 成本陡增 [行業實踐經驗估算，無單一權威資料來源]。
範式二：Semantic/Embedding-Based Router（語義路由）
機制： 將每個工具的能力描述預編碼為向量，存入向量索引；使用者查詢同樣編碼後做相似度檢索，取 Top-K 工具交給 LLM 做最終選擇。
┌────────────────────────────────────────────────┐
│ Semantic Router Pipeline │
│ │
│ User Query │
│ │ │
│ ▼ │
│ [Embedding Model] → q_vec │
│ │ │
│ ▼ │
│ Vector Index (工具描述庫) │
│ │ │
│ ├── Top-1 → 直接路由（高置信度時） │
│ ├── Top-K → 送入 LLM 做精細化選擇 │
│ └── 低置信 → 拒絕/澄清 │
│ │
└────────────────────────────────────────────────┘優點： 工具集可擴充套件到數百/數千、每次 LLM 呼叫只需看少量候選 缺點： 嵌入模型質量是瓶頸、難以處理需要組合多個工具的複雜查詢
範式三：Hierarchical / Learned Router（分層/學習型路由）
機制： 先用輕量分類器（可以是小模型、規則引擎、或訓練的 Router 網路）做粗篩，再由 LLM 做細選。某些系統會訓練專門的 Router 模型（類似 MoE 中的 gating network）。
與 MoE 的類比（重要）：
| 維度 | MoE 路由 | Tool Router |
|---|---|---|
| 路由物件 | Token / sequence | User intent / query segment |
| 路由目標 | Expert FFN 層 | 外部工具 / API |
| 路由網路 | 可學習的 gating network | 可為規則/小模型/LLM |
| 組合方式 | 多 expert 加權求和 | 通常單工具或序列多工具 |
| 通訊模式 | All-to-All dispatch（MoE 專家並行中） | HTTP/函式呼叫（非同步或同步） |
注意區分： MoE 中的 All-to-All 通訊是分散式訓練/推論中 token dispatch 到不同 GPU 上 expert 的硬體通訊模式；Tool Router 的”路由”是邏輯層面的決策，兩者在機制上完全不同，僅在”條件分發”的抽象概念上有相似性。
關鍵技術挑戰
1. 工具描述的歧義性
許多工具能力高度重疊（如”搜尋”可以是 Google Search、Bing Search、內部知識庫檢索、SQL 查詢）。Router 需要理解 細粒度的能力邊界，而非簡單的關鍵詞匹配。
2. 引數提取與 Schema 驗證
選對工具只是第一步。Router 還需要從自然語言中提取符合工具 API schema 的結構化引數。這是一個 資訊抽取 問題，當前主要靠 LLM 自身能力，錯誤率隨引數複雜度上升。
3. 多步工具編排（Orchestration）
複雜任務需要序列/並行呼叫多個工具。Tool Router 在此場景下進化為 Tool Orchestrator，需要維護狀態、處理工具間依賴、做錯誤恢復。
4. 安全與權限控制
Router 需要實現 權限邊界：某些高風險工具（如”刪除檔案”、“傳送郵件”）需要人工確認或被策略引擎攔截。這不是純技術問題，而是安全架構設計。
5. 工具集的動態註冊與版本管理
生產環境中工具會頻繁增減、升級 API 版本。Router 需要支援 熱更新 而無需重新訓練 LLM。
技術原理（最深）
LLM-Native Function Calling 的內部機制
以 OpenAI 風格的 Function Calling 為例（基於公開文件 [OpenAI Platform Docs]）：
┌─────────────────────────────────────────────────────┐
│ API Request Structure │
│ │
│ { │
│ "model": "gpt-4o", │
│ "messages": [...], │
│ "tools": [ ← 工具定義陣列 │
│ { │
│ "type": "function", │
│ "function": { │
│ "name": "get_weather", │
│ "description": "...", │
│ "parameters": { ... JSON Schema ... } │
│ } │
│ }, │
│ { ... more tools ... } │
│ ], │
│ "tool_choice": "auto" | "required" | "none" │
│ | {"type":"function","function":...}│
│ } │
└─────────────────────────────────────────────────────┘tool_choice 引數的本質就是一個硬編碼的 Router 策略：
| tool_choice 值 | Router 行為 |
|---|---|
"auto" | LLM 自行決定是否呼叫工具、呼叫哪個（最常見） |
"required" | 強制 LLM 必須呼叫至少一個工具 |
"none" | 禁止工具呼叫 |
| 指定 function name | 強制路由到特定工具（繞過 Router 決策） |
內部實現推測 [未充分揭露]： 主流 LLM 廠商的 function calling 訓練通常包括：
- 在 SFT 階段注入大量 tool-use 樣本（含正確/錯誤工具選擇的對比）
- 可能使用特殊 token 標記 tool call 的開始/結束
- 推論時，模型在檢測到需要工具時，輸出結構化 JSON 而非自然語言
Embedding-Based Tool Selection 的數學架構
工具註冊階段：
for each tool t_i:
desc_i = LLM.generate_description(t_i.schema)
e_i = Encoder(desc_i) # 工具描述向量
index.add(e_i, tool_id=i)
路由階段：
q_vec = Encoder(user_query)
candidates = index.search(q_vec, top_k=K) # ANN 檢索
selected = LLM.rank_and_select(user_query, candidates)
return selected關鍵引數（定性）：
- Encoder 選型： 通常使用通用 text embedding 模型（如 text-embedding-3-small、BGE 系列、E5 系列等）。專用 fine-tune 可提升 top-K 召回率 [Gorilla 論文, Berkeley, 2023 的實驗資料方向性參考]。
- top-K 設定： 經驗上 K=3~10 是常見範圍，平衡精度與 LLM 上下文開銷。
- 索引型別： 工具規模 <100 時暴力檢索可行；>1000 時需要 ANN（HNSW/IVF 等）。
學習型 Router 的訓練架構
訓練資料構造：
Input: (user_query, tool_set)
Label: ground_truth_tool_id + expected_arguments
模型架構選擇（典型方案）：
┌─────────────────────────────────────────────┐
│ 方案 A: 小模型分類器 │
│ Query → [BERT/DeBERTa] → MLP → softmax │
│ → tool_id (分類) │
│ 引數量級：~100M-500M │
│ 推論延遲：<10ms (GPU) │
│ 適用場景：工具集固定、高QPS │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 方案 B: Fine-tuned LLM 路由器 │
│ Query + tool_descriptions → [小LLM] │
│ → structured output (tool_name + args) │
│ 引數量級：1B-8B │
│ 推論延遲：~50-200ms (GPU) │
│ 適用場景：複雜意圖、需要引數提取 │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ 方案 C: 兩階段混合 │
│ Stage 1: Embedding 檢索 top-K │
│ Stage 2: LLM 從 K 個候選中選擇+填參 │
│ 綜合延遲：檢索 ~5ms + LLM ~100ms │
│ 適用場景：工具集大（>100）、需兼顧速度與精度 │
└─────────────────────────────────────────────┘技術演進史
| 時期 | 階段 | 關鍵事件 |
|---|---|---|
| 2022 及以前 | 前 Router 時代 | LLM 基本無工具呼叫能力；少數系統用硬編碼規則 + prompt engineering 實現簡單 API 呼叫 |
| 2023 H1 | 萌芽期 | OpenAI 釋出 Function Calling API（2023.06）；LangChain 的 Tool/Agent 模式快速普及；ChatGPT Plugins 探索工具整合 |
| 2023 H2 | 研究爆發 | ToolLLM（清華）釋出 ToolBench 資料集和 ToolAlpaca；Gorilla（Berkeley）證明小模型可匹敵 GPT-4 的 API 呼叫準確率；NexusRaven 展示開源 function calling 能力 |
| 2024 H1 | 生態成熟 | Anthropic、Google 相繼推出原生 Tool Use / Function Calling；OpenAI Assistants API 內建 Code Interpreter + Retrieval + Function Calling；多 Agent 架構（CrewAI、AutoGen）將 Tool Router 作為核心元件 |
| 2024 H2-2025 | 產品化與最佳化 | 工具數量從個位數擴充套件到生產級的數十到數百；Router 最佳化成為效能瓶頸研究熱點；MCP（Model Context Protocol, Anthropic 提出）嘗試標準化工具接入協議；Tool Router 開始與安全架構、權限系統深度耦合 |
技術路線對比
| 維度 | LLM-Native (原生函式呼叫) | Embedding Router (語義檢索) | Learned Router (學習型) | Rule-Based (規則引擎) |
|---|---|---|---|---|
| 工具集規模 | 中小（~50-100） | 大（數百-數千） | 中（~100-500） | 小（~10-30） |
| 引數提取能力 | 強 | 弱（需額外 LLM） | 取決於架構 | 無/模板化 |
| 推論延遲 | 高（全量 LLM 推論） | 低（~5-20ms 檢索） | 低-中 | 極低（<1ms） |
| 部署成本 | 高（需 LLM 推論） | 低（向量檢索） | 中（小模型推論） | 極低 |
| 可擴充套件性 | 差（工具增多→準確率降） | 好（索引可擴充套件） | 中 | 差（維護成本高） |
| 多工具編排 | 較好 | 差 | 中 | 差 |
| 可解釋性 | 中（可看 LLM 輸出） | 高（相似度分數） | 低（黑箱） | 高（規則可審計） |
| 代表產品 | OpenAI / Anthropic 原生 | 自建檢索系統 | Gorilla / 定製訓練 | 傳統規則引擎（如 IFTTT） |
上下游
上游（Tool Router 依賴什麼）
┌─────────────────────────────────────────────────┐
│ 1. 基座 LLM │
│ - 推論能力決定意圖理解質量 │
│ - Function calling 微調質量 │
│ │
│ 2. 工具描述 / Schema │
│ - 工具的 API 定義（OpenAPI/Swagger 等） │
│ - 自然語言能力描述 │
│ - 描述質量直接影響路由準確率 │
│ │
│ 3. Embedding 模型（語義路由方案） │
│ - 向量化能力決定檢索精度 │
│ │
│ 4. 上下文視窗 / Token 預算 │
│ - 工具定義佔用 context，與 Router 設計強相關 │
│ │
│ 5. 訓練資料 │
│ - Tool-use 對話資料（含正確/錯誤路由標註） │
│ - 工具描述-意圖對齊資料 │
└─────────────────────────────────────────────────┘下游（Tool Router 餵給什麼）
┌─────────────────────────────────────────────────┐
│ 1. Tool Executor / Runtime │
│ - 實際執行 API 呼叫、資料庫查詢、程式碼執行 │
│ │
│ 2. Tool Result Aggregator │
│ - 收集工具返回結果 │
│ - 處理錯誤/超時/重試 │
│ │
│ 3. Response Synthesizer │
│ - 將工具結果融入 LLM 最終回答 │
│ │
│ 4. 安全 / 權限層 │
│ - Router 決策需要經過權限校驗 │
│ - 高風險操作觸發人工確認流程 │
│ │
│ 5. 可觀測性 / 日誌系統 │
│ - 記錄每次路由決策（輸入、選擇的工具、置信度） │
│ - 用於除錯和持續最佳化 │
└─────────────────────────────────────────────────┘關鍵指標
| 指標 | 定義 | 業界基準（定性，據公開論文/報告方向性估計） |
|---|---|---|
| 工具選擇準確率 (Tool Selection Accuracy) | 在測試集上正確選擇工具的比率 | 原生 Function Calling: ~85-95%（工具數<20）; 隨工具數增多可降至 ~70-80% [Gorilla 論文方向性資料] |
| 引數提取準確率 (Argument Accuracy) | 選對工具後，引數填寫正確的比率 | 複雜巢狀引數場景錯誤率可達 ~20-30% [行業實踐經驗估算] |
| 路由延遲 (Routing Latency) | 從接收查詢到輸出路由決策的耗時 | LLM-based: ~100-500ms; Embedding-based: ~5-30ms; Rule-based: <1ms |
| 工具集承載力 (Tool Capacity) | Router 能有效管理的最大工具數量 | LLM-native: ~50-100; Embedding: 數百-數千; 規則: ~10-30 |
| 拒絕率/回退率 (Fallback Rate) | Router 無法找到合適工具而回退到 LLM 直接回答的比率 | 健康系統一般 <10-15% [經驗估算] |
| 端到端任務完成率 (End-to-End Success) | 從使用者請求到最終正確完成任務的比率 | 高度依賴任務複雜度，簡單單工具任務 >90%，複雜多步驟任務 ~40-70% [行業實踐方向性估計] |
供需與市場資料
需求端
- Agent 平台爆發： 2024-2025 年，企業級 AI Agent 部署從 PoC 進入生產階段。每個 Agent 通常需要整合 5-50 個內部/外部工具。
- 工具碎片化： 企業內部系統（CRM、ERP、HR、資料倉儲等）各有獨立 API，需要統一接入層。
- 成本敏感： LLM 推論成本（以 token 計價）使得”全量暴露工具定義”的樸素方案在高 QPS 場景下不經濟。高效 Router 可顯著降低 token 消耗。
供給端
- 開源方案： LangChain、Semantic Kernel、LlamaIndex 提供基礎 Router 能力，但生產級最佳化需大量定製。
- 雲端廠商： OpenAI、Anthropic、Google 的原生 Function Calling 已成為預設選擇，但工具管理能力有限。
- MCP（Model Context Protocol）： Anthropic 於 2024 年底提出的開放協議，目標是標準化 LLM 與工具的接入方式，可能從根本上改變 Tool Router 的實現形態 [Anthropic 官方部落格]。
- MCP 的影響： 如果 MCP 成為事實標準，Tool Router 可能從”自建適配層”轉向”協議標準化發現與選擇”，降低整合成本。
市場規模
無可靠獨立資料來源。 Tool Router 作為 Agent 基礎設施的子模組，目前主要嵌入在各 Agent 架構和 LLM 平台中，尚未獨立形成可量化的市場規模。可參考的資料點：
- Agent/Agentic AI 市場規模預測存在多家機構估算，但口徑差異大 [各機構報告口徑不一，不列具體數字]
- Tool Router 的價值更多體現在 LLM 推論成本節約 和 Agent 任務成功率提升 上，是效能乘數而非獨立營收單元
代表公司與資本對映
| 層級 | 公司/專案 | Tool Router 相關能力 | 上市/融資狀態 |
|---|---|---|---|
| LLM 廠商（內建） | OpenAI | GPT-4 Function Calling, Assistants API | 未上市（估值百億美元級，據公開報道） |
| LLM 廠商（內建） | Anthropic | Claude Tool Use + MCP 協議 | 未上市 |
| LLM 廠商（內建） | Google DeepMind | Gemini Function Calling | Alphabet 子公司 |
| 開源架構 | LangChain | LangGraph, Tool 抽象層 | 私有，獲多輪融資 |
| 開源架構 | LlamaIndex | Tool/Query Engine 路由 | 私有 |
| 微軟 | Semantic Kernel | Plugin 系統 + Planner | MSFT 子公司 |
| 研究 | Gorilla (UC Berkeley) | 學術專案，專注 function calling 準確率 | 學術 |
| 研究 | ToolLLM / ToolBench (清華) | 大規模 tool-use 資料集與訓練架構 | 學術 |
| Agent 平台 | 各類創業公司 | 在自建 Agent 中實現 Router | 早期融資階段 |
投資邏輯
核心觀點
-
Tool Router 是 Agent 基礎設施中的”路由器”——雖然不直接產生營收，但決定了 Agent 系統的可用性和成本效率。 類比網路基礎設施中路由器的角色。
-
短期（6-12 個月）： LLM 廠商的原生 Function Calling 將持續改善，工具集規模在 50 以內時體驗尚可。Router 最佳化對大部分場景尚非瓶頸。
-
中期（1-3 年）： 企業級 Agent 部署工具數量進入 100+ 量級，原生 Function Calling 的精度和成本優勢開始消退。專用 Router 層（語義路由 + 學習型路由）的需求將變得剛性。
-
長期（3-5 年）： MCP 等協議可能標準化工具接入，Router 從”適配層”轉變為”智慧發現層”——類似從手動配置 DNS 到自動服務發現的演進。
機會方向
- Agent 平台/架構公司： 誰的 Tool Router 最好用、最高效，誰就佔據 Agent 基礎設施的核心位置。
- 向量資料庫 / 檢索技術公司： Embedding-based Router 的核心依賴，天然與現有技術棧對齊。
- LLM 廠商： Function Calling 能力是 LLM 的核心差異化因素之一。
- MCP 生態參與者： 如果 MCP 成為標準，圍繞其建置工具註冊、發現、路由的中介軟體將有價值。
風險
- LLM 能力躍升： 如果未來 LLM 的上下文視窗無限大、推論成本趨近於零，“全量暴露 + LLM 直接選擇”可能變得可行，Router 的獨立價值被壓縮。
- 協議標準化： MCP 若成功，Router 可能被協議內建的發現機制取代，降低中介軟體層的獲利空間。