AI

每天吃透一个 AI 知识点 —— CLI 是什么？会取代 MCP 吗？

Posted Cola🌀

转载：小红书 AI产品赵哥

前言🔖

你可能听说过 MCP（Model-Caller Protocol），它一度被誉为 Agent 的万能钥匙，是连接 AI 大脑与外部世界的最重要的连接器，我们之前也聊过 MCP 的牛掰之处。

但最近，越来越多顶级的开发者和 AI 公司，开始悄悄地抛弃它，转而用一种更原始的方式来解决问题，那就是直接调用命令行程序 —— CLI（Command-Line Interface）。

  • Perplexity 的 CTO 在开发者大会上公开宣布，他们内部正在全面转向 API 和 CLI 工具，放弃 MCP。
  • YC 孵化的明星公司，其 CEO 也明确表示，他们更青睐 CLI。
  • 最近火爆全网的开源项目 Open Interpreter，其核心就是让大模型直接与操作系统的命令行交互。
  • 即便是那些看似使用了复杂 Agent 系统的工具，底层执行的很多任务，也都是通过调用 CLI 命令完成的。

为啥 AI 时代要这么复古？这就好比，在大家都在用智能手机 App 点餐的时代，一群高级餐厅突然宣布，他们只用最原始的柴火和铁锅，并且做出的菜肴效率更高、味道更好。

今天这篇笔记，咱们就来聊这个话题：什么是 CLI？它的优势是什么？能取代 MCP 吗？

好了，大家准备好的话，咱可就发车了！！！

　　

一、CLI 和 MCP 到底是什么？🔖

在开战之前，我们必须先搞清楚这俩是什么货？

🔹1.1 命令行界面 (CLI – Command-Line Interface)

如果你用过电脑的终端或 Windows 的命令提示符，那个黑了吧唧的、只能打字的窗口，就是 CLI。

CLI 工具，就是那些设计出来在命令行里运行的程序。你通过输入一行特定的命令和参数来让它干活。

举例：

  • 想把一个视频从 mp4 格式转成 gif？输入一行 ffmpeg 命令。
  • 想在一个巨大的代码库里搜索包含某个关键词的文件？输入一行 grep 命令。
  • 想批量把一堆照片调整成同样的大小？输入一行 ImageMagick 命令。

这些工具，它们在程序员的世界里已经存在了几十年，稳定、高效，是无数自动化脚本的基础。

💡 简单而言，和 CLI 工具交互，就像你对一个专业的专家下达一个精确的指令。你说清楚你要什么，它就给你做什么，不多一句废话。

　　

🔹1.2 模型调用协议 (MCP – Model-Caller Protocol)

MCP 的诞生，源于一个美好的愿景：为大模型创建一个统一、标准、安全的工具调用方式。

它本质上是一个基于 JSON 格式的通信规范。开发者需要把自己工具的功能，按照 MCP 的格式进行封装。这个包装里要详细说明：

  • 工具名称 (name)：比如 list_github_issues。
  • 工具描述 (description)：详细解释这个工具是干嘛的。
  • 输入参数 (parameters)：需要哪些输入，每个输入的名称、类型、是否必需。

AI 在需要使用工具时，开发者会把所有封装好的工具清单都提供给 AI。AI 会阅读这份清单，然后选择一个最合适的工具，并按照格式要求，生成一个 JSON 对象来调用它。

💡 简单说，和 MCP 工具交互，就像你在填写一张非常详尽的任务申请表。表格上列出了所有你能申请的服务，以及每项服务需要填写的字段。你填好表，提交上去，系统就会按规定帮你处理。

　　

二、CLI 的两大优势🔖

既然 MCP 是专门为 AI 设计的官方配置，为什么会被上古老登 CLI 打得节节败退？因为 CLI 在两个最要命的地方，拥有碾压性的优势：成本和效率。

🔹2.1 优势一：Token 消耗更小

在 AI 的世界里，Token 就是钱，上下文窗口就是寸土寸金的土地。谁能用更少的 Token 办成同样的事，谁就掌握了成本优势。

而 MCP，恰恰是一个吞金（token）兽。

