一周年即遇冷：MCP的兴衰与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，则需再开发一套。对于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多则模型智商下降，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最大的贡献。
本文来自微信公众号“硅星人Pro”，作者：董道力，36氪经授权发布。
本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。
免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com