从 MCP 到 CLI：AI Agent 的"接口之争"，终端才是终局

2024 年 11 月，Anthropic 发布 MCP（Model Context Protocol），号称"AI 世界的 USB-C"，要用一个标准协议统一大模型与外部世界的所有连接。一时间社区沸腾，MCP Server 如雨后春笋，GitHub 上冒出几千个实现，每个 AI IDE 都在争相接入。

然而 MCP 的"一周年纪念日"，却在一片寂静中度过。

2026 年 3 月，Perplexity 联合创始人兼 CTO Denis Yarats 在公司内部宣布：放弃 MCP，转而使用 API 和 CLI。 同一时期，全球最火的开源 AI Agent 项目 OpenClaw——其创始人 Peter Steinberger 已加入 OpenAI——干脆从一开始就不支持 MCP 协议，而是用自己的 Skills 系统 + CLI 替代。

讽刺的是，"Perplexity 放弃 MCP"成了近几个月 MCP 声量最高的事件。网友们的评论一边倒："早该如此。"

这篇文章想聊的是：MCP 到底出了什么问题？为什么行业头部玩家纷纷倒戈 CLI？AI Agent 的工具交互，终局到底长什么样？

一、MCP 的天生缺陷：不只是"不好用"，而是"设计上有病"

先给 MCP 说句公道话：它要解决的问题是真实的。大模型需要连接外部世界——数据库、API、文件系统、第三方服务——但每个工具都要单独适配，开发成本极高。MCP 试图用一套标准协议（基于 JSON-RPC 2.0）统一这一切。

想法是好的，但执行出了大问题。

1.1 致命缺陷：线性上下文成本

MCP 的协议模式是：定义一组工具（带有 Schema 的函数），将其注入 Agent 的上下文窗口，然后让 Agent 调用它们。

这种模式可行，但难以为继。

核心问题在于——你添加的每一个 MCP 工具，包括它的名称、描述、参数 Schema 和示例，都会占用 Agent 的上下文窗口。如果你连接 10 个服务，每个服务有 5 个工具，那么在 Agent 开始执行任何任务之前，你就已经烧掉了数千个 Token。

据社区开发者反馈，仅加载一个 Playwright MCP Server 就会占用 200K 上下文窗口的 8%。在多轮对话中，这会迅速累积，导致成本飙升和推理能力下降。

上下文窗口是 LLM 最稀缺的资源。你把它的 1/3 塞满了"菜单"，留给"正事"的空间就少了。开发者只能在三种不理想的方案中做选择：

预加载所有工具：性能下降，成本飙升
限制集成数量：违背了"连接一切"的初衷
构建动态加载机制：引入额外的复杂度，MCP 就不"标准"了

Anthropic 自己在工程博客里也承认了这个问题。他们提出的"Code Execution with MCP"方案，让 Agent 通过写代码而非调用工具来交互，Token 使用量从 150,000 降至 2,000，节省 98.7%。

等等——Anthropic 自己都在告诉你：别用标准的 MCP 工具调用，写代码更高效？ 这不是在打自己的脸吗？

1.2 日常使用的三座大山

如果说上下文成本是理论缺陷，那日常使用中的摩擦才是压垮骆驼的稻草。

初始化地狱：MCP Server 经常启动失败。配置文件写错一个逗号、环境变量漏了一个、端口被占用了……结果就是疯狂重启、清空状态、从头再来。你以为在用 AI 提升效率，实际上一半时间在调 MCP Server。

认证疲劳：每个 MCP 工具都需要单独认证——GitHub 要 Token、数据库要密码、云服务要 Key。而且这些认证还经常失效，需要无休止地重新授权。

权限粗糙：MCP 的权限控制非黑即白——要么完全信任 Server，要么完全不用。你没法说"我只给你读权限，不给写权限"或者"你只能查这张表，不能查那张表"。这在企业场景中是不可接受的安全隐患。

1.3 "builder 多于 user"：一个危险信号

从 MCP 发布以来，社区里一直有个尖锐的观察：写 MCP Server 的人，比用 MCP Server 的人多。

这不是段子。你去 GitHub 上搜"MCP Server"，能找到几千个实现。但你问问身边的开发者——有几个人的日常工作流里真的用到了 MCP Server？大多数人的体验是：装了，试了，卡了，卸了。

