MCP vs CLI：AI Agent 的协议之辩
2026年2月底到3月，AI 开发者社区爆发了一场关于 AI Agent 工具调用方式的激烈争论。一方说"MCP 已死，CLI 万岁"，另一方说"MCP 没死，我们只是太早了"。而飞书、钉钉、企业微信在同一周内开源各自的 CLI，用实际行动给出了第三种答案。
一、争论的起点：一句"MCP 是个错误"
2026年1月，OpenClaw 创始人 Peter Steinberger 在 X 上发了一条推文：
"mcp were a mistake. bash is better."
这条推文在 AI 开发者社区埋下了一颗种子。一个月后，Eric Holmes 发布博文《MCP is dead. Long live the CLI》，从六个维度系统论证 CLI 优于 MCP，引发了广泛讨论。随后 Jannik Reinhard 发布实测数据，Matt Hall 发布反驳文章，中文社区的掘金、头条上也出现了大量分析------这场争论在钉钉、飞书开源 CLI 时达到高潮。
二、唱衰 MCP 的三个核心论点
2.1 Token 吞噬：上下文效率的致命差距
Jannik Reinhard 用实测数据揭示了 MCP 最尖锐的问题------上下文吞噬。
一个 GitHub MCP Server 需要将 93 个工具的完整 Schema 注入模型上下文，总计约 55,000 tokens ------还没问任何问题，上下文就没了将近一半。多个 MCP Server 叠加，轻松突破 15 万 tokens。
他在 Intune 设备合规检查任务上做了并行对比：
| 指标 | MCP 方案 | CLI 方案 | 差距 |
|---|---|---|---|
| Schema 注入 | ~28,000 tokens | 0 tokens | --- |
| 推理 + 调用 | ~3,200 tokens | ~800 tokens | 4x |
| 50 台设备处理总消耗 | ~145,000 tokens | ~4,150 tokens | 35 倍 |
CLI 方案的 Agent 有 95% 的上下文窗口留给实际推理，而 MCP 方案的 Agent 大量精力花在解析 Schema 上。
为什么 CLI 更省？ 因为 AI 模型在数十亿行终端交互上训练过------Stack Overflow 答案、GitHub 仓库、man page。当你说 gh pr view 123，模型天然理解。而 MCP Schema 是模型运行时第一次见到的自定义抽象，需要额外的认知开销去理解。
社区基准测试也证实了这一点：CLI 的任务完成率高出 MCP 约 28%，Token 效率得分高出 33%。
2.2 调试地狱：看不见的工具
Eric Holmes 指出了 MCP 的可调试性问题：CLI 对人类可见，而 MCP 工具只存在于 LLM 对话内部。
shell
# CLI：出问题了，我自己跑一遍就知道
$ gh pr view 123
# 看到和 Agent 一样的输出
# MCP：出问题了，你得翻 JSON 传输日志
# 工具调用隐藏在 LLM 对话流里
# 没有 "自己跑一遍" 的选项这个痛点很真实。MCP 把工具调用封装在协议层后面，人类开发者失去了"复现 Agent 行为"的能力。
2.3 工程摩擦：部署之痛
- 初始化不稳定：MCP Server 启动失败、Claude Code 里冒出 100+ 僵尸 Node 进程
- 认证繁琐：每个 MCP Server 单独认证，没有 SSO
- 权限粗暴：all-or-nothing，无法区分"查看"和"删除"的风险等级
- 协议动荡：从 STDIO → SSE → Streamable HTTP，兼容性混乱
三、为 MCP 辩护：我们只是太早了
Matt Hall 的反驳文章《MCP Isn't Dead. We're Just Early.》代表了另一派观点。
3.1 CLI 自身的问题被低估了
- 输出不稳定：CLI 输出格式随意、版本间无警告就变更，Agent 误读时没有契约可验证
- 管道的脆弱性 ：
grep | jq | awk对人类来说灵活，但无类型管道容易静默失败，Agent 链式调用时边缘情况频发 - 认证无法延伸 ：
gh auth login对单个开发者够用，但无法支持多 Agent 协作、权限委派、Token 撤销
3.2 MCP 的价值在于结构化契约
Matt Hall 的核心论点是：MCP 的价值不是传输层，而是契约层。
类比 OpenAPI 对 REST 的作用：在 OpenAPI 之前，一千个 API 有一千种风格；OpenAPI 给了 REST 一个标准契约，让工具链、文档、测试都变得可用。MCP 在做同样的事------给 Agent-工具交互一个机器可验证的结构化契约。
当 MCP Server 暴露一个接口时，Agent 能获得：可用操作列表、参数结构、返回值类型。这比"读一段文档然后猜"要可靠得多。
3.3 从本地守护进程到托管基础设施
Matt Hall 还指出了 MCP 的演进方向：Streamable HTTP + OAuth 2.0。
早期 MCP 的问题是 Server 跑在本地------需要安装、管理、排障。但当 MCP Server 变成托管服务（像 Linear、Granola 已经在做的），用户不需要安装任何东西，指向一个 URL 完成 OAuth 就连上了。维护负担消失了。
这就像 REST API 早期也被吐槽"太多开销"，但最终证明底层抽象值得标准化。
四、实践中的答案：MCP 是协议，CLI 是实现
如果只看社区争论，你会觉得这是非此即彼的选择。但飞书、钉钉、企业微信的 CLI 开源给出了一个更务实的答案------MCP 和 CLI 不在同一层，它们是协议与实现的关系。
4.1 重新理解分层
- MCP 负责 integration（集成层）：标准化暴露能力、治理权限、工具发现
- CLI 负责 execution（执行层）：面向用户和 Agent 的命令行壳、结构化输出、本地脚本
4.2 三家平台的实际架构印证了这一点
钉钉 dws ：CLI 外壳下是完整的 MCP Client。它从 MCP 市场拉取服务注册表，通过 MCP initialize + tools/list 握手发现能力，再通过 MCP JSON-RPC 执行调用。CLI 只是把 MCP 的能力"翻译"成了 dws calendar event list 这样的命令行格式。
企业微信 wecom-cli：同样是一个 MCP Client 的 CLI 壳。Rust 核心通过 JSON-RPC 与服务端通信，npm 层做跨平台分发。
飞书 larksuite/cli：虽然没用 MCP 协议名，但做的事情等价------从 OpenAPI 元数据构建命令树，服务端定义能力，CLI 透传调用。本质上也是"协议层 + 实现层"的分层。
4.3 回看社区争论：两边都没错，但都只说了一半
| 论点 | "CLI 派"说得对的部分 | "MCP 派"说得对的部分 |
|---|---|---|
| Token 效率 | ✅ CLI 不注入 Schema，上下文更轻 | ⚠️ 但如果 CLI 文档不好，Agent 会猜错 |
| 可调试性 | ✅ CLI 对人类可见，可复现 | ⚠️ MCP 的结构化契约让错误可验证 |
| 可组合性 | ✅ 管道是 Linux 五十年的积累 | ⚠️ 无类型管道对 Agent 容易静默失败 |
| 认证 | ✅ CLI 的 auth 已经很成熟 | ⚠️ 无法延伸到多 Agent、多租户场景 |
| 部署复杂度 | ✅ 本地 MCP Server 确实不稳定 | ⚠️ 托管 MCP 会消除这个问题 |
两边说的都是真实的痛点，但解决方案不是二选一------而是分层组合。
五、Token 效率：这场争论中最硬的数据
Token 效率是整个争论中最有说服力的维度。ScaleKit 的 benchmark 数据给出了量化的结论：
| 指标 | CLI | MCP | 差距 |
|---|---|---|---|
| Token 消耗 | 基准 | 9-32 倍 | MCP 多出一个数量级 |
| 成本 | 基准 | 17 倍 | MCP 贵得多 |
| 失败率 | 0% | 有明确失败率 | MCP 更不可靠 |
~28,000 tokens"] M2["工具选择
~3,200 tokens"] M3["调用 + 解析
~6,300 tokens"] M4["50 台设备
总计 ~145,000 tokens"] M1 --> M2 --> M3 --> M4 end subgraph CLI_TOKENS["CLI Token 消耗"] C1["Schema 注入
0 tokens"] C2["命令组合
~800 tokens"] C3["执行 + 解析
~3,350 tokens"] C4["50 台设备
总计 ~4,150 tokens"] C1 --> C2 --> C3 --> C4 end style M4 fill:#ff6b6b,color:#fff style C4 fill:#51cf66,color:#fff style C1 fill:#51cf66,color:#fff
这个差距的根本原因是：CLI 把知识放在了模型的训练数据里 （数十亿行终端交互），而 MCP 把知识放在了运行时的上下文窗口里（每个 Server 的 Schema 定义）。
前者是一次性成本（训练时已经付了），后者是每次调用都要付的持续成本。
六、Trevin Chow 的七个原则：Agent 友好的 CLI 长什么样？
这场争论催生了一个建设性的产出------Trevin Chow 在构建多个为 Agent 优化的 CLI 后，总结了七个设计原则：
- 默认非交互：不要弹交互式提示，Agent 无法处理
- 结构化可解析输出 ：
--format json是标配，不要只给人类可读的表格 - 快速失败 + 错误可操作：报错要告诉 Agent 怎么修，而不是只说"失败了"
- 安全重试 + 明确变更边界：幂等操作、dry-run 预览
- 渐进式帮助发现 ：
--help和子命令帮助让 Agent 按需获取信息 - 可组合 + 可预测结构：输出格式一致，可被管道串联
- 有界 + 高信噪比响应：限制输出量，不要把整个数据库 dump 出来
这些原则的核心洞察是：每一条同时让 CLI 对人类更好------结构化输出、操作错误、有界响应不是对 Agent 的妥协，而是一直应该做的设计。
七、结论：不是二选一，而是分层
回到最开始的问题：MCP 和 CLI 到底谁赢了？
答案是都不完全对。正确的理解是：
命令行壳 + --format json
Skills 文档 + 本地脚本"] L_MCP["MCP 协议层（集成标准）
能力发现 + 权限治理
结构化契约 + 审计"] L_API["平台 API（业务能力）
钉钉 / 飞书 / 企业微信"] L_AGENT -->|"命令调用"| L_CLI L_CLI -->|"JSON-RPC"| L_MCP L_MCP -->|"HTTP"| L_API end style L_CLI fill:#51cf66,color:#fff style L_MCP fill:#1976d2,color:#fff
- MCP 不会死，但会退到它该在的位置------作为集成层的标准化协议，负责能力暴露、权限治理、工具发现
- CLI 不是万能的，但它是面向 Agent 和人类的最佳执行入口------轻量、可调试、Token 高效
- 最优架构是两者组合：MCP 负责 integration，CLI 负责 execution
飞书、钉钉、企业微信已经在实践这个分层了。它们的 CLI 外壳下面跑的都是 MCP 协议（或等价的 OpenAPI 元数据驱动），只是把 MCP 的能力"翻译"成了更友好的命令行格式。
社区争论了一个月，最后发现大厂早就想清楚了------协议和实现从来就不是对立的。
参考资料
- Eric Holmes, "MCP is dead. Long live the CLI" , 2026-02-28 ejholmes.github.io/2026/02/28/...
- Matt Hall, "MCP Isn't Dead. We're Just Early." , 2026-02 matthewhall.com/posts/mcp-i...
- Jannik Reinhard, "Why CLI Tools Are Beating MCP for AI Agents" , 2026-02-22 jannikreinhard.com/2026/02/22/...
- Trevin Chow (@trevin), Agent 友好型 CLI 设计原则, 2026-03 x.com/trevin/stat...
- Peter Steinberger (@steipete), "mcp were a mistake. bash is better." , 2026-01 x.com/steipete/st...