TheMCPCompany: Creating General-purpose Agents with Task-specific Tools

• ArXiv URL: http://arxiv.org/abs/2510.19286v1

• 作者: Vishwas Suryanarayanan; Stephen H. Bach; Vishal Chowdhary; Reza Esfandiarpoor

• 发布机构: Brown University; Microsoft

---

TL;DR

本文提出了一个名为 TheMCPCompany 的大规模工具调用基准（包含超18000个工具），并通过实验证明，利用专门的工具集比通用浏览器能带来更好的性能和更低的成本，但从海量工具中检索并组合正确工具以解决复杂问题仍是当前智能体面临的核心挑战。

关键定义

• MCP (Model Context Protocol): 由 Anthropic 提出的一个标准化协议，旨在让大型语言模型（LLMs）能够与外部工具和服务进行交互和调用。本文基于此协议构建了所有的工具接口。
• TheMCPCompany: 本文提出的一个新型基准测试，它扩展了现有的 TheAgentCompany 基准。其核心特点是模拟一个拥有超过18,000个通过MCP协议暴露的专用工具的软件公司环境，涵盖了Azure、GitLab等多种真实世界的服务，用于评估智能体在复杂、工具密集型环境中的能力。
• MCPAgent: 本文提出的基线智能体。其核心设计是，不直接向语言模型提供所有18,000+个工具，而是提供一个带有“工具查找器”（\(tool finder\)）功能的网关。智能体必须使用这个查找器，通过自然语言查询来动态搜索和发现完成任务所需的工具，然后才能调用它们。

相关工作

当前，通用的AI智能体主要依赖于浏览器、代码解释器等通用工具与环境交互。虽然已有一些研究开始探索专用工具，但它们普遍存在两个关键问题：

1. 智能体研究的局限性: 现有的通用智能体框架和基准测试虽然模拟了复杂的任务和环境，但通常只集成极少数（几个到几十个）的专用工具。因此，当可用工具数量激增至数千乃至数万时，这些智能体的表现如何，目前尚不明确。
2. 工具调用研究的局限性: 现有的工具调用研究虽然探讨了如何使用大量工具，但它们大多在简单的环境中进行，任务也相对简单（例如，任务描述与工具名称有很高的语义重叠）。这与真实世界的企业级应用场景（如修复一个复杂的云应用）相去甚远，在这些场景中，任务描述与所需工具之间的联系并不直观。

本文旨在解决上述问题，通过创建一个兼具任务复杂性、环境真实性和工具集规模化的新基准 TheMCPCompany，来系统性地研究和评估以大规模专用工具集为主要交互方式的智能体的潜力和挑战。

本文方法

本文的核心贡献在于构建了一个新的基准（TheMCPCompany）和一个对应的基线智能体（MCPAgent），以探索在工具极其丰富的企业环境中智能体的能力。

TheMCPCompany 基准

TheMCPCompany 是对现有基准 TheAgentCompany 的一次重大扩展，旨在模拟一个未来可能出现的、工具高度丰富的企业环境。

• 环境扩展: 在原有 TheAgentCompany 包含的 Plane (项目管理)、GitLab (DevOps)、RocketChat (通信) 和 ownCloud (文件) 四种服务的基础上，本文引入了更为复杂的 Microsoft Azure 云计算平台。这极大地增加了环境的复杂性和智能体可执行操作的数量。

• 构建大规模工具集: 本文的核心工作是将这些服务（Azure, GitLab, RocketChat 等）的全部功能通过 MCP 协议暴露为工具。通过转换服务的 REST API，本文创造了一个包含超过 18,505 个工具的庞大工具集，其中仅 Azure 就贡献了近 17,000 个工具。这种方法为 LLM 提供了一个标准化的、可发现的接口来与真实世界的服务交互。

• 复杂的任务设计: 基准包含了两种类型的任务：
  1. TheAgentCompany 适配任务: 将原有基准中的任务调整为适用于工具调用。
  2. 新增 Azure 任务: 设计了一系列新的、更具挑战性的 Azure 任务，从简单的资源标记到复杂的复合任务，如修复一个由多个云服务（CosmosDB, Key Vault 等）组成的损坏的 Web 应用。这些任务要求智能体不仅要找到正确的工具，还要理解复杂的服务依赖和业务逻辑。
