“MCP已死，CLI当立”的真相是什么？

2026年3月11日，Morgan Linton在X上转述了一条消息：Perplexity联合创始人兼CTO Denis Yarats在Ask 2026大会上表态，Perplexity内部正从MCP转向APIs和CLIs。

同一天，Y Combinator掌门人Garry Tan直接开炮："MCP sucks honestly"，点名context window膨胀、工具开关麻烦、auth机制糟糕。Pieter Levels随即跟进："Thank god MCP is dead。"

三个名字叠在一起，把原本只在Agent infra圈子里打转的技术争论，一把推上了全网热搜。

3月13日机器之心也发了一篇，把它包装成"MCP已死，CLI当立"，这个话题在中文AI圈也开始热闹起来。我也在朋友圈第一时间聊了聊自己的看法

这几天社群各种讨论，我觉得有必要系统聊聊这事儿。

先搞清楚大家在吵什么

要理解这场争论，得先搞清楚两个词在2026年的AI语境里到底指什么。

CLI，在这波讨论里不是指传统的命令行界面本身，而是指通过编写本地命令行程序、或者直接用curl这类工具连接云端服务的方式。简单说就是：我的agent需要调用什么能力，就写一个脚本或者直接敲一行命令，干净利落，无需中间层。

MCP（Model Context Protocol），Anthropic在2024年11月推出的开放协议标准，解决的是"AI系统如何标准化地连接外部工具"这个问题。

那大家到底在抱怨MCP什么？

大家抱怨的不是协议本身的设计理念，而是工程实践中的真实问题：

• 上下文膨胀：MCP的默认实现会把所有工具定义一股脑塞进上下文——不管你这轮对话用不用得到。10个工具还好，50个工具上下文就炸了，token成本直线飙升
• 手动管理负担：需要自己开关MCP server，管理连接状态。对个人开发者来说，太太太太麻烦
• 中间层损耗：很多MCP server做的事，本质上就是把一个本来可以直接调的API又包了一层

而skill + CLI的组合恰好站在了对面：轻量、直接、按需加载。agent需要什么能力就加载什么skill，skill本身就是一个可执行的CLI工具或脚本，不需要常驻服务，不需要预加载工具定义到上下文里。用完即走，干净利落。

所以这波舆论的本质是：在coding agent和C端agent这条线上，开发者受够了MCP带来的工程负担，发现skill + CLI的方式又轻又快，于是集体"起义"了。

理解了这个背景，我们才能看清争论的全貌——以及争论双方各自的一叶障目。

"MCP已死"党的一叶障目

CLI确实爽。敲一行命令，立刻出结果，多巴胺瞬间到位。

但"MCP已死"这个论调犯了一个错误：用Demo场景的体验标准，去衡量基础设施的价值。

MCP作为一个协议标准，它成长至今要解决的就不是"让你在terminal里少敲几个字符"这件事。它是为企业级agent做基础设施的。 只不过2025年它恰好填补了一个空白——AI工具连接没有统一标准——于是被开发者社区疯狂追捧，变成了"万物默认接口"。

追捧过度之后，反噬是必然的。但反噬的对象应该是"过度追捧"本身，不是协议标准。

打个比方：高铁刚开通的时候，有人坐高铁去隔壁超市买菜，发现还得先到车站、安检、候车，比打车麻烦多了。于是宣布"高铁已死，出租车才是王道"。

但高铁是为北京到上海设计的，不是为你去隔壁超市设计的。

企业级才是MCP的主场

跳出个人开发者的视角，看看企业级AI应用的真实需求。

你是某大厂AI平台负责人，要为内部100个AI应用提供工具连接能力。这些应用需要连接数据库、API、文件系统、消息队列等几十种外部服务。

如果用CLI方式：

每个AI应用自己实现一套shell调用逻辑。Python的用subprocess，Node.js的用child\_process，Go的用os/exec。每种工具的参数格式不一样，返回值解析各有标准，错误处理五花八门。

更要命的是：你根本无法审计这些AI应用到底在执行什么命令。

这就是CLI方案在企业场景下的致命短板：可控性、可审计性、安全性全部裸奔。

而MCP提供了什么？

• 显式权限模型：每个工具的每个操作都可以单独授权
• 结构化输入输出：不是靠字符串解析，是typed interface
• 统一审计日志：所有工具调用都有标准化的记录格式
• 沙盒化执行：工具运行在受控环境中，不继承宿主的全部权限

这些特性在Demo阶段显得"笨重"，在生产环境里却是救命稻草。

"MCP万岁"党的一叶障目

但话说回来，MCP也不是没有问题。

