为什么大模型工具接口正在从 MCP 回到 CLI

摘要（先看结论）

• CLI（Command Line Interface，命令行界面）最近重新成为大模型调用外部工具时的高频选择，本质原因不是“老技术复活”，而是它在很多场景里更省 Token、更快、更直接。
• MCP 可以理解为一种面向大模型的结构化工具调用方式。它的价值不在于“更万能”，而在于参数边界清晰、可控性更强、安全性更容易做进系统。
• 如果任务本来就适合本地串成一条流水线，比如搜索文件、批量处理图片、调用 GitHub CLI，那么 CLI 往往能一条命令跑完整个流程，减少模型反复调度。
• 如果任务运行在企业环境、共享环境或高风险环境里，MCP 仍然更稳，因为它天然更容易限制能力边界，避免命令注入和误操作。
• 更可能出现的不是“谁彻底消灭谁”，而是分工收敛成两类场景：个人和轻量场景偏 CLI，企业和强治理场景偏 MCP。

快速导航（按困惑定位）

困惑/现象	看哪节	一句话解释
为什么大家又开始谈 CLI 了？	2	因为很多工具链本来就是 CLI 原生，模型直接调用更省中间层。
MCP 到底怎么传给模型？	1 / 2	MCP 通常先变成宿主框架里的结构化工具描述，再交给模型，不是靠固定文本分隔符。
模型为什么知道怎么用 CLI？	2 / 3	常见工具来自预训练知识，自定义工具则要靠当前上下文补说明。
CLI 工具是怎么传给模型的？	1 / 2	常见做法要么暴露成一个通用 bash/terminal 工具，要么通过 system prompt/skill 文档补使用约定。
CLI 到底赢在什么地方？	3	省 Token、少调度、易组合。
MCP 为什么没有被淘汰？	4	因为结构化参数和安全边界在很多环境里仍然更重要。
未来会不会只剩 CLI？	5	不会，更可能是场景分化。
最容易误解的点是什么？	6	CLI 不是总优，MCP 也不是天然低效。

1. 先把两个概念说清楚

• CLI：让模型通过命令行直接调用现成工具，比如 grep、ffmpeg、git、gh、ImageMagick。
• MCP：把工具能力包装成结构化接口，模型按预定义参数去调用。

二者最大的差别，不是“能不能调用工具”，而是“工具能力以什么形式暴露给模型”。

可以把它们理解成两种不同的抽象层级：

CLI 路线
模型 ──> 命令行工具 ──> 操作系统/本地环境 ──> 结果

MCP 路线
模型 ──> 结构化工具接口 ──> 工具服务/执行层 ──> 结果

CLI 更接近现成工具本身，抽象更薄；MCP 在工具和模型之间多加了一层结构化协议，抽象更厚。

这就是后面所有差异的来源。

1.1 MCP 是怎么传给大模型的

先说一个容易混淆的点：MCP 本身不是“大模型提示词里的一段固定文本格式”，而更像是宿主程序和工具服务之间的一层协议。

也就是说，真实链路通常不是：

把一段 MCP 文本直接拼进 prompt -> 模型就懂了

更常见的链路是：

MCP Server
   │ 暴露工具清单、参数 schema、说明
   ▼
Agent / 宿主框架
   │ 把这些信息转换成模型可消费的工具描述
   ▼
大模型
   │ 选择某个工具并生成结构化调用
   ▼
Agent / 宿主框架
   │ 再把调用转回 MCP 请求
   ▼
MCP Server

这里最关键的一点是：

• 模型看到的，通常不是“MCP 协议原文”
• 模型看到的，通常是宿主框架整理后的工具描述

在很多模型 API 里，这类工具描述会以结构化字段出现，比如：

• 工具名
• 工具说明
• 输入参数 schema
• 必填字段

所以，MCP 传给大模型时，常见形态更像“结构化 tools 列表”，而不是靠某个固定分割符把工具信息塞进普通文本 prompt。

换句话说，问题里的“是否有 tools 的固定分割字段”，答案更接近：

• 在协议层，没有一个跨所有宿主都统一的“文本分隔符”
• 在实现层，通常会有宿主框架自己的结构化字段
• 模型往往消费的是这些结构化字段，而不是原始 MCP 报文

这也是为什么不同 Agent 框架、不同模型厂商，看起来“都在支持 MCP”，但真正喂给模型的格式可能并不完全一样。

1.2 CLI 工具又是怎么传给大模型的

CLI 传给模型，常见有两种做法。

第一种做法，是把“命令行”暴露成一个通用工具。

例如，宿主框架只给模型一个 bash、shell 或 terminal 工具，然后告诉模型：

• 你可以执行命令
• 参数是整段命令字符串
• 返回的是 stdout / stderr / exit code

