2026 年 AI 工程圈最热闹的对线：
Perplexity CTO 怒删 MCP，回归 CLI；
Anthropic 推 Progressive Discovery，说 MCP 能降本 85%；
Scalekit 跑 75 次基准，MCP token 是 CLI 的 32 倍；
Arize 的 eval 却说：MCP 在某些任务上反而更快更便宜。
到底谁对？谁错？谁在断章取义？
今天我们把所有公开数据摊在桌上，扒个底朝天。

---

先给结论（建议你先看完再喷）

没有"谁吊打谁"。只有"在哪些约束条件下，谁有结构性优势"。

• 本地、有成熟 CLI、模型熟悉、无需多租户鉴权 → CLI+Skill 在 token（4–32×）和可靠性（100% vs 72%）上碾压
• 任务干净映射到 MCP 单个端点（如 create_branch + create_pr）→ MCP 反而更快更便宜
• 跨过"代理他人操作"的边界（OAuth、租户隔离、审计）→ MCP 目前无可替代
• 2026 年的 Progressive Discovery 正在快速缩小 token 差距（85% 降本），但 CLI 的"零 schema 开销 + shell 组合性"仍是结构性优势

真正的问题是"代理在替谁执行"，而不是"哪个协议更好"。

---

一、先别急着站队，搞清楚两个东西到底是什么

• CLI + Skill：不是协议，是组合拳。

  • CLI：git、gh、kubectl、aws……真正的干活工具
  • Skill：一份 markdown 指令文件，教 AI 怎么用这些 CLI（比如你们团队的 PR 模板、分支策略）
  • AI 通过 shell 执行命令，stdout 直接读结果

• MCP（Model Context Protocol）：Anthropic 提出的开放协议。

  • 用 JSON-RPC + JSON Schema 把外部工具/数据源封装成"AI 可调用的函数"
  • 常驻或远程 server，支持 OAuth、审计、多租户

它们不是替代关系，是不同约束下的选型。

---

二、Token 成本：CLI 的"结构性优势"是真实的

这是 2026 年社区骂战的核心。数据来自 Scalekit 的 75 跑基准（Claude Sonnet 4，查询 GitHub 仓库语言和 License）：

方案	Token 消耗	月 1 万次成本（Sonnet 4 定价）
纯 CLI（模型自己拼命令）	~1,365	~$3.20
CLI + Skill（加载指令文件）	~4,724	~$8–10
MCP（传统，全量 schema 注入）	~44,026	~$55.20

CLI 比 MCP 省 4–32 倍 token。 这不是营销数字，是跑出来的。

为什么差距这么大？

• CLI+Skill：Skill metadata 常驻（~100 tok），正文懒加载；CLI 输出直接给模型，零 schema 开销
• MCP 传统实现：所有 tool schema 每轮注入上下文，GitHub MCP 这种大型 server 轻松破 40k tokens
• 2026.1 Anthropic 推出 Progressive Discovery：只注入 metadata，触发后才加载 schema，token 从 77k 降到 8.7k（降 85%），月成本估算从 $55 降到 ~$5——但仍然比纯 CLI 高

Token ≠ 延迟，但 Token = 钱 + 思考时间。多 30 倍 token，就是多 30 倍 API 成本和首字延迟。

---

三、延迟与可靠性：数字要"说人话"

社区实测的两个关键数据点

Scalekit 基准（查询 GitHub 仓库信息）：

• CLI：100% 成功，平均 120 ms
• MCP：72% 成功，平均 420 ms
• 注意：MCP 的 7 次失败（28%），全部是直连 GitHub Copilot 远程 MCP server 的 TCP 超时，不是 MCP 协议本身的错误。本地 MCP server 或走网关的情况完全不同。

Arize eval（复杂分析任务）：

• MCP 端到端耗时是 Skill 方案的 ~5 倍
• 但！当任务能干净映射到 MCP 端点时（如 create_branch + create_pull_request），MCP 反而更快：8 次调用 / 33 秒 / $0.16，对比 Skill 的 22 次调用 / 90 秒 / $0.50

所以真实情况是：

• 本地有 CLI + 任务可 shell 组合 → CLI 延迟显著更低
• 任务映射为少量 MCP 端点调用 → MCP 反而更高效
• 远程 MCP server 网络跳数多 → 延迟和超时风险上升

不要信"CLI 永远快"或"MCP 永远慢"，任务形状决定一切。

---

四、并发与规模化：MCP 的设计主场

CLI 在本地很爽，一上规模就露馅：

维度	CLI + Skill	MCP
并发模型	每个调用 fork 一个进程	常驻进程 + 连接复用
10–30 并发	开始吃力	轻松
100+ 并发	❌ 基本不可行	✅ 设计目标
云沙箱 / 浏览器	⚠️ 受限（无 shell）	✅ 主流
连接池 / 限流 / 熔断	❌ 需自己实现	✅ 协议层支持

MCP 的杀手锏不是"快"，是"稳"和"可治理"。 企业级系统宁可多花 token，也不能让 28% 的请求超时。

---

五、安全与治理：MCP 的护城河

这是 CLI+Skill 永远无法补齐的短板：

能力	CLI + Skill	MCP
鉴权	继承 shell 用户权限，“全有或全无”	OAuth、per-user token、scoped access
审计日志	难（bash 历史不算审计）	协议层支持，每次调用可追踪
租户隔离	❌	✅
权限撤销	kill 进程	协议级 revoke
多用户 SaaS	❌ 不可能	✅ 唯一解

如果你的 Agent 是"替客户操作 Slack/Notion/Stripe"，CLI 直接出局。这不是性能问题，是合规问题。

---

六、什么时候选谁？一张决策表

你的场景	推荐	理由
本地 coding agent，高频调 git/gh/kubectl	✅ CLI + Skill	Token 省、延迟低、模型训练数据熟悉
成本敏感，月调用百万次	✅ CLI + Skill	数量级成本差异
多用户 SaaS，代客操作	✅ MCP	OAuth + 审计 + 租户隔离
无 CLI 的云端 SaaS（Slack/Notion/Salesforce）	✅ MCP	没有 shell 可用
有状态会话（分页 cursor、长连接、服务端缓存）	✅ MCP	CLI 无状态
云沙箱 / 浏览器 Agent / 移动端	✅ MCP	没有 bash 环境

---

七、现实世界的真相：大家都在"混用"

在 Scalekit、Arize 等团队的实践中，CLI+Skill 与 MCP 网关被同时使用：

Skill（认知层 / 调度层）
 ├── 本地环境 → CLI（执行层）
 └── 云端 / 多租户 → MCP（执行层）

• Skill 统一描述"做什么"（团队规范、PR 模板、分支策略）
• CLI / MCP 负责"怎么安全地做"
• 底层根据环境切换实现

这才是 2026 年工程界的主流架构，不是二选一。

---

八、写在最后

别信"MCP 已死"，也别信"CLI 万能"。

• 个人开发者 / 本地 agent：CLI+Skill 是性价比之王，但别指望它做多租户
• 企业架构师：MCP 是目前唯一能落地的多租户方案，但记得开 Progressive Discovery 省 token
• Agent 框架作者：Skill 是认知层，CLI/MCP 是执行层，缺一不可

性能从来不是绝对指标，而是约束条件下的权衡。
选对场景，CLI 和 MCP 都能跑出极致性能；选错场景，再好的协议也是废铁。

---