工具过载（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 条 |
上下文预算紧张时，路由与裁剪要联动设计，参见 上下文工程与 Token 预算管理：大模型长上下文的架构裁剪与注意力保真。
验证方法
离线评测：标注几百条真实用户指令，分别量测"正确工具出现在候选集内"的召回率与最终选择正确率——召回率先掉说明索引或画像有问题，只有正确率掉说明 K 偏大或 Schema 描述差。在线监控：对比启用路由前后的工具调用失败率与平均任务轮数，两者应同向改善，若轮数反而上升，多半是兜底检索没配好。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 模型请求了未注册的正确工具 | 粗筛漏召回 | 启用元工具兜底并补该工具画像 |
| 选对工具但参数频繁出错 | 候选过多或 Schema 含糊 | 降低 K，重写参数描述 |
| 路由环节延迟明显 | 每次请求全量嵌入计算 | 高频意图缓存，热点工具常驻注册 |
| 冷门工具长期零命中 | 描述与用户措辞脱节 | 从失败日志中补充真实说法示例 |
小结
这套架构值得上线的判据：候选 5 工具方案的召回率稳定在高位（例如对标注集九成以上的指令能包住正确工具，经验值），且注入 token 数明显低于全量挂载。召回率与准确率必须分开监控——它们对应两类完全不同的修复动作：前者改索引和画像，后者改 K 值和 Schema 描述。