在VS Code中，GitHub Copilot Chat通过模型上下文协议（MCP）可以访问数百个工具，从代码库分析工具到Azure专用工具应有尽有。但给智能体提供过多工具并不总能让它更智能，有时反而会让它变慢。

如果你在VS Code中见过这个旋转加载图标，说明你已经遇到了模型尝试同时推理过多工具时的限制。

为了解决这个问题，我们构建了两个新系统——嵌入引导工具路由和自适应工具聚类——并推出一个精简工具集，将默认的40个内置工具减少到13个核心工具。在SWE-Lancer和SWEbench-Verified等基准测试中，这些更改将成功率提高了2-5个百分点。在在线A/B测试中，平均响应延迟减少了400毫秒。

过多工具会阻碍智能体性能

VS Code中的默认工具集包含约40个内置工具，从通用命令行工具到Jupyter Notebook专用工具不一而足。加上MCP服务器，这个数字可能增长到数百个。通常，MCP服务器会引入如此多的工具，以至于可能超过某些模型的API限制。

我们探索了过滤工具集的方法，只提供与用户查询最相关的工具，同时不限制智能体的能力。具体来说，我们需要确保不会为了降低延迟而牺牲用户体验。

为了实现这一目标，我们设计了一个折中方案：“虚拟工具”。这包括将相似工具功能性地分组到一个"虚拟工具"下，聊天智能体可以根据需要展开。可以将其视为包含相关工具的目录。这让模型大致了解可用的工具，而不会被数百个工具名称淹没。它还降低了模型搜索单个工具时可能出现的缓存未命中率，因为相似的工具很可能被一起使用和激活。

为MCP工具应用无损动态工具选择

自适应工具聚类

最初，我们将所有可用工具输入LLM，要求它对它们进行分组和总结。但这有两个大问题：

• 我们无法控制创建的分组数量，有时会超过模型限制
• 速度极慢且产生巨大的令牌成本。模型有时还会"忘记"对某些工具进行分类，导致需要重试

为了解决这个问题，我们应用内部优化的Copilot嵌入模型为每个工具生成嵌入，并使用余弦相似度对它们进行分组。这种聚类方法允许精确、稳定和可复现的分组。例如，这里是GitHub MCP服务器工具在嵌入空间中的一个可能分组：

我们仍然使用模型调用来总结每个聚类，但这一步比要求模型从头开始对所有内容进行分类要快得多且便宜得多。工具嵌入和分组总结被缓存在本地，因此重新计算它们相对便宜。

上下文引导工具选择

工具分组后，我们面临另一个问题：模型如何知道要打开哪个分组而无需检查所有分组？我们发现，大多数时候，模型最终会找到适合其任务的正确工具。然而，每次调用虚拟工具仍然会导致缓存未命中、额外的往返行程，以及一小部分智能体操作失败的机会。

例如，当用户说：“修复这个错误并将其合并到开发分支。”

模型通常会打开搜索工具，然后是文档工具，接着是本地Git工具，最后才意识到它实际上需要GitHub MCP工具组内的合并工具来完成操作。

每个不正确的分组查找都会增加延迟和开销，即使正确的分组从上下文中相当明显。

为了解决这个问题，我们引入了嵌入引导工具路由。在任何工具组展开之前，系统将查询嵌入与所有工具（及其聚类）的向量表示进行比较，允许它预先选择语义上最相关的候选工具——即使它们深藏在某个组内。

通过上下文感知路由，我们可以从一开始就推断模型很可能需要GitHub MCP工具组内的合并工具，并将其直接包含在其候选集中——消除了不必要的探索性调用，显著降低了延迟和失败率。通过仅显示最有希望的匹配项，我们使模型的搜索更加有针对性和可靠，同时减少了冗余探索。

基于嵌入的选择（由Copilot嵌入模型驱动）

我们通过工具使用覆盖率来衡量基于嵌入的选择过程的成功程度，该指标衡量模型在需要时已经拥有正确工具可见的频率。

在基准测试中，基于嵌入的方法实现了94.5%的工具使用覆盖率，优于基于LLM的选择（87.5%）和默认静态工具列表（69.0%）。

在离线测试中，这种方法在覆盖率上实现了27.5%的绝对改进，明显超过了基于LLM的方法，同时帮助智能体更快地推理并保持效率。

在线测试显示了相同的模式：使用旧方法只有19%的稳定工具调用被成功预展开，而由于基于嵌入的匹配，72%的内部版本工具调用被预展开。这证实了离线观察到的增益在实际使用中得到了持续体现。

少即是多：缩小默认工具集

即使没有触发大型MCP服务器可能触发的模型限制，过大的内置工具集仍然会降低性能。在离线基准测试中，我们观察到当智能体可以访问完整内置工具集时，包括SWE-Lancer在内的基准测试解决率下降了2-5个百分点。在行为上，智能体最终会忽略明确的指令，错误使用工具，并调用手头任务不必要的工具。

因此，我们精简了列表。基于工具使用统计和性能数据，我们确定了一个包含13个基本工具的核心工具集。这些工具涵盖了高级仓库结构解析、文件读写和编辑、上下文搜索以及终端使用。

其余的非核心内置工具被分为四个虚拟类别：Jupyter Notebook工具、Web交互工具、VS Code工作区工具和测试工具。这样，模型可以看到较小的核心集，并且仅在必要时展开分组。因此，使用精简工具集的用户体验到首次令牌时间平均减少190毫秒，最终令牌时间平均减少400毫秒。

更小的工具集使智能体更有效：推理更简单，响应时间更快，性能更好。

未来方向：从工具选择到长上下文推理

随着MCP系统的发展，挑战不仅在于选择正确的工具——还在于跨时间、上下文和交互进行推理。

一个真正智能的模型不应该仅仅对查询做出反应；它应该记住以前的工具使用情况，从历史中推断意图，并在长会话中规划多步操作。从这个意义上说，工具选择是长上下文推理的早期形式。今天帮助模型路由到正确工具的相同机制，未来可能帮助它们在数千轮对话中进行推理，帮助它们决定何时行动、何时委托以及何时停止。

我们的下一步是探索嵌入、记忆和强化信号如何结合，以创建能够学习如何使用工具，而不仅仅是选择哪些工具的上下文感知智能体。