开发者弃用MCP转向CLI与Skills：性能差异可达250倍的背后原因

“MCP 烂透了！”

过去一年，MCP（模型上下文协议）被广泛吹捧为 AI 时代的 TCP/IP，承诺能一键连接所有工具。然而，步入 2026 年，一线产品开发者们发现，这个“万能接头”不仅笨重，成本还异常高昂。

近日，Perplexity 联合创始人 Denis Yarats 和 YC 总裁 Garry Tan 公开批评 MCP，并倡导回归 API 和命令行界面（CLI），再次引发了业界对 MCP 价值的广泛讨论。不得不感叹 AI 领域的技术祛魅周期正变得越来越短。

那么，MCP 到底出了什么问题？它真的如部分网友所言“已死”了吗？

硅谷领袖的尖锐批评

事件的起点是 Perplexity 公司的一次内部会议。

2026年3月12日，Perplexity 的联合创始人兼首席技术官 Denis Yarats 在内部宣布，公司正在放弃 MCP，转而回归 API 和 CLI。与此同时，Perplexity 发布了一个全栈式、与模型无关的 API 平台，旨在用一个软件包整合模型提供商、搜索层和嵌入层。公司的立场非常明确：API 应作为底层架构，而非构建在 MCP 服务器之上。

随后，YC 总裁 Garry Tan 的批评则更为直接和尖锐。

“说实话，MCP糟透了，”他在社交媒体上发帖指出，并列举了其诸多问题：占用过多的上下文窗口、身份验证机制笨拙、需要手动开关服务器等。

他对基于 MCP 的 Claude 浏览器集成体验感到失望，甚至亲自动手，仅用30分钟就编写了一个 Playwright 的 CLI 包装器。结果发现，这个自制方案的效果提升了100倍，代码量却只有大约100行！

更早的“反叛”声音：用 Markdown 文件替代 MCP

事实上，在这两位大佬发声之前，业内已有不少创业者和投资者指出了 MCP 的弊端。一篇文章的标题甚至写道：“RIP MCP. Long live skills!”

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

无独有偶，开源系统 CompanyOS 的创始人 Brad Feld 也在用实践回应 MCP 的复杂性。CompanyOS 在设计上虽然连接了8个 MCP 服务器来访问 Gmail、Linear 等服务的 API，但 Brad 表示，系统真正的核心在于那些 重回流行巅峰的 Markdown 文件。

每个 Skill（.md）文件都编码了具体的工作流、护航规则、语气校准以及决策逻辑。相比之下，MCP 服务器的作用显得有些“鸡肋”：即使 MCP 连接断开，这些 Skills 依然有效，用户只需将自动操作改为手动复制粘贴即可。

为何 AI 产品正在“逃离”MCP？

MCP 的初衷是宏大的：通过一套标准化的服务器协议，让 AI 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 Schema、复杂的验证逻辑和繁琐的服务器握手流程。
• API + Skill 是给 AI 看的：一个简单的 .md 文件（即 Skill）就能告诉 AI：“这是 API 端点，这些是参数，请直接执行。”这种被称为 “语义压缩” 的方式，不仅极大节约了成本，更显著降低了延迟。当 Garry Tan 吐槽 MCP 导致 Claude 浏览器集成反应迟钝时，他指出的正是过度架构带来的 “认知负担”。

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

更深一层看，这场争论反映了 AI 工程化进程中两种截然不同的路线选择。

1. 协议派 (MCP)：追求“大一统”的理想主义
这一派主要由 Anthropic 等大型模型厂商推动，旨在为 AI 时代建立一套通用的“标准语”。其核心逻辑是：先有协议，再有连接。正如互联网离不开 TCP/IP，他们认为 AI Agent 要调用成千上万的工具，必须有一套严谨、标准化的沟通协议（MCP）。
然而，其工程代价是巨大的：为了实现通用性，系统变得极其沉重。Agent 在执行任务前需要进行复杂的“握手”和“语义校验”，从而产生了前文提及的巨额 Token 开销。

2. 实效派 (API/CLI)：追求“极简”的黑客主义
这一派则以 Perplexity、Garry Tan 及广大一线开发者为代表，对“过度工程化”表现出明显的反感。他们的信条是：AI时代，连接大于协议。既然 API 和 CLI 已经是现成、成熟的接口，为何还要在外面包裹一层厚重的 MCP 协议？
采用 API 或 CLI 的核心优势在于 极致的上下文密度。通过 Skill.md 进行语义压缩，可以绕过繁琐的协议验证，用 200 Token 的指令直击目标，速度快、成本低。他们的态度很明确：“别谈什么全球标准，我只想用最少的 Token 让我的 Agent 高效完成任务。”

MCP 真的会消亡吗？

然而，断言“MCP 已死”显然过于夸张。MCP 并非一无是处，它正在退守到自己最擅长的领域：企业内网的复杂工具链整合。而在面向消费者、追求极致性能和成本的 Agent 应用场景中，轻量化的 API 和 CLI 正在收复失地。

几周前，微软最新的 .NET Skills Executor 展示了一个可供参考的 “混合架构”答案：

1. 第一层（Skill层）：使用极简的 Markdown 文件来引导 AI。
2. 第二层（执行层）：仅在涉及跨系统、高频调用的复杂工具时，才在后台静默调用 MCP 服务器。

这种分层、按需使用的思路，或许会成为业界的新共识。

写在最后

从开发者“拆除 MCP 服务器，替换为 Skills .md 文件”，到 Perplexity 内部转向，再到 Garry Tan 的公开批评，这一系列事件揭示了一个朴素的道理：在快速迭代的 AI 领域，过度工程化往往是创新的天敌。

MCP 试图为 AI 建立一套完美的“礼仪规范”，但一线的创新者们当下最迫切的需求是“极致效率”。Perplexity 将搜索、模型、嵌入打包成“全栈 API”的做法，正是试图跳过复杂的中间协议层，直接掌控底层基座。

这种转向对所有开发者都是一个提醒：如果一个简单的 CLI 包装器或一个清晰的 Markdown 文件就能解决问题，那么就不要去构建一个复杂的 MCP 服务器。在效率至上的 2026 年，最好的协议，有时可能就是“没有协议”。从追求实际产出的角度看，部分开发者认为“MCP的确烂透了”，也就不难理解了。

关于AI工程化和Agent开发的更多实践与趋势，欢迎在云栈社区的人工智能或开发者广场板块与同行们继续深入探讨。