硅谷大佬炮轰MCP：简直烂透了

“MCP 烂透了！”

过去一年，MCP 被吹捧为 AI 时代的 TCP/IP，承诺一键连接所有工具。但到了 2026 年，一线的产品开发者发现，这个“万能接头”不仅重，而且贵。

近日，Perplexity 联合创始人 Denis Yarats 和 YC 总裁 Garry Tan 带头开喷 MCP，并倡导回归 API 和 CLI，再次引起了人们对于 MCP 的热议。

不得不感叹 AI 领域的发展速度，MCP 出圈了刚刚一年，这祛魅周期愈发地变短了！

那么，MCP 到底怎么了？真的如某些网友所说的“已死”了吗？

硅谷两位大佬开怼 MCP

一切都源于一场 Perpelxity 的内部会议。

3 月 12 日，Perplexity 的联合创始人兼首席技术官 Denis Yarats 在内部表示，他们正在放弃 MCP，回归 API 和命令行界面 (CLI)。

与此同时，Perplexity 发布了一个全栈式、与模型无关的 API 平台，该平台在一个软件包中取代了模型提供商、搜索层和嵌入层。公司的立场很明确：API 是底层架构，而不是 MCP 服务器。

随后，YC 总裁 Garry Tan 的批评更加直白。

“说实话，MCP糟透了，”他发帖说道，并列举了上下文窗口臃肿、身份验证笨拙以及需要手动开关服务器等问题。

他对 Claude 基于 MCP 的浏览器集成感到非常失望，甚至自己编写了一个命令行包装器，结果发现只用了 30 分钟，而且效果要好 100 倍，代码只有 100 行！

拆除 MCP ，替换 md 文件！

除了这两位，其实更早也有不少创业者和风投人士，也指出过“MCP的弊端”，甚至高呼：MCP 安息吧！Skills 永存！

1 月，Sentry 公司的 David Cramer（他搭建了 Sentry 自己的 MCP 服务器）直言不讳地指出，“许多 MCP 服务器根本没有存在的必要”，因为它们要么是糟糕的 API 封装，要么可以用 Skills 文件替代。

无独有偶，开源系统 CompanyOS 的创始人 Brad Feld 同样也在用实际行动，打脸 MCP。CompanyOS 的虽然在设计上连接了 8 个 MCP 服务器，用以访问 Gmail、Linear、Help Scout 等服务的 API。

但 Brad 表示，其实系统真正的“灵魂”在于那些重回流行巅峰的 Markdown 文件。每个 Skill 文件都编码了工作流、护航规则、语气校准以及决策逻辑。

而 MCP 服务器作用则明显有些“鸡肋”了：即使 MCP 断开连接，这些 Skills 依然有效，你只需将自动发送改为手动复制粘贴即可。

为什么AI产品正在“叛逃”MCP？

MCP 的初衷是伟大的：通过标准化的服务器，让 Agent 能够理解任何第三方工具。但这种“标准化”是有代价的。

问题的核心在于“上下文肥胖症”。在 MCP 的工作流中，Agent 为了理解如何使用一个复杂的工具（比如 GitHub），必须先读取大量的协议定义。这就像你每次进餐前都要通读一遍《食品安全法》和《餐具使用规范》。

网上有一个非常流行的对比例子：《Markdown 是新的 API》。

其中记录了所记录的真相：为了教会 Agent 如何与 GitHub 交互，GitHub MCP 服务器消耗了约 50,000 个 Token 的上下文（即便后来削减到了 23,000 个）；而一个写着“使用 gh 命令行工具进行操作”的 SKILL.md 文件，仅用 200 个 Token 就达到了同样的效果。

某种变革正在发生。开发者们正在拆除 MCP 服务器并将其替换为 Markdown 文件。

这并非因为 MCP 坏了，而是因为许多 MCP 服务器从一开始就是为了解决错误的问题而设计的。

MCP 模式： 消耗 50,000 Tokens 来构建交互环境。

