三月中旬，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的前景再次盖章认真。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 看看有什么，按需展开，不用一口气把所有参数文档塞进上下文。Agent Skills 的设计思路完全不同。一个 Skill 本质上是一个 markdown 文件，里面写着 SOP：先干什么、再干什么、失败了怎么重试、什么时候该告知用户。agent 拿到的不是一个孤零零的工具，而是一整套操作流程。MCP 的工具只能被动等着 agent 来调。Skill 可以主动介入 agent 的对话过程：什么时候该触发、前后要准备什么、出错了怎么兜底，这些都可以写在里面。这一点我感触很深。半年前我们做 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 到底需要什么样的工具接口？可以确定的是，至少它不再是一个协议就能回答的了。张晨
Zilliz Algorithm Engineer
