# 塞满即瞎：工具召回三式实测 ## 概述 当 Agent 的工具库从 5 个涨到 50 个、500 个、5000 个 MCP 服务器时，"把所有工具 schema 塞进系统提示"这条默认路径会同时触发两件事：**token 爆炸**与**选择准确率塌方**。一个 20+ 工具的 Agent，光工具定义就轻松吃掉 3000 token；而实测显示，全量塞入在百级工具规模下选择准确率会跌到 13% 量级——**塞得越满，模型越瞎**。本文横评三种主流应对范式：全量塞入（Stuff-All）、静态分层分组（Hierarchical Two-Stage）、动态语义召回（Tool RAG / ScaleMCP），从每轮 token 开销、选择准确率、往返延迟、召回层失误风险、自治性五个维度拆解，给出按工具规模与场景的选型分界线：≤10 个塞满即可，10–50 个分层分组，50 个以上必须上动态召回，并指出召回层本身会成为新的准确率天花板。 ## 三式对比总表 | 维度 | 全量塞入（Stuff-All） | 静态分组（Two-Stage） | 动态召回（Tool RAG / ScaleMCP） | |------|------|------|------| | 每轮 token 开销 | O(全量工具)，20+ 工具 >3000 token | O(单组工具)，中等 | O(1 元工具 + top-k)，最低，省约 50% | | 选择准确率（大规模） | 13% 量级，持续塌方 | 中，受分类器级联误差拖累 | 3× 提升（相对塞入） | | 往返延迟 | 0 额外跳 | +1 路由跳 | +1 召回跳（可 auto-continue） | | 准确率天花板 | 模型注意力 | 路由分类器 | 召回层召回率 | | 实现复杂度 | 最低 | 中（需手工分组） | 高（向量库 + 阈值 + 同步） | | Agent 自治性 | 无 | 无（硬编码分组） | 高（可运行时 re-query） | | 适用工具规模 | ≤10 | 10–50 | 50–5000+ | | 变现/训练营难度 | 入门友好 | 中级专题 | 高级架构课 | ## 深度分析 ### 一、全量塞入：默认路径的两面性 全量塞入是所有 function calling SDK 的开箱默认：把每个工具的 `name`、`description`、`parameters`（JSON Schema）原样塞进系统提示或 `tools` 数组。OpenAI、Anthropic、Gemini 的 client 都是这么做的。 ```python # Stuff-All：5 个工具时人畜无害 tools = [search_web, get_weather, send_email, calc, read_file] resp = client.chat.completions.create(model=..., messages=..., tools=tools) ``` 5–10 个工具时它确实是最佳解：零额外往返、零召回误差、模型注意力充裕。但越过 20 个工具，两个税同时开征。**第一是 token 税**：Agentic Forge 实测，20+ 工具的定义就轻松突破 3000 token，且每一轮都为"永远用不到的工具"付费。**第二是注意力税**：Liu 等人《Lost in the Middle》早已证明，模型对上下文中段的信息注意力显著弱于首尾；当几十个相似工具的中段描述挤在提示里，模型开始调错工具、幻觉参数。Berkeley Function Calling Leaderboard（BFCL）的大工具集子项也复现了这条塌方曲线。 **优缺点**：优点是零工程、零延迟、零召回失误可能；缺点是不可扩展、token 与成本线性膨胀、大规模下选择准确率掉到 13% 量级。**变现评估**：这是所有"三天上手 Agent"训练营的标配起点，但也是最容易在学员真正上手后翻车的范式——Demo 里 5 个工具很美，生产里 50 个工具就崩。 ### 二、静态分组：分层两段式路由 当工具数涨到几十个，最自然的过渡是**分层两段式（Hierarchical Two-Stage）**：先让一个轻量路由 LLM（或分类器）判断用户意图属于哪个工具组，再把该组 10 个以内的工具塞进主 Agent。 ```python CATEGORIES = { "hr": [lookup_employee, request_leave, ...], # 8 tools "finance": [get_balance, create_invoice, ...], # 10 tools "it": [reset_password, open_ticket, ...], # 9 tools } cat = router_llm.classify(user_query, list(CATEGORIES)) # +1 hop active = CATEGORIES[cat] answer = main_agent.run(query, tools=active) # only ~10 tools ``` 它把每次暴露给模型的工具压回个位数，选择准确率回升，token 开销回落到单组规模。**但它引入了级联误差**：路由分类器一旦把"帮我查上季度人均差旅"误判进 HR 组，主 Agent 手里没有财务工具，只能硬编或再次路由；跨组任务（先查人、再查报销、再开票）需要多次路由跳。更重要的是，**分组是硬编码的**：新增工具要人肉决定归入哪组，分组边界一旦定死就难以应对意图漂移。 **优缺点**：优点是工程量可控、能把单次工具数压到 BFCL 甜区；缺点是分组僵化、分类器误差全链路放大、跨组多步任务延迟翻倍。**变现评估**：适合做成"企业知识库 Agent 实战"中级专题，把按业务域分组作为案例，但要把"分类器选错怎么办"作为核心讨论点而非彩蛋。 ### 三、动态召回（Tool RAG）：按需语义检索 动态召回把 RAG 的思想从"检索文档"平移到"检索工具"：Agent 启动时只见一个元工具 `search_tools`，需要某项能力时先语义检索，再把命中的 top-k 工具载入下一轮上下文。Agentic Forge 的 Tool RAG、apxml 的"Scaling MCP with Tool RAG"都属此派。 ```python # Tool RAG：Agent 只见一个元工具 meta_tools = [search_tools] # /mcp?mode=rag # 第一跳：search_tools("get current weather for a city") hits = vector_db.query(embed("...weather..."), top_k=5, threshold=0.5) # 第二跳：载入命中的真实工具 answer = agent.run(query, tools=hits) # auto-continue，用户无感 ``` 实测收益非常硬核：ToolRAG 论文报告相对全量塞入有 **3× 工具选择准确率提升**与**约 50% 的 prompt token 下降**。代价是多一跳往返（可用 auto-continue 对用户隐藏），以及相似度阈值难调。**真正的命门在召回层**：如果向量检索没把正确工具召回到 top-k，Agent 在第二跳里就永远选不对——召回层的召回率成了选择准确率的新天花板。这与 Stuff-All 的天花板（模型注意力）本质不同：前者可工程优化（换 embedding、加权、重排），后者只能换模型。 **优缺点**：优点是 token 省一半、准确率翻 3 倍、天然支持工具库动态增删；缺点是延迟 +1 跳、阈值与冷启动工具是两道坎、召回失误静默难发现。**变现评估**：这是 2026 年最有训练营价值的高级架构专题，"百器企业 Agent"几乎是它的天然靶场。 ### 四、ScaleMCP：把召回权交给 Agent 自己 动态召回的下一级进化是让 **Agent 自己持有检索器并能在多轮中动态 re-query**，这正是 ScaleMCP（arXiv 2505.06416）的核心主张。它批评了"在 LLM 被调用前就把工具选死"的做法——那会剥夺 Agent 的自治权、阻断多轮中的动态再查询。ScaleMCP 给 Agent 装一个 MCP 工具检索器，让 Agent 能自主把工具加入自己的记忆，并用 CRUD 让 MCP 服务器作为唯一真相源自动同步工具存储。 它还提出 **TDWA（Tool Document Weighted Average）嵌入策略**，对工具文档的关键部分（工具名、合成问题）加权，让向量表示更贴合"用户会怎么问"。 ```python # TDWA：对工具文档关键片段加权后再求平均向量 vec = (W_NAME * embed(doc["name"]) + W_DESC * embed(doc["description"]) + W_QUES * embed(synthetic_questions(doc))) / (W_NAME+W_DESC+W_QUES) index.upsert(tool_id, vec) # MCP server CRUD 自动同步 ``` 它的评测规模最能说明问题：**5000 个金融指标 MCP 服务器、10 个 LLM、5 个 embedding 模型、5 种检索器**——这是 Stuff-All 与静态分组完全无法触及的量级。**优缺点**：优点是自治 re-query、MCP 为 single source of truth、自动同步；缺点是实现重、要维护向量索引与同步管线、加权权重需调参。**变现评估**：可作为"自治 Agent 进阶"旗舰课的压轴案例，但要警告学员其工程复杂度，别让小白照抄。 ### 五、召回层失误：被低估的新天花板 无论 Tool RAG 还是 ScaleMCP，准确率都被"召回层能不能把正确工具带进 top-k"封顶。这一节值得单列，因为它是三式横评里最常被忽视、却最致命的失败模式。 失败有三态。**漏召**：阈值设太高（如 0.7）或 embedding 对工具名不敏感，正确工具根本没进 top-k，Agent 在残缺工具集里只能选次优或幻觉。**噪声召回**：阈值太低（0.2）把一堆近义工具全塞回来，又退化成"小号 Stuff-All"，lost-in-the-middle 卷土重来。**冷启动工具**：新工具没有任何调用历史，合成问题质量决定它能不能被召回到。 ```python # 阈值与重排：召回层调优的旋钮 hits = vec_db.query(emb, top_k=20, threshold=0.4) # 宽召回 reranked = cross_encoder.rerank(query, hits)[:5] # 精排压回 5 个 if not reranked: # 漏召兜底 reranked = fallback_to_llm_rewrite(query) # 改写再查一次 ``` TDWA 的加权、cross-encoder 重排、query 改写兜底，都是把这条天花板往上推的工程杠杆。**变现要点**：把"召回层 = 选择准确率上限"作为训练营里最值钱的认知之一，附一个调阈值前后准确率对比的小实验，效果远胜讲十页理论。 ### 六、生产落地：MCP 网关与热工具常驻 纯动态召回在生产里很少单用，更常见的是**混合架构**：按业务域切分多个 MCP 服务器，服务器内部走 Tool RAG，再叠一层网关做动态工具发现（discovery → invocation 两阶段）。Microsoft 365 Copilot 与 agentic-community 的 MCP Gateway & Registry 都走这条路：Agent 先调 `invoke_mcp_tool` 拉回工具元数据（discovery 阶段），再用元数据真正调用（invocation 阶段），且能"近实时"拿到 MCP 服务器新增的工具，不必等清单刷新。 ```mermaid flowchart LR U[用户请求] --> A[Agent Loop] A -->|"启动只载入元工具"| M[search_tools 元工具] M --> Q[语义查询] Q --> V[(向量库 pgvector\n含 TDWA 加权向量)] V -->|top-k + 阈值| R[召回工具集] R -->|auto-continue 载入| A A --> T[真实工具调用] T --> MCP[(MCP 服务器\nsingle source of truth)] MCP -.->|CRUD 自动同步| V H[热工具缓存] -.常驻.-> A ``` 两个生产细节决定成败。第一是**热工具常驻**：少数高频工具（如查天气、查余额）反复召回浪费一跳，应直接常驻上下文，只对长尾工具走召回。第二是**Token Tax 警示**：Medium 上的 MCP Tool Retrieval Pattern 一针见血指出——塞满式让 Agent"为永远用不到的工具，每一轮都付 token 与延迟"。混合策略的目标就是让常驻集小、召回集准。 ## 推荐方案 **按工具规模分档**： - **≤10 个工具**：全量塞入。别过度工程化，省下的开发时间更值钱。 - **10–50 个工具**：静态分组（按业务域两段式路由），单组压到 10 个内进 BFCL 甜区；把"分类器选错"做成可观测的兜底分支。 - **50–5000+ 个工具 / 多 MCP 服务器**：动态召回起步，热工具常驻 + 长尾 Tool RAG；规模到千级且需自治时升级到 ScaleMCP 式 agent 持有检索器 + CRUD 自同步。 - **跨域、意图漂移严重**：优先动态召回而非静态分组——硬编码分组扛不住意图漂移，召回层可热更新。 **按场景分档**： - **客服/知识库 Agent**：分组即可，域边界清晰。 - **企业级"百器"Agent（CRM+ERP+OA+自研 API）**：Tool RAG + MCP 网关，按域切服务器、服务器内召回。 - **金融/科研指标库（千级工具）**：ScaleMCP 式自治召回，TDWA 加权 + 重排，召回层单独评测。 - **面向 C 端、对延迟敏感**：热工具常驻 + 预召回缓存，把召回跳藏进流式首字之前。 **避坑红线**：永远单独评测召回层的召回率——它是你 Agent 选择准确率的隐形天花板；任何"工具上到几十个还坚持塞满"的方案，都在用 13% 量级的准确率换零点几秒的延迟。 ## 参考来源 1. [Tool RAG: Dynamic Tool Discovery for AI Agents — Agentic Forge](https://agentic-forge.github.io/blog/tool-rag-dynamic-discovery.html) — 提出 `search_tools` 元工具 + 向量检索范式，给出 20+ 工具 >3000 token、ToolRAG 论文 3× 准确率与 ~50% token 下降的实测数据。 2. [ScaleMCP: Dynamic and Auto-Synchronizing Model Context Protocol Tools (arXiv 2505.06416)](https://arxiv.org/abs/2505.06416) — agent 持有 MCP 检索器、CRUD 自同步、TDWA 加权嵌入；在 5000 个金融 MCP 服务器上跨 10 LLM / 5 embedding / 5 检索器评测。 3. [How to Scale MCP to 100+ Tools — apxml](https://apxml.com/posts/scaling-mcp-with-tool-rag) — 用 Tool RAG 解决百级 MCP 工具的上下文燃烧与成本飙升，含模式切换 `/mcp?mode=rag`。 4. [RAG-MCP: Scaling Tool Selection for AI Agents — Medium](https://medium.com/@pankaj_pandey/rag-mcp-scaling-tool-selection-for-ai-agents-6de02b08b64f) — 基于检索过滤将工具选择准确率从 13% 基线大幅拉升的对照实验。 5. [Lost in the Middle: How Language Models Use Long Contexts (Liu et al., arXiv 2307.03172)](https://arxiv.org/abs/2307.03172) — 长上下文首尾偏好、中段注意力衰减，是塞满式选择塌方的理论根基。 6. [Dynamic tool discovery for MCP plugins — Microsoft Learn](https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/plugin-dynamic-tool-discovery) — M365 Copilot 生产级两阶段（discovery → invocation）动态工具发现与近实时更新。 7. [Berkeley Function Calling Leaderboard (BFCL)](https://gorilla.cs.berkeley.edu/leaderboard.html) — 工具调用事实标准基准，含大工具集子项，是选择准确率分档的参照系。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。