评分 8.5 · 来源：Apideck Blog · 发布于 2026-03-16
评分依据：深度技术分析，用实测数据揭示 MCP 的 token 开销问题，提出 CLI 作为务实替代方案
要点
Apideck 发布深度技术文章，分析 MCP（Model Context Protocol）在 AI Agent 集成中的 token 消耗问题，并提出 CLI 作为更高效的替代方案。
MCP 的 token 开销问题：
- 连接 GitHub、Slack、Sentry 三个服务（约 40 个工具），在 Agent 读取第一条用户消息之前，就消耗了 55,000 tokens（占 Claude 200k 上下文的 27%）
- 每个 MCP 工具平均消耗 550-1,400 tokens（名称、描述、JSON schema、字段说明、枚举、系统指令）
- 一个团队报告三个 MCP 服务器消耗了 143,000 / 200,000 tokens（72%），只剩 57,000 tokens 用于实际对话
Scalekit 基准测试（75 次对比）：
- MCP 比 CLI 多消耗 4-32 倍 token
- 最简单的任务（检查仓库语言）：CLI 1,365 tokens vs MCP 44,026 tokens
- MCP 对 GitHub Copilot 服务器的调用失败率达 28%（TCP 超时）
CLI 的优势：
- 渐进式披露 — Agent 通过
--help按需发现能力，而不是预加载所有工具定义 - 本地可靠性 — 二进制本地运行，无远程服务器超时风险
- 结构化安全 — 基于 HTTP 方法的权限分类（GET 自动批准，POST/PUT/PATCH 需确认，DELETE 默认阻止），无法通过 prompt 绕过
- 通用兼容 — 所有 Agent 框架都支持 shell 命令，无需专门的 MCP 客户端
Apideck CLI 的 Agent prompt 只需 ~80 tokens，而 MCP 需要 10,000-50,000+ tokens 预加载。
🤖 AI 点评
这篇文章用硬数据打破了「MCP 是 Agent 集成标准答案」的共识。55,000 tokens 的预加载开销、28% 的失败率、4-32 倍的 token 消耗——这些数字让人重新审视 MCP 的适用边界。
CLI 的「渐进式披露」思路很聪明：模仿人类开发者的行为模式（先 --help 再深入），而不是一次性灌输所有信息。这不只是 token 优化，更是认知负载管理。
但文章也诚实地指出 CLI 的局限：不适合高频调用的少量工具、不适合需要流式通信的场景、不适合多租户 OAuth 场景。这种「知道自己边界」的技术讨论比盲目推销更有价值。
MCP、代码执行、CLI 三种方案各有适用场景，关键是理解 tradeoff。这篇文章最大的贡献是把 token 经济学摆到台面上——在上下文窗口有限的现实下，架构选择不只是技术偏好，更是资源分配策略。