• 工具集特性: 这个工具集不仅规模大，而且复杂度高，很好地模拟了现实世界的混乱性。
  • 工具平均有超过5个参数，某些 Azure 工具甚至需要多达39个参数。
  • 工具之间存在显著的依赖关系（例如，创建虚拟机前必须先创建其依赖的磁盘和网络资源）。
  • 约21.5%的工具需要复杂的参数类型（如数组或对象），给调用带来了挑战。
  • 存在命名相似但功能迥异的工具，也存在功能相似但命名不同的工具。

r0.45

服务 (Service)	MCP工具数量 (#MCP Tools)	平均参数数量 (Avg #Args)	复杂工具比例 (%) (Complex Tools (%))
Plane	52	2.06	28.85
RocketChat	520	2.82	12.31
ownCloud	11	1.64	0.00
GitLab	1,085	5.47	10.69
Azure	16,837	5.63	22.50
总计 (Total)	18,505	5.53	21.52

MCPAgent 智能体

为了应对拥有超过18,000个工具所带来的挑战（远超当前LLM的上下文窗口容量），本文设计了 MCPAgent。

• 创新点: MCPAgent 的核心创新在于其动态工具发现机制。它不试图将所有工具信息一次性提供给 LLM，而是通过一个“网关MCP服务器”进行交互。这个网关只提供两个核心工具：
  1. 工具查找器 (\(tool finder\)): 智能体可以使用这个工具，通过文本查询来在庞大的工具库中搜索相关工具。底层实现上，它使用文本嵌入模型（text-embedding-3-large）计算查询与所有工具文档的余弦相似度，并返回最匹配的 top-k 个工具的详细信息。
  2. 工具调用器: 智能体在发现所需工具后，使用此功能来实际执行该工具，网关服务器会负责调用并返回结果。
• 优点: 这种架构将一个巨大的、静态的工具集问题，转化为一个动态的、迭代的“搜索-使用”问题。它允许智能体根据任务进展灵活地探索不同的解决方案，并动态地选择所需工具，从而在处理海量工具集时保持了可行性和高效性。

实验结论

本文在 TheAgentCompany 适配任务和新的 Azure 任务上，对多种 LLM（包括 GPT-4.1, GPT-5, Opus-4.1 等）进行了评估。

!

在TheAgentCompany的175个适配任务上，不同LLM模型的性能表现。Browser：LLM使用浏览器完成任务。MCPAgent：LLM使用工具查找器来发现和调用所需工具。Oracle Tool Set：LLM被直接给予完成每个任务所需的正确工具集。

TheAgentCompany 任务上的结论

1. 专用工具的巨大潜力: 在“神谕”（Oracle）设定下（即直接为智能体提供完成任务所需的正确工具），与使用浏览器的智能体相比，使用专用工具的智能体平均性能提升13.79分，并且平均每个任务的推理成本降低了 $2.29（降幅达54%）。这证明了专用工具在性能和效率上的巨大优势。

2. 专用工具在实践中的可行性: 在更实际的设定中，MCPAgent（需要自己检索工具）的表现仍然优于浏览器智能体，平均性能提升5.39分，成本同样显著降低。这表明即使面临工具检索的挑战，该方法在实践中仍然是更优的选择。

3. 模型间的性能差异:

   • 对于能力较弱的模型，从“神谕”设定切换到“检索”设定后，性能下降明显。这说明它们虽然能使用给定的工具，但在从海量工具库中发现正确工具方面能力不足。
   • 相比之下，最先进的模型 GPT-5 在“检索”设定下的表现非常接近其在“神谕”设定下的表现。这表明，顶尖的推理模型已经具备了在相对简单的环境中有效发现和使用工具的能力。

Azure 复杂任务上的结论

• 在最难的 Azure 任务上，即使是最强大的模型也几乎完全失败。
• 失败的主要原因是智能体难以应对 Azure 服务的极端复杂性和多样性。它们在以下方面表现不佳：
  • 无法正确定位应用的根本问题。
  • 在一种方案失败后，不能有效地探索所有可能的替代解决方案。
  • 往往只能实现解决方案的一部分，而无法完成整个修复流程。

总结

• 成功之处: 实验结果表明，通过 MCP 协议暴露大量专用工具，并让智能体直接与之交互，是一条比依赖通用浏览器更有前景的技术路径。
• 核心挑战: 未来的核心挑战在于检索与推理的结合。当前的智能体难以在包含数万个工具的复杂环境中进行导航，并以非平凡的方式组合这些工具来解决复杂的多步骤问题。
• 未来方向: 要实现能够胜任复杂企业任务的通用智能体，需要同时在推理模型和检索模型两方面取得更大进展。TheMCPCompany 基准为此方向的研究提供了一个有效的评估平台。