MCP工具越多AI越聪明？微软揭示的3个性能下降机制

每次安装新的MCP，都会有一种”AI变聪明了”的感觉。Claude Code做到了昨天还做不到的事，你心想：这个方向对了。

我也这么想过。认真使用Claude Code两个月后，我已经装了超过15个MCP。看着能做的事越来越多——那种感觉确实不错。

然而上周，Claude Code宣告”我将打开浏览器进行验证”之后，就僵住了整整两分钟。最后返回的只有一行：“我无法判断应该使用哪个工具。“MCP太多了，它没法做决定。

2026年6月14日，ITmedia根据微软官方说明刊发了一篇文章，核心意思是”增加MCP并不会让AI更聪明”。那一刻，我的直觉终于和官方论述对上了。

读完这篇文章，你这个周末将拿到三件事：

• 15分钟审查MCP配置的清单
• 3问删减框架，可直接套用到你的Claude Code配置
• 3条反模式清单，避免我踩过的坑

为什么”MCP越多=AI越聪明”的错觉如此真实

新增一个MCP，就能做到新的事情。这个事实本身没有问题。问题在于从”能做的事更多”到”变聪明了”的那一步跳跃——那是感觉，不是事实。

两个月前，我的MCP配置：GitHub、Slack、Notion，共三个。覆盖了80%的工作，Claude Code响应流畅，没有任何抱怨的理由。

一个月前，新增Playwright、Stripe、SendGrid、Cloudflare KV、Vercel，共八个。每完成一个通过新MCP处理的任务，“装对了”的感受就叠加一次。

两周前：超过15个。Supabase、Linear、Figma、Anthropic Workbench、Cloudflare R2、自制日报MCP。“试试就放着”已经成了默认操作。

到那时为止，事情确实是在变得”更能干”——因为刚安装完的头几天，你看到的都是新工具能做到的事。那几天”变聪明了”的感觉是真实可测量的。

陷阱在于：你的感知停留在”头几天”。拉长时间来看，另一条曲线出现了：当MCP数量超过某个门槛，Claude Code开始变慢，判断失误也越来越频繁。

就连信奉”先把东西跑起来”的我，也结结实实地掉进了这个坑。感觉与其说是个人管理问题，不如说是MCP这种机制结构上就有的特性。

最早让我察觉的迹象是这样的：我让Claude Code找测试失败的原因。以前3～4轮就能定位，现在要6～7轮。每一步判断都没问题，但轮数增加悄悄地耗尽了我的专注力。“最近感觉变慢了”——后来才意识到，这和MCP数量有关。

微软指出的3个性能下降机制

通过ITmedia，我接触到了微软的官方说明。增加MCP工具所导致的性能下降被整理为三个机制。由于我手头没有原始URL，以下以”报道内容”框架呈现——但实质内容与我的亲身体验完全吻合。

机制1：上下文压缩

LLM在系统提示词中接收每个MCP工具的”名称、描述、参数规格”。一个MCP可能消耗数百到数千个token。装了15个，还没说正题，上下文就已经被工具定义占去了相当一部分。

实测自己的环境：装了15个MCP后，Claude Code的剩余上下文有时会降到30%以下。会话一旦拉长，关键的工作历史就会被挤出——不是失忆，而是被工具定义占据了席位。

机制2：语义冲突

当多个MCP服务于相似的目的，LLM就难以判断该调用哪一个。我同时装了Notion和Google Docs之后，Claude Code每次都开始询问”贴到哪里”。

原本自动化的流程，因为选择过多而开始犹豫。“我来处理”变成”您希望用哪个？“，对话的摩擦感一下子上升了。

机制3：错误工具选择

超过一定数量后，LLM的工具选择精度就会下降。微软的说明据报道指出”工具定义越长，LLM越容易忽略末尾部分”。

我自己的体验是：排在第13位安装的一个实用工具，在真正需要时几乎从没被调用过。“明明装了却不用”不是功能缺陷——有时是位置顺序的问题。

这三个机制并非各自独立运作，而是叠加生效。上下文压缩降低选择精度，语义冲突再添混乱。打破这个循环最快的方式，就是在入口处控制数量。

从15个MCP削减到5个：实际发生了什么

“先把东西跑起来”依然是我的核心信念。在MCP上，“先把工具装上”却起了反作用。以下是从15个削减到5个的具体过程。

第一步：把本地环境里的所有MCP写到纸上。完整清单如下：

GitHub、Slack、Notion、Google Docs、Playwright、Stripe、SendGrid、Cloudflare KV、Cloudflare R2、Vercel、Supabase、Linear、Figma、Anthropic Workbench、自制日报MCP。写出来自己都有点不好意思。

下一步：通过Claude Code的历史记录，统计过去一个月实际被调用的MCP。结果是5个：GitHub、Slack、Playwright、自制日报MCP、Linear。其余10个有安装记录、有我记得装过它们的印象，但调用次数为零。

那10个”也许某天会用到”的MCP，每次会话都在消耗上下文，每次工具判断都在制造噪音。这就是现实。

削减到5个后：

• 响应速度：体感约提升1.5倍
• 工具混乱频率（Claude Code询问”应该用哪个工具？“的次数）：下降约三分之二
• 会话中途剩余上下文：稳定保持在60%以上

