原文：https://mp.weixin.qq.com/s/s9Y6I7wOpeL7xVbmo6mInA

先说清楚这个争论

2026 年，AI Agent 圈有一个争论越来越热：

到底该用 MCP 还是 CLI？

Perplexity 的 CTO 在公开场合说公司内部正在降低 MCP 的优先级。YC CEO Garry Tan 说 MCP 吃掉太多上下文窗口，认证机制也有问题，他自己用 30 分钟造了个 CLI 替代品。Hacker News 上反 MCP 的声音越来越多。

与此同时，OpenClaw 创始人 Peter Steinberger 在 X 上说了一句话，被广泛转发："当 Agent 能直接跑命令行，为什么还要多一层协议？"——然后他造了 MCPorter，一个把 MCP 服务器转换成 CLI 工具的工具。

这个争论不是在争谁更高级，而是触碰了一个真实的架构问题。

MCP 是什么，CLI 是什么

CLI（命令行工具）：git status、gh pr list、docker ps——Agent 直接在终端里跑这些命令，拿到输出，继续干活。

模型在训练数据里见过海量的命令行操作，知道怎么用这些工具。零额外配置，直接可用。

MCP（Model Context Protocol）：Anthropic 制定的开放标准，定义了 Agent 和外部工具之间通信的统一格式。工具方（数据库、GitHub、Slack……）把自己的能力包装成 MCP 服务器，Agent 通过 tools/list 发现有哪些工具，通过 tools/call 调用它们。

相当于给所有工具装了一个统一的插头——理论上，任何遵循 MCP 标准的工具，都能接进任何支持 MCP 的 Agent。

为什么这个争论会出现：一个真实的 Token 问题

Scalekit 做了一组基准测试，结果很直接：

完成同一个 GitHub 任务：

为什么差这么多？

GitHub 的 MCP 服务器暴露了 43 个工具。Agent 连上它之后，这 43 个工具的完整 schema——名称、参数、描述、用法——全部注入上下文。不管 Agent 用不用这些工具，schema 都在那里占着空间。

对一个简单的"查一下这个 PR 的状态"任务，Agent 实际只用了 1-2 个工具，但要带着另外 41 个工具的 schema 全程陪跑。

用 CLI 的话，Agent 直接跑 gh pr view 123 --json title,state，几百个 Token 搞定，连发现工具的步骤都省了——因为模型训练时就见过这个命令，直接知道怎么用。

这就是 MCP 的 Token 税。

连接的服务器越多，税越重。有人测过接 4 个 MCP 服务器（GitHub、数据库、Microsoft Graph、Jira），光工具 schema 就用掉 150,000+ Token——上下文窗口还没开始干活就去了一大半。

那 MCP 没用了？不对

这个结论跳得太快。CLI 赢了个人开发者场景，但输了另一个场景。

CLI 的根本限制：你的凭证，你的权限。

Agent 跑 CLI，用的是你本地配置好的身份——你的 GitHub Token、你的 AWS 凭证、你的数据库密码。这对你自己的工作流完全没问题。

但如果你在做一个产品，你的用户要通过你的 Agent 访问他们自己的 GitHub、他们自己的 Salesforce、他们自己的工作区——这就不是"用我的凭证跑 CLI"能解决的了。

你需要：

• 每个用户独立的 OAuth 认证

• 用户级别的权限隔离

• 结构化的审计日志

• 多租户的访问控制

这些东西，MCP 天然支持，CLI 做不到。

还有另一个场景：没有 CLI 的系统。

Salesforce 没有 CLI。Workday 没有 CLI。Greenhouse 没有 CLI。这些 SaaS 系统只有 API，而且通常还是需要 OAuth 的复杂 API。MCP 是为这种场景生的，CLI 根本进不了门。

结论：不是选边，是按场景分工

业界在这个争论里形成的共识，比"谁赢了"更有意思：

CLI 适合的场景：

• 模型训练数据里见过这个工具（git、gh、aws、docker……）

• 本地执行，不需要多用户身份

• 高频率、轻量级的操作（每次调用成本必须低）

• 循环处理大批量数据（150 个 API 请求，CLI 可以写 for 循环，MCP 要调 150 次工具）

MCP 适合的场景：

• SaaS 系统（Salesforce、Workday，根本没有 CLI）

• 需要 OAuth 多用户身份的产品

• 需要审计日志和权限隔离的合规场景

• 工具发现——不知道有什么可用时，MCP 能自动告诉 Agent

最聪明的架构：同时用两个，按任务选择。

