先这样答
工具一多，问题会换性质：不再是「模型选得准不准」，而是「工具列表本身把上下文挤爆、把模型看花」。业界的基本共识是不让模型直面全量工具，中间加一层检索，做法就是把 RAG 的思路搬到工具选择上。
具体三层。第一层做减法：上百个工具先审一遍，功能重叠的合并（五个不同来源的查询接口合成一个带 source 参数的）、长期没人用的下线。很多系统工具多不是需求多，是没人管。第二层做索引：把每个工具的名称、描述、适用场景做成可检索的条目，用 Embedding 建向量索引，也可以再配上关键词路。第三层做两段选择：用户请求来了，先用查询（可以结合任务上下文改写）从索引里召回 top 10 到 20 个候选工具，把这小撮工具的定义放进提示词，模型在候选集里做最终的 Function Calling。这样模型每次面对的工具数量是可控的，准确率和上下文占用都改善。
这套机制有两个配套要点。一是召回不能只看查询文本：用户说「帮我处理下那个单子」，光靠这句话召回不出工单工具，要把任务规划阶段的中间结论拼进召回查询。二是要监控召回层：选错工具有相当比例其实是「正确工具没被召回」，这层坏了上层怎么调都没用，评测时要把工具召回率单独拆出来看。
面试官会怎么追问
- 两段选择会不会漏掉真正要用的工具？ 会，所以要评测召回率，候选集大小和阈值按评测调；高频核心工具可以设白名单常驻提示词，不受召回影响。
- MCP 场景下工具更多，怎么办？ 同样思路下沉到服务器侧：按域拆 MCP 服务器，Host 层先选服务器再选工具，两级路由。
- 工具的描述要为检索优化吗？ 要。工具描述既是给模型看的也是给索引用的，写清「解决什么问题、什么时候用」，检索和选择两头的准确率都吃它。
回答的坑
- 只答「把描述写好」。几十个工具以内描述够用，上百个必须上检索层，量级判断是这道题的得分点。
- 忽略「先合并再检索」。工具膨胀是组织问题，检索只是技术兜底。
同系列的题
—— 本题完 ——