MCP 曾被誉为 Agent 的万能接口，连接一切工具的标准。但最近越来越多的顶级开发者开始悄悄地抛弃它，转而用一种更原始的方式来解决问题——那就是直接调用命令行程序。比如转换视频格式就一行 ffmpeg 命令，搜索文件就一行 grep，调整图片尺寸就一行 ImageMagick。这些命令有一个共同点：它们一般是在命令行界面里执行的。

命令行界面的英文是 Command Line Interface，简称 CLI。所以我们称这些工具为 CLI 工具。对，前面演示的 ffmpeg、grep 和 ImageMagick 其实都是 CLI 工具。注意了，这不是少数极客的小圈子自嗨。就在今年 3 月份，Perplexity 的 CTO 在一场开发者大会上公开宣布他们内部正全面转向 API 和 CLI 工具，放弃 MCP。

Y Combinator 的 CEO 也选择使用 CLI，不用 MCP。而最近爆火的 OpenClaw 在实际执行任务时用的几乎全是内部工具和 CLI 命令，基本上也是看不到 MCP 的身影。但问题来了：MCP 明明是专门为大模型设计的工具接口标准，为什么现在反而被古老的 CLI 工具抢饭碗？

CLI 到底有什么惊为天人的优势，而 MCP 又有什么不为人知的问题呢？CLI 和 MCP 到底谁才是大模型工具的未来，这期视频我们就来聊聊这个话题。

既然 CLI 工具能获得越来越多人的青睐，那它必然有着非常明显的优势。我总结了一下，我认为 CLI 工具的优势主要体现为两点：Token 消耗小，以及执行效率高。我们先来看第一部分：CLI 工具的 Token 消耗小。其实这从反面来看，就意味着 MCP 工具的 Token 消耗大。对，没错，尤其是 MCP 的元信息——包括名称、描述、入参格式等等。

这些其实都会传到大模型的上下文里面，从而消耗大量的 Token。我们就来看一个具体的例子：最近 OpenClaw 这个项目不是非常火吗？假设我们就想来看看 OpenClaw 这两天有哪些 bug，帮他们修修给自己一个练手的机会。此时我们就可以向大模型发问：“OpenClaw 这个 GitHub 仓库最新的 3 个 issue 是什么？”

注意，发给大模型的可不止有用户的问题，还有可用的 MCP 工具列表。比如 list issues 用来查询 issue 列表，create branch 用来创建 git 分支等。这样大模型才能够从中挑出与用户问题最为相关的 MCP 工具，并且调用它。当然这个工具列表不是用户发过去的，是 Claude Code 和 Codex 这类程序帮我们发过去的。

那现在问题来了：我们发给大模型的工具列表可不止有工具名称那么简单，其实我们会把每个工具的详细信息也发给它。比如工具叫什么、能干什么、调用时要传哪些参数、每个参数的格式是什么，诸如此类的。这些工具的元信息会占用大量的 Token。我们以 list issues 这个工具为例，看看它的信息有多少？

这个就是它的工具说明了，一共是有 67 行。你可能会想：67 行好像也不多嘛，应该还好？但问题在于我们发过去的可不止有这么一个工具。一般情况下，我们会把所有可用的工具列表都发给模型。这里面我们用的是 GitHub 的 MCP Server，这个 MCP Server 里面有多少工具呢？44 个。

我们来看一下这 44 个工具在一起的信息有多少：这就是 44 个工具的全部信息了。可以看出它有这么多，我翻都翻不完。翻到最底下我们来看一下它一共是有 1683 行，然后它的字符数量呢？大概是 63703 个字符。这 63703 个字符代表什么含义呢？我们来到这个计算 Token 数量的网站来算一下它有多少个 Token。

粘贴进去可以看出，它一共会占用 14268 个 Token。我用 Claude Sonnet 这个模型的价格算了一下，这么多 Token 大概是 3 毛钱的样子。你不要觉得 3 毛钱不多：我们这里面只考虑了 GitHub 这么一个 MCP Server，要是你同时装了好几个类似的 MCP Server 的话，光是工具说明都能花掉你好几块钱。

我们甚至都还没考虑模型输出所花费的价格，这么一想的话那确实是很不划算了。

那如果换成 CLI 会是什么样子呢？首先流程基本上是一样的，唯一的区别在于我们不用发 44 个工具信息了。我们只需要发一个——那个就是 bash 工具。bash 是一个很常见的执行 CLI 命令的程序，相信稍微写过代码的人都知道。这个工具的说明也非常简单就这么十几行：

这个说明的核心就一句话：传一个叫做 command 的参数，参数值就是你要执行的命令。这个命令到时候会由大模型生成。对于我们现在的这个用户问题来说，大模型生成的命令就可以是这个样子的：

