---

前言

MCP 曾被誉为 Agent 的万能接口，连接一切工具的标准。但最近，越来越多的顶级开发者开始悄悄地抛弃它，转而用一种更原始的方式来解决问题——直接调用命令行程序。

---

一、什么是 CLI 工具？

所谓 CLI，即 Command Line Interface（命令行界面），通过一行命令就能完成复杂操作：

• 转换视频格式 → ffmpeg -i input.mp4 output.avi
• 搜索文件内容 → grep "keyword" ./src
• 调整图片尺寸 → convert input.jpg -resize 800x600 output.jpg

这些工具（ffmpeg、grep、ImageMagick 等）都是典型的 CLI 工具。

---

二、行业趋势

这不是少数极客的自嗨，而是行业级的集体转向：

人物/项目	动向
Perplexity CTO	2025年3月开发者大会公开宣布全面转向 API 和 CLI，放弃 MCP
Y Combinator CEO	选择使用 CLI，不用 MCP
OpenClaw	实际执行任务时几乎全用内部工具和 CLI 命令，基本看不到 MCP

---

三、CLI 的核心优势

优势一：Token 消耗极小

MCP 工具的元信息（名称、描述、入参格式等）会全部传入大模型上下文，消耗大量 Token。

以 GitHub MCP Server 为例：

• 工具数量：44 个
• 工具说明总行数：1683 行
• 字符数量：63,703 个字符
• 换算 Token：约 14,268 个 Token
• 折合费用（Claude Sonnet）：约 ¥0.3 / 次调用

如果同时安装多个 MCP Server，光工具说明就可能花掉数元，还未计算模型输出费用。

换成 CLI 是什么样？

只需传一个 bash 工具，说明仅十几行，Token 消耗几乎可以忽略不计。

bash 工具说明（核心一句话）：
传一个叫 command 的参数，值就是你要执行的命令。

---

优势二：执行效率高

MCP 模式下的任务流程

以「筛选横版照片 → 加水印 → 上传服务器」为例：

关键问题：大模型是整个链路的调度中心，每一步都必须经过它响应一次，整体效率被严重拖慢。

---

CLI 模式下的任务流程

核心差异：三个步骤全在本地自动串联执行，大模型只参与一次思考和一次结果接收，链路极短。

---

两种模式对比

---

优势三：UNIX 生态红利 + 极致灵活

CLI 工具能高效组合，依赖两个关键符号：

符号	含义
| （管道符）	把上个命令的输出传给下一个命令
&&	上个命令成功后，才执行下一个命令

这背后是 UNIX 几十年确立的设计哲学：

一个工具只做一件事，做到极致，并能自由拼接。

• exiftool 负责读取信息
• magick/convert 负责图像处理
• scp 负责传输

无需封装、无需 Schema、无需开发，拿来即用。

而 MCP 想要实现类似组合，往往需要重新开发工具或编排逻辑，灵活性远不如 CLI。

优势四：调试简单、可复用、可沉淀

• CLI 报错直接可见，复制命令就能手动复现、修改
• 可保存为 .sh 脚本，加入 crontab、CI/CD
• 可分享、可文档化、可长期复用

MCP 调用则依赖协议、Schema、服务状态，出问题排查链路更长，也难以直接固化为通用脚本。

---

四、MCP 的不可替代优势

CLI 并非完美，MCP 在结构化、安全、可控上依然不可替代。

优势一：参数边界清晰，不易出错

CLI 遇到特殊字符（如单引号、空格、特殊符号）容易语法崩溃：

# 若文件名为 mark's photo.png，文件名中的单引号会破坏命令语法，直接报错
convert 'mark's photo.png' -watermark watermark.png output.png
#              ↑ 此处单引号破坏了命令结构

MCP 的处理方式：使用结构化 JSON，参数天然隔离，无注入风险：

{
  "tool": "add_watermark",
  "params": {
    "filename": "mark's photo.png",
    "watermark": "watermark.png"
  }
}

文件名躺在 JSON 字段里，JSON 有自己的转义规则，参数边界清晰，不会与命令语法冲突。

---

优势二：更安全

CLI 的灵活性是一把双刃剑：它什么都能做，也意味着什么都能搞砸。

在以下场景中，MCP 的受限设计反而是优势：

• 云端自动化服务（如 Make、Zapier）
• 企业级共享环境
• 对安全审计有要求的生产系统

MCP 只能做工具设计者允许它做的事，不多也不少。

补充：CLI 也可以变得安全

CLI 的不安全是 “默认权限宽松”，不是本质缺陷。

通过轻量沙箱即可大幅提升安全：

• Docker 隔离
• WASM 运行时
• chroot、bubblewrap、命名空间
• 只读目录、禁止网络、权限限制

加一层沙箱后，CLI 可以兼顾灵活与安全。

---

五、CLI vs MCP 全面对比

维度	CLI	MCP
Token 消耗	极低，仅需 bash 工具	高，需加载大量工具 Schema
执行效率	高，管道串联一次完成	低，LLM 逐次调度
灵活组合	极强，管道自由拼接	弱，需按预定义工具执行
生态成熟度	几十年 UNIX 工具，无限丰富	新兴生态，需逐个封装
调试难度	低，可复制可复现	高，依赖协议、序列化、服务状态
可控性	一般，特殊字符易出错	高，JSON 参数边界清晰
安全性	默认宽松，可通过沙箱增强	高，白名单能力，天然安全
适用场景	个人、本地、效率优先	企业、云端、多租户、安全审计

六、未来格局预测

最终的分工会很清晰：

• CLI 会越来越多地走向个人与轻量化使用
• MCP 会留守企业和云端，在对安全性和稳定性要求高的场景中不可替代

---

七、总结

MCP 不是过时，CLI 也不是复古。

这场 “转向” 的本质，是开发者在效率与安全之间做出了更理性的场景化选择。

• 追求低成本、高效率、强生态、灵活拼接 → 用 CLI
• 追求安全可控、权限隔离、多租户、审计追溯 → 用 MCP

工具没有优劣，只有场景是否合适。

未来一定是 CLI 与 MCP 长期并存、各司其职的格局。