千级工具路由为何不能只靠向量检索

工具目录扩展到千级，Agent 还能靠向量检索找出候选，再交给模型挑选吗？dev.to 的这篇文章指出，这条路径会遇到召回和后续决策两类瓶颈，并提出混合检索、硬过滤、学习式重排、渐进披露与分阶段评估的组合思路。目前只有标题和摘要，具体实现与实验结果尚不清楚。

目前能确认什么

文章讨论的是大规模工具选择：先从工具目录中找出候选，再决定调用哪个工具。

向量检索通常按语义相似度返回排名靠前的 K 个结果，也就是 Top-K。但语义接近不等于满足调用条件。作为通用背景，工具名称、描述中的精确关键词，以及参数要求、权限等约束，都可能影响工具是否适用。

摘要提出的思路，是把选择拆成多个环节：混合检索兼顾语义与关键词，硬过滤排除不满足明确条件的候选，学习式重排调整候选顺序，渐进披露则按需提供工具信息。分阶段评估用于区分问题出在哪一步。

正确工具没被召回，与正确工具已经出现却被模型选错，是两类故障。

我的判断

对维护大量工具的程序员来说，优先要补的是可定位问题的记录：候选列表里有没有正确工具，过滤是否误删，模型最终为什么选了另一个。只看任务成功率，很难决定该改检索还是改选择提示。

单纯增大 K 也不能当作完整方案。它可能扩大候选范围，同时增加模型需要辨别的信息量；这属于通用的设计权衡，不能据此认定文章验证了哪种配置更好。

目前还不能确认：作者如何组合这些环节、重排需要什么训练数据、渐进披露如何触发，以及各阶段采用什么指标。因此，这份摘要能支持的是分层排查思路，还不足以支持直接照搬一套工具路由架构。