这些是我本地环境的测量值，不保证在所有人的环境中同样重现。但我相信改善的方向是一致的。不要只听我的，自己试一周。

一个意外的附带效果：配置文件变轻了。从15个MCP的版本跟进、凭证更新等维护工作中解放出来，写代码的时间增加了。

削减一周后，我注意到另一个变化：Claude Code”试着做某件事然后失败”的模式几乎消失了。装了15个的时候，它会宣布”我来试试这个MCP”然后落空，一周大概3～4次。削减到5个后：几乎归零。

选择变少了，AI的行为就更精准。我把这个说成个人观察而非定论。但”MCP越多=越困惑，而非越自由”这个可能性，值得自己去验证。

MCP删减的3个判断问题：周末30分钟的整理步骤

以下是实用部分。三个问题，让你在周末30分钟内完成MCP审查。

问题1：这个MCP过去两周被调用了几次？

在Claude Code中，可以通过/cost命令或日志查看调用频率。过去两周调用次数为零 → 删除候选。“也许某天会用到”是陷阱。真正需要的时候重新安装只需几分钟——带着这个认知，让自己大胆删除。

统计调用次数这个动作本身，也会让你的实际工作轮廓可视化。你会发现没在用的MCP比想象中多得多。

问题2：同样的目的能用其他工具代替吗？

Cloudflare KV MCP很方便，但对我的业务来说，curl和wrangler命令完全够用。如果Shell脚本或内置Bash可以替代，跳过MCP就能节省上下文。

关键筛选标准：只保留”非MCP绝对无法做到”的操作。有用但非必要的工具可以去掉。

问题3：调用频率是否值得工具描述的token消耗？

像Stripe MCP这样描述文字较长的工具，如果一个月只调用十次以内，每次的上下文成本就不划算——切换到”需要时打开文档”的操作方式，长期来看上下文会更轻。

按顺序走这三个问题：问题1给出明确的删除对象；问题2和3用来处理灰色地带。

30分钟时间分配：

• 10分钟：从配置文件中提取当前MCP列表，写出来
• 10分钟：用3个问题筛选删除候选，确定删除清单
• 5分钟：从配置文件中删除对应条目，重启Claude Code
• 5分钟：用日常3～5个任务确认是否正常运行

含缓冲，30分钟内完成。周末早上一杯咖啡的时间。

在我之前的vibe coding工具选择：原型和生产阶段的不同标准中，整理了工具选择的思考框架。MCP整理同样遵循”只保留每天在生产中使用的那一个”的原则。

不能踩的3个反模式

从15个削减到5个过程中，我遇到的3个反模式。提前了解，能让你省下三个小时。

反模式1：“试试看”地安装每个新MCP

不加跟进地”随手试装”，半年内就会超过20个。我涨到15个，就是这个原因。

试用本身没问题。试完就忘才是问题。要试的话，就设一个”下周末前做出是否正式采用的决定”的截止日期，把删除日期记进日历。

反模式2：一个一个慢慢删

“多一个应该无害”——关于MCP，这个判断是错的，它们会叠加生效。一次只删一个，感受不到改善效果。

我的经验：一次删5个，效果才能明显感知。看到明确的改善，才能维持继续精简的动力。

反模式3：在多个LLM中复用同一套MCP

在Claude Code、Codex、Cursor中共用同一套MCP，会忽视每个工具各自的强项。Claude Code擅长处理结构化工具定义，Cursor擅长文件操作。共用配置会抹掉这种差异。

我现在的分工：Claude Code配”设计和实现类MCP”，Cursor配”文件操作和重构类MCP”。只这一项调整，两者的响应质量都提升了。

Nagi的文章Claude Code 8种用途：面向非工程师的实例整理了Claude Code的用途地图。一旦明确”自己用Claude Code来做什么”，所需的MCP自然也就收窄了。

总结：MCP的本质是”设计”，不是”数量”

“先把东西跑起来”依然是我的根本信念。在MCP上，我追加了一条：“先把东西删掉”。

作为一个曾经碰壁的工程师来说：在代码设计的世界里，把所有”可能有用”的东西都加进去，最终会让项目无法维护。MCP有着同样结构的陷阱。区别在于，MCP的失败方式不是”运行不起来”，而是”悄悄变笨”——这种静默的性能退化。

三行总结：

• MCP是设计工具，不是功能堆砌器。精选的5个往往胜过15个。
• 微软揭示的3个下降机制（上下文压缩、语义冲突、错误工具选择）可以在自己的环境中验证复现。
• 这个周末的30分钟3问审查，会让Claude Code悄悄变快。请自己测量重启后的响应时间。

删减MCP不是”放弃功能”，而是”让Claude Code专注”的设计行为。这样理解之后，削减的心理门槛就低多了。让AI困惑的选项，正是由我们来配置的。

削减到5个之后，我感觉找回了自己的手感。15个MCP时代的Claude Code，被一堆”可能有用”的工具填满，判断轮廓变得模糊。清空的那一刻，AI的响应重新贴合了我的工作。

这个周末，请你也试试。30分钟的整理，会静静地提升下一周的开发体验。