三月中旬，Perplexity 在自家的 Ask 2026 大会上，CTO Denis Yarats 毫无预兆的，对MCP做了开火：我们内部正在放弃 MCP，转回 REST API 和 CLI。

紧接着，这句话传到社交媒体上就炸了。YC 的 CEO Garry Tan 转发时直接说「MCP sucks honestly」，大意是 MCP 很糟糕，吃掉太多上下文窗口，认证也拉胯，他自己花 30 分钟写了个 CLI 封装器来替代它。

这种表态放在一年前根本不敢想。MCP 当时被捧为 AI 工具集成的终极标准，生态建设热火朝天，服务器数量以周为单位翻倍。然后伴随突然间被炒起来、被用烂的，是突然间的被抛弃，当然，这也是大模型时代所有产品与工具的常态。

而同一时期，国内包括飞书在内的平台，也推出了其CLI，给CLI+Skill的前景再次盖章认真。

所以，MCP到底哪里出了问题？

01 MCP 太重：上下文窗口撑不住

有人测过，三个服务器（GitHub、Playwright、加一个 IDE 集成），在 20 万 token 的模型上，光工具定义就占掉了 14.3 万。也就是说，标准 MCP 设置消耗约 72% 的上下文窗口，Agent 还没开始干活，可用空间就只剩下不到三成。

这带来的问题不只是费钱。上下文里塞的东西越多越杂，模型对关键信息的聚焦能力就越弱。100 个工具的 schema 全堆在那里，agent 每做一个决策都得先翻过这些描述。

研究者管这个叫 context rot，上下文腐烂：过长的上下文，会让工具选择准确率从 43% 掉到了 14% 以下。也就是说，工具配得越多，agent 反而越不知道该用哪个。

根源在于 MCP 的加载方式。在协议层面的设计选择上，它把所有工具描述在 session 一开始就全量灌进来，也不管这次对话用不用得上，在后续，代价会随工具数量增长越来越大。

Skills 走了另一条路，叫渐进式披露。session 开始时，agent 只读每个 Skill 的元数据：名称、一句话描述、什么时候该用。加起来一共只需要几十个 token，可以忽略。等等 agent 判断某个 Skill 跟当前任务相关了，才会把把相关的完整内容加载进来。

简单概括，就是MCP 是把所有工具在门口一字排开让你自己挑；Skills 是先给你一份目录，需要的时候再翻。

02 MCP 响应被动：只会等着被调用

MCP 本质上是一套 tool 调用协议：怎么发现工具、怎么调用、怎么拿结果。小规模场景里很干净，但问题也出在这个干净上，它太平了。

没有层级，没有子命令

MCP 里一个工具就是一个函数签名。没有子命令，没有会话生命周期的感知，也不知道 agent 当前走到哪一步了。工具就摆在那里，等着被调用，别的什么都不管。

CLI 就不一样。一个 CLI 工具天然有子命令，git commit、git push、git log 背后是完全不同的行为路径。agent 可以先跑个 –help 看看有什么，按需展开，不用一口气把所有参数文档塞进上下文。

没有 SOP，不会教 agent 怎么做

Agent Skills 的设计思路完全不同。一个 Skill 本质上是一个 markdown 文件，里面写着 SOP：先干什么、再干什么、失败了怎么重试、什么时候该告知用户。agent 拿到的不是一个孤零零的工具，而是一整套操作流程。

MCP 的工具只能被动等着 agent 来调。Skill 可以主动介入 agent 的对话过程：什么时候该触发、前后要准备什么、出错了怎么兜底，这些都可以写在里面。

没法复用 agent 的 LLM

这一点我感触很深。半年前我们做 claude-context 的 MCP 项目，给 Claude Code 提供上下文代码检索。用户提问的时候，MCP 从 Milvus 向量数据库里召回相关的历史对话片段，塞回上下文里辅助回答。

功能跑通之后，问题马上来了：召回 top 10 条结果，真正有用的可能就 3 条，剩下 7 条是噪声。不处理的话全塞给外层 agent，反而干扰判断。

我当时试了几种办法。全给 agent的话，噪声太多，回答质量明显下降，有时候甚至被无关的历史记录带偏。在 MCP server 里加 rerank 过滤的话，用小模型精度不够，而且得分阈值设 0.7 还是 0.8，不同场景下完全不一样。用大模型的话，MCP server 是一个独立进程，它访问不了外层 agent 的 LLM，我得在 server 里另外配一个 LLM client，另外填 API key，另外管调用逻辑。

