过去一年，关于 Agent 工具链的争论越来越集中在一个问题上：

MCP（Model Context Protocol）是让工具调用更简单了，还是把原本简单的事情复杂化了？

在大多数日常开发任务里，CLI 正在成为更实用的默认方案。

成本差异不是“体验问题”，是数量级问题

MCP 最大的现实压力是 token 开销。

常见场景里，MCP 在真正执行任务前，需要先加载大量工具 schema。以 GitHub MCP Server 为例，初始化就可能消耗数万 tokens。对于长任务来说，这会直接挤占上下文预算。

社区基准测试也反复指向同一个结论：

• MCP 单次调用成本常见是 CLI 的数倍到数十倍
• 失败重试成本也更高（要重建连接、重新加载上下文）

这不是“慢一点”的差距，而是会放大成 API 费用、时延和稳定性问题。

为什么模型天然更“会用 CLI”

一个常被忽略的事实是训练分布。

LLM 在训练中看过海量终端文本：命令、输出、报错、脚本、man page。也就是说，CLI 交互模式本来就接近模型的“母语输入”。

相反，MCP 的 JSON-RPC 与 tool schema 是近两年才大规模出现的新范式。模型当然能学会，但熟悉度和压缩效率通常不如 CLI 这类历史语料。

这也解释了为什么很多时候：

• 同样目标，CLI 指令更短
• 输出更适合直接继续推理
• 错误恢复路径更稳定

安全与隔离：MCP 还有补课空间

MCP 不是不能做安全，而是生态还在早期。

当前常见担忧包括：

• 工具描述投毒（Tool Poisoning）
• 服务行为漂移（Rug Pull）
• 同名工具覆盖（Shadowing）

CLI 当然也有安全问题（注入、越权、路径风险），但其进程模型、权限边界、审计链路已经经过几十年工程实践验证。对生产环境而言，这种“可预期性”很重要。

这不等于 MCP 没价值

我不认为 MCP 应该被抛弃。

更合理的定位是：

• CLI 负责执行层（本地、低延迟、高频调用）
• MCP 负责连接层（远程服务发现、统一认证、审计与多租户）

也就是常说的混合架构：CLI + MCP Gateway。

在需要对接大量远程系统、做统一权限治理和合规审计时，MCP 仍然有明显价值；但在“让 Agent 快速完成开发任务”这件事上，CLI-first 往往更符合当前模型能力边界。

在今天的工程现实里，CLI 更像 Agent 的工作母语；MCP 更适合作为连接协议，而不是唯一执行协议。