Apideck CLI：比 MCP 省 99% 上下文的 AI Agent 接口方案

评分 8.3 · 来源：Apideck Blog · 发布于 2026-03-16

评分依据：针对 MCP 上下文消耗痛点提出实用替代方案，有详实基准测试数据支撑，HN 热议，对 Agent 开发者有直接价值

要点

Apideck 发布 CLI 工具，作为 Model Context Protocol (MCP) 的轻量级替代方案，解决 MCP 的上下文窗口消耗问题：

MCP 的上下文危机：

• 连接 3 个服务（GitHub、Slack、Sentry）→ 55,000 tokens 工具定义（占 Claude 200K 上下文的 27%）
• 每个 MCP 工具消耗 550-1,400 tokens（名称、描述、JSON schema、枚举等）
• 实际案例：3 个 MCP 服务器消耗 143,000/200,000 tokens（72% 上下文），只剩 57K 用于对话
• Scalekit 基准测试：MCP 比 CLI 多消耗 4-32 倍 tokens（同样任务，同样模型）

CLI 方案的优势：

1. 渐进式发现（Progressive Disclosure）

   • 系统提示仅需 ~80 tokens（vs MCP 的 10,000-50,000+）
   • 按需加载：--help 调用仅消耗 50-200 tokens
   • 三层发现：--list API → <api> --list 资源 → <resource> <verb> --help 操作详情

2. 更高可靠性

   • MCP 远程服务器故障率 28%（Scalekit 测试中 25 次调用 7 次超时）
   • CLI 本地执行，无远程连接失败风险
   • 月成本对比：CLI $3.20 vs MCP $55.20（17 倍差距）

3. 结构化安全

   • 权限分类内置于二进制：GET 自动批准、POST/PUT/PATCH 需确认、DELETE 默认阻止
   • 无法通过 prompt injection 绕过（vs MCP 的 prompt-based 安全）
   • 支持自定义权限策略（YAML 配置）

4. 通用兼容性

   • 所有 Agent 框架都支持 shell 命令（Claude Code、Cursor、Copilot、Gemini CLI）
   • MCP 需要专门客户端支持和连接管理
   • 单个二进制，跨平台运行

技术实现：

• 基于 OpenAPI spec 动态生成命令树（无需代码生成）
• 智能输出：TTY 环境显示表格，非 TTY（Agent 调用）自动输出 JSON
• 认证透明：从环境变量或配置文件自动注入
• --service-id 支持多租户（同一命令切换不同后端）

适用场景对比：

• CLI 更适合：广泛 API 集成、token 预算紧张、需要渐进发现
• MCP 更适合：高频调用少量工具（5-10 个）、需要 OAuth 代理授权、B2B 多租户场景
• 代码执行更适合：复杂有状态工作流（轮询、分页、事务回滚）

🤖 AI 点评

这篇文章击中了 MCP 生态的真实痛点。MCP 的设计哲学是”把所有工具定义预加载到上下文”，这在 demo 阶段没问题，但扩展到真实应用时会遇到 上下文预算耗尽 的硬墙。

Apideck 的 CLI 方案本质上是把 “人类开发者的工具使用模式” 复制给 Agent — 先看 --help，再看子命令，最后看具体参数。这种渐进式发现不是新概念（Claude Agent Skills 也用类似思路），但 CLI 作为载体有独特优势：所有 Agent 框架都原生支持 shell 命令，无需额外协议支持。

28% 的 MCP 远程调用失败率是个被低估的问题。这不是协议设计缺陷，而是分布式系统的固有风险。CLI 的”本地二进制”架构天然规避了这个问题。

不过文章也诚实指出了 CLI 的局限：多租户 OAuth 授权 仍然是 MCP 的优势领域。当你的 Agent 需要代表不同用户操作不同租户的数据时，MCP 的结构化授权模型更合适。这不是非此即彼的选择，而是根据场景选工具。