【MCP 的败家模式】

让我们来看一个真实的例子。假设你的 Agent 需要查询一个 GitHub 仓库（比如 Open-Interpreter）最新的 3 条 issue。

如果使用 MCP，你的 AI Agent 在做决策前，需要看到一份完整的、可用的 MCP 工具清单。对于一个集成了 GitHub 功能的 MCP 服务器来说，这份清单可能包含了几十个工具，比如 list_issues、create_branch、get_pull_request 等等。

关键问题在于，传给 AI 的，绝不仅仅是工具的名称。每个工具的完整说明、功能介绍、所有参数的名称、参数的格式、参数的描述…… 这些元信息，一个字都不能少，全都要塞进宝贵的上下文窗口里。

我们来看一下，仅仅是一个 list_issues 工具的 MCP 描述，可能就有几十上百行。而一个标准的 GitHub MCP 服务器，内置了 44 个工具，把它们所有的描述加起来，可能就是：

  • 1683 行的文本
  • 63703 个字符
  • 换算成 Token，大约是 14268 个 Token！

这是什么概念？按照 Claude 系列模型的计价，仅仅是让 AI 看一眼这份工具菜单，你就已经花掉了将近三毛钱！这还没算上你的提问和 AI 的回答所消耗的 Token。

这还只是一个 GitHub 服务器。如果你的 Agent 同时接入了 JIRA、Slack、数据库等多个 MCP 服务器，那光是工具描述的 Token 开销，每次请求可能就要花费好几块钱。这对于需要高频调用的应用来说，成本是根本无法承受的。

【CLI 的抠门模式】

现在，我们换成 CLI 的方案，看看画风是如何大变的。

整个流程，你只需要给 AI 提供一个通用的 bash 执行工具。这个工具的描述可能就十几行，核心思想只有一句话：

  • “我是一个可以执行任何命令行命令的工具。请你生成一个命令字符串，作为 command 参数传给我。”

然后，当用户提出 “查询最新的 3 条 issue” 的需求时，AI 会怎么做？它会直接生成并执行一条 gh（GitHub 的官方 CLI 工具）命令：gh issue list --repo Open-Interpreter/open-interpreter --limit 3

看到了吗？整个流程，AI 的上下文中，只需要携带那一份极其简短的 bash 工具说明。相比 MCP 那上万 Token 的消耗，CLI 方案在工具描述上的 Token 消耗，几乎可以忽略不计！

【一个常见的疑惑】

有人可能会问：AI 又没有专门学过 gh、git、grep 这些命令，它怎么会用呢？

答案很简单：这些通用 CLI 工具，在大模型的训练数据中，已经海量地出现过了！无数的教程、博客、代码仓库、Stack Overflow 的问答，都包含了这些命令的用法。对于 AI 来说，使用这些命令就像一个资深程序员写 git commit 一样，家常便饭。

那如果是公司内部自研的、比较冷门的 CLI 工具呢？也很好解决。你只需要为它写一份简短的说明文档（就像我们前面提到的 Agent Skill），告诉 AI 这个工具是干嘛的、有哪些常用的参数。这份文档的体积，也远远小于 MCP 的元信息。

【总结一下】

  • MCP：每次都要带上一本厚厚的说明书，成本高昂。
  • CLI：通用工具 AI 天生就会，冷门工具只需带上一张小纸条，成本极低。

在 Token 成本日益成为核心竞争力的今天，CLI 的轻量化优势是很明显的。

　　

🔹2.2 优势二：执行效率更高

【MCP：官僚风】

让我们来想象一个摄影师处理素材的典型场景：

  • 需求：一个文件夹里有几十张单反相机拍的原图（RAW 格式），需要筛选出所有横版照片（宽度大于高度），给它们批量加上水印，然后上传到服务器的一个指定目录。

