MCP协议一周年：从爆红到遇冷的深度剖析

在11月25日，Anthropic通过官方博客发布了一篇庆祝文章，宣告MCP（模型上下文协议）迎来一周年纪念，同时推出了更新版规范。

官方数据显示，MCP Registry目前已收录近2000个Server，相比9月份上线初期增长了407%。OpenAI在3月份宣布全面支持MCP，Google、AWS、HuggingFace等科技巨头也计划接入，从表面看，这似乎是一个被行业广泛接纳的开放标准。

然而，这条周年庆消息在社交媒体上几乎未引发波澜，讨论寥寥无几。

回顾一年前，MCP横空出世时曾震撼硅谷。"AI界的USB-C"、"Agent时代的基础设施"、"我们有救了"等激动人心的口号，如今听起来已如隔世。

更引人深思的是，Anthropic自身似乎在悄然"去MCP化"。打开最新版Claude，一套名为Skills的系统正逐步接管更多任务。生成PPT？依赖Skill。处理Excel？同样靠Skill。这个曾被寄予厚望的通用协议，为何会陷入如此境地？

1

MCP 为什么出道即巅峰

2024年MCP发布时引发巨大轰动，因为它精准命中了当时AI应用开发的核心痛点：开发者必须重复构建相似功能。

在MCP出现前，开发者若想让Claude访问Google Drive，需编写一套API代码；访问Slack则需另一套。对于IDE厂商而言，情况更糟：Cursor需适配Linear，Windsurf也需适配Linear，每家都在进行几乎相同的繁琐工作。

MCP承诺一次开发、处处运行。例如，只要Linear官方开发一个MCP Server，无论是Claude、Cursor还是未来的任何AI Agent，均可直接使用。

那时GitHub上的MCP项目如雨后春笋般涌现：查询天气、查看股票、发布社交媒体内容等。开发者沉浸在"将世界数据馈送给AI"的狂欢中，普遍认为当大模型接入无数MCP后，将获得无所不能的能力。

然而，实际工程落地给所有人泼了一盆冷水。

2

致命弱点：MCP 越多、AI 越蠢、越花钱

MCP最显著的问题是，其调用方式必须占用上下文窗口。

MCP要求所有工具定义、调用请求和返回结果都必须经过模型的上下文窗口，因为模型需要"看到"这些信息才能进行决策和推理。而且这一过程是累积的——每次MCP调用都会增加token消耗，多次调用后上下文迅速膨胀。

Django联合创始人Simon Willison在博客中指出，仅GitHub官方的MCP就定义了93个工具，消耗55000个Token。如果按照某些教程建议挂载20个MCP Server，几轮对话后上下文就会溢出。

Anthropic也承认了这个问题。他们在博客中写道，当Agent需要读取一份两小时会议的文档时，可能需额外处理50000个Token，更大文档甚至会直接超出上下文窗口限制，导致整个工作流崩溃。

Claude的Token成本众所周知，加载过多MCP后，可能尚未生成内容，费用就已显著增加。

更严重的是，当安装过多MCP时，模型开始出现错误。

有开发者利用MCP构建了一个简单计算器，结果模型调用减法工具后，尽管服务器返回-9，它却自行报告+9，未信任工具返回值，而是用自己的常识覆盖了结果。

此类问题在工具较少时几乎不会发生，但当上下文被各种工具定义填满后，模型的注意力被稀释，开始进行胡乱推理。

如果说结果错误仅浪费资源，那么设计不安全的MCP可能导致不可逆的损害。有人挂载了文件系统MCP，AI产生幻觉，删除了不该删除的代码库。

早期MCP的权限设计过于粗放，挂载一个文件系统往往意味着AI能读写整个磁盘。几次事故后，大公司的安全部门迅速介入，建立白名单的成本比传统API更高。

MCP过多会导致模型智商下降，安装过少则限制模型能力，这一悖论至今无解。

3

双刃剑：门槛低了，但也太低了

MCP的另一个问题是门槛过低。

构建一个MCP Server极其简单，几十行代码即可运行，导致人人参与。这引发了大量重复和低质量的实现。十个天气查询MCP中，可能九个半都是换皮复制，真正设计精良、维护活跃的屈指可数。

有研究论文分析了近1900个MCP Server，发现大量存在凭证暴露、缺乏维护等问题。生态表面繁荣，实则泡沫居多。

开发者面对琳琅满目的选择，反而需花费更多时间甄别哪个可用、哪个可靠，筛选成本甚至超过自己编写一个。

4

Skills 上位，官方的隐性认错

另一方面，如果MCP真的如此完美，为何Anthropic自身都在"去MCP化"？

打开最新官方文档，Skills被置于核心位置，而MCP越来越像是一个不得不保留的兼容层。潜台词很明确：不要再盲目推崇那个通用MCP了，回归定制化开发吧。

Skill的本质是对MCP的一次纠正，有人称之为给MCP擦屁股。它不再试图让模型实时理解外部世界，而是将高频、经过验证的能力封装成精简预设。对于编程、绘图、网页浏览等核心能力，原生集成永远比通过通用协议更快速、稳定且节省Token。

Anthropic最近发布的技术博客也间接承认了MCP的设计缺陷。他们提出新思路：让Agent编写代码来调用MCP，而非直接暴露工具定义。据称这种方式能减少98.7%的Token消耗，这难道不是在暗示MCP原有用法存在错误吗？

那个试图用一套协议统一世界的宏大叙事，正悄然瓦解。

5

MCP、Skill，都只是过渡

当我们跳出协议细节，从更长时间轴观察，会发现一个更深刻的事实。

无论是试图用JSON标准化世界的MCP，还是用预设封装能力的Skills，抑或是我们每日精心编写的Prompt，本质上都是同一类事物：补丁。

它们是我们为弥补当前AI智力不足而不得不实施的临时措施。

因为现有AI还不够聪明，无法即兴发挥。所以我们需要MCP告知它这是数据接口，需要Skill告知它这是标准流程，需要Prompt告知它这是注意事项。

我们正用确定性的工程方法，试图驾驭一个概率性的智能体。

想象真正强大的ASI（人工超级智能）出现的那一天。它还需要你编写MCP Server来告知如何查询天气吗？不，它会自行打开浏览器查看。它不需要协议，因为它本身就是适配器。

MCP彻底失效了吗？或许并未完全凉透。Anthropic在路线图中仍在推进远程连接、OAuth认证、企业级部署等功能，IBM也宣布将向MCP社区贡献企业级资产。它只是从网红状态回归基础设施角色。高频能力归Skills，长尾数据归MCP，这可能是其最终的生态定位。

不再盲目地为AI堆砌工具，而是开始思考哪些接口真正关键，这或许是MCP带来的最大启示。