MCP已死，CLI当立！Perplexity弃用MCP引发AI圈大地震

type

status

date

slug

summary

引言：从“行业标准”到“弃子”的陨落

在人工智能领域，技术的迭代速度往往快得令人咋舌。2024年11月，Anthropic 推出了模型上下文协议（Model Context Protocol，简称 MCP），旨在解决大模型与外部工具通信的标准化问题。当时，MCP 被整个 AI 社区寄予厚望，被视为 Agent 时代的“通信总线”。

然而，仅仅时隔一年多，这股热潮却迅速冷却。近日，Perplexity 的联合创始人和 CTO Denis Yarats 在公司内部明确表示，他们正在放弃 MCP，转而回归 API 和 CLI（命令行界面）。这一决定在社交媒体上引发了巨大震动，甚至连 Y Combinator 的 CEO Garry Tan 也公开直言：“MCP sucks！”

为什么曾经被视为救星的 MCP 会在短时间内走向消亡？在 AI资讯 飞速更迭的今天，这背后反映了 AI 工程化怎样的趋势？

MCP 的“原罪”：昂贵的线性上下文成本

MCP 协议的核心模式是定义一组工具（Schema 化的函数），并将其注入到 Agent 的上下文中。这种设计在逻辑上是通顺的，但在实际大规模应用中却遇到了严重的性能瓶颈。

最核心的问题在于线性上下文成本。每一个接入的 MCP 工具，其名称、功能描述、参数 Schema 乃至示例，都会占用大模型的上下文窗口。如果你试图让一个 Agent 连接 10 个不同的服务，每个服务提供 5 个工具，那么在 Agent 还没开始执行任何具体任务前，就已经白白烧掉了数千个 Token。

对于开发者而言，这变成了一个痛苦的“三选一”难题： 1. 预加载所有工具：导致推理性能下降，对话历史和工作记忆被严重挤占。 2. 限制集成数量：牺牲 Agent 的能力上限，使其沦为只能处理少数任务的“残疾”智能体。 3. 构建动态加载中间件：增加了系统的复杂度和响应延迟。

在 大模型 资源极其宝贵的当下，这种对上下文窗口的挥霍被证明是难以为继的。

稳定性与权限管理的双重崩塌

除了架构上的缺陷，MCP 在实际使用中的用户体验也广受诟病。许多开发者反馈，MCP 服务端的启动极不稳定，经常需要重启 Claude Code 才能生效。这种不确定性对于追求高效的生产力工具来说是致命的。

其次是认证噩梦。每增加一个 MCP 工具，用户往往需要重新进行一次认证流程。如果你集成了多个工具，认证过程将变得极其繁琐。

更深层的问题在于权限管理的粗糙。目前的 MCP 协议在权限控制上几乎是“非黑即白”的。你很难精细化地限制 Agent 的操作范围，例如将其限制为只读，或者对某些敏感参数进行拦截。这种安全隐患让许多企业级应用对 MCP 望而却步。

CLI 的复兴：古法拯救世界

在 MCP 遭遇滑铁卢的同时，传统的 CLI（命令行界面）却在 人工智能 领域焕发了第二春。Perplexity 等公司的转向，本质上是对成熟技术的重新发现。

为什么 CLI 比 MCP 更适合 AI Agent？ * 训练数据的天然优势：LLM 在训练过程中接触了数以亿计的 man 手册、Stack Overflow 问答以及 GitHub 上的 Shell 脚本。大模型天生就精通 CLI 的使用逻辑。 * 极高的透明度与可调试性：当 Agent 执行错误时，开发者可以直接运行相同的 CLI 命令来复现问题。输入一致，输出一致，没有 MCP 那种隐藏在 JSON 传输日志下的黑盒感。 * 无敌的可组合性：CLI 的精髓在于管道符（Pipe）。Agent 可以利用 grep、jq、awk 等工具自由组合逻辑，而无需在 MCP 服务端内部构建复杂的过滤功能。

正如 Eric Holmes 所言，我们已经拥有了一个足够好的抽象层（CLI），何必再去强行构建一个低效的新协议呢？

结语：技术回归本质的启示

MCP 的衰落并不是技术创新的失败，而是对“过度抽象”的一次警示。在 AGI 的演进过程中，最简单的路径往往是最有效的。Perplexity 的果断放弃，标志着 AI 工程化正从“追逐新协议”转向“利用成熟基础设施”。

对于关注 AI新闻 和行业动态的开发者来说，这一转变意味着我们需要重新审视工具集。与其等待一个完美的统一协议，不如深耕现有的 API 和 CLI 生态。

如果你想获取更多关于 LLM、Prompt 以及 AI变现 的深度解析，欢迎访问 AI资讯门户，掌握大模型时代的最新脉搏。