更糟糕的是，大量 MCP Server 本质上只是现有 API 的套壳——在 REST API 外面包了一层 JSON-RPC 中间层。你本来可以直接调 GitHub API，现在要通过 MCP Server 中转一下，多了一层抽象，多了一层出错的可能，但没带来任何新能力。

当一个标准的主要产出是"把已有能力重新包装"，这个标准就值得怀疑了。

1.4 安全模型的先天缺陷

MCP 还引入了一个全新的攻击面：Prompt Injection 可以通过工具返回的数据注入恶意指令。 一个看似无害的"读取文件"工具，返回的内容里可能包含精心构造的指令，劫持 Agent 的后续行为。

每个 MCP Server 都是一个独立进程，拥有自己声明的权限范围。但谁来验证这些声明是否属实？谁来防止恶意 Server 滥用权限？

有人替 MCP 辩护说"MCP 有明确的权限控制"，但现实是：使用带白名单的沙箱执行 CLI 命令一样安全，甚至更安全——因为 CLI 的执行完全透明，每条命令都可审计。

二、行业倒戈：从 Perplexity 到 OpenClaw

MCP 的问题不是某个人的吐槽，而是行业头部玩家用行动投票。

2.1 Perplexity：CTO 亲自宣布放弃

2026 年 3 月，Perplexity CTO Denis Yarats 在公司内部明确表态：放弃 MCP，全面转向 API + CLI。

这不是一个小团队的边缘决策，而是估值 $180 亿的 AI 独角兽的技术路线选择。Perplexity 作为 AI 搜索赛道的头部玩家，在实际使用中遇到了上述所有问题，最终做出了"止损"的决定。

这个消息一出，社交媒体上几乎是一边倒的赞同。说明 MCP 的问题不是个例，而是共识。

2.2 OpenClaw：从一开始就拒绝 MCP

OpenClaw（原名 Clawdbot）是 2026 年开年以来全球最火的开源 AI Agent 项目。创始人 Peter Steinberger 是奥地利知名开发者（PSPDFKit 创始人，后加入 OpenAI），这个项目仅用不到四个月就登上 GitHub 全球第一。

但 OpenClaw 从一开始就不支持 MCP 协议。

这不是疏忽，而是刻意的技术选择。OpenClaw 的核心架构是 Gateway-Node-Channel 三层解耦，能力扩展依靠的是Skills（技能包）系统，而非 MCP。

Skills 系统和 MCP 有本质区别：

维度	MCP	OpenClaw Skills
加载方式	预加载所有工具定义到上下文	按需加载，需要什么加载什么
上下文成本	线性增长，工具越多越贵	最小化，只加载当前任务需要的 Skill
能力边界	限于已实现的 MCP Server	操作系统级别，CLI + API 无限扩展
知识注入	只定义工具接口	包含领域知识（怎么用、什么场景、最佳实践）
开发成本	需要实现 JSON-RPC Server	写一个 Markdown 文档 + 一个脚本

一句话总结：MCP 解决了"能够连接"的问题，但没有解决"知道如何使用"的问题。 拥有数据库连接能力，不等于 Agent 知道如何编写高效且安全的 SQL；能够访问文件系统，不意味着它理解特定项目的代码结构和开发规范。

Skills 系统补上了这一层——每个 Skill 不仅告诉 Agent "你能用什么工具"，还告诉它"怎么用好这个工具"。

2.3 三巨头的 CLI 布局

不只是 Perplexity 和 OpenClaw。2025 年，三大 AI 巨头几乎同时做了同一个决定：把最强的模型，塞进终端命令行。

Anthropic：发布 Claude Code（claude 命令）
Google：发布 Gemini CLI（gemini 命令），Apache 2.0 开源
OpenAI：发布 Codex CLI（codex 命令），开源

这不是巧合，这是集体投票。而且注意——这三个 CLI 工具本身都不依赖 MCP 协议。 它们直接执行 Shell 命令、读写文件系统、调用系统工具。操作系统就是它们的"工具服务器"。