如果用 MCP 来实现，流程可能是这样的：

  1. AI 思考：嗯，第一步我需要知道文件夹里有哪些文件。
  2. AI 调用：调用 list_files 工具，获取全部图片的文件名列表。
  3. 结果返回：工具执行完毕，把文件名列表返回给 AI。
  4. AI 再次推理：好的，现在我需要挨个检查这些照片的尺寸。
  5. AI 循环调用：对每个文件名，调用 get_image_metadata 工具，获取其宽度和高度。
  6. 结果多次返回：每次调用后，结果都返回给 AI。
  7. AI 筛选并再次推理：AI 在脑子里筛选出横版照片，然后决定下一步是加水印。
  8. AI 循环调用：对每个横版照片，调用 add_watermark 工具。
  9. …… 后面的上传步骤以此类推……

发现问题了吗？大模型（AI）是整个流程的绝对调度中心。每一步工具的执行结果，都必须先返回给 AI，等待它进行下一步的判断和决策。这个过程中，AI 的推理、工具的调用、网络传输…… 来来回回，像极了在一个庞大而臃肿的官僚机构里盖章办事，每一步都要请示领导。

整条链路的执行效率，被 AI 的推理速度和网络延迟死死地限制住了。

【CLI：侠客风】

现在，我们看看用 CLI 如何解决同样的问题。

AI 只需要调用一次 bash 工具，然后生成一条组合好的超级命令，一次性下发：

exiftool -if '$ImageWidth>$ImageHeight' -p '$Directory/$FileName' . | xargs -I {} sh -c 'convert "{}" -gravity southeast -pointsize 20 -fill white -draw "text 10,10 '\''@YourName'\''" "output/$(basename "{}")"' && scp output/* user@server:/path/to/upload

这条命令可能看起来像天书，但它做的事情非常清晰，通常由几部分通过管道符 | 或顺序执行符 && 串联起来：

  1. 第一部分 (exiftool)：扫描当前文件夹，用 exiftool 筛选出所有宽度大于高度的照片，并把它们的文件名打印出来。
  2. 第二部分 (imagemagick)：通过管道符 |，将第一步筛选出的文件名，一个一个地传递给 imagemagick 的 convert 命令，批量添加水印，并输出到 output 目录。
  3. 第三部分 (scp)：等前面的所有操作都成功完成后（&& 的作用），用 scp 命令将 output 目录下的所有图片，批量上传到指定的服务器。

整个过程：

  • AI 只介入一次：在最开始生成这条复杂的命令。
  • 命令一次性下发：就像给一个高手下达了一个复合指令。
  • 本地连续执行：三个 CLI 工具在你的电脑上，一个接一个地自动执行。exiftool 处理完的数据直接流向 imagemagick，保证没有中间商赚差价 😂。
  • 全程无需 AI 干预：直到最后所有步骤都完成了，一个最终的结果（比如 “上传成功”）才会被返回给 AI。

CLI 高效的核心，源于 Unix 的设计哲学：

  • 每个工具只做一件事，并把它做到极致。exiftool 只管元数据，imagemagick 只管图像处理，scp 只管文件传输。
  • 通过管道自由串联，像搭乐高积木一样组合出复杂的流程。

【有人可能会反驳】

“我也可以把读取目录、加水印、上传这些功能，封装成一个巨大的、复合的 MCP 工具，然后让 AI 一次调用啊！”

理论上可行，但这种做法牺牲了宝贵的灵活性。

  • 需求微调，成本巨大：如果明天老板说，除了加水印，还要统一转成 png 格式，并且只处理 4K 分辨率以上的照片。对于 MCP 来说，你就得回去修改那个复合工具的后端代码，重新开发、测试、部署。
  • CLI 的极致灵活：对于 CLI，你只需要花几秒钟，调整一下命令里的参数，或者在管道里再加一个工具，就能立刻适应新的需求。

这种即时组合、动态适应的能力，是笨重的 MCP 难以复刻的。

　　

三、MCP 的护城河：在某些领域，它仍不可替代🔖

那 MCP 是不是就不行了？当然不是。

MCP 之所以能一度成为行业标准，并且至今仍在企业级、云端等场景牢牢占据一席之地，就是因为它拥有 CLI 难以企及的两大核心优势：可控性和安全性。

🔹3.1 可控性与低出错率

