MCP工具选择实际在哪里失效：基于检索的修复最多只能挽回约23%的失败

这个问题我琢磨了好几天。 7月份来自实践者的报告（Chew Loong Nian在Towards AI上的文章，以及DEV Community上的几篇技术帖）都指向同一个观察：当MCP工具数量超过大约20个时，智能体的工具选择准确率会明显下降。 默认的应对方法是检索——对工具目录进行RAG，然后给模型一个过滤后的短列表。RAG-MCP（arXiv:2505.03275）报告称，通过这种方法，他们的基准测试结果从13.62%提升到43.13%，同时提示词token减少了50%以上。这是合理的结果。 但一篇6月底提交的论文（arXiv:2606.16364，《看见不等于选中：LLM智能体工具选择失败的注意力分段解释》）认为，仅靠检索很快就会达到上限。 他们对该机制的探究如下： - 在真实的伯克利函数调用排行榜失败案例中，模型在80%的情况下最关注正确的工具（而随机基线的概率为21%）。仅在约10%的失败案例中，黄金工具属于“注意力不足”的部分。因此，“中间丢失”或“拥挤框架”的说法并不占主导地位。 - 输入侧的提示修复（重新排列工具、在提示中重复黄金工具）最多只能挽回≤23%的失败。读取侧的干预措施（添加注意力logit偏置、残差流导向向量）可挽回59-91%的失败。这两种独立的方法大致覆盖了相同的失败类型。 - 他们无需训练、无需黄金标签的选择器，利用每个分段的注意力作为置信门控，在BFCL综合集上函数名称准确率提升了+11.9个百分点，在Seal-Tools综合集上提升了+14.9个百分点。 我的看法：这并不否定基于检索的工具选择。仅凭成本和延迟考虑，减少50%以上的提示词token仍然是值得做的，而且那23%的提升也是实实在在的。但如果你正在部署一个拥有大量工具空间的智能体，并且唯一的防御手段是检索或工具描述优化，那么你正在触及输入侧的上限。读取层似乎是下一个真正突破点所在。 很好奇大家实际是怎么做的。如果你曾与超过约20个工具时的准确率崩溃作斗争，是什么改变了你的指标？有没有人尝试过触及读取阶段的方法——比如logit处理器、对工具名称进行约束解码、外部重新评分——而不仅仅是预先过滤目录？ 披露：我从事智能体记忆与上下文基础设施方面的工作（MTRNIX）。不是推销。这个现象之所以引起我的注意，是因为“输入侧天花板”的框架在应用安全领域似曾相识——在那里，基于相同信任模型的纯过滤防御总是会达到上限。真心想知道在生产环境中什么方法有效。