2026 年了，Agent 接入工具该选 MCP 还是 CLI？Scalekit 实测：Token 消耗最多差 32 倍，可靠性 CLI 100% vs MCP 72%。这不是技术路线的意气之争，而是场景匹配的理性选择。
1. 痛点：一个让 Agent "变笨" 的真实问题
你是不是也遇到过这种情况：给 Agent 接了 MCP Server，配置了一大堆工具，结果它反而变得更"笨"了——响应变慢、幻觉增加、有时候干脆直接"摆烂"不干活了？
这不是你的幻觉。这是有实测数据支撑的事实。
Scalekit 在 2026 年 3 月发布了 一份 benchmark 报告，使用同一模型（Claude Sonnet 4）、相同的任务，仅改变工具接入方式，对比了 CLI 和 MCP 的实际表现。
具体数据如下：
| 任务 | CLI Token 数 | MCP Token 数 | 差距 |
|---|---|---|---|
| 获取仓库语言和许可证 | 1,365 | 44,026 | 32 倍 |
| 获取 PR 详情和审核状态 | 1,648 | 32,279 | 20 倍 |
| 获取仓库元数据 | 9,386 | 82,835 | 9 倍 |
| 按贡献者汇总已合并的 PR | 5,010 | 33,712 | 7 倍 |
这不是选哪个"更好"，这是能否在有限上下文窗口内完成任务的生死线。
2. 溯源：MCP 的"Token 膨胀"从何而来？
MCP（Model Context Protocol）是由 Anthropic 主导推出的标准化协议，目标很美好：让 AI Agent 能够动态发现工具、理解参数 Schema，以 JSON-RPC 协议与任意服务交互。
它的设计确实优雅：
- 互操作性：一次编写，多端通用（Claude Desktop、Cursor、VS Code 等）
- 资源抽象：不仅支持"动作"，还引入"资源（Resources）"概念
- 安全治理：基于代理架构，可实现精细的权限控制、请求审计
但代价是什么？
Atlassian 在 2026 年 3 月底发布的 MCP 压缩技术博客 中揭示了一个关键数据：官方 GitHub MCP 服务器暴露 94 个工具，仅工具 Schema 定义就消耗约 17,600 个 Token。
更直观的对比：Atlassian 自家的 MCP Server 消耗超过 10,000 Tokens，而通过 MCP-compressor 压缩后，最高可减少 97% 的 Token 消耗。
也就是说，原始 MCP 的工具描述里，有大量内容对模型来说不是"有效信息"，而是协议本身的格式开销（Schema Overhead）——模型需要从数百行 type: object、properties: {...} 中提取真正有意义的指令。
3. 对比：CLI 与 MCP 的核心差异
3.1 效率维度
| 指标 | CLI + Skills | MCP (直接) | MCP (网关) |
|---|---|---|---|
| Token 效率 | 最佳 | 开销大 (4-32x) | 接近 CLI |
| 月度成本 (10k 操作) | $3.20 | $55.20 | ~$5 |
| 可靠性 | 100% | 72% | ~99% |
数据来源：Scalekit Benchmark 2026-03-11，基于 Claude Sonnet 4
Scalekit 的测试结果显示：
- CLI：25 次测试全部成功（100% 成功率）
- MCP 直接连接：18 次成功，7 次因 TCP 连接超时失败（72% 成功率），主要是因为与远程服务器建立连接时的可靠性问题
3.2 安全维度
这是两者最根本的差异，决定了它们各自的最佳适用场景。
| 特性 | CLI | MCP |
|---|---|---|
| 认证授权 | 继承开发者环境凭证，难以按用户授权 | 原生支持 OAuth 2.1 + PKCE，可按用户/范围授权 |
| 工具边界 | 无严格边界，可执行任意 shell 命令 | 明确的工具边界，行为更可控 |
| 审计追踪 | 依赖 shell 历史，非结构化 | 结构化审计，每次调用都有类型化记录 |
| 多租户 | 应用层实现，复杂易出错 | 协议层支持会话级租户隔离 |
3.3 架构哲学
| 维度 | CLI / Skills (OpenClaw) | MCP |
|---|---|---|
| 设计哲学 | 动作优先（Action-first） | 协议优先（Schema-first） |
| 工具发现 | 静态文档（自然语言） | 动态发现（JSON-RPC） |
| 交互深度 | 单次调用，无状态 | 双向流、资源订阅、状态保持 |
| 适用场景 | 个人提效、快速原型 | 企业级集成、分布式系统 |
4. 原理：为什么 CLI 更"懂" AI？
4.1 Help 即 Prompt
对于 LLM 来说，CLI 的 --help 输出就是一份天然的高质量 Prompt——清晰的参数说明、示例、注意事项，一目了然。无需额外的 Schema 定义，无需 JSON 序列化。
而 MCP 的 JSON Schema 对模型来说是什么样的体验？
想象你让一个人去拿"工具箱里的十字螺丝刀"，但你给他的不是直接描述，而是一份完整的 JSON Schema：
{
"type": "object",
"properties": {
"tool_name": {
"type": "string",
"enum": ["screwdriver"],
"description": "工具名称"
},
"screwdriver_type": {
"type": "string",
"enum": ["phillips", "flathead"],
"description": "螺丝刀类型"
}
}
}
你能想象这有多折磨吗？
4.2 Unix 哲学的天然契合
CLI 遵循"只做一件事并做好"的原则，通过管道（|）任意组合。这与大模型的"思维链（CoT）"逻辑高度契合。
Agent 可以像搭积木一样编排命令：
git log --oneline | grep "fix" | awk '{print $1}' | xargs git show
用 MCP 实现类似的跨工具流程？需要复杂的调用编排和状态管理。
4.3 AI 原生 CLI 的两个关键要素
未来给 AI 用的 CLI 工具，必须具备两个特性：
- 支持
--json输出：让 Agent 方便解析结构化数据，而不是费劲去读 ASCII 表格 - 支持
--yes非交互模式：避免 Agent 卡死在Are you sure? (y/n)的终端阻塞中
5. 选型：不同场景的决策树
5.1 个人开发者
核心诉求：效率至上，逻辑驱动。
自建功能 → CLI / Skills（像肌肉一样快）
调用大厂服务 → MCP（像插座一样准）
CLI 的集成成本有多低？写一个 TypeScript 脚本的时间，远少于配置一个 MCP Server。SKILL.md 就是你的"说明书"，改完即刻生效。
5.2 企业级场景
核心矛盾：生产力 vs 治理。
| 场景 | 推荐方案 |
|---|---|
| 内部工具分发 | MCP（自发现 + 安全调用） |
| 本地开发/调试 | CLI（保持 Vibe Coding 节奏） |
| 生产环境 | MCP-CLI 混合（MCP 做网关，后端挂 CLI 脚本） |
| 合规要求高 | 强制 MCP（Schema 约束，防非预期动作） |
企业级高手的真相：向老板汇报时讲 MCP（标准化、治理、安全），带队写代码时用 CLI（脚本、Skills、生产力）。
5.3 普通用户
直接用大厂封装平台（Coze、钉钉 Agent、Claude Desktop），背后 MCP 是绝对主力——因为大厂需要协议保证安全性、合规性和界面统一。
5.4 大厂为什么"既要又要"？（商业视角）
你可能还有疑问：为什么各大厂一边在平台上狂推 MCP，标榜自己是"国际标准"的推手；一边又在各自云业务里拥抱 OpenClaw？
从商业角度看，这并非"跟风"，而是一场极其清醒的生态围猎：
- 拥抱 MCP：稳住企业级基本盘。银行、跨国企业需要审计、安全合规、权限精细到毫秒，MCP 的代理架构是唯一解。
- 跟进 OpenClaw：抢夺开发者心智。如果大厂不支持 OpenClaw，极客就会流向 Cursor、Windsurf 或纯开源社区。大厂提供"一键部署 OpenClaw"的能力，本质是要把你的 Agent 数据流留在它们的云上。
具体到各厂家的"私货"：
- 字节跳动：基于 OpenClaw 开源项目推出了三款产品——飞书妙搭 OpenClaw（嵌入飞书办公生态）、火山引擎 ArkClaw（云端 SaaS 版）、扣子 OpenClaw（低代码可视化），核心思路都是把 CLI 模式 UI 化，试图圈住自己的开发者生态。
- 腾讯/阿里：腾讯 QClaw 已进入邀请制内测（定位企业级）；阿里云推出了 OpenClaw 部署指南和安全加固方案，强调"企业级"和"安全中转"。
- 百度：在千帆平台全面支持 MCP 协议，同时上线了"MCP广场"，试图成为工具分发入口——这一点与原文描述高度吻合。
以上各厂产品信息来源于 2026 年 3 月公开报道。需要注意的是，这些产品大多仍在早期阶段（内测、预发布），具体功能细节可能有变化。
所以，大厂不是没想法，而是想把两种未来都锁在自己的地盘里。理解这一点，有助于你在选型时保持清醒——大厂推荐的不一定是最适合你的。
6. 进阶：两条优化 MCP 的路径
6.1 路径一：MCP-compressor 按需压缩
如果你已经在用 MCP，但被 Token 消耗困扰，Atlassian 的 MCP-compressor 提供了另一种思路：不是放弃 MCP，而是按需加载工具 Schema。
核心思想：用两个"元工具"替代完整的工具列表：
| 元工具 | 作用 |
|---|---|
get_tool_schema(tool_name) | 按需获取特定工具的完整 Schema |
invoke_tool(tool_name, tool_input) | 执行指定的工具 |
| 压缩级别 | Token 消耗 | 减少比例 |
|---|---|---|
| 基线（无压缩） | 17,600 | - |
| 低压缩 | 3,900 | 78% |
| 强压缩 | 2,200 | 87% |
| 最大压缩 | 500 | 97% |
本质上是将"一次性发送所有工具"转变为"按需发现、按需加载"，这和 CLI 的"静态文档 + 按需调用"哲学是相通的。
6.2 路径二：Anthropic 的"代码执行"思路
Atlassian 的方案是减少工具 Schema 的注入量，而 Anthropic 提出了另一种完全不同的思路——让 Agent 用代码调用工具，而不是直接工具调用。
2025 年 11 月，Anthropic 工程博客发布了 Code Execution with MCP 的实践总结。其核心方法是：
- 代码即工具：Agent 编写代码来调用 MCP 工具，而非直接触发工具调用
- 数据处理在代码环境内完成：过滤、转换、循环等操作不需要传回模型上下文
- 按需发现：Agent 通过"浏览文件系统"发现可用工具，而非一次性加载全部工具定义
实测效果：
- 传统 MCP 直接调用：约 150,000 Tokens
- 代码执行方式：约 2,000 Tokens
- 节省 98.7%
这种方案的代价是需要沙箱执行环境，但对于有技术能力的团队来说，是值得考虑的第二条优化路（第一条是 MCP-compressor）。
7. 总结：三条路，一个口诀
7.1 三条路一览
| 路 | 方案 | 核心优势 | 适用场景 |
|---|---|---|---|
| 第一条路 | CLI / Skills（OpenClaw） | Token 效率最佳、可靠性 100%、集成成本极低 | 个人自动化、快速原型 |
| 第二条路 | 纯 MCP（经压缩或代码执行优化） | 保持协议标准化，Token 成本降低 80-98% | 企业内部，需兼顾治理与效率 |
| 第三条路 | MCP-CLI 混合架构 | MCP 做网关保证安全，CLI 脚本保证性能 | 生产环境、高性能需求 |
7.2 一个口诀
CLI 是肌肉，MCP 是神经；重数据走 MCP，重动作走 CLI。
7.3 补充视角
Marvin Zhang 在 2026 AI Agent 全景图 中指出，纯 MCP 的自动化上限约为 L3（半自动）级别。若要突破 L4-L5 的更高自动化，需要在 MCP 基础上叠加 ACP、A2A 等其他协议。这也印证了：对于追求极致效率和直接自动化的场景，CLI/Skills 仍是不可替代的选择。
最终建议：
如果你构建的是个人工具，CLI 成本最低、可靠性最高；如果你构建的是面向客户的产品，MCP 的授权模型不可或缺——但建议通过 MCP 网关使用，可将成本降低 10 倍、可靠性提升至 99%。
没有银弹，只有匹配。
