020 · 百工具陷阱與語意路由解法
把所有工具塞進每次請求會拖垮準確率與延遲，改用語意路由按需注入工具能解決這個問題。
原標題：The 100-Tool Agent Is a Trap - Sohail Shaikh & Ankush Rastogi, Prosodica
重點摘要
- fat agent 為什麼會失準把整套工具目錄的名稱、描述、schema 全部塞進每次請求，工具一多，模型就會選錯、搞混相似工具，甚至捏造不存在的工具名稱。
- 數字有多誇張10 個工具時準確率約 78%，到 100 個工具剩 40%，到 741 個工具只剩 13.6%；語意路由在同樣的目錄規模下穩定維持在 83% 左右。
- 成本與延遲也跟著爆掉741 個工具的 schema 文字要吃掉約 12.7 萬 token，一天十萬次請求就等於燒掉數十億 token；工具目錄一大，first token 延遲也可能拖到 5 秒以上。
- 解法是把工具當文件做 RAG離線先把每個工具的描述做 embedding 存進向量資料庫，收到查詢時再即時比對相似度，取 top-k（常用 k=5）schema 注入模型，其餘工具完全不會出現在 context 裡。
- 業界已有驗證案例Anthropic 公開的 on-demand tool loading 案例，把 token 用量從 15 萬降到 2000，減少了 98.7%；社群也有現成的開源語意路由專案可以直接拿來測。
- 不是每個系統都需要工具數在 10 到 20 個以下時直接靜態載入就好，超過 50 個、開始出現延遲或選錯問題時，做路由才划算。
時間軸
時碼點下去會跳到影片的那一段。
| 時碼 | 段落 | 重點 |
|---|---|---|
| 00:00 | 開場 | 講者 Sohail Shaikh 與 Ankush Rastogi（Prosodica）點出一個常見錯誤：把 agent 可能用到的所有工具一次給齊，看似無害，其實會拖垮效能。 |
| 02:19 | 案例設定 | 假設系統要能查資料庫、寄信、查行事曆、查訂單，最簡單的做法是把每個工具的名稱、描述與 schema 全部塞進每次請求，這就是「fat agent」。 |
| 03:02 | 為什麼會失準 | 工具目錄一大，模型就開始選錯、搞混相似工具、甚至捏造不存在的工具名稱；問題不是某個工具寫得差，而是每次請求都被迫扛整份目錄，例如 741 個工具的 schema 就要佔掉約 12.7 萬 token。 |
| 04:18 | 準確率崩跌數字 | 10 個工具準確率約 78%，100 個工具剩 40%，741 個工具只剩 13.6%；語意路由在同樣規模下維持在 83% 左右，因為模型是在少量相關工具裡挑，不是在整個目錄裡大海撈針。 |
| 05:50 | 成本與延遲 | 以 741 個工具、一天十萬次請求估算，光描述工具就要燒掉數十億 token；工具目錄一大，first token 延遲也會被拖長，甚至可能超過 5 秒。 |
| 08:16 | 語意路由設計 | 語意路由不會一開始就載入所有工具，而是先看使用者的查詢，只取三到五個最相關的工具注入模型呼叫，context 維持小而穩定。 |
| 09:36 | 工具版 RAG | 概念就是把 RAG 套用在工具選擇上：離線先把每個工具描述做 embedding 存進向量資料庫，使用者問問題時再即時比對相似度，取出 top-k 工具的 schema 才注入模型。 |
| 12:10 | 業界已驗證 | Anthropic 公開的 on-demand tool loading 案例，透過 MCP 依需求載入工具，把 token 用量從 15 萬降到 2000，減少了 98.7%。 |
| 12:52 | 評測方法 | 用 Berkeley function calling leaderboard 等資料集，在同樣的模型與工具目錄下比較 fat agent 與語意路由，並掃過 k 等於 3、5、10；k=5 是實務上不錯的起始值。 |
| 15:54 | 落地三步驟 | 建索引存進向量資料庫、每次請求 embed 查詢取 top-k 工具、把選到的 schema 丟進模型呼叫，並記錄選了哪個工具方便之後除錯。 |
| 20:22 | 上線檢查清單 | 六步驟：盤點工具、建索引、寫 router、把工具清單接進 agent loop（改由 router 決定，不再寫死整份目錄）、用不同 k 值評估、上線後持續監控。 |
| 24:25 | 風險與因應 | 三個常見風險：router 漏抓工具可以擴大 k 值或退回更廣的工具群組補救；工具描述太模糊要用使用者實際講話的方式重寫；冷門工具要靠監控找出漏抓再補描述。 |
| 25:35 | 收尾建議 | 工具數在 10 到 15 個以內時，靜態載入就夠用，不必為了路由而路由；工具一多、延遲或選錯問題浮現，語意路由才划算，起手可以先用 k=5 並持續監控改善。 |
值得記的話
名詞與人物
| Prosodica | 兩位講者任職的公司，做的是 applied AI、NLP 與對話智能（conversational intelligence）相關工作。 |
|---|---|
| fat agent | 講者對「把所有工具 schema 一次塞進每次請求」這種設計方式的稱呼，是這場要指出的反例。 |
| semantic routing | 語意路由：先用查詢向量比對工具描述向量，只挑出最相關的少數工具交給模型，而不是整個工具目錄都塞進去。 |
| just-in-time context injection | 只在真正需要時才動態把該有的 context（這裡指工具 schema）加進 prompt，而不是一開始就全部載入。 |
| MCP | Model Context Protocol，這場提到 Anthropic 用它做 on-demand tool loading 的案例。 |
| Berkeley function calling leaderboard | 講者用來評測工具選擇準確率的公開資料集之一。 |
| Aurelio Labs | 開源 semantic router 專案的作者，講者說這套可以自己在本機跑來做 benchmark。 |
延伸
- 講者提到 Aurelio Labs 的開源 semantic router 可以本機測試，也點名 tool bench 與 Berkeley function calling leaderboard 兩個評測，但沒有說明實際導入的細節。
- 開源專案 mcp0 被提到在數千個工具、跨多個 server 的規模上做路由，但這場沒有展開細節。
- Berkeley function calling leaderboard 與 ToolBench 風格的測試場景被列為評測起點，但沒有說明實際題目長什麼樣子。