CLI vs. MCP：谁才是大模型工具的未来？

小皮咖   in 广州

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

比如：

  • 转换视频格式，一行 ffmpeg 命令；
  • 搜索文件，一行 grep；
  • 调整图片尺寸，一行 ImageMagick。

这些命令有一个共同点：它们一般在命令行界面中执行。命令行界面的英文是 Command Line Interface，简称 CLI，所以我们称这类工具为 CLI 工具。

注意，这不是少数极客的小圈子自嗨。

就在今年 3 月份，Perplexity 的 CTO 在一场开发者大会上公开宣布，他们内部正在全面转向 API 和 CLI 工具，放弃 MCP。Y Combinator 的 CEO 也选择使用 CLI，不用 MCP。而最近爆火的 OpenCloud，在实际执行任务时，应用的几乎全都是内部工具和 CLI 命令，基本看不到 MCP 的身影。

但问题来了：

MCP 明明是专门为大模型设计的工具调用标准，为什么现在反而被"古老"的 CLI 工具抢了风头？

CLI 到底有什么惊人的天然优势？而 MCP 又有什么不为人知的问题？

CLI 和 MCP，到底谁才是大模型工具的未来？

我们就来聊聊这个话题。

# 一、CLI 的两大优势

既然 CLI 工具能够获得越来越多人的青睐，那它必然有着非常明显的优势。我总结为两点：Token 消耗小 与 执行效率高。

# 1. Token 消耗小

从反面来看，这意味着 MCP 工具的 Token 消耗较大——尤其是 MCP 的元信息（包括工具名称、描述、入参格式等）都会传到大模型的上下文中，从而消耗大量 Token。

来看一个具体例子。

假设我们想让大模型回答："OpenCloud 这个 GitHub 仓库最新的三个 issue 是什么？"
在 MCP 模式下，我们不仅要把问题发给大模型，还要把所有可用工具的详细信息也发过去——工具叫什么、能干什么、需要哪些参数、参数格式是什么…… 这些元信息会占用大量 Token。

以 GitHub 的 MCP Server 为例，它包含了 44 个工具，这些工具说明合计约 1683 行、63703 个字符。换算成 Token 大约 14268 个，按 Claude Sonnet 的价格估算，仅工具说明就要花费约 0.3 元。如果同时装有多个 MCP Server，光工具说明就可能花掉好几元，这还没算模型输出的费用。

而如果换成 CLI 模式，流程基本相同，唯一区别是：我们只需要发一个 bash 工具给大模型。

bash 工具的说明仅十几行，核心就是"传一个 command 参数，参数值就是你要执行的命令"。

对于上面这个问题，大模型生成的命令可能是：

gh issue list --repo opencloud --limit 3

这里只需要一个简单的 bash 工具说明，Token 消耗几乎可以忽略不计。

你可能会问：大模型怎么知道 gh 这种命令的？
其实像 git、grep、ffmpeg 等常见 CLI 程序，大模型在训练阶段已见过大量用法，所以能直接使用。如果是冷门或自研工具，则可通过 Agent Skill（本质上是给模型看的说明文档）来补充。

# 2. 执行效率高

再看一个场景：你是一名摄影师，需要从 10 张单反照片中，找出所有横版照片（宽>高），加上专属水印，然后上传到服务器。

  • MCP 模式下，大模型需要多次思考、多次调用工具：

    1. 调用"读取目录"工具，获取文件名列表；
    2. 调用"读取图片信息"工具，获取每张图的宽高；
    3. 筛选出横版照片，调用"图像处理"工具加水印；
    4. 调用"上传"工具传到服务器；
    5. 返回最终结果。

整个过程中，大模型是调度中心，每一步都要经过它，等待它的响应，整体效率受限于模型的往返延迟。

  • CLI 模式下，大模型只需思考一次，然后调用一次 bash 工具，传入一条组合命令：