这种情况下，模型并不是“看见了 100 个 CLI 工具”，而是只看见了一个通用的终端执行入口。

可以把它理解成这样：

模型看到的工具：

tool: bash
input:
  command: <string>

模型自己决定：
- 要不要用 grep
- 要不要用 ffmpeg
- 要不要把多个命令串起来

第二种做法，是不把 CLI 当成一个正式工具字段，而是通过 system prompt、skill 文档或任务说明，把“当前允许使用哪些命令、常见命令怎么写、哪些路径能访问、哪些命令危险”告诉模型。

这时模型获取 CLI 知识的来源更像：

• 一部分来自它对常见命令的预训练记忆
• 一部分来自当前 system prompt / skill 文档补充

所以，问题里的“CLI 是否需要字段，还是放在 system prompts 里”，更准确的回答是：

• 可以有结构化字段：例如一个通用 bash 工具
• 也可以靠 prompt / skill 文档补规则
• 很多实际系统是两者结合

一个很常见的组合是：

结构化字段：
  提供一个 bash/terminal 工具

system prompt / skill：
  说明哪些命令常用
  说明哪些目录可访问
  说明哪些操作危险
  说明输出应该如何整理

1.3 为什么这会直接影响 CLI 和 MCP 的成本差异

现在就能看出两条路线的关键差别了。

MCP 路线里，宿主框架往往要把一整套工具元信息整理后交给模型，工具越多，这份描述就越重。

CLI 路线里，如果只暴露一个通用 bash 工具，那么模型拿到的结构化描述可能非常短，真正复杂的部分被留给了模型自己的命令组合能力，以及 system prompt / skill 里的少量补充说明。

这也是为什么很多人会直观感受到：

• MCP 更像“把工具目录交给模型”
• CLI 更像“给模型一把终端，再补一页使用约定”

当然，这种轻量并不自动等于更安全，它只是把复杂度换了个位置。

2. 为什么 CLI 突然又重要了

一个很直接的原因是：很多开发和内容处理任务，本来就已经有成熟的命令行工具。

例如：

• 查仓库信息，可以直接用 gh
• 搜文件和文本，可以直接用 grep
• 转视频格式，可以直接用 ffmpeg
• 处理图片，可以直接用 ImageMagick

如果这些能力已经以 CLI 的形式存在，那么再包一层 MCP，虽然会得到更清晰的接口，但也会引入额外描述成本和调度成本。

这里可以用一个很典型的对比来感受差异：

• CLI 只需要传递一段很短的 bash 工具说明，大约 10 行
• 一个包含 44 个工具的 MCP 服务，其工具说明达到 1683 行、63703 个字符，约 140268 Token

这里的 Token 可以理解成模型读入上下文时的基本计量单位。工具说明越长，模型每次“先理解工具再决定怎么调”的成本就越高。

所以，CLI 的回潮，本质上是对一件事的重新认识：

当工具本身已经很成熟时，最省事的方式往往不是继续加抽象，而是让模型更直接地用它。

2.1 模型为什么会用这些命令行工具

这背后其实有三层来源。

第一层是预训练知识。

很多常见命令行工具，比如 git、grep、curl、ffmpeg，在公开文档、教程、博客、问答网站、代码仓库里出现得非常频繁。模型在训练阶段已经反复见过这些工具名、常见参数、典型用法，所以它往往能形成一种“统计意义上的熟悉”。

但这里要注意，模型并不是像人在终端里那样“真正学会了一个工具”，而是学会了：

• 这个工具通常用来解决什么问题
• 常见参数大概长什么样
• 哪些参数组合经常一起出现

第二层是当前运行环境提供的工具说明。

即使模型“听说过”某个工具，它在真正执行前，通常仍然需要知道当前环境到底允许它用什么、应该怎么调用、是否有额外限制。也就是说，预训练知识解决的是“我大概知道这是什么”，而不是“我已经确认当前机器上就是这么用”。

第三层是任务侧补充说明。

如果一个工具是团队自定义 CLI，或者是很冷门的内部命令，那么模型在预训练里几乎不可能真正见过。这时候，能不能用好它，就取决于你有没有把最小必要信息放进当前上下文。

可以把这三层理解成下面这张图：

模型会不会用一个 CLI，通常取决于三层信息叠加

┌─────────────────────────────┐
│ 1. 预训练知识               │
│ 常见工具名 / 常见参数 / 场景 │
└──────────────┬──────────────┘
               │ 提供“熟悉感”
               ▼
┌─────────────────────────────┐
│ 2. 当前工具说明             │
│ 这个环境里能不能用、怎么用   │
└──────────────┬──────────────┘
               │ 提供“可执行性”
               ▼
