曾被誉为“AI界USB-C”的MCP协议，一年内从万众瞩目到无人问津。问题不在愿景，而在现实：工具越多，模型越蠢；上下文膨胀，成本飙升。当Anthropic自己转向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。曾经被寄予厚望的万能协议，怎么就沦落到这步田地？
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 最大的问题是，其调用方式是要占用上下文的。
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 多，模型智商下跌，装的少，模型能力变少，这个悖论至今无解。
MCP 的另一个问题是门槛太低。
搭建一个 MCP Server 实在太简单了，几十行代码就能跑起来，于是人人都在做。这就导致了大量重复和低质量的轮子。十个天气查询 MCP，可能九个半都是换皮复制，真正设计精良、维护活跃的屈指可数。
有论文研究了在近 1900 个 MCP Server 中，大量存在凭证暴露、缺乏维护等问题。生态看似繁荣，实则泡沫居多。
开发者面对琳琅满目的选项，反而要花更多时间甄别哪个能用、哪个靠谱，筛选成本甚至高过了自己写一个。
从另一方来说，如果 MCP 真那么完美，为什么 Anthropic 自己都在“去 MCP 化”？
打开最新的官方文档，Skills 被摆到了 C 位，而 MCP 越来越像是一个不得不保留的兼容层。潜台词很明确：别再迷信那个通用的 MCP 了，回来做定制化吧。
Skill 的本质是对 MCP 的一次拨乱反正，也有人说这是给 MCP 擦屁股。它不再试图让模型实时去理解外部世界，而是把高频的、经过验证的能力封装成精简的预设。对于编程、绘图、网页浏览这些核心能力，原生集成永远比走通用协议更快、更稳、更省 Token。
Anthropic 最近发布的技术博客也在变相承认 MCP 的设计缺陷。他们提出了一个新思路：让 Agent 写代码去调用 MCP，而不是直接暴露工具定义。据称这种方式能减少 98.7%的 Token 消耗，这不就是在说 MCP 原来的用法是错的吗？
那个试图用一套协议统一世界的宏大叙事，正在悄悄破产。
当我们跳出协议的细节，站在更长的时间轴上看，会发现一个更有意思的事实。
无论是试图用 JSON 标准化世界的 MCP，还是试图用预设封装能力的 Skills，亦或是我们每天绞尽脑汁编写的那些 Prompt，本质上都是同一类东西：补丁。
它们是我们为了弥补当前 AI 智力不足而不得不打的补丁。
因为现在的 AI 还不够聪明，不懂得即兴发挥。所以我们需要 MCP 告诉它这是数据接口，需要 Skill 告诉它这是标准流程，需要 Prompt 告诉它这是注意事项。
我们在用确定性的工程手段，去试图驾驭一个概率性的智能体。
想象一下真正强大的 ASI 出现的那一天。它还需要你写一个 MCP Server 告诉它怎么查天气吗？不，它会自己打开浏览器看一眼。它不需要协议，因为它本身就是适配器。
MCP 凉了吗？或许没有彻底凉透。Anthropic 在路线图里还在推进远程连接、OAuth 认证、企业级部署等功能，IBM 也宣布会向 MCP 社区贡献企业级资产。它只是从网红跌落回了基建。高频能力归 Skills，长尾数据归 MCP，这大概就是它最终的生态位。
不再盲目地给 AI 堆工具了，而是开始思考，究竟哪几个接口才是真正重要的，可能是 MCP 最大的贡献。
作者｜董道力
本文由人人都是产品经理作者【硅星人】，微信公众号：【硅星人Pro】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。