The 100-Tool Agent Is a Trap - Sohail Shaikh & Ankush Rastogi, Prosodica

在生產環境中構建 AI Agent 時，一個看似無害的做法會隱藏著陷阱：將所有工具定義一次性載入每個請求。這種「Fat Agent」方法在工具數少於 10 個時運作良好，演示看起來完美無缺，但當產品成長、工具目錄擴展至 50、100 甚至 741 個時，系統開始崩潰。

Sohail 和 Ankush 的研究揭示了這個問題的嚴重程度。使用 Berkeley Function Calling Leaderboard 和合成工具池進行的基準測試顯示，Fat Agent 的工具選擇準確率隨著工具數指數級下降：10 個工具時達 78% 的準確率，到 100 個工具時跌至 40%，在 741 個工具的完整目錄中僅剩 13.6%——平均每 8 個工具調用中只有 1 個正確。根本原因並非模型本身變差，而是一個已知的 LLM 問題：Lost in the Middle。當數百個工具描述全部塞入提示中時，模型對開頭和結尾的內容注意力更強，而中間位置的工具定義被忽略。

成本維度上更加令人吃驚。741 個工具的完整描述需要 127,000 個 tokens。在日均 100,000 次請求的生產系統中，這意味著每天數十億個 tokens 純粹用於描述工具，而用戶的實際問題還未被處理。首 token 延遲也隨之增長，Fat Agent 在工具數達 500 時可能需要超過 5 秒才能生成第一個回應，這在實時產品中是不可接受的。

解決方案是語義路由結合即時上下文注入。這個思路並非全新，而是將檢索增強生成（RAG）的模式應用於工具選擇。實現分為三個階段：首先在離線階段，工程團隊對每個工具進行編目（記錄名稱、描述、JSON 模式），嵌入這些描述並存入向量數據庫；在運行時，系統嵌入用戶的查詢、在向量空間中進行鄰近搜索、返回最相關的 K 個工具（通常為 3-5 個）；最後，只有這些篩選出的工具模式被注入到模型調用中。關鍵是模型永遠看不到整個目錄，只看到當前請求相關的小型列表。

基準測試證明了這種方法的有效性。語義路由在測試的全部工具數範圍內保持 83% 以上的準確率，因為模型始終從一個小的、專注的工具集中選擇，而非巨大的完整目錄。即時上下文注入將每次請求的工具描述 tokens 從 127,000 減少至約 1,000，達到 99% 的成本降幅。首 token 延遲保持平穩，用戶體驗變得更加實時且可預測。Anthropic 在其 MCP（Model Context Protocol）文檔中報告了類似的成果：tokens 從 150,000 降至 2,000，驗證了這一架構在生產級別的可行性。

實施這個模式的成本很低。對於大多數團隊來說，這不是六個月的平台重構，而是一次聚焦衝刺。如果團隊已有 RAG 基礎設施，向量數據庫和嵌入模型都已就位，語義路由只是將既有工具重新應用於工具選擇問題。Pinecone、Quadrant 等託管向量庫可用，或者可以從本地 Chroma DB 開始。評估時應在 K 值為 3、5、10 的配置下運行測試集，選擇滿足準確率目標的最小 K。K=5 是實踐推薦的起點。生產環境中的日誌記錄極為重要，需要追蹤路由選擇、實際工具調用、失敗和回退情況，以便持續改進工具描述。