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

一个 AI 圈最打脸的故事：新造的"万能协议"正在被一个 50 岁的老东西取代，而且输得毫无悬念。

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

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

为什么？因为 CLI 简单到极致：文本进、文本出，没有 JSON 握手、没有状态管理、没有协议兼容性问题。而你装好系统就有的 git、npm、docker、kubectl，就是最好的 AI 工具连接层。

明天你就能用：打开 Claude Code 或 Cursor，别去配 MCP Server，直接用自然语言描述需求，让它调用系统 CLI 工具——比你费劲配一套 MCP 靠谱 100 倍。

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

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	CLI
写一个 Server/工具	需要理解 JSON-RPC、状态管理、协议规范。新手第一周还配不齐环境。	写个脚本，输出到 stdout。新手五分钟搞定。
生态规模	~200+ 个 MCP Server（增长速度慢，维护成本高）	数十万个CLI 工具（整个 Unix/Linux/Node/Python 生态系统）

维度二：调试难度

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 的组合武器叫管道符 |：

1 .# 找出代码仓库里所有TODO注释，按类型统计
2. 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。

感兴趣的可以了解一下我整理的表单，//jsj.top/f/o38ijj

作者：web_Leon

来源：稀土掘金