Claude Code 就是这样做的——本地文件操作和代码执行走 CLI，SaaS 集成走 MCP，用 Skills 这一层把两者统一封装，Agent 不需要关心下面走的是哪条路。

三个框架各自怎么站队

OpenClaw：MCP 作为生态继承层

OpenClaw 接 MCP 的出发点很直接：外面已经有 5,800+ 个 MCP 服务器，不用自己造轮子。

配置就是在 openclaw.json 里加一段 mcpServers，连上哪个服务器，Agent 就能用哪个服务器的工具。GitHub、Postgres、Slack、Notion——统统可以接。

但 OpenClaw 没有做工具的按需加载优化。接的服务器越多，上下文里的工具 schema 就越多，Token 消耗线性增长。社区实践发现，接超过 5-6 个 MCP 服务器后，上下文压力就开始变得明显。

对 CLI 的支持，OpenClaw 主要通过 Skills 系统——用 Skill 封装命令行操作，Agent 调用 Skill，Skill 去跑命令。这条路已经跑通，但没有形成 MCP 那样统一的发现和接入机制。

总结：MCP 是 OpenClaw 的主要扩展路径，CLI 是补充。生态规模是最大优势，Token 效率是短板。

Claude Code：两条路都走，Skills 统一封装

Claude Code 对这个问题给出了最系统的架构答案。

CLI 是默认执行方式。 Claude Code 本质上是一个能跑终端命令的 Agent，文件操作、代码执行、Git 操作——全部走 Shell。这是最轻量、最高效的路径。

MCP 是结构化扩展层。 接入 MCP 服务器时，Claude Code 做了一个关键优化：延迟加载（defer_loading: true）——Session 启动时只加载工具名称，完整 schema 只在真正需要时才加载。这把 MCP 的 Token 税从"全量预付"变成了"按需支付"。

同时有 tool search 机制——Agent 通过语义搜索找到相关工具，而不是遍历整个工具列表。

Skills 是统一接口层。 不管下面走的是 CLI 还是 MCP，对 Agent 来说都是调用一个 Skill。这个抽象让 Agent 不需要关心传输细节，也让同一个任务可以灵活地在两种路径之间切换。

从源码泄露里还能看到：Claude Code 的内置工具（文件读写、Shell 执行）和 MCP 工具，走的是同一套工具注册表——统一的权限门控、统一的 schema 验证，没有内外之分。Computer Use 功能本身也是作为 @ant/computer-use-mcp 实现的——Anthropic 没有为它写专用管道，而是用 MCP 服务器的标准接口实现。

总结：CLI 干活，MCP 扩展，Skills 统一，三层分工最清晰。

Hermes Agent：MCP 客户端 + MCP 服务器，双向参与

Hermes Agent 对 MCP 的处理有一个独特的角度：它不只是 MCP 客户端，自己也能作为 MCP 服务器。

hermes mcp serve 命令让 Hermes 把自己的会话历史和记忆暴露给 MCP 客户端——Claude Desktop、VS Code、Cursor 可以通过 MCP 协议查询 Hermes 的历史记录。这让 Hermes 的记忆不只是给自己用，也可以被其他 AI 工具调用。

Hermes 还有 ACP（Agent Communication Protocol），专门用于和编辑器的双向通信——编辑器把当前打开的文件和光标位置告诉 Hermes，Hermes 据此更准确地理解任务上下文。

安全处理上，Hermes 对 MCP 子进程做了环境变量隔离——主机上的敏感凭证默认不传入 MCP 服务器进程，需要某个环境变量的服务器必须在 Skill 里显式声明。

CLI 方面，Hermes 通过六种执行后端支持本地和远程的命令行执行，但没有形成 MCP 那样的统一发现接口。

总结：MCP 双向参与是最大特色，安全处理最保守，CLI 是执行选项之一但不是核心路径。

这个争论的真正答案

MCP vs CLI 不是非此即彼的选择，是按场景分工的问题。

一句话总结行业共识：

CLI 处理模型已经知道的工具，MCP 处理需要发现和认证的工具。

对个人开发者的工作流，CLI 更快更便宜。对面向用户的产品，MCP 解决了 CLI 解决不了的多用户认证问题。对没有 CLI 的 SaaS 系统，MCP 是唯一选项。

最成熟的 Agent 架构——比如 Claude Code——已经内部解决了这个问题：CLI 和 MCP 并行运行，Skills 这一层做统一封装，Agent 不用操心下面走的是哪条路。

这个问题社区还在热烈讨论，但架构答案其实已经在产品里了。