不知道大家看没看出来，前面那条看起来很酷的 CLI 复合命令，其实隐藏着风险。

  • 隐藏的语法陷阱：如果你的图片文件名里，恰好包含了一个单引号，或者一个空格，会发生什么？很可能会直接破坏整条命令的语法结构，导致命令执行失败，或者更糟 —— 执行了意想不到的操作。
  • 细节出问题：复杂的 CLI 命令，就像手写复杂的 SQL 语句，极易出现这类由特殊字符、转义问题导致的隐蔽 bug。即便是经验丰富的程序员，也很难在第一时间发现。

MCP 的优势在这里就体现出来了。

  • 结构化传参：MCP 基于 JSON 格式进行参数传递。任何文件名、特殊符号、空格、引号，都会被严格地按照 JSON 的转义规则进行处理，变成一个安全的字符串。
  • 参数边界清晰：参数就是参数，永远不会和调用的语法本身发生冲突。 {"filename": "my's photo.jpg"} 这样的结构，清晰地告诉了后端，文件名就叫 my’s photo.jpg，不会引起任何歧义。

💡 结论：在对执行稳定性要求极高的场景，MCP 的出错概率远低于手写的 CLI 命令。

　　

🔹3.2 权限隔离与高安全性

CLI 的极致灵活性，是一把锋利的双刃剑。它能执行任意操作，也意味着它能执行任意危险的操作。

  • 误删风险（rm -rf）：这是所有程序员的噩梦。如果 AI 在生成一条清理临时文件的命令时，稍微犯点迷糊，生成了一条包含 rm -rf / 的命令，并且被执行了…… 那后果将是灾难性的，你的整个文件系统可能会被瞬间清空。
  • 安全漏洞：一个不受限制的 bash 执行权限，就等于向外界敞开了一扇大门，各种命令注入的风险层出不穷。

在个人本地电脑上，这个风险或许你还能自己承担。但想象一下，在多租户的云端共享服务上，哪个平台敢给用户开放一个原生的 bash 权限？

  • 一条失控的 CLI 命令，可能会污染甚至摧毁整个集群的服务。
  • 即便某些云产品支持 CLI，也必须在外面套上层层加固的沙箱环境，并进行严格的权限管控，成本和复杂性都非常高。

MCP 的设计，从根源上就考虑了安全性。

  • 受限的操作集：MCP 工具能做什么，不能做什么，是由开发者预先定义好的。AI 只能在开发者允许的范围内行事，它无法调用 rm 命令，因为它压根就没有这个工具。
  • 最小权限原则：每个工具都只拥有完成自己任务所必需的最小权限。

因此，在企业内部系统、金融领域、云端 PaaS/SaaS 平台等对安全性、权限管控要求达到变态级别的场景，MCP 的这种受限设计是不可替代。

　　

四、CLI 和 MCP 到底怎么选？🔖

CLI 的版图：个人开发者与本地自动化

  • 优势：低成本、高效率、极致灵活、轻量化。
  • 场景：非常适合个人开发者、AI 研究人员、极客玩家，在自己的本地环境里，构建各种酷炫的、轻量级的自动化工作流。比如，一个能帮你自动整理下载文件夹、转换文档格式、发布博客的个人 AI 助手。在这些场景下，成本和效率是第一位的，安全风险相对可控。
  • 趋势：CLI 在个人和开源社区的使用占比会持续、快速地提升，成为默认选择。

　　

MCP 的版图：企业级应用与云端服务

  • 优势：稳定可控、高安全性、易于管理和审计。
  • 场景：它将退守到那些大厂和大客户最关心的领域。比如，在银行的 AI 客服系统中，你绝不希望 AI 能执行任意数据库操作；在企业的内部 OA 系统中，严格的权限控制是生命线；在公有云平台上，多租户的安全隔离是基石。在这些场景下，为了换取绝对的安全和可控，人们愿意付出更高的 Token 成本和牺牲一定的灵活性。
  • 趋势：MCP 的整体占比可能会有所收缩，但它在高安全、高合规性的护城河内，地位依然稳固，甚至会发展出更精细的权限控制和审计功能。