发布于 10小时前

MCP已死，CLI当立！Perplexity首先放弃使用MCP，全网赞成

编辑｜冷猫

OpenClaw 已经爆火了好一阵子了。

大部分感兴趣的用户都已经尝试过「养龙虾」的操作，也有一部分人已经寻求彻底卸载，斩断与AI的孽缘。

这阵风有隐隐消退的趋势。但使用过 OpenClaw 的朋友们有没有发现，OpenClaw 不支持 MCP 协议。

模型上下文协议（Model Context Protocol，简称 MCP），在2024 年 11 月由 Anthropic 推出。推出后，MCP 在开发者和 AI 社区中迅速获得了广泛关注，被视为大模型通信和交互的标准协议。

但时间仅过了一年多，MCP 似乎已经销声匿迹了，就连 MCP 协议的「一周年纪念日」却在一片寂静中度过。从发布以来，MCP 的「builder 多于 user」、「旧瓶装新酒」的质疑始终存在。

而现在，MCP 似乎正在走向消亡。昨天，Perplexity 的联合创始人和 CTO Denis Yarats 在其公司内部表示，他们正在放弃 MCP，转而使用 API 和 CLI。

讽刺的是，这似乎是近期 MCP 声量最高的事件，引发了网友们的讨论。

网友们的想法都挺一致的，尤其是 Skills 逐渐占据了智能体应用的主场后，MCP 似乎早就应该消失了。

除了 Perplexity 以外，曾经对 MCP 集成的全面支持，甚至实现了 OAuth 和动态客户端注册的 AI 聊天工具 Duetchat ，在 v2 版本中，也彻底删除了 MCP 集成的功能。

就连 Y Combinator 总裁兼 CEO Garry Tan 也直言不讳：MCP sucks！

那么，MCP 到底有哪些问题，导致谁都不待见呢？

MCP 的天生缺陷

MCP 协议的模式是：定义一组工具（带有 Schema 的函数），将其注入 Agent 的上下文，然后让 Agent 调用它们。

这种模式可行，但难以为继。核心问题在于线性上下文成本。

你添加的每一个 MCP 工具，包括它的名称、描述、参数 Schema 和示例，都会占用 Agent 的上下文窗口。如果你连接 10 个服务，每个服务有 5 个工具，那么在 Agent 开始执行任何任务之前，你就已经烧掉了数千个 Token。

所以在使用MCP协议之前，我们只能选择：

这些都不是理想方案。上下文窗口是 Agent 拥有的最宝贵的「房地产」，使用 MCP 协议是一种极大的浪费。

MCP 在日常使用中也存在几点问题：

CLI 和 API，古法拯救世界

来自 Eric Holmes 的一篇博客指出了传统 CLI 在大模型智能体的强大能力。他认为，MCP 并没有带来任何实际价值。LLM 真正擅长靠自己搞清楚状况。给它们一个 CLI 和一份文档，它们就能如鱼得水。

LLM 非常擅长使用命令行工具。它们在数以百万计的 man 手册、Stack Overflow 的回答以及充斥着 Shell 脚本的 GitHub 仓库中接受过训练。MCP 承诺提供一个更简洁的接口，但在实践中，我们仍要写同样的文档：每个工具的功能、接受的参数，更重要的是，何时去使用它。

当 Claude 对 Jira 执行了某些出乎意料的操作时，我可以运行同样的 jira issue view 命令，看看到底它看到了什么。输入一致，输出一致，没有任何谜团。但在 MCP 下，工具仅存在于 LLM 的对话内部。一旦出错，就不得不去翻找复杂的 JSON 传输日志，而不是自己跑一遍命令。

最重要的差距是：CLI 是可组合的。我可以通过 jq 过滤数据，通过 grep 串联逻辑，或者重定向到文件。这不仅是方便，通常也是唯一可行的方法。

如果使用 MCP，你要么将整个计划全部塞进上下文窗口（既昂贵又往往不可行），要么在 MCP 服务端内部构建自定义的过滤功能。无论哪种方式，你都是在用更多的精力换取更差的结果。而 CLI 方案使用的是现成的、文档齐全的工具，且人类和智能体（Agent）都能理解。

最好的工具是那些对人类和机器都好用的工具。CLI 已经历了数十年的设计迭代，它们可组合、可调试，并寄生于现有的认证体系。

MCP 试图构建一个更好的抽象层，但事实证明，我们已经拥有一个足够好的了。

参考链接：

https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html

https://x.com/dzhng/status/2029518820872945889

浏览 (2)