百工具陷阱與語意路由解法

020Sohail Shaikh、Ankush Rastogi（Prosodica）28:272026-06-28

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 個、開始出現延遲或選錯問題時，做路由才划算。

時間軸13 段

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 並持續監控改善。

值得記的話5 句

That is why we are calling it the 100 tool agent trap.這就是為什麼我們稱它為百工具 agent 陷阱00:39
So the context stays small, latency stays stable, and the accuracy holds because the model is choosing from a focused list instead of giant catalog.context 維持小、延遲穩定，準確率也不會掉，因為模型是從一小群相關工具裡挑，不是從整個大目錄裡挑08:37
We are just applying the simple and same principle to the LLM context.我們只是把同樣簡單的原則套用在 LLM 的 context 上12:10
The router does not only add the right tool, it also removes the wrong tool from the model's choice set.router 不只加對的工具進來，也會把錯的工具從模型的選項裡拿掉20:06
Do not over engineer small systems.不要在小系統上過度工程化25:16

名詞與人物7 個

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 風格的測試場景被列為評測起點，但沒有說明實際題目長什麼樣子。

Agent開發工具評估

在 YouTube 看原片 ↗