API/Skill 模式： 消耗 200 Tokens 直接发送指令。

在长上下文模型依然昂贵的 2026 年，这种 250 倍的差距直接决定了一个 AI 产品是盈利还是亏损。

语义压缩的降维打击：Skill.md 的崛起

所以，原因就已经很清楚了。

为什么 Perplexity 的 CTO 宁愿回归 API 和 CLI？因为在 AI 时代，“描述”比“定义”更高效。

MCP 是给机器看的： 它有着严苛的 JSON 架构、复杂的验证逻辑和繁琐的服务器握手。

API + Skill 是给 AI 看的： 一个简单的 .md 文件（Skill）就能告诉 AI：“这是 API 终点，这是参数，开火吧。”

这种“语义压缩”不仅节省了成本，更降低了延迟。当 Garry Tan 吐槽 MCP 导致 Claude 的浏览器集成变得迟钝时，他指出的正是架构复杂性带来的“认知负担”。

两个世界的博弈：标准化 vs. 灵活性

更进一层，其实这场争论反映了 AI 工程化的两种路线。

在 2026 年的技术十字路口，开发者们分化成了以下两个阵营：

1. 协议派 (MCP)：追求“大一统”的理想主义，这一派系由 Anthropic 等大模型厂商主导，试图建立一套 AI 时代的“全球标准语”。

协议派的核心逻辑是：先有协议，再有连接。 就像互联网需要 TCP/IP，这一派认为 AI Agent 如果要调用成千上万的工具，必须有一套严谨、标准化的沟通协议（MCP）。

但工程代价就是： 为了实现这种通用性，系统变得极其沉重。Agent 在执行任务前，需要进行复杂的“握手”和“语义校验”，导致了上文提到的 50,000 Token 的巨大开销。

2. 实效派 (API/CLI)：追求“极简”的黑客主义。很明显，这一派由 Perplexity、Garry Tan 以及广大的一线开发者组成，他们对“过度工程化”表现出强烈的反感。

在他们看来：AI时代，连接大于协议。 既然 API 已经是现成的、成熟的，为什么还要在外面包一层厚重的 MCP？

采用 API 或 CLI 的有很明显的工程优势：极致的上下文密度。 通过 Skill.md 这种语义压缩方式，绕过繁琐的验证。200 Token 的指令直接命中 API 终点，速度快、成本低。

“别跟我谈什么全球标准，我只想用最少的 Token 让我的 Agent 把活干完。”

MCP真的要消亡了？

然而，说“ MCP 已死”，明显是一种夸张的说法。

MCP 并不是毫无用处，它只是正在退缩到它最擅长的领域：企业内网的复杂工具链。而在面向消费者的、追求极致体验的 Agent 场景中，API 正在收复失地。

几周前，微软最新的 .NET Skills Executor 给出了一个可供业界参考的“混合式”答案：

第一层（Skill层）： 用极简的 Markdown 引导 AI。

第二层（执行层）： 只有在涉及跨系统、高频调用的复杂工具时，才在后台静默调用 MCP。

可以说，这种做法会许会成为业界的新共识。

写在最后

从开发者们“拆除 MCP 服务器，替换为 Skills md文件”，再到 Perplexity 内部宣布放弃 MCP，Garry Tan 炮轰 MCP，不难看出这样一个道理：

在如今的 AI 领域，过度工程化是创新的天敌。

MCP 试图为 AI 建立一套“礼仪”，但 AI 创新者们真正需要的是“效率”。

Perplexity 的做法就是很典型的一个例子：它正在把搜索、模型、嵌入打包成“全栈 API”，试图跳过复杂的协议层，直接接管底层基座。

这种转向提醒了所有开发者：如果一个简单的 CLI 包装就能解决问题，千万不要去写一个复杂的 MCP 服务器。

也许，在 2026 年，最好的协议就是“没有协议”。

从这层面看，“MCP的确烂透了！”