MCP 没有死，只是你用错了

软件工程领域每隔几个月，就会选出一项技术来「厚葬」。2026 年初，轮到 Model Context Protocol（MCP）了。Perplexity 的 CTO 说它撑爆了上下文窗口，Cloudflare 转向代码生成，一波大 V 帖子把 MCP 定性为失败的实验。这套剧本我们再熟悉不过：一个有用的协议被炒热，吸引来一堆糟糕的实现，然后协议本身背锅。所以先说明白——「MCP 已死」不是技术结论，是一种 vibe。

批评是真实的，结论是错的

批评者们指出的确实是真问题，但锅甩得太宽了。上下文膨胀是真的——一个设计糟糕的 GitHub MCP 服务器能带上 93 个工具定义，在用户开口之前就吃掉约 55,000 个 token。再加上 Jira、数据库连接器、Confluence，光是 schema 就能突破 15 万 token。这不是抽象概念，而是直接啃掉 Agent 推理预算的设计失误。

Cloudflare 的数据把这个道理讲得更狠：把 2500 个 API endpoint 暴露成 MCP 工具，光是描述它们就需要约 24.4 万 token。而他们的替代方案——让已经授权的客户端直接做代码生成——干同样的活只要大约 1000 个 token。Perplexity 的批评也站得住脚：如果工具 schema 在用户输入还没进来之前就吃掉 72% 的上下文窗口，那架构确实是崩的。

但这些都不能证明 MCP 死了。它们证明的是：把所有可能的工具无脑丢进一个扁平的 MCP 服务器，然后管它叫 Agent 架构，这是偷懒的工程。问题不在 MCP，而在使用它时完全不考虑上下文成本。

Adoption 曲线讲的完全是另一个故事

如果 MCP 真的在死，adoption 曲线绝不会长这样。相反，整个生态在高速增长：MCP 服务器的下载量从 2024 年 11 月的大约 10 万次，飙到 2025 年 4 月的 800 多万次。Anthropic 官方 Python 和 TypeScript SDK 的月下载量达到 9700 万，到 2026 年初已有超过 1 万个公开的 MCP 服务器被部署。这些不是一个被抛弃的协议该有的数字，而是一个正在扩大使用范围的协议该有的数字。

厂商格局也指向同一个方向。OpenAI、Google、Microsoft、AWS 都以某种形式接入了 MCP——尽管他们明明有充足的理由去忽视一个弱势标准。2025 年 12 月，Anthropic 把 MCP 捐赠给了 Linux Foundation 的 Agentic AI Foundation，让它变成厂商中立、社区治理的协议。Gartner 预测到 2026 年，75% 的 API 网关厂商和 50% 的 iPaaS 厂商会原生支持 MCP 功能，这更让案子变得扎实。

「MCP 已死」的叙事，和真实的 MCP 生态，描述的压根不是同一个现实。前者是在对糟糕的实现做出反应，后者是在描述一个标准如何变成基础设施。

MCP 拼的不是效率，是控制力

大部分争论混淆了一个关键区别：CLI 在效率上赢 MCP，但 MCP 在治理上赢 CLI。 这两者不是非此即彼，它们回答的是不同的问题。

如果 Agent 已经知道该调用什么，而且是直接代表你行动，那基于 CLI 的工具调用往往更快、更便宜、也更容易调试。对于在 Cursor 或类似环境里跑本地工具的独立开发者来说，CLI 通常是更好的选择。在这种场景下，MCP 增加的 overhead 并不足以抵消它的价值。

类似的混淆也出现在人们拿 MCP 和 skills 做比较的时候。它们不是替代关系。Skills 把可复用的行为、指令和工作流封装在模型层内，帮助 Agent 更一致地知道该做什么、怎么做。MCP 解决的是另一个问题：它把模型连到外部系统，附带权限控制、可审计性和清晰的工具边界。Skills 能让 Agent 更聪明，MCP 则让 Agent 能安全地操作真实系统。

一旦 Agent 不再只代表你个人，而是开始代表其他人行动，等式就变了——这就是企业场景的起点。MCP 能提供按用户的 OAuth、显式的工具边界、结构化的审计追踪，以及受监管环境在让 Agent 触碰生产数据之前所需要的治理平面。一个 CLI wrapper 给不了你这些。自定义集成层也许能给，但前提是你得把 MCP 正在尝试标准化的那套治理机制重新造一遍。

这是典型的 hype cycle 误判

MCP 正在经历的事并不稀奇。每次一个新标准公开走向成熟时，都会出现同样的剧本。

GraphQL 出来的时候，REST 据说要死了；tRPC 火了以后，GraphQL 又被说太臃肿；Kubernetes 也曾被认为除了 Google 那种体量根本玩不转，直到它变成标准基础设施。

剧本几乎没变过：标准出现，人们做出幼稚的实现，这些实现暴露出真实问题，批评者把问题错当成标准本身的问题，而标准照样在压力下走向成熟。

MCP 现在就在这个阶段。糟糕的实现被拎出来批，这没错。但批评幼稚的实现，不等于协议本身失败了。事实上，情况似乎正好相反。2026 版 MCP 规范增加了异步操作、无状态改进和服务器身份特性，直指批评者们发现的生产环境缺口。

这不是一个死了的标准会做的事。这是一个正在被压测、被打磨、被推向生产环境的标准会做的事。

解药是更好的架构，不是抛弃

如果你正在用 MCP 搭建东西，且遇到了批评者描述的那些问题，答案不是把协议扔掉，而是更仔细地设计。每个工具都花 token，所以服务器的暴露面必须被当作架构决策来对待，而不是图省事。

真正的问题不是「MCP 能暴露什么？」，而是「这个 Agent 到底需要什么？」更小、更紧的工具面通常表现更好，因为它们保留了推理预算，也减少了歧义。

同样的原则也适用于系统层面。你得给活儿配对的工具。对于本地、单人、对延迟敏感的 workflow，CLI 通常更赢；对于多用户、强治理、重审计的系统，MCP 更说得通。无论哪种情况，上下文预算都得像其他任何架构约束一样被认真对待。

Harness MCP v2 的例子很好地说明了「协议失败」和「实现成熟」之间的区别。他们的第一版暴露了 130 多个工具，造成了严重的上下文膨胀；重新设计后砍到 11 个，工具定义成本从 20 万 token 窗口的大约 26% 降到了 1.6%。协议没有失败，实现变聪明了。这才是成熟的样子。

MCP 没有死，它才刚刚开始被认真对待

MCP 没有死。它进入了 post-hype 阶段——对任何技术来说，这都是更健康的阶段。Post-hype 意味着一个工具不再因为「新」而被加分，开始被真正检验它到底有没有用。这是一个更难的考试，但也是唯一重要的考试。

按这个标准，MCP 在真正重要的地方撑住了：生产环境、大规模场景、以及 Agent 最可能发挥作用的企业环境里。

很多喊 MCP 已死的人，不过是在对幼稚的实现撞上可预见的墙做出反应，然后得出了错误的结论。与此同时，那些在不声不响地把 MCP 部署到受治理、范围清晰、多用户的系统里的团队，发现了一件没那么戏剧性、却更重要的事：当协议被认真设计和部署时，它是能用的。

糟糕的实现不会否定好的协议。它们只是暴露出工程上还需要努力的地方。这不是悼词，这是一个 build problem，而 build problem 最终会被解决。