维度	Claude Code	Gemini CLI	Codex CLI
开发商	Anthropic	Google	OpenAI
底层模型	Claude Opus/Sonnet	Gemini Pro/Flash	GPT/Codex
开源	❌（商业）	✅（Apache 2.0）	✅
核心优势	Agent 自主性最强	免费额度慷慨	编程能力强
工具调用	直接执行 Shell 命令	直接执行 Shell 命令	直接执行 Shell 命令
上下文	文件系统 + git history	文件系统	文件系统
权限控制	Plan Mode / Auto Accept	权限确认	沙箱执行

注意"工具调用"那一行：三个工具全部选择了直接执行 Shell 命令，没有一个选择 MCP。

三、CLI 凭什么赢？Eric Holmes 的三个论证

开发者 Eric Holmes 在一篇被广泛传播的博客中，系统阐述了 CLI 优于 MCP 的三个核心论证。这些观点引发了整个行业的共鸣。

3.1 透明性与可调试性

在 CLI 下，人类可以看到 AI 运行的每一条具体命令：

$ jira issue view PROJ-123
$ git log --oneline -10
$ kubectl get pods -n production

输入输出一目了然，出了问题一眼就能排查。

而在 MCP 下，工具调用隐藏在复杂的 JSON-RPC 交互内部：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "jira_get_issue",
    "arguments": {"issue_key": "PROJ-123"}
  },
  "id": 1
}

出了问题？你得去翻 MCP Server 的日志，检查 JSON-RPC 的请求和响应，排查序列化/反序列化是否有问题，确认传输层（Stdio? SSE? WebSocket?）没出错——整个调试链条拉长了三倍。

3.2 可组合性：Unix 管道 vs JSON 嵌套

CLI 工具天生支持管道组合：

# 找出生产环境最近一小时的错误，按频率排序
kubectl logs -n prod deployment/api --since=1h | grep ERROR | sort | uniq -c | sort -rn | head -20

五个简单命令通过管道串联，完成了一个复杂的日志分析任务。每个中间结果都可以单独查看和验证。

同样的事情用 MCP 怎么做？你需要一个"读日志"的 MCP Server，一个"文本处理"的 MCP Server，然后让模型在它们之间传递数据——每次传递都要经过 JSON 序列化/反序列化，每次传递都要把数据回传到模型的上下文窗口。

管道是数据在进程间直接流动，MCP 是数据在模型的上下文窗口里反复折叠。

3.3 利用现有生态：LLM 天生会用 CLI

这是最被低估的一点。当今所有主流 LLM，都在海量的 man 手册、Shell 脚本、Stack Overflow 回答中训练过。模型天生就"会用" git、curl、grep、docker。

你让 Claude 执行 jira issue view PROJ-123，它立刻就知道怎么解读输出。你让它调用一个叫 jira_get_issue 的 MCP 工具——这个工具名在它的训练数据里可能根本不存在，它需要完全依赖 Schema 描述来理解该工具的行为。

CLI 工具经过数十年的迭代，拥有成熟的认证体系、完善的文档和庞大的用户社区。MCP 想从零重建这一切，不是不可能，但为什么要重新造轮子？

有人替 MCP 辩护说"MCP 提供类型化结构和验证"。反驳很简单：写得好的 CLI 工具同样有参数验证——git push --force 会提示危险操作，kubectl delete namespace 会要求确认，rm -rf / 会拒绝执行。

还有人说"MCP 是个标准"。回怼也很直接：一个会导致上下文爆炸的标准，哪怕被 ISO 认证了，也还是个烂标准。

四、从"连接一切"到"掌控一切"：Agent 架构的范式转移

MCP vs CLI 之争的背后，是 AI Agent 架构的一次范式转移。

4.1 MCP 时代：Agent 是"调度员"

                    ┌── MCP Server A (GitHub)
用户 → Agent ──────┼── MCP Server B (Database)
                    └── MCP Server C (Slack)

Agent 的角色是调度员——根据用户意图选择合适的工具，发送 JSON-RPC 请求，接收结果，组合答案。Agent 不直接接触底层系统，一切都通过 MCP 的标准接口代理。

问题是：调度员能做的事情，永远受限于它连接的 Server 提供了什么工具。 没有对应的 MCP Server？Agent 就抓瞎。

4.2 CLI 时代：Agent 是"操作员"

用户 → Agent → Shell → 操作系统（文件/网络/进程/一切）