┌─────────────────────────────┐
│ 3. 任务补充文档 / skill      │
│ 自定义参数、约束、示例、边界 │
└─────────────────────────────┘

所以，大模型“知道怎么用 CLI”，本质上不是因为它在脑子里装了一份完整 man page，而是因为：

• 对常见工具，它在训练中见过足够多模式
• 对当前任务，它又拿到了最小必要的上下文

这两件事叠加，才让它看起来像“会用命令行”。

2.2 如果是自定义 CLI，应该怎样告诉大模型怎么用

答案不是把整份帮助文档一股脑塞给模型，而是给它一份“最小可执行说明”。

这份说明通常至少要包含五类信息：

• 工具是干什么的：一句话说明用途
• 基本调用骨架：命令格式长什么样
• 关键参数：最常用的 3 到 5 个参数分别代表什么
• 输入输出：读什么、写什么、成功后返回什么
• 约束与禁区：哪些参数危险，哪些场景不要用

例如，一个自定义 CLI 不需要先给模型 200 行帮助文档，很多时候下面这种说明就已经够用了：

tool: acme-image
purpose: 批量处理图片并输出到目标目录

syntax:
  acme-image <input-dir> --output <output-dir> [--resize <spec>] [--watermark <text>]

important flags:
  --output: 输出目录，必填
  --resize: 调整尺寸，例如 1920x1080
  --watermark: 添加文字水印

behavior:
  - 只处理 jpg/png
  - 默认不会覆盖已存在文件
  - 成功时输出处理数量与失败文件列表

avoid:
  - 不要把 input-dir 和 output-dir 设成同一路径

这类说明的作用，不是把模型训练成这个工具的专家，而是把它从“只知道名字”推进到“足以安全完成当前任务”。

如果还想进一步提升成功率，通常再补两样东西就够了：

• 一个最小示例：给模型一条成功命令样例
• 一个失败示例：告诉模型最容易踩的坑是什么

例如：

good example:
  acme-image ./raw --output ./dist --resize 1920x1080

common mistake:
  不要把 --output 省略，否则工具会直接报错退出

这也是为什么很多 agent skill 会非常有效。

skill 本质上不是“替模型思考”，而是把某个自定义 CLI 的使用边界、调用套路和常见坑提前整理好，让模型在当前任务里少走弯路。

3. CLI 赢在哪里

3.1 Token 成本低

CLI 最大的现实优势，不是优雅，而是便宜。

很多时候，模型要先读懂“我手头有哪些工具、每个工具的参数是什么、该怎么选”，然后才能开始真正做事。MCP 的问题在于，如果工具很多，这份“说明书”会很重。

对比起来：

• CLI：只要知道可用命令和基本用法即可
• MCP：往往需要把整套工具 schema 一起塞进上下文

当任务很小，但工具描述很大时，就会出现一种不划算的情况：

真正任务只有一句话
        │
        ▼
先读一大段工具说明
        │
        ▼
再决定调哪个工具
        │
        ▼
最后才开始执行

这也是为什么在一些高频、小任务场景里，CLI 会显得更“轻”。

3.2 执行链更短

设想一个很常见的批处理场景（以摄影工作流为例）：

• 先筛选横版照片
• 再加水印
• 再上传服务器

如果按 MCP 的方式拆开，模型通常要多次调用工具，并在每一步重新决定下一步做什么。

而 CLI 可以把这些动作直接串成一条本地流水线：

读目录
  │
  ▼
筛选符合条件的图片
  │
  ▼
批量加水印
  │
  ▼
上传服务器

对应到命令行世界，这条链路往往可以通过管道符 |、条件执行 &&，或者多个命令组合成一次完成。

例如，可以把它写成一个很直观的 bash 流程：

find ./photos -type f \( -name "*.jpg" -o -name "*.png" \) \
  | xargs identify \
  | awk '$3 > $4 { print $1 }' \
  | xargs -I{} sh -c 'convert "{}" -gravity southeast -annotate +20+20 "Sample" "./watermarked/$(basename "{}")"' \
  && scp -r ./watermarked user@server:/data/photos/

这条命令的意思是：

• find：先找出目录里的图片文件
• identify：读取图片尺寸信息
• awk：筛出横版图片
• convert：给筛出来的图片批量加水印
• scp：在前面都成功后，再统一上传到服务器

这意味着：

• 模型少做几次中间判断
• 本地工具自己接力
• 流程更像“执行脚本”而不是“逐步请示”

任务越流程化，CLI 的优势越明显。

3.3 工具组合能力强

CLI 的另一个优势，来自典型的 UNIX 哲学：一个工具做好一件小事，然后通过组合完成复杂任务。

