# 百工具选择塌方与检索增强工具路由实测 ## 概述 本轮回到工具使用（Tool Use / Function Calling）的能力评测，但切入一个被大多数教程刻意回避的维度——**工具目录规模**。实测数据揭示了一条冷酷的规模法则：当注册工具从 10 个增长到 100 个以上时，工具调用准确率会从 80–95% 雪崩到 13–15%，逼近随机；一个模型在工具数从 207 翻倍到 417 时，准确率从 64% 跌到 20%。问题不在模型推理能力，而在于"把所有工具的 JSON Schema 塞进系统提示"这一默认集成模式。本文以 Berkeley FC Leaderboard、Anthropic 内部测试、RAG-MCP（arXiv 2505.03275）、ACL 2025 工具检索基准、Red Hat Tool2Vec 等多源数据，拆解塌方曲线、双重惩罚机制，并实测 search-then-load 两阶段选择、三层混合路由、语义路由命名空间三种破局栈。 ## 一、为什么"全塞上下文"是默认陷阱 几乎所有 Agent 框架开箱即用的模式都一样：把每个工具的 `name` + `description` + `parameters`（JSON Schema）三件套序列化进系统提示，模型每轮扫描全表再选一个调用。这套循环在 10–15 个工具时表现优异，超过这个量级就会同时触发两个相互叠加的惩罚。 ### 1.1 塌方曲线：百工具即随机 把多份公开评测的实测点连起来，得到一条远非优雅退化的曲线： | 工具数（上下文内） | 选择准确率 | 工程含义 | |---|---|---| | 10–20 | 80–95% | 健康，默认集成可用 | | ~50 | 明显下滑 | schema 已占 5–7% 上下文，成本与准确率双咬 | | 100+ | ~13–15%（近随机） | 实质崩坏，模型在猜 | | 207 → 417（同模型同任务） | 64% → 20% | 目录翻倍，准确率砍 2/3 | 更尖锐的是 Berkeley Function Calling Leaderboard 的单点：在跨多域的日历调度任务上，工具数从 4 扩到 51，准确率从 43% 直坠到 2%。这是控制变量的实验——同模型、同任务、唯一变量是工具列表大小。你无法用"换个更强的模型"或"优化提示词"来逃脱，因为模型需要的信息都在上下文里，**问题是被埋住了，而"埋住"本身就是 bug**。 ### 1.2 双重惩罚：消歧 + 注意力稀释 - **消歧惩罚（disambiguation penalty）**：工具数到一百，几乎必然出现近重复集群——`search_documents` / `search_knowledge_base` / `query_index`，`create_ticket` / `create_issue` / `open_case`。模型必须仅凭你写的描述在这些兄弟间消歧，而绝大多数描述是为"工具单独存在时"写的，不是为"在三个兄弟中胜出"写的。 - **注意力稀释惩罚（attention-dilution penalty）**：即便工具完全互异，200 条 schema 的平铺列表对工作记忆仍是巨大负担。这跟所有长上下文系统里的衰减是同一现象——百万 token 窗口在撒谎，**多 token 不等于多可用信号**。 ### 1.3 被忽视的第三惩罚：文档质量方差 50 个工具里，必然有些描述精确、有些模糊重叠，由不同团队在不同时间写出。`send_notification` 与 `push_alert` 描述相近时，模型会稳定地混淆，尤其在正确选择依赖描述文本未写明的微妙行为差异时。这是后续所有破局栈都要处理的"描述重写"动力的根源。 ## 二、朴素 RAG 工具检索的四道红线 第一反应是把文档 RAG 那套搬过来：嵌入所有工具描述，嵌入用户 query，取 top-k 最相似的塞给模型。这确实比"全塞"好——既砍 token 又收窄选择空间，对 50–500 规模目录是主力方案。但纯 embedding 检索有四道实战红线，踩过的人才懂： 1. **词表不匹配**：用户说"改下会议时间"，与工具名 `calendar_event_update` 的余弦相似度未必高，尤其是嵌入模型没在 API 文档上训练过。用户语言和工具文档语言常驻嵌入空间的不同角落。 2. **动态工作流失效**：多步任务第二步该用哪个工具，往往取决于第一步的输出。只对原始 query 检索，会系统性漏掉执行中途才变相关的工具。**条件化检索（同时纳入原始意图 + 演进中的执行状态）在多步基准上稳定胜过 query-only 检索。** 3. **top-k 截断**：两个工具相关性接近时，正确那个可能落在第 k+1 位，刚好被切掉。 4. **语义覆盖攻击**：多个工具描述宽泛重叠，会吃掉所有 top-k 槽位，top-5 全是同一个宽泛能力的五个变体，而非互补集合。这既是可靠性问题，也是安全问题。 ## 三、破局栈 A：search-then-load 两阶段选择 同时攻击两个惩罚的最高杠杆动作，是**停止把完整目录摆到模型面前**。把工具使用拆成两相： ```text Search 相（检索/路由，非生成）：根据用户请求 + 对话状态，找出小集合"可能相关"的工具 Load 相（执行）：只把这 5–15 个候选 schema 装载进上下文，让模型调用其一 ``` 模型从看到 200 个工具，变成看到 5–15 个。它在两端同时见效：近重复集群在模型看到前就被滤掉，注意力稀释消失，token 成本骤降。这正是 Anthropic 内置 `tool-search` 能力的设计内核，LangGraph 的 tool node 也支持在模型调用前插入 discovery 步骤过滤活动工具集。Search 相按健壮性递增有三档实现： ```python # 档位一：规则/关键词路由——按域划桶（github 桶、db 桶），匹配到域只暴露该域工具 def route_by_rule(query, domain_index): domain = classify_domain(query) # github / database / calendar ... return domain_index[domain].tools # 通常 <20 个，零模型调用 # 档位二：embedding 检索（RAG-MCP 主力，50–500 规模） def retrieve_topk(query, tool_vec_index, k=8): qv = embed(query) return tool_vec_index.search(qv, top_k=k) # name+description 的向量 # 档位三：小模型路由——只看压缩目录（name + 一行描述），输出相关工具名 def llm_route(query, compressed_catalog): # 不含完整 schema return fast_model.select(query, compressed_catalog) ``` 关键调参是 `k`：太小会排除正确工具，太大重新引入稀释。从 k=5–10 起步，对着标注 query 集调。注意 Anthropic 的内部测试给出一个换算锚点：**58 个工具定义 ≈ 55,000 tokens**，按生产推理单价，这意味着每轮 Agent 回合都背着"总结一部短篇小说"的基础开销，且无论这些工具是否被调用都要付费。对高吞吐系统，这是让单位经济性崩盘的隐藏账目。 ## 四、破局栈 B：RAG-MCP 与三层混合路由 RAG-MCP（arXiv 2505.03275）是对 embedding 工具检索最干净的正式化——名字即设计：把 RAG 那套检索增强模式从文档迁移到工具。但单独的 dense embedding 在术语密集的 API 文档上不够，因为方法名、参数名、领域行话更适合关键词匹配。所以生产级系统普遍落到**三层混合路由**： ```mermaid flowchart TD U[用户请求 + 执行状态] --> T1 subgraph Tier1[Tier 1 意图分类 - 消除80%目录] T1{轻量分类器/小LLM} --> CAT[calendar_ops / doc_mgmt / data_query ...] end CAT --> T2 subgraph Tier2[Tier 2 域内混合检索] T2D[dense embedding 检索] --> MERGE T2S[稀疏 BM25 关键词检索] --> MERGE MERGE[融合排序 top-k] --> CAND[候选工具集] end CAND --> T3 subgraph Tier3[Tier 3 上下文条件化重排] T3[re-ranker: 已调用工具 + 输出状态] --> FINAL end FINAL[5-15 个工具 schema] --> LLM[模型 Load 相执行] ``` 三层各有职责：**Tier 1 用结构化分派**（不需要语义检索）把请求映射到粗类目，目标是在任何相似度计算前先砍掉 80% 工具；**Tier 2 在类目内用 dense + sparse 双路检索再融合**，因为 API 文档的精确术语是 embedding 的弱项却是 BM25 的强项，混合稳定胜过纯语义；**Tier 3 对多步工作流用 re-ranker 重排**——它能看到前面调了哪些工具、输出了什么，从而系统性浮出 query-only 检索漏掉的选项。 ## 五、破局栈 C：语义路由与命名空间（去消歧） 即便检索准确，多个 MCP server + 内部 REST API 接在一起仍是"50–200 条近重复描述的平铺"。语义路由 + 命名空间是直接的工程解法： - **命名空间前缀**：`github.search_issues` / `jira.search_issues`，让模型在前缀层先做域消歧。 - **描述重写为"何时选它而非兄弟"**：把 `search_documents` 的描述从"搜索文档库"改写成"当需要全文检索已索引文档时使用；若需按元数据过滤用 query_index，若需跨系统检索用 search_knowledge_base"。这条"互斥化重写"是单条改动里 ROI 最高的。 - **拆 sub-agent**：当某个域工具密度过高（如"所有数据库工具"），把它整体交给一个专门 sub-agent，主 agent 只看到一个 `db_agent.call` 入口。 这一栈的实际效果非常硬：语义工具路由可达到约 **86.4% 的选择准确率，而全塞上下文时不到 50%**。 ## 六、破局栈 D：Tool2Vec 与小模型路由下沉 Red Hat 在企业落地中提出 Tool2Vec 方法：不是简单嵌入工具描述，而是学习工具的**能力向量**，让一个 SLM（小语言模型）就能高效完成检索。这对企业的意义在于路由下沉——把"选哪几个工具"这个高频、低复杂度的决策从昂贵的大模型里剥离，交给本地小模型，**大模型只负责对 5–15 个候选做最终调用决策**。配合 ACL 2025 论文 *Retrieval Models Aren't Tool-Savvy* 的发现（通用检索模型在工具检索上表现不佳，需在 API 文档上特化），Tool2Vec 这类特化嵌入/微调路径正是对"现成 embedding 不行"的直接回应：要么换特化模型，要么用 LLM 路由补位。 ## 七、检索模型本身不"工具在行"：评测警示 ACL 2025 的 tool-retrieval-benchmark 给了一个反直觉但关键的结论：**你在文档 RAG 上用顺手的现成检索模型，迁移到工具检索会显著掉点**。原因是工具描述是高度结构化、术语密集的短文本，与检索模型预训练的长文档分布错配。这带来两条评测红线： 1. **别用通用 IR 模型评测/上线工具检索**——要么用工具检索特化模型，要么干脆上 LLM 路由。 2. **评测必须分两个独立指标**：召回（正确工具有没有进 top-k）与消歧（进了 top-k 后模型选不选得对）。前者衡量检索栈，后者衡量模型在缩小后目录上的选择力。只看整体准确率会把两个独立的失败混为一谈。 τ-bench（航空/零售客服多轮工具）、ToolBench（~16000 个 RapidAPI RESTful API）、Gorilla（海量 API）、AnyTool（自反思 + 分层 API 检索）等基准，最好都按"召回层 / 选择层"拆开看，否则跨模型对比会被检索栈质量污染。 ## 八、多维度对比与实战选型 | 检索/路由策略 | 适用目录规模 | 准确率恢复 | 额外延迟 | 实现复杂度 | 典型栈 | |---|---|---|---|---|---| | 全塞上下文（默认） | ≤15 | 基线 80–95% | 无 | 极低 | 所有框架开箱 | | 规则/域分桶路由 | 20–80 | 高 | 极低 | 低 | 内部 API 网关 | | 纯 embedding（朴素 RAG） | 50–500 | 中（受四红线） | 一次检索 | 中 | RAG-MCP 基础版 | | Dense+Sparse 混合 + 重排 | 200–2000 | 高 | 检索+重排 | 中高 | Tier2+Tier3 | | 小模型 LLM 路由 + Tool2Vec | 500–10000+ | 高 | 一次 SLM 调用 | 中高 | 企业级 + SLM 下沉 | | Sub-agent 域拆分 | 任意（单域高密度） | 高 | 跨 agent 通信 | 高 | 多智能体框架 | ### 推荐方案（按目录规模） - **<20 工具**：维持全塞默认，别引入检索税。把精力放在**描述互斥化重写**上。 - **20–100**：加一层规则/域分桶或 embedding 检索，k=8–10 起步。监控"召回层"指标。 - **100–1000**：上线三层混合路由（意图分类 → dense+sparse → 条件化重排）+ 命名空间。这是塌方曲线的"恢复区"，目标把准确率从 13–15% 拉回 80%+。 - **1000+（多 MCP server + 企业 API 海洋）**：Tool2Vec/SLM 路由下沉 + sub-agent 域拆分 + 动态工具发现，把"选工具"彻底从大模型职责里剥离。 一句话收口：**Agent 调错工具，没有一招是"换更聪明的模型"，全都是"在它面前摆什么、怎么摆"的问题。** 把发现（discovery）与执行（execution）分离，是万级工具时代唯一站得住的默认架构。 ## 参考来源 1. [Agent Tool Selection at Scale: Fix Picking the Wrong Tool](https://particula.tech/blog/agent-tool-selection-at-scale-80-tools-wrong-one) — 实测 100+ 工具准确率塌方到 13–15%、207→417 工具 64%→20%、两阶段 search-then-load 与 RAG-MCP 数据 2. [The Tool Selection Problem: How Agents Choose What to Call When They Have Dozens of Tools](https://tianpan.co/blog/2026-04-09-tool-selection-problem-agent-tool-routing-at-scale) — Berkeley FC Leaderboard 4→51 工具 43%→2%、Anthropic 58 工具≈55k tokens、三层混合路由（意图分类→dense+sparse→条件化重排）详解 3. [RAG-MCP: Retrieval-Augmented Tool Selection (arXiv 2505.03275)](https://arxiv.org/abs/2505.03275) — 把 RAG 模式正式迁移到工具检索的核心论文 4. [tool-retrieval-benchmark (ACL 2025)](https://github.com/mangopy/tool-retrieval-benchmark) — *Retrieval Models Aren't Tool-Savvy*：通用检索模型在工具检索上掉点，需特化；含召回/消歧双层评测口径 5. [A Practical Approach to Smart Tool Retrieval for Enterprise AI Agents (Red Hat)](https://next.redhat.com/2025/12/05/a-practical-approach-to-smart-tool-retrieval-for-enterprise-ai-agents/) — Tool2Vec 方法：用能力向量让 SLM 高效完成工具检索，路由下沉到小模型 > [!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 等场景全覆盖。