Agent 的角色是操作员——直接在操作系统上执行命令，拥有与人类开发者相同的能力边界。想读文件就 cat，想搜代码就 grep，想装依赖就 npm install，想部署就 kubectl apply。

Agent 的能力上限等于操作系统的能力上限。 不需要等谁写一个 MCP Server，不需要等生态补齐，man 页面就是工具文档，--help 就是 Schema。

4.3 最深层的矛盾：描述 vs 执行

MCP 是把工具的能力描述给模型看（通过 JSON Schema），然后模型选择要调用的工具。

CLI 是让模型直接编写和执行命令。

前者的问题在于：描述永远是有损的。一个工具的 JSON Schema 无法完整表达它的所有能力、限制和边界条件。

后者的优势在于：执行就是最好的理解。 模型跑一个命令，看到输出，根据输出调整下一步——这是经典的 REPL 循环，也是最高效的探索式问题解决方式。

4.4 OpenClaw 模式：Skills 才是正确的抽象层

如果说 MCP 是"错误的抽象层"，那 OpenClaw 的 Skills 系统可能是"正确的抽象层"。

Skills 的设计哲学是：

按需加载：不预注入所有工具定义，Agent 遇到特定任务时才加载对应的 Skill
知识 + 工具：每个 Skill 不仅包含"能调什么"，还包含"怎么调好"——领域知识、最佳实践、常见陷阱
底层走 CLI：Skill 内部的实际执行，还是通过 CLI 命令和 API 调用完成

这等于说：上层用 Skills 管理"做什么"和"怎么做"，下层用 CLI 管理"具体执行"。 MCP 那个夹在中间的 JSON-RPC 协议层，完全多余。

MCP 模式：     Agent → JSON-RPC → MCP Server → API/CLI
Skills 模式：  Agent → Skill（知识+策略） → CLI/API（直接执行）

少了一层抽象，多了一层智慧。

五、反直觉的预判：MCP 不会彻底消亡，但会"下沉"

说了这么多 MCP 的问题，我的判断并不是"MCP 彻底死了"。更准确的说法是：

MCP 会从"AI 工具的通用标准"下沉为"企业集成的中间件协议"，而 CLI + Skills 会成为 Agent 与世界交互的主要方式。

这跟历史上的很多技术演进是一致的：

类比	"协议层"	"直接操作层"	最终格局
Web 服务	SOAP/WSDL	REST/HTTP	SOAP 退守企业内部
容器编排	Mesos/DCOS	Docker CLI + K8s	Docker CLI 成为开发者标准
数据库	ODBC/JDBC	psql/mysql CLI	协议层隐入底层
AI 工具	MCP	CLI + Skills	MCP 退守企业集成层

每一次，"更简单、更直接"的方案都赢了面向开发者的市场。

MCP 在以下场景仍然有价值：

非技术用户的 AI 产品：Claude Desktop、Copilot Studio 等产品的内部协议，用户无感知
企业 IT 集成：统一鉴权、审计、限流，IT 部门用它管理 AI 与内部系统的连接
跨组织边界：当需要跨公司、跨平台共享工具定义时，标准协议仍有意义

但对于开发者的日常工具交互——这个 AI 工具最大的使用场景——CLI 已经胜出。

5.1 社区用脚投票

2026 年初，GitHub 上最火的 AI 项目不是 MCP Server，而是 CLI Agent：

OpenClaw（GitHub 全球第一）—— 不支持 MCP，用 Skills + CLI
OpenCode（99.8K Star）—— 开源 CLI Coding Agent，支持 75+ 模型
Aider —— 终端内的 AI Pair Programming
各种 CLI wrapper —— 把各家 API 包装成终端命令

与此同时，curl、sed、awk、grep 这些"古董级"命令行工具迎来了第二春。它们曾是极客的标配，被现代框架和 GUI 工具埋没了十几年。现在有了 AI Agent 这个"全能司机"，这些工具的组合威力被重新释放出来——每个开发者都拥有了一支"CLI 大神军团"。

六、对开发者的建议

如果你是工具开发者

优先提供 CLI 接口，而不是只提供 MCP Server。一个好的 CLI 工具，AI Agent 可以直接调用；一个只有 MCP 接口的工具，在终端 Agent 面前是隐形的
写好 --help 和文档。对 AI Agent 来说，man 页面就是 JSON Schema，--help 就是工具描述
支持管道和标准输入输出。Unix 管道是最古老也最强大的"工具组合协议"

