2026年7月9日 周四晚上19:30,报名腾讯会议了解“如何构建自进化的动态知识库(Brain)”(限30人)
免费POC, 零成本试错
FDE知识库

FDE知识库

学习大模型的前沿技术与行业落地应用


收藏

MCP彻底被抛弃了吗?

发布日期:2026-04-07 19:08:09 浏览次数: 2296
作者:Zilliz

微信搜一搜,关注“Zilliz”

推荐语

Perplexity CTO公开炮轰MCP协议,揭秘AI工具集成标准为何突然失宠。

核心内容:
1. MCP协议被弃用的两大技术缺陷:上下文窗口过载和被动响应机制
2. Skills与CLI的渐进式披露设计如何解决MCP痛点
3. 大模型时代工具生态快速迭代的行业现象分析

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
三月中旬,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 到底需要什么样的工具接口?可以确定的是,至少它不再是一个协议就能回答的了

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询

扫码登录
登录即表示您同意《53AI网站服务协议》
服务协议

欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。

在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。

一、 定义

本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。

会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。

知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。

二、 账号注册与登录

登录方式:本网站支持以下登录方式,您可根据实际情况选择:

微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。

手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。

账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。

实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。

未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。

三、 服务内容与规范

知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。

服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。

禁止行为:您在使用服务时不得实施以下行为:

利用技术手段批量爬取、下载、转存知识库内容;

将知识库内容用于商业目的或未经授权地向第三方传播;

干扰本网站正常运行或侵犯其他用户合法权益;

发布违法违规信息或从事违反公序良俗的活动。

四、 知识产权声明

权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。

有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。

侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。

五、 个人信息保护

我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。

您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。

您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。

六、 免责声明

内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。

不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。

第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。

七、 违约责任

如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。

如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。

八、 法律适用与争议解决

本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。

因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。

九、 其他

本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。

本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。

我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。


已查阅