📢 转载信息
原文链接：https://www.microsoft.com/en-us/research/blog/tool-space-interference-in-the-mcp-era-designing-for-agent-compatibility-at-scale/
原文作者：Microsoft Research
# 规模化智能体时代的挑战：工具空间干扰与兼容性设计
今年以来，以AI智能体为代表的代理式人工智能取得了显著的进步，它们能够执行深入研究、操作计算机、完成复杂的软件工程任务，并应对各种多步骤目标。在初期，业界主要依赖**垂直整合**的策略：工具和智能体被协同设计、共同训练和测试，以实现最佳性能。例如，OpenAI 的最新模型
预设了Web搜索和文档检索等工具的可用性。同样，
Magentic-One 的提示和动作也便于进行任务交接，例如允许 WebSurfer 智能体将下载的文件传递给 Coder 智能体。
然而，随着智能体的激增，我们预计高度依赖垂直整合的策略将不再适用。来自不同开发者或公司的智能体将越来越多地相遇，必须协同工作才能完成任务，形成一个**“智能体社会”**。这些系统在协调程度、目标一致性以及信息共享方面可能存在巨大差异。在这种环境下，异构的智能体和工具究竟能否有效协作，还是会相互妨碍、拖慢进度？
早期线索已从一个意想不到的来源浮现：**模型上下文协议 (Model Context Protocol, MCP)**。
自2025年1月以来，MCP 已从一个有前途的规范发展成为一个蓬勃发展的工具服务器市场。例如，
Zapier 拥有一个包含 30,000 个工具的目录，横跨 7,000 个服务。
Composio 提供了超过 100 个托管的 MCP 服务器，暴露了数百个工具。Hugging Face 正在通过 MCP 为许多
Spaces 应用提供服务，并且
Shopify 已为数百万个店面启用了 MCP。一个**“工具社会”**已经到来，它有望通过**跨提供商的水平整合**来扩展智能体的能力。
那么，MCP 对水平整合有何启示呢？随着目录的增长，我们预计会出现一些新的故障模式。本文将这些模式定义为**“工具空间干扰”**，并概述初步观察结果以及一些实用的干预措施，以确保我们所构建的社会不会“绊倒自己”。
**工具空间干扰**描述了原本合理的工具或智能体在共同存在时，导致端到端效率降低的情况。这可能表现为更长的动作序列、更高的 Token 成本、从错误中恢复能力脆弱，甚至任务失败。
## 一个示例框架
考虑将 MCP 作为扩展我们去年发布的通用多智能体系统 **Magentic-One** 的方式，以覆盖更多软件工程任务。Magentic-One 自身配备了编写代码、与计算机终端交互、浏览网页和访问本地文件的智能体。为了帮助 Magentic-One 导航版本控制、查找待解决的问题和创建 Pull Request，我们可以添加一个配备了 GitHub MCP 服务器的智能体。然而，现在每当团队遇到涉及 GitHub 的任务时，都必须在以下选项中进行选择：在浏览器中访问 `github.com`、在命令行执行 `git` 命令，或者使用 GitHub MCP 服务器。随着任务的进展，智能体对状态的理解也可能出现分歧：在浏览器中更改分支不会改变终端中的分支状态，并且已授权的 MCP 工具不意味着在浏览器中也已授权。因此，虽然任何单个智能体都可能高效地完成任务，但更大范围的智能体集合可能会相互误解或干扰，从而导致额外的调试轮次，甚至任务完全失败。
图 1：我们可以通过添加一个配备 GitHub MCP 服务器的智能体来扩展 Magentic-One。然而，在每次涉及 git 任务的回合中，协调器都需要在消息传递给计算机终端智能体（具有 git 命令行接口访问权限）、WebSurfer 智能体（具有 github.com 访问权限）和具有 GitHub MCP 服务器的智能体之间做出选择。这种重叠增加了它们相互干扰的可能性。
## 通过 MCP 视角审视工具空间干扰
为了更好地理解潜在的干扰模式和 MCP 生态系统的当前状态，我们对两个注册表中列出的 MCP 服务器进行了调查：
smithery.ai 和
Docker MCP Hub。Smithery 是一个 MCP 服务器注册表，包含超过 7,000 个第一方和社区贡献的服务器，我们从 Smithery API 中抽取了样本。同样，Docker MCP Hub 是一个以 Docker 镜像形式分发 MCP 服务器的注册表，我们手动收集了热门条目。然后，我们启动了每个服务器进行检查。在排除空置或启动失败的服务器并对具有相同功能的服务器进行去重后，我们的目录中仍有 1,470 个服务器。
为了自动化检查正在运行的 MCP 服务器，我们开发了一个 **MCP Interviewer（MCP 访谈工具）**。MCP Interviewer 首先编目服务器的工具、提示、资源、资源模板和能力。从这个目录中，我们可以计算描述性统计数据，例如工具数量或参数模式的深度。然后，给定可用工具列表，访谈工具使用 LLM（在我们的案例中是 OpenAI 的 GPT-4.1）来构建一个功能测试计划，该计划至少调用每个工具一次，在此过程中收集输出、错误和统计数据。最后，访谈工具还可以通过使用 LLM 将专门构建的评分标准应用于工具模式和工具调用输出来评估更定性的标准。我们很高兴能将 **MCP Interviewer 作为开源 CLI 工具发布**，以便服务器开发人员可以从代理可用性的角度自动评估其 MCP 服务器，用户也可以验证新服务器。
尽管我们的调查提供了初步的有用结果，但它也存在明显的局限性，其中最明显的就是**授权**：许多最受欢迎的 MCP 服务器提供对需要授权才能使用的服务的访问，这阻碍了自动化分析。我们通常仍然可以收集这些服务器的静态特征，但在功能测试方面受到限制。
### 一刀切的方案（但效果各异）
那么，我们对 MCP 服务器的调查告诉我们关于 MCP 生态系统的哪些信息呢？我们稍后会深入探讨具体数字，但在思考统计数据时，需要牢记一个总体主题：**MCP 服务器不知道它们正在与哪些客户端或模型协同工作，而是向所有人提供一套通用的工具、提示和资源**。然而，一些模型处理长上下文和大型工具空间的能力比其他模型更好（具有不同的硬性限制），并且对常见的提示模式反应截然不同。例如，
OpenAI 关于函数调用的指南建议开发人员：
> “在其中包含示例和边缘案例，特别是为了纠正任何重复出现的失败。（注意：添加示例可能会损害推理模型的性能）”
因此，这已经使 MCP 相较于针对操作环境进行优化的垂直集成处于不利地位。现在让我们深入了解更多数字。
### 工具数量
虽然模型通常在工具调用能力上存在差异，但总体趋势是**工具数量增加，性能下降**。例如，OpenAI 限制开发人员最多使用 128 个工具，但
建议开发人员：
> “保持函数数量较少以提高准确性。用不同数量的函数评估性能。目标是每次不超过 20 个函数，但这只是一个软性建议。”
虽然我们预计随着每一代新模型的出现，这种情况会有所改善，但目前，大型工具空间可能会使**某些模型的性能下降高达 85%**。
（arxiv.org/abs/2505.10570v1） 值得庆幸的是，我们调查中的大多数服务器包含四个或更少的工具。但也有例外：我们编目的最大 MCP 服务器添加了 256 个不同的工具，而接下来最大的 10 个服务器每个添加了 100 多个工具。再往下看，我们发现了像
Playwright-MCP（截至撰写本文时有 29 个工具）和 GitHub MCP（91 个工具，在替代端点 URL 下有子集可用）这样流行的服务器，它们可能对某些模型来说过于庞大。
图 2：每个已编目服务器在初始化后列出的工具数量。注意：服务器可以随时更改其列出的工具，但我们目录中只有 226 个服务器声明了此功能。
### 响应长度
工具通常在智能体循环中被调用，其输出随后作为输入上下文反馈给模型。模型对输入上下文有硬性限制，但即使在这些限制内，较大的上下文也会增加成本并降低性能，因此**实际限制可能要低得多**。
（research.trychroma.com/context-rot） MCP 没有关于工具调用可以产生多少 Token 的指导，并且某些响应的大小可能会令人意外。在我们的分析中，我们考虑了在服务器检查的活动测试阶段，MCP Interviewer 成功调用的 2,443 个工具调用（涉及 1,312 个唯一工具）。虽然大多数工具产生的 Token 数在 98 个或更少
（github.com/openai/tiktoken），但一些工具的开销极大：**排名第一的工具平均返回 557,766 个 Token**，这足以淹没许多流行模型的上下文窗口，如 GPT-5。往下看，我们发现 **16 个工具会产生超过 128,000 个 Token**，这使得 GPT-4o 和其他流行模型不堪重负。即使响应能适应上下文窗口长度，过长的响应也会显著降低性能（在一项研究中
高达 91%），并限制可以进行的未来调用次数。当然，智能体可以实施自己的上下文管理策略，但这种行为在 MCP 规范中是未定义的，服务器开发人员不能指望任何特定的客户端行为或策略。
| | 调用次数溢出上下文的工具数量 |
| 模型 | 上下文窗口 | 1 次调用 | 2 次调用 | 3-5 次调用 | 6-10 次调用 |
| GPT 4.1 | 1,000,000 | 0 | 1 | 7 | 11 |
| GPT 5 | 400,000 | 1 | 7 | 15 | 25 |
| GPT-4o, Llama 3.1, | 128,000 | 16 | 15 | 33 | 40 |
| Qwen 3 | 32,000 | 56 | 37 | 86 | 90 |
| Phi-4 | 16,000 | 93 | 60 | 116 | 109 |
图 3：MCP Interviewer 功能测试计划观察到的平均工具调用响应长度（以 Token 为单位）。仅考虑成功的工具调用。水平线表示 GPT-4o 和 GPT-5 的上下文窗口限制。
### 工具参数复杂性
与增加工具数量带来的挑战相呼应，增加工具参数空间的复杂性也会导致性能下降。例如，虽然 MCP 工具可以接受复杂的对象类型和结构作为参数，但
Composio 发现，**扁平化参数空间可以将工具调用性能提高 47%**（相对于基线性能）。在我们的分析中，我们发现了大量深度嵌套结构的例子——在一种情况下，深度达到了 20 层。
图 4：每个工具输入属性模式的最大深度。深度 0 表示没有属性的工具。深度 1 表示具有命名属性但没有注释（例如，没有描述或类型）的工具。深度 2 表示具有命名和带注释属性的工具。深度 3+ 表示具有... [内容被截断]
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，小白也可以简单操作。
青云聚合API官网https://api.qingyuntop.top
支持全球最新300+模型：https://api.qingyuntop.top/pricing
详细的调用教程及文档：https://api.qingyuntop.top/about
评论区