MCP已死，MCP万岁

梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

现在浏览任何AI开发者论坛，你都会看到同样的判决，像悼词一样充满信心地重复：MCP已死。

太复杂。太有状态。太容易崩溃。给开发者一个REST API让他们回家就好。

它开始于2026年2月下旬，当时基础设施工程师Eric Holmes发布了一篇标题像麦克风落地般震撼的文章："MCP已死。CLI万岁。" 他的论点不是工具调用毫无意义，而是对于人类和智能体与系统对话来说，普通的命令行接口通常比专门构建的协议层更可靠、更可组合。 几天后，投资者Garry Tan在X上称MCP为"垃圾"。大约在同一时间，有消息称Perplexity的CTO正在悄悄地将工作流从MCP转移到传统API，据称是因为模型上下文窗口的70%在任何实际任务开始之前就被工具定义吞噬了。

如果你过去一年一直在埋头构建MCP服务器，那么你在2026年3月的时间线看起来就像一场葬礼。

And yet.

1、身体仍在前行

这是"MCP已死"帖子往往会跳过的不便细节：在所有人撰写讣告的同一时期，该协议的使用量一直在攀升。 到2026年中期，Anthropic自己的维护者报告称，Tier 1 SDK的月下载量接近5亿次，TypeScript 和 Python SDK 的总下载量加起来都超过 10 亿次。谷歌云提供了完全托管的远程 MCP 服务器。JetBrains、Cursor、Windsurf、SourceGraph 和 Replit 都内置了 MCP 支持。Anthropic 的直接竞争对手 OpenAI 和 Google DeepMind 采用了相同的协议，而不是自行开发。

这不是一个已死标准的样子。当一个标准不再是一个演示，而开始成为基础设施时，它就是这样的——如果你曾经观察过基础设施的采用过程，就会知道这正是抱怨声最大的时候。 没有人会为一个玩具写愤怒的博客文章。人们会为他们现在不得不依赖的东西写愤怒的博客文章。

2、真正坏掉的是什么

然而，这种强烈反对并非凭空而来。MCP确实遇到了真正的生产壁垒。

核心投诉，按其实际重要性排序：

• 上下文膨胀。 你加载的每个工具定义在模型执行任何工作之前都会消耗令牌。对于同时处理十几个连接服务器的智能体来说，这种开销变得无法忽视。
• 有状态性。 原始协议携带大量会话和连接状态，这对于运行单个本地服务器的笔记本电脑来说没问题，但对于任何试图在负载均衡器后面大规模运行MCP的人来说都是痛苦的。
• 安全漏洞。 2026年4月，研究人员披露了一个设计弱点，该弱点可能允许在易受攻击的MCP实现上执行任意命令，这种标题会让任何安全团队对"只需安装这个社区服务器"感到紧张。
• 没有真正的注册表。 与npm或PyPI不同，没有一个中心化的、经过验证的地方来查找MCP服务器。你用谷歌搜索，你检查GitHub星标，你靠运气。对于个人修补者来说，这是一种不便。对于企业采购流程来说，这是致命的。
• CLI羡慕。 对于已有稳定命令行工具的工作流，MCP的抽象层有时增加了摩擦而不是消除它，这是Holmes最初的论点，也是公平的。

注意这个列表中缺少什么："没人用它"和"这个想法是错的"。这些投诉几乎完全是关于实现的成熟度，而不是关于标准化AI模型工具访问是否值得做。

3、维护者听到了

对"MCP已死"浪潮最有说服力的回应不是来自热点博客，而是来自协议自己的维护者，它于2026年7月28日发布。

2026-07-28规范按照维护者自己的描述，是自协议添加授权以来最重大的重写。 标题变化：MCP现在在协议层无状态。 不再需要会话跟踪。 六个独立的提案共同实现了这一点，包括基于头部的路由，以便负载均衡器可以在不检查正文的情况下路由请求，以及基于标准HTTP缓存的可缓存列表结果。 Tasks功能——更尴尬的有状态遗留功能之一——被完全移出核心规范，进入可选扩展。 授权得到了加强。添加了正式的扩展框架，以便MCP Apps等功能可以按照自己的发布计划发展，而不是拖着整个规范一起走。

In plain terms: the maintainers took the exact complaints from the "MCP is dead" spring-state fulness, scaling friction, bloat-and rebuilt the protocol's foundation around fixing them. 这不是一个垂死项目的行为。这是一个项目经历不光彩、不性感的成长工作的行为。

4、同一个标题下的两种不同对话

这是值得注意的模式：最响亮的"MCP已死"声音几乎完全来自个人开发者和小团队——那些优化个人生产力、在笔记本电脑上运行几个本地服务器的人，他们直接而立即地感受到每一点摩擦。 "MCP正在蓬勃发展"的信号完全来自不同的人群：平台团队、企业供应商，以及负责大规模认证、治理和审计跟踪的人——那些不光彩的东西不会出现在病毒式帖子中，但绝对会出现在采购决策中。

这两个群体正在进行两种不同的对话，却称之为同一个协议。 一组想要一个轻量级的约定来将工具粘合在一起，结果在一段时间内得到了比他们预期更多的仪式。 The other group wanted exactly the ceremony the identity model, the observability, the governance-and finally started getting it in July.

5、那么它死了吗？

不。2026年初死去的是一种特定的幻觉：MCP将是一种无摩擦、零成本的方式，可以将任何工具附加到任何模型上，而没有任何工程权衡。 这种幻觉赢得了它的葬礼。其下的协议并没有。

实际发生的是最不可能点击的结果：一个标准正在经历正常、无聊、伤痕累累的生产加固过程。 强烈反对不是故事的结局。它是产生下一个版本的输入。

如果你正在构建的东西真正需要稳定的CLI而不是协议，Eric Holmes是对的，使用CLI。 如果你正在构建需要跨公司扩展的智能体基础设施，并附带认证、审计跟踪和治理，那么2026年7月的规范可以说是第一个专门为你们构建的MCP版本。

这两个事实都不能像"MCP已死"那样成为好标题。但其中只有一个是正确的。

6、更大的教训

我们以前见过这种模式。每项新技术最初看起来都可能成为抽象层。

Then the ecosystem grows. New requirements appear. Different layers emerge. Specialized protocols develop.

最终，原始技术成为更大架构中的一个组件。

这就是MCP的走向。不一定是走向灭绝。而是走向正常化。老实说，这是一个更大的成就。

Because the ultimate sign that infrastructure has won isn't that developers talk about it constantly.

It's that they stop noticing it.

So yes:

MCP is "dead."

但不是标题所暗示的方式。MCP炒作周期可能正在消亡。MCP协议正在成为基础设施。下一场战斗不是关于替换MCP。

而是关于定义其上方、下方和旁边的一切。

原文链接：MCP Is Dead. Long Live MCP.

汇智网翻译整理，转载请标明出处