为什么 CLI 比 MCP 更适合 LLM

近期，Google Workspace CLI 的推出在技术社区引发了广泛讨论。一个值得深思的现象正在显现：越来越多的开发者开始绕过复杂的协议框架，回归到最经典的交互方式——CLI（命令行界面）。在大模型工具调用体系中，我们是否正在经历一场“过度设计”后的反思？

CLI 为何更符合 LLM 的认知模式

在当前的 LLM 能力与工程实践条件下，CLI 是一种更自然、更高效、更工程友好的工具调用方式。这并不是说要用 CLI 完全替代 MCP，而是说：在大量实际场景中，CLI 是 LLM 触达真实世界的“最短路径”。它同时跨越了“表达层”和“执行层”，赋予了极高的效率。

工程实践中的基础设施优势

首先，CLI 实现了推理路径与执行路径的高度一致性。以 `grep "error" logs.txt | sort | uniq -c` 为例，LLM 的推理过程是线性的——查找、排序、计数——推理结构与命令结构完美对应。而 MCP/JSON 模式需要 LLM 理解复杂的 Schema 并构造嵌套的 JSON 字段，这中间多了一步“映射”的开销。简而言之，CLI 实现了“推理即执行”，而 MCP 则是“推理 → 映射 → 执行”。其次，CLI 是一个低熵空间。JSON 嵌套越深、Schema 越复杂，LLM 调用出错的概率就越高（高熵状态）。而 CLI 语法稳定、容错性强，更接近自然语言的逻辑表达方式。

Token 效率的碾压级优势

CLI 在工程实践中展现出多维度的基础设施优势。其一是 CLI Help 本身就是最好的 Prompt——无论是 `git --help` 还是 `kubectl --help`，它们本身就是结构化清晰、参数自描述的文档，等同于文档、Schema 与 Prompt 的集合体。其二是彻底规避“环境地狱”。相比于依赖 Python 或 Node 环境的插件，CLI 通常以二进制文件分发（如通过 brew、apt 安装），无运行时依赖，不会因为版本冲突而出现问题，同时拥有数十年验证的签名、校验和权限控制机制。其三是继承了整个 Unix 软件宇宙——使用 CLI 意味着 LLM 可以直接调用 ffmpeg 处理视频、docker 管理容器、awk/sed 处理文本，相当于继承了 Unix 几十年的进化成果。

MCP 的价值边界

Scalekit 针对 GitHub 操作场景的对比数据令人深思：在使用 Claude 3.5 Sonnet 时，CLI 模式的 Token 消耗仅为 1.3k-9k，而 MCP 模式高达 32k-82k——MCP 贵了 4-32 倍。更重要的是可靠性：CLI 模式达到 100%（本地执行），而 MCP 仅为 72%（网络超时）。调试方面，CLI 透明可复现，MCP 则如同黑盒且依赖服务端状态。综合来看，CLI 在工程指标上实现了全面碾压。

如有侵权，请联系删除。