大厂纷纷抛弃MCP转向CLI的深层原因

为什么越来越多的大厂抛弃MCP，转向CLI？

先说结论（给不想看长文的朋友）

MCP（Model Context Protocol）是Anthropic在2024年底推出的"AI连接万物"标准。但到了2026年，一个明显的趋势出现了：越来越多的开发者和公司正在悄悄放弃它，转而拥抱一个更古老、更简单、也更可靠的东西——命令行CLI。

原因其实很简单：CLI的哲学是极致的简单——文本进，文本出。没有复杂的JSON握手，没有令人头疼的状态管理，更没有层出不穷的协议兼容性问题。你系统里自带的 git、npm、docker、kubectl，就是AI工具最好的连接层。

明天你就能验证这一点：打开Claude Code或Cursor，别费劲去配置MCP Server了。直接用自然语言描述你的需求，让它调用系统CLI工具——效果比你折腾一套MCP靠谱一百倍。

一、这故事要从一个"万能翻译官"说起

2024年冬天，Anthropic发布了MCP，全称是Model Context Protocol——模型上下文协议。

它的愿景非常宏大：做一个"AI世界的万国翻译官"。你的AI Agent想查数据库？MCP帮你连接。想调API？MCP帮你翻译。想读写文件？MCP帮你处理。理论上，有了MCP，AI就能跟外部世界的一切顺畅通信。

但问题就出在"翻译官"这三个字上。

打个比方你就明白了。假设你去参加一个国际会议，主办方给你配了个翻译官。翻译官信誓旦旦地说："我能翻译所有语言！"听起来很棒对吧？但实际开会的时候——

• 你每说一句话，翻译官都要跟你确认三遍："你说的这句话是中文吗？你是认真的吗？你的语气是疑问还是反问？" ——这就是所谓的"三次握手"。

• 翻译官把你的话转成JSON格式再传给对方："{"intent": "question", "tone": "curious", "content": "这个API怎么调用？"}" ——这就是JSON-RPC消息编码。

• 如果翻译官突然卡住了，你根本搞不清楚是它听错了，还是翻译错了，还是对方理解错了。日志一打就是500行，你得一行行翻。 ——这就是状态机调试地狱。

这就是MCP在现实中的样子。它的设计很"完备"，但完备的代价是复杂。而在工程世界里，复杂，往往是最大的敌人。

二、CLI：50岁的"插座哲学"

那么命令行CLI（Command Line Interface）呢？

它的哲学和MCP完全相反。MCP是"我什么都能懂，只要你按我的规矩来"。CLI是"我什么都不懂，我只有一个规矩：你给我文本，我给你文本"。

还是用比喻来说——

MCP是万国翻译官。CLI是标准插座。

你往插座上插台灯，它亮。插风扇，它转。插电视机，它播。插座根本不在乎你是谁，也不关心你是什么规格——只要你对准220V、输出文本到stdout、接收文本从stdin，它就能工作。

git log → 给你commit记录。npm test → 给你测试结果。curl api.example.com → 给你HTTP响应。

没有握手，没有JSON，没有状态机，也没有协议版本兼容问题。

Unix/Linux的命令行在服务器上已经跑了整整50年。这50年里，服务器崩过、操作系统换过、CPU架构变过、编程语言迭代过——但 /bin/sh 的文本流模型，从来没有崩过。

三、五个维度看清CLI为什么赢

我们把MCP和CLI放在五个维度上对比一下。你会发现，CLI的胜利并非偶然——

维度一：开发成本

维度二：调试难度

MCP出错了：500行JSON堆栈，嵌套三层的错误对象，你得用 jq 或者专门的工具去解析。

CLI出错了："command not found" → 你没装这个工具。"Permission denied" → 加个 sudo。"Connection refused" → 服务没启动。

你花在MCP调试上的时间，足够你写十个CLI脚本了。

维度三：可靠性

CLI的可靠性已经被时间充分验证过了。grep 从1970年代诞生至今，中间经历了多少次操作系统大版本升级？零次因为"协议变更"导致 grep 不能用。

MCP呢？协议还在快速迭代。今天你的MCP Server还跑得好好的，明天一更新SDK，Agent就不能用了。你说这怪谁？