比如同样是处理照片，需求一变，从“筛选横版”变成“筛选 4K 分辨率照片”，往往只需要改参数，不需要重新设计接口。

这类组合能力可以抽象成下面这样：

小工具 A ─┐
小工具 B ─┼──> 管道/组合 ──> 完整流程
小工具 C ─┘

MCP 当然也能组合，但如果组合方式不在原本的工具设计里，就常常需要新增工具、改 schema，或者让模型显式地做更多步骤编排。

所以从“应对变化”的角度看，CLI 更像积木，MCP 更像预制模块。

4. MCP 为什么不会消失

如果只看效率，很容易得出“那以后都用 CLI 不就行了”的结论。但这正是最容易犯的错误。

MCP 真正的价值，在另外两个维度上非常突出。

4.1 参数边界更清晰

MCP 的参数通常是结构化的，比如 JSON 形式。它的好处是：

• 字段是什么，边界很清楚
• 特殊字符不容易把调用语义搞乱
• 调用前更容易做校验

举一个很实在的问题：如果文件名里带单引号或其他特殊字符，CLI 命令更容易因为转义和拼接问题出错；结构化参数则稳定得多。

换句话说，CLI 的自由度高，但自由度越高，语法错误空间也越大。

4.2 安全边界更容易收紧

在企业环境、云端环境或共享环境里，安全性通常比灵活性更重要。

这时 MCP 的受限设计就很有价值：

• 模型只能调用预设功能
• 不容易越权执行危险命令
• 审计和权限治理更容易做

与之相比，CLI 的风险更接近“把一把真正的瑞士军刀交给模型”。能力强，但如果没有额外沙箱、权限隔离和命令审查机制，误执行危险命令的代价也更高。

用 rm -rf 作为极端例子，意思并不是说模型一定会这么做，而是说明：

只要能力边界是开放命令行，风险上限就天然更高。

所以，MCP 并不是“落后版本”，它更像是为高治理环境准备的安全型接口。

5. 未来格局：不是替代，而是分层

对未来的判断可以压缩成一句话：

个人用 CLI，企业用 MCP。

这句话不一定覆盖所有情况，但它很好地抓住了趋势。

更完整地说，未来大概率会出现三种分层：

• 个人开发、本地自动化、轻量任务：CLI 占优
• 团队共享、云端运行、关键业务：MCP 占优
• 混合系统：外层用 MCP 管边界，内层仍然调用 CLI 完成实际执行

可以把这种格局画成一张图：

轻量 / 个体 / 本地
        │
        ▼
      CLI 更优

重治理 / 共享 / 云端
        │
        ▼
      MCP 更优

这也解释了为什么 MCP 很难彻底消失。

只要还有以下需求，它就会一直存在：

• 权限要严格分层
• 调用要便于审计
• 工具行为要稳定可预测
• 运行环境不能允许自由命令行

6. 常见误区

6.1 误区一：CLI 更先进，所以会全面替代 MCP

不对。

CLI 的优势主要来自轻量、直接、组合灵活，不代表它在安全和边界控制上更好。只要场景一换，评价标准也会变。

6.2 误区二：MCP 低效，是因为设计错了

也不对。

MCP 的很多“成本”其实是在换取治理能力。它更像把复杂度前置，目的是让调用过程更可控，而不是单纯追求最短路径。

6.3 误区三：模型只要学会 CLI，就不再需要额外工具描述

这也不能一概而论。

很多模型对常见的 git、grep 一类工具已经较容易理解；但这种理解更接近“知道典型模式”，不等于“知道当前环境里的精确行为”。

一旦换成冷门工具、自定义 CLI、团队内部脚本，模型就很可能缺少关键上下文。这时就必须补充最小必要说明，或者通过 agent skill 之类的方式，把以下内容明确交给模型：

• 这个工具是干什么的
• 最常用的命令骨架是什么
• 关键参数和默认行为是什么
• 输入输出长什么样
• 哪些用法容易出错或有风险

所以真正的差别不是“要不要说明书”，而是“说明书有多重、是否必须每次都完整加载”。

7. 总结

这场讨论的核心，不是 CLI 和 MCP 谁更正确，而是哪种抽象更适合当前任务。

如果你只看效率，结论往往会偏向 CLI：

• Token 成本更低
• 流程更短
• 工具组合更自然

如果你把安全、治理和稳定性也放进来，MCP 的价值就会立刻变得明确：

• 参数边界更清楚
• 权限控制更容易
• 在企业环境里更可审计

因此，更准确的结论不是“CLI 正在取代 MCP”，而是：

大模型工具接口正在从“统一标准幻想”走向“按场景分层”的现实格局。

对个人和轻量场景来说，最小化抽象往往更有效；对企业和高风险场景来说，结构化约束仍然不可替代。