exiftool -if 'ImageWidth>ImageHeight' -filename . | xargs -I {} convert {} -gravity southeast -fill white -pointsize 36 -annotate +10+10 'My Watermark' output/{} && scp output/* user@server:/path/

这条命令大致分为三部分：

  1. exiftool 筛选宽>高的照片；
  2. convert（ImageMagick）批量加水印；
  3. scp 上传结果到服务器。

命令发出后，这三步在本地自动执行，无需大模型介入。全部执行完毕后，结果才返回给大模型，大模型只需判断任务已完成，即可给出最终答案。

CLI 的链路比 MCP 短得多，效率自然更高。

为什么 CLI 能做到这一点？

因为 CLI 程序可以自由组合。

上面命令中的 |（管道）负责将上一个命令的结果传给下一个命令，&& 表示"如果上一个命令成功，则执行下一个命令"。

正是这些看似不起眼的符号，把独立的工具串联成完整流程，能完成的任务远超想象。

这背后其实是 Unix 设计哲学：每个工具只做一件事，但做到极致；工具之间可以自由组合，像搭积木一样拼出任意复杂的流程。

exiftool 只管读元数据，ImageMagick 只管处理图像，scp 只管传文件——它们互不干涉，却能无缝协作。

你可能会想：那把 MCP 工具也做成一个"全能工具"，一口气完成所有步骤，不也行吗？
理论上可以，但需求一旦变化（比如想筛选 4K 照片，或转成 PNG 格式），工具就得重新开发。而 CLI 天生是组合式的，调整参数、重新拼接，几秒钟就能适应新需求。这种灵活性是 MCP 难以复刻的。

# 二、MCP 的两大优势

聊了这么多 CLI 的好，你可能会觉得 MCP 一无是处。别急，MCP 能成为行业标准，自然有它不可替代的优势，我也总结为两点：更可控 与 更安全。

# 1. 更可控

所谓"更可控"，说白了就是 MCP 工具更不容易出错。

再看上面的加水印命令，假设某张照片的文件名包含单引号，比如 mark's_photo.png，这条命令就会直接报错——因为文件名中的单引号会破坏命令的引号结构。

这类问题在 CLI 中很常见：命令越复杂，出错的概率越高，且错误往往很隐蔽，人类审查时难以一眼看出。

而换成 MCP 工具，同样是加水印，调用方式大致如下（示意）：

{
    "tool": "add_watermark",
    "params": {
        "filename": "mark's_photo.png",
        "watermark_text": "My Watermark"
    }
}

文件名老老实实地躺在 JSON 的字段里，不管包含单引号、双引号还是空格，都不会影响工具执行——因为 JSON 有自己的转义规则，参数边界清晰，不会与命令语法冲突。

所以 MCP 工具的执行结果更可控，出错的概率也更低。

# 2. 更安全

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

如果大模型生成的命令中夹带了 rm -rf / 这样的操作，本地文件可能被误删。在本地环境，这个风险或许还能接受（后果自负），但在云端共享环境（如 make.com 等自动化服务），一条失控的命令可能影响整个服务器甚至集群。

因此，很多云端服务允许接入 MCP，但绝不允许直接执行任意 bash 命令。即便有产品支持 CLI，也做了严格限制（沙箱、权限控制），成本高且安全性难与 MCP 媲美。

在对安全性要求非常高的场景下，MCP 这种"受限设计"反而成为优势：它只能做工具设计者允许的事，不多也不少。

所以，MCP 并不是一无是处——在可控性和安全性上，它确实比 CLI 做得更好。在对这两点要求很高的场景中，MCP 仍然是不可或缺的方案。

# 三、未来属于谁？

我的判断是：CLI 工具的比重会越来越大，而 MCP 的比重会逐渐缩小。

原因很直接：

  • CLI 更省 Token、执行效率更高。对于大部分场景、大部分人来说，CLI 是更快、更便宜、更直接的选择，天然更偏向轻量、个人化的使用方式。
  • MCP 的使用比例会逐步下降，但不会消失。它更安全、可控，因此会退守到对安全性和稳定性要求较高的场景，比如企业或云端。在这些场景中，不可能让大模型自由执行任意命令，MCP 的结构化、可控调用方式仍是不可替代的。

所以最终的格局很清晰：CLI 会越来越多地走向个人，而 MCP 会留在企业和云端。

一、CLI 的两大优势
1. Token 消耗小
2. 执行效率高
二、MCP 的两大优势
1. 更可控
2. 更安全
三、未来属于谁？
  • MIT Licensed | Copyright © 2024 小皮咖