连Anthropic自己都在承认MCP的工程问题。2025年11月Anthropic写的《Code execution with MCP》里明确提到：工具一多，预加载tool definitions和中间结果会拖慢agent、增加成本。Cloudflare在2025年9月和2026年2月连写两篇Code Mode文章，核心结论也一样：别把所有工具直接塞进上下文，改成让模型写代码去调API，token能省很多。

"MCP吃上下文"不是反对派在空喊，是官方和大厂自己都在修的问题。

2025年整年就是埋雷期：春天Shrivu Shankar写了《Everything Wrong with MCP》做系统性批评；11月Thoughtworks直接把"naive API-to-MCP conversion"列进Technology Radar的Hold象限，理由是granular API被agent串起来后带来token污染、性能差和安全风险。

所以如果MCP阵营一直拿"你们不懂标准化的价值"来回应所有批评，同样是一叶障目。标准化的价值没人否认，但标准化不等于高成本的标准化。

两个场景，两套逻辑

争到最后，你会发现CLI和MCP根本不是"谁替代谁"的关系，而是在不同场景下各有主场。

Coding agent / C端 / 非严肃场景：用户和开发者更在意的是成本和效率。上下文窗口寸土寸金，每多塞一个工具定义就多一分成本。skill + CLI的方式——按需加载、用完即走、不带无关工具进上下文——天然契合这个场景。这也是为什么Claude Code、Gemini CLI、OpenClaw都走了这条路。

企业级 / 多租户 / 安全敏感场景：需要统一权限、治理、审计、跨客户端标准化。CLI在这个场景里就像散兵游勇，每个agent自己搞一套，审计不了、管控不住、出了事追不到源头。MCP的协议标准化在这里才真正发挥价值。

这不是CLI vs MCP，是轻量灵活 vs 标准治理。在不同的生命周期阶段、不同的应用场景里，天平会自然倾斜。

标准化的网络效应不可忽视

还有一点被严重低估了：标准化带来的网络效应。

回忆一下USB的故事。90年代的电脑外设连接堪称地狱：键盘PS/2，鼠标COM口，打印机LPT口，每种设备一套标准。USB 1.0速度才1.5Mbps，比并行口还慢。按"体验至上"的逻辑，USB应该被立即淘汰。

但USB赢了，赢了二十多年。因为它解决的不是"快不快"，而是"乱不乱"。统一接口、统一电源、统一热插拔、统一设备发现——这些"无聊"的基础设施特性才是真正的护城河。

MCP追求的也是这种网络效应：

• 工具开发者只需适配一种协议，就能被所有MCP客户端使用
• AI平台只需实现MCP客户端，就能连接所有MCP工具
• 企业用户可以在不同AI平台间迁移，因为工具连接是标准化的

这种生态价值，不是"单个工具用起来爽不爽"能衡量的。

现在下结论太早

技术圈的"XX已死"论简直是月经帖：

• "Java已死，Scala才是未来" → Java还在，Scala凉了
• "SQL已死，NoSQL当立" → SQL还在，NoSQL成了补充
• "关系数据库已死" → 你的公司数据库大概率还是MySQL或PostgreSQL

结果呢？那些宣布别人"已死"的技术，很多自己先没了。

技术的生命力不在于是否"先进"，而在于是否解决了真实存在的问题。

MCP解决的问题——AI系统的工具连接标准化——真实存在。Anthropic在2025年12月把MCP捐给了Linux Foundation的Agentic AI Foundation，2026年1月仍然宣称它是industry standard，官方文档也在持续更新。

更准确的判断是：MCP失去了"万物默认接口"的话语权，但没有失去它真正的位置——需要统一权限、治理、审计、跨客户端标准化的企业级场景。而在coding agent这条线上，CLI和Skills的声量已经压过了它。

结语

"MCP已死"是一句很好的传播口号，但不是事实判断。

在2025-2026这个时间窗口，MCP被过度追捧，然后被过度否定。追捧者把它当成万能钥匙，否定者把它当成落后产物。两边立场不同，都是故意的一叶障目。

真正的答案很无聊，但很诚实：

轻量场景用CLI和Skills，严肃场景用MCP，混合场景两者并存。 未来大概率是MCP继续进化（解决上下文膨胀和工程摩擦），CLI/Skills继续繁荣（在coding agent和C端场景深耕），两条路线互相借鉴，最终走向某种融合。

宣布一项技术"已死"很容易，建设一个生态很难。

在这个不博眼球就没流量的内容泛滥的时代，搞清事情原委，基于自己场景做出科学的判断才是最最重要的事情。

至于标题党们，随便看看就行了。