维度四：可组合性（这是CLI的核武器）

Unix哲学有一条核心原则："Do one thing and do it well" —— 把事情做专、做到极致，然后组合。

CLI的组合武器叫管道符 |：

# 找出代码仓库里所有TODO注释，按类型统计git diff HEAD~10 | grep "+.*TODO" | sort | uniq -c | sort -rn

一个工具的结果，直接喂给下一个工具。没有任何中间格式转换，没有任何协议适配。

MCP做不到这一点。每个MCP Server都是一个孤岛——它的输出必须经过Host层解析，再以JSON传给另一个Server。这中间损耗的不仅仅是性能，更是灵活性。

维度五：维护成本

git、npm、docker、kubectl、aws、gh —— 这些CLI工具要么你装好系统就有，要么在官方源一键安装。它们有专门的团队维护，你不需要多写一行代码。

MCP Server呢？你写的，你维护。你团队写的，你团队维护。没人会帮你升级协议兼容性，也没人会帮你修状态机的bug。这就像你养了一笔技术债，每个月还得付利息。

四、战场实况：谁在放弃MCP？

先别管理论怎么说，看看事实——

Claude Code（Anthropic自家的AI编程工具）：底层大量使用系统CLI调用，git、npm、eslint 这些全走CLI，而不是MCP。

Cursor：Agent模式直接运行终端命令——npm run dev、python test.py、git diff，全是原生CLI调用。

Windsurf（Codeium的AI IDE）：正在从MCP集成转向更直接的CLI工具链集成。社区里已经有大量关于"MCP维护成本太高"的讨论。

OpenAI Codex CLI：2025年发布，整个设计哲学就是"用自然语言驱动CLI工具"。它甚至没有MCP，直接走 subprocess。

仔细想想：连Anthropic自己的旗舰产品都在大量使用CLI，MCP还有什么理由宣称自己是"唯一标准"？

五、明天就能用的三个实战

好了，理论说了不少。现在告诉你明天打开电脑就能做的事：

场景一：用Claude Code自动创建PR

打开Claude Code，在对话里说："分析最近5个commit，生成PR描述并创建PR。"

Claude Code会自动：

1. 执行 git log --oneline -5 → 拿到commit记录
2. 用LLM理解每个commit做了什么 → 生成PR描述
3. 执行 gh pr create --title "..." --body "..." → 创建PR

全程没有MCP。全是CLI。你不需要配置任何东西。

场景二：用Cursor分析日志

在Cursor的Agent聊天里说："分析app.log，按小时统计error出现的频率。"

Cursor会自动：

1. 执行 grep error app.log → 拿到所有error行
2. 用时间戳正则提取小时
3. 执行 sort | uniq -c → 统计频率
4. 返回给你一个清晰的分布表

场景三：构建你自己的AI+CLI工作流

你不需要等待工具官方支持某个功能。只要确保你的工具有CLI，AI就能操作它。

• Jira？用 jira-cli
• Kubernetes？用 kubectl
• AWS？用 aws-cli
• Notion？用 notion-cli（第三方）

核心原则：任何有CLI的工具，都是AI的原生工具。你根本不需要它支持MCP。

六、所以，MCP真的死了吗？

倒也不是。

MCP在某些场景下仍然有价值——特别是需要双向实时通信的复杂交互场景。比如AI Agent需要持续监控某个数据源的变化，或者需要跟浏览器做深度交互。

但问题在于：MCP当初被定位为"通用标准"，而现在它正在滑向一个"专用协议"。它没能成为AI连接万物的USB-C——它变成了一个需要特定适配器的专用接口。

而CLI，这个"原始"的文本流协议——因为太简单，所以不可替代；因为太古老，所以绝对可靠；因为太通用，所以万物皆可连。

七、最后一句话

当所有人都在造新轮子的时候，最聪明的人回到了那个最老的轮子。

AI时代的"通用协议"，不叫MCP——叫 /bin/sh。

延伸阅读（如果你想深挖）

• Anthropic MCP官方文档 — 了解MCP的设计哲学
• Unix哲学：Do One Thing and Do It Well — CLI背后的思想基石
• Claude Code文档 — 看看它怎么用CLI的
• OpenAI Codex CLI — "自然语言驱动CLI"的官方实现