如果你是 AI 应用开发者

终端优先。你的用户大概率是开发者，他们在终端里最高效
考虑 Skills 模式。不要只定义"工具接口"，要把"怎么用好"的知识一起注入
MCP 作为后备。面向非技术用户或企业集成时，MCP 仍有一定价值

如果你是普通开发者

学好你的 Shell。在 AI 时代，精通终端不是过时了，而是比以往任何时候都重要。你对 Shell 的理解深度，直接决定了你能多有效地指挥 AI Agent
拥抱 CLI Agent。Claude Code、Gemini CLI、OpenClaw——选一个用起来。不是"尝鲜"，是真的用它写生产代码
别囤 MCP Server 了。如果你花了很多时间学写 MCP Server，也不用焦虑——核心的 API 调用逻辑是通用的，改成 CLI 工具或 Skill 成本很低

写在最后

技术世界有一条反直觉的规律：看起来"落后"的方案，往往比看起来"先进"的方案活得更久。

REST 比 SOAP 活得久，不是因为它更强大，而是因为它更简单。Docker CLI 比 Mesos 活得久，不是因为它功能更全，而是因为开发者能直接上手。

MCP 是一个精心设计的协议，它解决了一个真实的问题。但 CLI——这个 50 年前就存在的交互方式——在 AI 时代焕发了第二春，原因同样简单粗暴：

它不需要你学习新东西。它只是让你已经会的东西变得更强。

当 AI 足够智能，最好的"工具协议"就是自然语言 + 操作系统。不需要 JSON-RPC，不需要 Schema，不需要 Server。你说一句话，Agent 在终端里帮你搞定。

终端，是人类与计算机对话的第一个界面。当 AI 真正成熟的那天，它可能也是最后一个。

相关链接：

参考文章：MCP已死，CLI当立！https://zhuanlan.zhihu.com/p/2015841871449040128

Eric Holmes 博客：CLI 在 AI Agent 中的优势

Perplexity CTO Denis Yarats 放弃 MCP 声明

OpenClaw 项目：https://github.com/openclaw/openclaw

Claude Code：https://docs.anthropic.com/en/docs/claude-code

Gemini CLI：https://github.com/google-gemini/gemini-cli

OpenAI Codex CLI：https://github.com/openai/codex

MCP 官方文档：https://modelcontextprotocol.io/

Anthropic MCP 代码执行博客：https://anthropic.com/engineering/code-execution-with-mcp

欢迎关注公众号 coft，获取更多 AI 前沿技术文章。

posted @ 2026-03-14 13:51 warm3snow 阅读(0) 评论(0) 收藏举报

刷新页面返回顶部

warm3snow

从 MCP 到 CLI：AI Agent 的"接口之争"，终端才是终局

从 MCP 到 CLI：AI Agent 的"接口之争"，终端才是终局

一、MCP 的天生缺陷：不只是"不好用"，而是"设计上有病"

1.1 致命缺陷：线性上下文成本

1.2 日常使用的三座大山

1.3 "builder 多于 user"：一个危险信号

1.4 安全模型的先天缺陷

二、行业倒戈：从 Perplexity 到 OpenClaw

2.1 Perplexity：CTO 亲自宣布放弃

2.2 OpenClaw：从一开始就拒绝 MCP

2.3 三巨头的 CLI 布局

三、CLI 凭什么赢？Eric Holmes 的三个论证

3.1 透明性与可调试性

3.2 可组合性：Unix 管道 vs JSON 嵌套

3.3 利用现有生态：LLM 天生会用 CLI

四、从"连接一切"到"掌控一切"：Agent 架构的范式转移

4.1 MCP 时代：Agent 是"调度员"

4.2 CLI 时代：Agent 是"操作员"

4.3 最深层的矛盾：描述 vs 执行

4.4 OpenClaw 模式：Skills 才是正确的抽象层

五、反直觉的预判：MCP 不会彻底消亡，但会"下沉"

5.1 社区用脚投票

六、对开发者的建议

如果你是工具开发者

如果你是 AI 应用开发者

如果你是普通开发者

写在最后

转载声明

公告