大规模工具库的动态工具路由（Dynamic Tool Routing）架构

工具过载（Tool Overload）问题

目前主流模型在上下文同时挂载 20 个以上工具时，调用准确率就会开始出现可察觉的下滑；当挂载 100 个工具时，模型常常会“看花眼”，选错工具或拼错入参。

工具元信息向量化（Tool Indexing）：将每个工具的名称、功能描述和典型应用场景转化为语义向量，存入轻量向量库；
第一阶段：语义粗筛（Semantic Pre-filtering）：根据用户当前发起的指令，计算余弦相似度，只召回与当前意图最相关的 Top-5 工具；
第二阶段：动态注册（Just-in-time Registration）：将这 5 个工具的完整 JSON Schema 临时注入当前轮次的 Prompt 中；
执行与回滚：任务完成后卸载工具，释放宝贵的上下文空间。

工具画像。把每个工具的名称、描述、参数要点与两三条典型调用示例拼成一段"画像文本"再做嵌入，描述质量对召回的影响远大于模型选型（写法参考提升 Agent 工具调用准确率的 10 个实战技巧：从命名规范到参数描述调优）；
建索引。按团队或业务域划分命名空间，避免不同场景的同名动作互相污染；工具上下线由注册表同步，不手工维护（治理方法见企业私有 MCP 注册表（Registry）搭建与生命周期治理实践）；
粗筛 + 兜底。召回 Top-K 注入当轮上下文，同时注册一个内置的"检索更多工具"元工具：当模型发现候选集里没有合适工具时可显式再查一次，防止漏召回直接卡死任务；
测反馈。记录每轮的召回命中、选错案例与最终成功率，把失败样本回灌到工具画像的迭代里。

参数	调大的影响	调小的影响	建议起点
Top-K 召回数	准确率降、token 变贵	漏召回风险升	5，按任务域微调
相似度阈值	召回变少但更纯净	噪声候选增多	先不设，观察分布后加
画像示例条数	描述成本与长度上升	语义覆盖不足	2–3 条

离线评测：标注几百条真实用户指令，分别量测"正确工具出现在候选集内"的召回率与最终选择正确率——召回率先掉说明索引或画像有问题，只有正确率掉说明 K 偏大或 Schema 描述差。在线监控：对比启用路由前后的工具调用失败率与平均任务轮数，两者应同向改善，若轮数反而上升，多半是兜底检索没配好。

这套架构值得上线的判据：候选 5 工具方案的召回率稳定在高位（例如对标注集九成以上的指令能包住正确工具，经验值），且注入 token 数明显低于全量挂载。召回率与准确率必须分开监控——它们对应两类完全不同的修复动作：前者改索引和画像，后者改 K 值和 Schema 描述。