本轮回到工具使用（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 个工具时表现优异，超过这个量级就会同时触发两个相互叠加的惩罚。
把多份公开评测的实测点连起来，得到一条远非优雅退化的曲线：
| 工具数（上下文内） | 选择准确率 | 工程含义 |
|---|---|---|
| 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。
search_documents / search_knowledge_base / query_index，create_ticket / create_issue / open_case。模型必须仅凭你写的描述在这些兄弟间消歧，而绝大多数描述是为"工具单独存在时"写的，不是为"在三个兄弟中胜出"写的。50 个工具里，必然有些描述精确、有些模糊重叠，由不同团队在不同时间写出。send_notification 与 push_alert 描述相近时，模型会稳定地混淆，尤其在正确选择依赖描述文本未写明的微妙行为差异时。这是后续所有破局栈都要处理的"描述重写"动力的根源。
第一反应是把文档 RAG 那套搬过来：嵌入所有工具描述，嵌入用户 query，取 top-k 最相似的塞给模型。这确实比"全塞"好——既砍 token 又收窄选择空间，对 50–500 规模目录是主力方案。但纯 embedding 检索有四道实战红线，踩过的人才懂：
calendar_event_update 的余弦相似度未必高，尤其是嵌入模型没在 API 文档上训练过。用户语言和工具文档语言常驻嵌入空间的不同角落。同时攻击两个惩罚的最高杠杆动作，是停止把完整目录摆到模型面前。把工具使用拆成两相：
Search 相（检索/路由，非生成）：根据用户请求 + 对话状态，找出小集合"可能相关"的工具
Load 相（执行）：只把这 5–15 个候选 schema 装载进上下文，让模型调用其一
模型从看到 200 个工具，变成看到 5–15 个。它在两端同时见效：近重复集群在模型看到前就被滤掉，注意力稀释消失，token 成本骤降。这正是 Anthropic 内置 tool-search 能力的设计内核，LangGraph 的 tool node 也支持在模型调用前插入 discovery 步骤过滤活动工具集。Search 相按健壮性递增有三档实现：
# 档位一：规则/关键词路由——按域划桶（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 回合都背着"总结一部短篇小说"的基础开销，且无论这些工具是否被调用都要付费。对高吞吐系统，这是让单位经济性崩盘的隐藏账目。
RAG-MCP（arXiv 2505.03275）是对 embedding 工具检索最干净的正式化——名字即设计：把 RAG 那套检索增强模式从文档迁移到工具。但单独的 dense embedding 在术语密集的 API 文档上不够，因为方法名、参数名、领域行话更适合关键词匹配。所以生产级系统普遍落到三层混合路由：
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 检索漏掉的选项。
即便检索准确，多个 MCP server + 内部 REST API 接在一起仍是"50–200 条近重复描述的平铺"。语义路由 + 命名空间是直接的工程解法：
github.search_issues / jira.search_issues，让模型在前缀层先做域消歧。search_documents 的描述从"搜索文档库"改写成"当需要全文检索已索引文档时使用；若需按元数据过滤用 query_index，若需跨系统检索用 search_knowledge_base"。这条"互斥化重写"是单条改动里 ROI 最高的。db_agent.call 入口。这一栈的实际效果非常硬：语义工具路由可达到约 86.4% 的选择准确率，而全塞上下文时不到 50%。
Red Hat 在企业落地中提出 Tool2Vec 方法：不是简单嵌入工具描述，而是学习工具的能力向量，让一个 SLM（小语言模型）就能高效完成检索。这对企业的意义在于路由下沉——把"选哪几个工具"这个高频、低复杂度的决策从昂贵的大模型里剥离，交给本地小模型，大模型只负责对 5–15 个候选做最终调用决策。配合 ACL 2025 论文 Retrieval Models Aren't Tool-Savvy 的发现（通用检索模型在工具检索上表现不佳，需在 API 文档上特化），Tool2Vec 这类特化嵌入/微调路径正是对"现成 embedding 不行"的直接回应：要么换特化模型，要么用 LLM 路由补位。
ACL 2025 的 tool-retrieval-benchmark 给了一个反直觉但关键的结论：你在文档 RAG 上用顺手的现成检索模型，迁移到工具检索会显著掉点。原因是工具描述是高度结构化、术语密集的短文本，与检索模型预训练的长文档分布错配。这带来两条评测红线：
τ-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 通信 | 高 | 多智能体框架 |
一句话收口：Agent 调错工具，没有一招是"换更聪明的模型"，全都是"在它面前摆什么、怎么摆"的问题。 把发现（discovery）与执行（execution）分离，是万级工具时代唯一站得住的默认架构。
[!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 等场景全覆盖。