MCP 真的“死”了吗？从 Perplexity 弃用到开发者应对策略

我前几天刚掌握 MCP（Model Context Protocol）的应用，正打算在项目里试试手，结果这两天就在社区里刷到一堆 “MCP is dead” 的帖子。

真是让人有点哭笑不得。我还没来得及大展拳脚，它就要“凉”了？

这不是我一个人的错觉。2026年3月中旬，整个 AI 社区突然炸锅，有三条高热度帖子直接把 MCP 钉上了“短命鬼”的标签。下面我就把这波“死讯”的来龙去脉串起来讲讲，也说说我们这些追赶技术潮流的 开发者 该怎么办。

1. 源头：Perplexity CTO 内部表态（morganlinton 爆料）

Morgan（@morganlinton）贴出了一张据称是 Perplexity 内部会议的截图，其中联合创始人兼 CTO Denis Yarats 明确表示：

“我们正在放弃 MCP，转而直接用 APIs 和 CLIs”。

Perplexity 是目前 AI 搜索领域最顶尖的产品之一，它的决定瞬间被解读为“行业风向标”。Morgan 配的那个“看戏”表情（👀）更是把氛围感拉满。

2. 跟进：DuetChat 彻底删除 MCP（dzhng 的长文）

DuetChat 的创始人 David（@dzhng）更直接，发表了一篇长文，标题就叫“我们 v2 版把 MCP 整个功能删了”。

他总结的理由非常扎心：

• MCP 会把几十个工具的 schema 一股脑全部塞进上下文窗口，导致上下文大小呈 O(n) 线性膨胀。
• AI 现在足够聪明，它可以自己阅读 API 文档、自己写集成代码、自己保存复用，完全不再需要预定义的工具包装。
• 未来属于 代码执行 + 持久化服务器 ：上下文占用 O(1) 恒定，能力全覆盖，还能自我进化。

David 甚至画了清晰的对比表：MCP 像“预制菜”，而代码执行是“现炒现卖”。他们把 OAuth、动态注册等功能全删了，换成让 Agent 自己写代码来完成集成。

PS： 原文已翻译，需要查看戳这里：为何我们移除了 MCP 集成——以及我们所构建的新方案

3. 高潮：levelsio 直接“开香槟”

知名独立开发者 levelsio 转发了 Morgan 的帖子，标题就一句话：

“Thank god MCP is dead”

他把 MCP 和之前的 llms.txt 协议并列，称两者都是“dumb abstractions”（愚蠢的抽象层）。他认为现在的 AI 聪明得接近人类，直接用现成的 API 和 CLI 就行，不再需要中间商赚差价。

谁是 levelsio？
简单说，他是独立开发者圈的传奇人物，真名 Pieter Levels。他几乎单枪匹马做出了 Nomad List、Remote OK、Photo AI 等多个成功产品，年收入达数百万美元，是“自力更生创业”的典范。他的 X 账号有超过 50 万粉丝，发言风格直白、犀利，因此这条“感谢上帝 MCP 死了”的推文瞬间将社区情绪推向了顶点。

回复区立刻分裂为两派：

• 一派欢呼：“终于死了！”
• 一派反驳：“Perplexity 说不用就不用？Chrome 和微软还在把 WebMCP 往浏览器里塞呢！”

我这个“刚学会 MCP”的开发者，现在是什么心情？

说实话，有点尴尬，又有点释然。

尴尬在于：我昨天还在照着 Laravel 官方文档写 Mcp::web() 和 Mcp::local()，今天就看到行业大厂在抛弃它。感觉就像刚学会 Vue 2，第二天就被告知 Options API 要被全面废弃。

但冷静下来想想，这波“死讯”其实暴露了 AI 代理时代一个残酷的真相：

1. 上下文就是命脉
   MCP 的本质是“把工具字典塞进提示词”。当 Agent 已经聪明到能自己写代码时，这份预装的字典就成了累赘。DuetChat 提出的 O(n) 与 O(1) 对比非常现实。

2. AI 已进化到“自己写集成”
   这就像过去开发者手写 API 文档一样，而现在 AI 可以自己阅读 OpenAPI 规范、编写调用代码、并保存以供复用。MCP 某种程度上成了一个“多余”的中间层。

3. 但它真的彻底死了吗？
   我认为并没有。

   • 在企业内部或受严格监管的场景（金融、医疗），标准化的工具发现、认证和双向通信流可能仍是刚需。
   • Chrome 和微软正在将 WebMCP 推进浏览器标准。
   • 应用内集成 MCP 仍有一个独特优势：它能与你的应用代码和内部业务逻辑深度融合，让 AI 真正“执行”而不仅仅是“读取”数据。

给刚接触 MCP 的开发者三个建议

1. 别慌，先别急着删
   MCP 目前仍然是接入 Claude Code、Cursor、Windsurf 等工具相对优雅的方式。可以继续使用它，但不要把全部希望都押注在上面。

2. 考虑双轨并行策略

   • 保留 MCP 作为“工具发现层”和简单工具的接口。
   • 同时增设一个“代码执行服务器”（像 DuetChat 那样），让更复杂的集成任务由 Agent 自行编写代码完成。MCP + CLI + 持久化沙箱，三者结合或许才是更稳健的方案。

3. 把 MCP 当作一个学习跳板
   学习并应用 MCP 的过程，本质上是在学习“如何将应用的能力安全、有效地暴露给 AI”。这些知识在未来 Agent 更强大时，可以直接转化为“如何让 AI 自行编写集成”的提示词工程。学了绝对不亏。

写在最后

MCP 或许正在成为技术浪潮中又一个“短命”的尝试，但这未必是它的错，而是 AI 自身的进化速度实在太快。

我们这些开发者，似乎永远在追赶时代的脚步——今天刚掌握的工具，明天可能就面临革新。

不过，也别太沮丧。
真正厉害的能力，不是死守某个特定的协议或框架，而是快速学习和适应变化的能力。就像那句老话：“ship or die”。

所以，MCP “死”了？
那就让它“死”吧。
我们收拾心情，继续学习下一个更强大的东西。技术演进本身就是一场接力赛，重要的是我们一直在赛道上。如果你对这类技术趋势和实战心得感兴趣，欢迎来 云栈社区 一起讨论。

延伸阅读：

• 为何我们移除了 MCP 集成——以及我们所构建的新方案
• Laravel MCP：隐藏的 AI 入口点，解锁 Laravel 应用的更多潜力