MCP一周年：从万众期待到隐忧浮现，Skills上位揭示AI工具协议的困境

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？再写一套API。对于IDE厂商更惨，Cursor要适配Linear，Windsurf也要适配Linear，每家都在做几乎一模一样的脏活累活。

MCP的承诺是一次开发、处处运行。比如，只要Linear官方写好一个MCP Server，无论是Claude、Cursor还是任何未来的AI Agent，插上就能用。那时候GitHub上的MCP项目如雨后春笋：查天气的、看股票的、发小红书的。开发者们沉浸在"把世界喂给AI"的狂欢中，人人都以为当大模型接入无数MCP后，将获得无所不能的能力。

然而，真实的工程落地很快给所有人泼了一盆冷水。理想很丰满，现实却很骨感，MCP在实际应用中暴露出诸多致命弱点。

2

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

MCP最大的问题在于，其调用方式需要占用上下文窗口。MCP要求所有工具定义、调用请求和返回结果都必须经过模型的上下文窗口，因为模型需要"看到"这些信息才能决策和推理。而且这个过程是累加的，MCP每一轮调用都在累加token，多次调用后上下文迅速膨胀。

Django联合创造者之一的Simon Willison在博客中写道，光是GitHub官方的MCP就定义了93个工具，消耗55000个Token。如果你像一些教程建议的那样挂载20个MCP Server，几轮对话后上下文就爆了。Anthropic自己也承认了这个问题。他们在博客里写道，当Agent需要读取一份两小时会议的文档时，可能要额外处理50000个Token，更大的文档甚至会直接超出上下文窗口限制，整个工作流直接崩溃。

Claude的Tokens价格昂贵众所周知，加载太多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被摆到了C位，而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最大的贡献。