MCP 正在失宠，不是因为不够火，而是因为它开始拖慢 Agent 了
MCP 去年刚出来的时候，很多人真的把它当成了 AI 时代的“HTTP”
MCP 去年刚出来的时候，很多人真的把它当成了 AI 时代的“HTTP”。
那阵子你随便刷一圈社区，几乎全是 MCP server、接入教程、兼容方案，气氛像极了一个新标准已经板上钉钉。
结果才过了一年多，风向就变了。
Perplexity CTO Denis Yarats 公开表示，他们正在放弃 MCP，转回 API 和 CLI。消息一出来，圈子里的反应不是震惊，而是一种“终于有人说出来了”。连 YC 的 Garry Tan 都直接下了评语：“MCP sucks.”
这话虽然难听，但它点中了问题。
MCP 现在遇到的麻烦，不是实现细节再打磨一下就能解决的那种麻烦，而是它的设计，从一开始就埋了成本。
MCP 最大的问题，不是难用，是太吃上下文
MCP 的基本思路是：先把工具名、描述、参数 Schema、调用方式这些信息，一股脑喂给大模型；然后再由模型决定调用哪个工具。
听起来很合理。
但问题是，这套机制本质上是在让 Agent 先“背菜单”，再开始干活。
工具少的时候，你感受还不明显。
可一旦服务多起来，问题立刻放大。
假设你接了 10 个服务，每个服务 5 个工具。那还没开始真正推理，光工具定义本身就已经烧掉了一大截 token。上下文窗口这种东西，本来就很贵，它决定了 Agent 还能记住多少历史、保留多少中间状态、留出多少推理空间。
结果 MCP 先把这块黄金地段拿去摆工具说明书了。
这就很尴尬。
因为你最后通常只会实际调用一两个工具，却要提前为几十个工具付上下文成本。
这不是优化一下 server、补几个缓存、改一套认证能彻底解决的。它是协议层面的结构性代价。
现实里的痛点，大家其实早就感受到了
如果你真的用过一段时间 MCP，大概率都踩过这些坑：
server 时不时起不来，重试也不一定有用
每接一个服务就要重新折腾一遍认证
权限控制非常粗，只能“给”或“不给”
很难限制某个工具只能只读，或者只能传某些安全参数
这些问题单独看，好像都只是工程问题。
但把它们和“超吃上下文”这个根因放在一起看，你会发现 MCP 的使用体验为什么会越来越拧巴：
它并没有换来一个足够大的收益，却先把复杂度和维护成本推上去了。
为什么很多团队又转回 CLI 了
CLI 看上去老，甚至老得有点土。
但它有一个 MCP 很难复制的优势：大模型天生就懂它。
别忘了，LLM 训练时看过无数 man 手册、Shell 脚本、Stack Overflow 问答、README 和终端日志。它们对 CLI 的理解，远比对某个私有 MCP server 的理解深。
换句话说，CLI 根本不需要先发明一层新协议，再让模型学着适应。
它本来就在模型的知识分布里。
而且 CLI 的好，不只是在“模型看得懂”。
- 它更容易调试
如果 Claude 调了一个奇怪的 Jira 操作，你可以直接把同一条命令手动跑一遍：
jira issue view ...你能看到一模一样的输入和输出，问题出在哪，很快就能定位。
但 MCP 不一样。很多调用过程都裹在对话内部，最后你只能去翻 JSON 日志，猜模型当时到底看到了什么、理解成了什么。
这种调试体验，工程师会越来越没耐心。
- 它天然支持组合
这是 CLI 最狠的一点。
你可以 grep，可以 jq，可以管道，可以重定向，可以把一个工具的输出立刻塞给另一个工具。
这不是“方便一点”而已。
很多复杂任务，离开这种组合能力，根本就做不顺。
而 MCP 没有真正继承这套哲学。要么你把一大坨结果直接塞回上下文，要么就在 server 端继续手写过滤逻辑。两边都更重，也都更笨。
- 它复用了成熟认证体系
CLI 走的是系统级、账号级、已有工具链级别的认证路径。
这些东西已经被工程世界打磨了很多年。
而 MCP 往往要为每个工具重新搭一轮认证和授权流程。理论上更规范，实际上维护成本更高，出错点更多。
这场退潮，真正说明了什么
Perplexity 放弃 MCP，这事本身不算最重要。
更重要的是，它在提醒所有做 Agent 的团队一件事：
不是所有“给 AI 设计的协议”都会比现有工具更好。
很多时候，AI 真正需要的，不是一套看起来更现代的新抽象，而是一套已经被人类工程实践验证过的工具系统。
CLI 之所以顽强，不是因为它怀旧，而是因为它一直遵循一个很朴素的原则：
一个工具做好一件事
多个工具通过组合解决复杂问题
这套方法对人类有效，对 Agent 也一样有效。
MCP 想做的是更统一、更优雅的“工具中间层”。问题在于，如果这个中间层没有明显降低成本，反而先吃掉上下文、增加认证负担、削弱调试能力，那它迟早会从“先进”变成“包袱”。
MCP 会消失吗？也不至于
我不觉得 MCP 会彻底死掉。
在一些企业内部场景里，它依然有价值。比如：
必须强依赖 Schema
必须做非常严格的访问控制
工具调用需要被统一审计
团队更希望所有能力都走一层中心化协议
这些场景下，MCP 还是有位置的。
但如果你把它定义成“AI 工具集成的通用标准”，现在看，确实已经开始站不稳了。
因为真正能活下来的标准，通常不是最像未来的那个，而是总成本最低、调试最直接、组合最自然的那个。
至少在今天，CLI 比 MCP 更接近这个答案。
最后一个很现实的问题
如果你现在在做 Agent 平台，或者正准备给产品接一堆外部工具，我觉得应该先问自己一句：
你是真的需要 MCP，还是只是因为它去年太红了，所以默认它应该是答案？
这个问题，值得每个团队重新想一遍。
因为很多技术路线，最危险的时候不是它没人吹，而是它刚被吹成“标准”的那一刻。
评论
加载评论…