这个命令其实就是在用 gh 这个 CLI 程序来获取 issue 列表，具体的我们就不仔细研究了不重要。你有个大概体感就行：在 CLI 这个流程里面，我们只需要传一个 bash 工具给大模型就行。而这个工具的说明就十几行，这跟我们之前看到的那种上万行的 MCP 工具相比，Token 的消耗量几乎可以忽略不计。

看到这里可能有同学会对大模型生成的命令产生一些疑问，所以我再把这行命令调出来看一下。我猜大家的疑问是：大模型怎么知道 gh 这种命令的？我们又没教它。其实很简单，像 gh、git 和 grep 这种常见的 CLI 程序大模型在训练阶段就已经见识过大量的用法了，所以它天然就知道怎么用。

这就像是你去问一个老程序员：“怎么用 git？”他不会去翻文档，而是直接告诉你命令。那如果是一个非常冷门甚至是你自己写的 CLI 工具怎么办呢？这个也很简单：给大模型一份对应的说明文档就行。在实际的工程里，这通常是通过 Agent Skill 来实现的。Agent Skill 本质上就是一份给模型看的说明文档。

所以总结一下大模型对 CLI 程序的使用策略：常见的程序模型早已经内化于心了，所以可以直接使用；而对于冷门程序而言，补一份说明文档就行。相信你现在明白了为什么我们说 CLI 的 Token 消耗量要明显低于 MCP。

那了解了这点之后，我们再来看看第二点：CLI 的执行效率高。我们这就来看一个具体的场景：假设你是一名摄影师，刚拍完一批素材，文件夹里面有 10 张单反照片。现在你的任务是：把所有的横板照片（也就是宽大于高的那些照片）找出来，找出来之后呢给这些照片加上你的专属水印，最后上传到你的服务器上用作网页展示。

听起来是一个很日常的需求对吧？我们先来看看 MCP 模式下会发生什么：大模型首先思考，发现第一步需要知道文件夹里面有哪些文件。于是调用了读取目录工具拿到了 10 张照片的文件名列表。拿到列表之后，大模型再次思考：发现光有文件名还不够，还需要知道每张照片是横板还是竖板。

于是调用读取图片信息工具拿到了每张图片的宽高数据。有了宽高数据之后，大模型再次思考：筛选出横板照片然后调用图像处理工具完成加水印的工作。拿到了处理结果之后大模型又思考了一下，发现下一步要上传文件了。于是调用上传工具把处理好的照片传到服务器上拿到上传结果。

最后大模型再思考一下，发现所有的任务都完成了于是就给出最终答案告诉你“完成了”。你可以看到在整个流程里面大模型一共是负责了两件事情：

一是不停地思考，以便确定下一步是调用工具还是出最终答案。如果是调用工具的话它还要决定到底调什么工具、参数是什么；二是不停地接收工具执行结果。每个工具跑完数据都必须要先回到大模型这里，它看过之后才能决定下一步该干什么。可见大模型是整个链路的调度中心所有操作都必须要经过它，少一步都不行。

这就意味着流程里的每一步都要等大模型响应一次整体效率自然就卡在这里了。好，我们再来看看 CLI 模式下是怎么做的：同样是大模型先思考，只不过在思考之后它只调用了一个工具——那就是 bash 工具。传给这个 bash 工具的是这样一条命令：

这个命令大致可以分为三个部分：第一部分是 exiftool，负责扫描文件夹里的所有照片筛选出宽大于高的横版照片；第二部分是 ImageMagick，接过文件名逐一完成加水印的工作然后把结果输出到 output 文件夹；第三部分是 scp，把 output 文件夹里处理好的照片批量上传到服务器上。

命令发出去之后这三步全部在本地自动跑完，不需要大模型的参与。等所有操作执行完毕结果才回到大模型这里，大模型简单思考了一下发现事情干完了就给出最终答案告诉你“完成了”。可见 CLI 的链路要比 MCP 短得多，效率自然也会高很多。

那为什么 CLI 可以做到这一点呢？因为 CLI 的程序可以随意组合。让我们再回头看看这行命令，这里面有两个非常重要的符号：一个是竖杠（|），它负责把上个命令的结果传给下一个命令；另外一个是双 AND 号（&&），它的意思是如果上个命令成功完成那就开始跑下一个命令。

你看就是这几个看似不起眼的符号把原本独立的工具串联成了一个完整的流程，最终能完成的任务远超你的想象。这背后其实就是 UNIX 系统几十年就确立的一个设计哲学：每个工具只做一件事，但做到极致；工具和工具之间可以自由组合像搭积木一样拼出任意复杂的流程。

exiftool 只管读元数据，ImageMagick 只管处理图像，scp 只管传文件。它们互不干涉却能够无缝协作。正是这种哲学使得几行命令就能完成一个完整的自动化流程，而且几乎没有上限。回头想想 MCP 就很难做到这一点：

