MCP 被抛弃的背后：不是技术输了，是 Token 和效率扛不住了
MCP 曾被誉为 Agent 的万能接口标准，但越来越多的顶级开发者转向 CLI。这不是技术先进与否的问题，而是工程权衡的不同选择。
今年 3 月，Perplexity 的 CTO 在一场开发者大会上公开宣布：他们内部正在全面转向 API 和 CLI 工具，放弃 MCP。
几乎同时，Y Combinator 的 CEO 也说自己选择用 CLI，不用 MCP。而最近爆火的 OpenClaw，在实际执行任务时用的几乎全是内部工具和 CLI 命令，基本上看不到 MCP 的身影。
这就有意思了。MCP 明明是专门为大模型设计的工具接口标准，曾被誉为"Agent 的万能接口"，为什么现在反而被一群"古老"的命令行工具抢了饭碗？
CLI 到底有什么惊为天人的优势？MCP 又有什么不为人知的问题？
CLI 的两大优势
既然 CLI 能获得越来越多人的青睐，那它必然有着非常明显的优势。我总结了一下，主要是两点：Token 消耗小和执行效率高。
Token 消耗：14268 vs 忽略不计
CLI 的 Token 消耗小，从反面看就意味着 MCP 的 Token 消耗大。尤其是 MCP 的元信息——包括名称、描述、入参格式等等——这些都会传到大模型的上下文里面，从而消耗大量 Token。
来看一个具体例子。假设你想让大模型帮你查 GitHub 仓库 OpenClaw 最新的 3 个 issue，此时发给大模型的不只是你的问题，还有可用的 MCP 工具列表。比如 list_issues 用来查询 issue 列表，create_branch 用来创建 git 分支等。
问题在于，这个工具列表可不止有工具名称那么简单。每个工具的详细信息都要发过去：工具叫什么、能干什么、调用时要传哪些参数、每个参数的格式是什么……
以 list_issues 这个工具为例，它的说明一共有 67 行。你可能会想，67 行好像也不多。但问题在于，发过去的可不止这一个工具。
一般情况下，我们会把所有可用的工具列表都发给模型。GitHub 的 MCP Server 里面有 44 个工具。这 44 个工具加在一起有多少？1683 行，63703 个字符。
这 63703 个字符换算成 Token 是多少？14268 个。用 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 的价值，不是比 MCP 更先进，而是把特定场景做到极致。
执行效率：6 次调用 vs 1 行命令
了解了 Token 之后，再来看看第二点：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 工具难以复刻的。
MCP 的优势在哪里
聊了这么多 CLI 工具的好话，你可能已经觉得 MCP 工具一无是处了。先别急着下结论。
MCP 工具能够成为行业标准，那必然也是有它不可替代的优势。我总结了一下，MCP 工具的优势主要是两点：更可控和更安全。
更可控：不容易出错
所谓更可控，说白了就是 MCP 工具更不容易出错。
还记得刚才的那段 CLI 命令吗？看起来很完美是吧，但是这个命令其实有个很严重的问题。
试想一下，如果某张横版照片的文件名里刚好包含一个单引号，比如是叫做 mark's photo.png，那这条命令就会直接报错。因为文件名里的单引号会破坏命令本身的引号结构。
这种问题在 CLI 里其实挺常见的。虽然我前面说过大模型非常擅长生成 CLI 命令，但现实是：命令越复杂，出错的概率就越高。而且这类错误往往很隐蔽，人类在审查的时候很难一眼看出来。
但如果换成 MCP 工具呢？
同样是加水印这一步，MCP 工具的调用方式大概是这个样子的：
| |
文件名就老老实实地躺在 JSON 的一个字段里。不管它包含单引号、双引号还是空格，都不会影响工具的正常执行。因为 JSON 有着自己的转义规则，参数的边界也是清晰的，不会像 CLI 那样跟命令本身的语法产生冲突。
所以 MCP 工具的执行结果更可控，出错的概率也更低。
更安全：权限边界清晰
那为什么说它更安全？
我们可以先看看 CLI 存在什么问题。CLI 命令的灵活性是一把双刃剑：它什么都能做，也就意味着它什么都能搞砸。
大模型刚才生成的那条命令里面，万一是夹带了一个 rm -rf 之类的操作，本地文件可能就被误删了。有可能大模型是好心的，它只是想删除临时文件而已，但是它犯错了我们可避免不了。而你可能执行了之后才后知后觉，这个时候就已经晚了。
在本地环境里面，这个风险或许还能接受，大不了你自己承担后果嘛。但如果是在云端环境呢？
很多云端的自动化服务，比如 Make，它允许你在工作流里面接入 MCP 服务，但它绝对不会让你直接执行一条 bash 命令。原因很简单：它是一个共享环境，你在上面跑的每一步操作都有可能影响到其他用户。一旦放开 CLI 权限，一条失控的命令就有可能把整个服务器甚至整个集群给搞崩。
当然，现在也有一些云端产品支持 CLI，但你仔细看就会发现，它们其实都是做了严格限制的，本质上还是通过沙箱和权限控制把风险锁在一个可控范围内。这个成本可就很高了，而且安全性也很难达到跟 MCP 一样的等级。
所以在对安全性要求非常高的场景下，MCP 工具这种受限的设计反而成了一种优势。它只能做工具设计者允许它做的事，不多，也不少。
所以你看，MCP 并不是一无是处。在可控性和安全性上，它确实比 CLI 做得更好。因此在对这两点要求很高的场景下，MCP 依然是不可或缺的功能。
什么时候该用 CLI，什么时候该用 MCP
聊完了两边的优缺点，最后来回答这个核心问题：未来到底属于谁？
我的判断是：CLI 工具的比重会越来越大，而 MCP 的比重会逐渐缩小。
原因很简单，前面已经分析过了：CLI 更省 Token、执行效率更高。模型只需生成一行命令就能搞定的事情，MCP 要来来回回折腾好几轮。对于大部分场景和大部分人来说，CLI 就是一个更快、更便宜、更直接的选择。
也正因为这样，CLI 天然更偏向于轻量和个人化的使用方式。
而 MCP 呢？它的使用比例会逐步下降，但不会消失。因为 MCP 更安全可控，所以它最终会退守到那些对安全性和稳定性要求比较高的场景，比如企业或者是云端。
在这些场景里，你不可能让大模型自由地敲命令行。MCP 这种结构化的、可控的调用方式依然是不可替代的。
所以最终的格局其实很清晰：
CLI 和 MCP 的差异，不是谁先进谁落后，而是工程权衡的不同选择。
CLI 会越来越多地走向个人，而 MCP 会留在企业和云端。
写到这里，我想问问你：
你现在的项目里，用的是 MCP 还是 CLI？
如果用的是 MCP，有没有遇到过 Token 消耗太大或者执行效率太低的问题？如果用的是 CLI，有没有踩过什么坑？
欢迎在评论区聊聊你的经验。说不定你的一个做法，就能帮到正在纠结选型的人。
最后，如果你觉得这篇文章对你有帮助，不妨转发给团队里那个正在为工具选型头疼的同事。毕竟，理解工程权衡比记住结论更重要。