当时就在想，能不能有一种方式，让外层 agent 的 LLM 直接参与到工具内部的决策里来？检索完了让 agent 自己判断哪些结果值得留，不用另起炉灶。

后来发现 Skill 恰好能解决这个问题。一个检索 Skill 可以写成：先调向量检索拿到 top 10，然后让 agent 自己的 LLM 做相关性判断，过滤噪声，最后只把有用的结果返回。不需要额外的模型，不需要额外的 API key，agent 自己就能搞定。

我们后来做的 memsearch 项目，它的 Claude Code 插件里就用了这个思路。记忆召回 Skill 跑在一个独立的 subagent 里，分三层渐进式检索：先向量搜索粗筛，拿到结果后 agent 自己判断哪些值得展开，有必要的话再深入到原始对话记录里去挖。agent 的 LLM 全程参与，哪些留、哪些扔、要不要继续往深了挖，都是它自己决定的。最终只把整理好的结果返回给主 agent，中间那些搜索噪声和原始数据，主对话窗口完全不可见。

MCP 做不到这些。server 和 agent 之间隔着进程边界，server 用不了 agent 的 LLM，agent 也管不了 server 内部怎么跑。做个简单的 CRUD 工具没问题，但一旦工具里需要做判断、做筛选，这个隔离就卡住了。

03 但 MCP真的该死吗？

Hacker News 上有一篇「When does MCP make sense vs CLI?」的帖子，高赞回答基本一边倒站 CLI：「CLI tools are like precision instruments」「CLIs also feel snappier than MCPs」。

不过事情没那么简单。

MCP 已经捐给了 Linux Foundation，活跃服务器超过 1 万个，SDK 月下载量 9700 万。这么大的生态摆在那里，说死就死不太现实。

也有开发者看法比较温和：Skills 像一份详细的菜谱，帮你把问题解决得更好；MCP 是帮你解决问题的工具。两者各有用处。

话是没错，但有个问题：如果菜谱本身就能指挥厨师用什么工具、怎么用，那还需要一个单独的「工具分发协议」吗？

得分场景看。MCP over stdio，就是大多数开发者在本地跑的那种，问题确实最多：进程间通信不稳定、环境隔离麻烦、token 开销大，基本上每个方面都能找到更好的替代。

但 MCP over HTTP 情况不同。企业内部的工具平台需要统一权限管理、集中 OAuth 认证、标准化的遥测和日志，这些东西分散的 CLI 工具确实很难提供，MCP 的集中式架构在这里有实打实的价值。

Perplexity 放弃的主要就是 stdio 的用法。Denis Yarats 强调的也是「内部」在降低优先级，没有说全行业都该这么做。但传播的时候这些细节就丢了，「Perplexity 放弃 MCP」比「Perplexity 放弃在内部工具集成中使用 MCP over stdio」好传播太多了。

说到底，MCP 当初之所以能起来，是因为它确实解决了一个真实的问题：以前每个 AI 应用都得自己写一套工具调用逻辑，碎片化严重。MCP 给了一个统一接口，加上推出的时机好，生态很快就滚起来了。直到越来越多人在生产环境里踩了坑，质疑的声音才冒出来。

MCP 大概率不会消失。它会缩回到适合它的地方，比如企业级工具平台、需要集中管控的场景。但「所有 agent 都该用 MCP」这个说法，确实站不住了。

04 结尾

Skills 开放标准化之后，各家工具链都在跟进。渐进式披露这个思路，行业基本已经接受了，只是最终形态还没定下来。

目前比较务实的组合是 CLI / RESTful / Skills：CLI 处理日常操作，RESTful 对接外部系统，Skills 管 agent 的行为知识。MCP 在这个组合里没有消失，但位置变了，从标准变成了选项之一。

对开发者来说这可能反而是好事。工具越来越多，没有哪个单一协议能通吃所有场景。知道什么时候该用什么，比死守一个标准实在得多。

MCP 给行业留下了一个有价值的问题：agent 到底需要什么样的工具接口？可以确定的是，至少它不再是一个协议就能回答的了

{{userData.name}}已认证

MCP彻底被抛弃了吗？

01

MCP 太重：上下文窗口撑不住

02

MCP 响应被动：只会等着被调用

03

但 MCP真的该死吗？

04 结尾

LongRAG：利用长上下文大语言模型提升检索生成效果

🤯 终于搞懂了！LLM、RAG 和 AI Agents 到底是什么关系？