你可能会想：“那我把读取目录、读取图片信息、加水印、上传这几个工具做成一个 MCP 工具不就行了吗？一口气把所有的事情全部干完，这样整个流程调用一次 MCP 工具就行了。这不也可以达到跟 CLI 工具一样的效果吗？”理论上确实是可以的，但问题是：需求稍微一变这个工具就不够用了。

比如你可能还想筛选出分辨率为 4K 的照片，或者是想把图片统一转换成 PNG 格式等等。每变一次工具就得重新开发；而 CLI 天生就是组合式的，换个需求调整几个参数重新拼一下几秒钟就搞定了。这种灵活性是 MCP 工具难以复刻的。

聊了这么多 CLI 工具的好话，你可能已经觉得 MCP 工具一无是处了。先别急着下结论：MCP 工具能够成为行业标准那必然也是有它不可替代的优势。我总结了一下 MCP 工具的优势主要是两点：一个是更可控，另外一个是更安全。我们先来看看第一点“更可控”。

所谓更可控说白了就是 MCP 工具更不容易出错。还记得刚才的那段 CLI 命令吗？我们再拿出来看一眼：看起来很完美是吧，但是这个命令其实有个很严重的问题。让我们来仔细看看它的第二部分。现在试想一下：如果某张横板照片的文件名里刚好包含一个单引号，比如是叫做 "mark's photo.png"。

那这条命令就会直接报错：因为文件名里的单引号会破坏命令本身的引号结构。这种问题在 CLI 里其实挺常见的：虽然我前面说过大模型非常擅长生成 CLI 命令，但现实是命令越复杂出错的概率就越高。而且这类错误往往很隐蔽，人类在审查的时候很难一眼看出来。

但如果换成 MCP 工具呢？同样是加水印这一步，MCP 工具的调用方式大概是这个样子的：你看文件名就老老实实地躺在 JSON 的一个字段里。不管它包含单引号、双引号还是空格都不会影响工具的正常执行，因为 JSON 有着自己的转义规则参数的边界也是清晰的不会像 CLI 那样跟命令本身的语法产生冲突。

所以 MCP 工具的执行结果更可控出错的概率也更低。好，MCP 更可控这一点我们明白了；下面来看看第二点：MCP 工具更安全。那为什么说它更安全？我们可以先看看 CLI 存在什么问题：CLI 命令的灵活性是一把双刃剑，它什么都能做也就意味着它什么都能搞砸。

大模型刚才生成的这条命令里面万一是夹带了一个 rm -rf 之类的操作，本地文件可能就被误删了。有可能大模型是好心的它只是想删除临时文件而已但是它犯错了我们可避免不了，而你可能执行了之后才后知后觉这个时候就已经晚了。

在本地环境里面这个风险或许还能接受，大不了你自己承担后果嘛；但如果是在云端环境呢？很多云端的自动化服务比如说是 Make，它允许你在工作流里面接入 MCP 服务但它绝对不会让你直接执行一条 bash 命令。原因很简单：它是一个共享环境，你在上面跑的每一步操作都有可能影响到其他用户。

一旦放开 CLI 权限一条失控的命令就有可能把整个服务器甚至整个集群给搞崩。当然现在也有一些云端产品支持 CLI，但你仔细看就会发现它们其实都是做了严格限制的：本质上还是通过沙箱和权限控制把风险锁在一个可控范围内。这个成本可就很高了，而且安全性也很难达到跟 MCP 一样的等级。

所以在对安全性要求非常高的场景下MCP工具这种受限的设计反而成了一种优势：它只能做工具设计者允许它做的事，不多也不少。所以你看 MCP 并不是一无是处：在可控性和安全性上它确实比 CLI 做得更好。因此在对这两点要求很高的场景下MCP依然是不可或缺的功能。

聊完了两边的优缺点，我们最后来回答这个核心问题：未来到底属于谁？我的判断是 CLI 工具的比重会越来越大，而 MCP 的比重会逐渐缩小。原因很简单：我们前面已经分析过了 CLI 更省 Token、执行效率更高，模型只需生成一行命令就能搞定的事情 MCP 要来来回回折腾好几轮。

对于大部分场景和大部分人来说 CLI 就是一个更快、更便宜、更直接的选择。也正因为这样，CLI 天然更偏向于轻量和个人化的使用方式；而 MCP 呢？它的使用比例会逐步下降，但不会消失。因为 MCP 更安全可控，所以它最终会退守到那些对安全性和稳定性要求比较高的场景。

比如企业或者是云端：在这些场景里你不可能让大模型自由地敲命令行，MCP 这种结构化的、可控的调用方式依然是不可替代的。所以最终的格局其实很清晰：CLI 会越来越多地走向个人，而 MCP 会留在企业和云端。

好这期视频到这里就结束了：如果对你有帮助别忘了点赞关注，我是马克用最通俗的语言讲最硬核的技术。我们下期再见拜拜。