抛弃 MCP？为什么 CLI 正在成为 Agent 的默认工具层

Fri, 10 Apr 2026 21:55:12 +0800

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

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

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

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

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

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

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

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

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

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

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

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

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

当前常见担忧包括：

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

我不认为 MCP 应该被抛弃。

更合理的定位是：

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

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

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