随笔
Search K

Appearance

CLI 与 MCP：不是替代关系，而是两层不同的能力封装 ​

在最近一波 AI 工具和 Agent 基础设施的讨论里，MCP 很容易被理解成一个“会取代 CLI 的新东西”。不少团队第一次接触 MCP 时，都会产生类似的问题：既然模型已经可以通过协议调用工具，为什么还要保留 CLI？是不是以后所有工具能力都应该直接做成 MCP Server？

这个判断如果不拆开看，很容易把两个本来不在同一层的概念混在一起。CLI 和 MCP 的确都在解决“如何让外部使用某种能力”的问题，但它们面向的对象、运行的位置、工程约束和适用场景并不相同。更准确地说，它们不是替代关系，而是两层不同的能力封装。

这篇文章试图回答四个问题：CLI 是什么，MCP 是什么，它们的核心区别在哪里，以及为什么在有了 MCP 之后，CLI 依然有长期价值。

一、CLI 是什么 ​

CLI，Command Line Interface，命令行接口。它的本质是把某种能力包装成一个可以在终端里直接调用的程序入口，让人或者脚本通过“命令 + 参数”的方式使用它。

例如，一个极简的天气查询工具可以长这样：

bash
weather-cli --city Shanghai

输出可能是：

text
Shanghai: 22C, cloudy

从工程角度看，一个 CLI 往往包含几个基本部分：

  1. 命令入口，例如 weather-cli
  2. 参数解析，例如 --city Shanghai
  3. 业务逻辑，例如调用天气服务或读取本地数据
  4. 输出通道，例如标准输出、标准错误、退出码
  5. 运行环境，例如 shell、Node.js、Python、Go 二进制等

CLI 的优势很直接：它天然适合开发者操作、脚本调用和 CI/CD 流水线集成。它遵循的是传统软件工程里非常成熟的一套交互方式。人可以在终端里手工执行，脚本可以批量执行，流水线可以稳定编排。

换句话说，CLI 首先是一个面向“人和自动化系统”的接口，而不是面向模型的接口。

二、MCP 是什么 ​

MCP，Model Context Protocol，可以理解为一种让模型或宿主程序以标准方式连接外部工具与上下文的协议。

如果说 CLI 解决的是“人在终端里怎么调一个能力”，那么 MCP 解决的是“模型在统一协议下怎么调用工具、读取资源、获取上下文”。它不是某一个具体工具，而是一套标准化接入机制。

以同样的天气能力为例，MCP 暴露出来的不会是一个给人敲的命令，而更像是一个工具定义：

json
{
  "name": "get_weather",
  "description": "Get weather by city",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string"
      }
    },
    "required": ["city"]
  }
}

模型或宿主在调用时，发送的是结构化参数：

json
{
  "tool": "get_weather",
  "arguments": {
    "city": "Shanghai"
  }
}

返回的也是结构化结果，例如：

json
{
  "city": "Shanghai",
  "temperature": "22C",
  "condition": "cloudy"
}

从组成上看，MCP 一般会涉及这些部分：

  1. Host 宿主环境，比如 IDE、桌面客户端或 Agent 运行环境

  2. Client 宿主内部负责与 MCP Server 通信的一层

  3. Server 真正暴露能力的一端，对外声明可用的 tool、resource 或 prompt

  4. Tool 模型可以调用的具体能力

  5. Resource 模型可读取的上下文资源，例如文档、配置、Schema

  6. Protocol 定义请求、响应、能力发现和交互方式的标准

因此，MCP 不是 CLI 的同义词，也不是简单的“远程命令执行”。它更像是面向模型生态的一层统一适配协议。

三、CLI 与 MCP 的核心区别 ​

如果把两者放在同一张表里，它们最关键的区别主要体现在以下几个维度。

1. 服务对象不同 ​

CLI 主要服务于人、脚本和传统自动化系统。它的直接使用者往往是开发者、运维、CI/CD、Shell 脚本。

MCP 主要服务于模型和宿主程序。它的直接使用者不是人，而是 IDE 中的 AI 助手、聊天式 Agent 或具备工具调用能力的模型运行时。

这个差异决定了两者设计时关注点完全不同。CLI 关注命令可读性、参数习惯、退出码语义；MCP 关注工具描述清晰度、参数 schema、结果结构化和上下文边界。

2. 调用方式不同 ​

CLI 的调用方式是命令式的，依赖 shell 语义：

bash
deploy-cli --env prod --service order

MCP 的调用方式是协议式的，依赖宿主和服务端之间的结构化通信。调用时不强调“敲什么命令”，而强调“调用哪个 tool，传什么参数”。

这意味着 CLI 更适合直接操作和脚本拼装，而 MCP 更适合让模型在可控边界内进行自动决策和调用。

3. 输出形式不同 ​

CLI 的输出通常是文本流，虽然也可以支持 --json，但传统上它首先是为终端阅读设计的。除了标准输出，还常伴随标准错误和退出码。

MCP 的输出天然偏结构化，因为它的消费者通常不是人，而是模型或上层程序。结构化结果更容易被后续推理、组合和二次处理。

这也是为什么很多优秀 CLI 工具后来会补上 JSON 输出能力：一旦进入机器消费场景，结构化就变得重要。

4. 工程约束不同 ​

CLI 的工程约束主要来自操作系统、Shell 生态、环境变量、文件系统、权限模型和脚本兼容性。

MCP 的工程约束则更多来自协议兼容性、宿主支持、工具描述规范、上下文控制、调用安全性和资源暴露边界。

简单说，CLI 更贴近系统层和工程自动化；MCP 更贴近模型接入层和上下文编排层。

5. 使用场景不同 ​

CLI 典型适合这些场景：

  • 本地开发工具
  • 构建、发布、部署
  • 运维操作
  • 批处理任务
  • CI/CD 流水线
  • 开发者自助工具

MCP 典型适合这些场景：

  • 为 AI 助手暴露工具能力
  • 让模型读取项目上下文或外部资源
  • 在 IDE 中统一接入代码、文档、数据库等能力
  • 构建 Agent 的工具层
  • 降低不同模型宿主的接入适配成本

从这个角度看，两者服务的是不同工作流，因此很难互相完全替代。

四、为什么有了 MCP，还需要 CLI ​

这是最容易被误解的部分。

如果只看“都能触发工具能力”，会觉得 MCP 可以逐步吞掉 CLI。但从实际工程实践看，情况恰好相反：MCP 的出现，更多是在 CLI、API、SDK 之上增加了一层面向模型的标准接入，而不是取代这些底层能力形态。

1. CLI 仍然是传统工程体系里最自然的接口 ​

大量团队内部能力首先不是给模型用的，而是给开发者、测试、运维和流水线用的。

例如：

  • git
  • kubectl
  • npm
  • mvn
  • docker

这些工具的核心价值并不依赖模型存在。它们要解决的是构建、发布、依赖管理、版本控制、集群操作等问题。这类能力天然适合 CLI，因为 CLI 与 shell、脚本和 CI 的耦合最紧密，成本也最低。

即使一个团队未来全面引入 AI 助手，也不意味着这些工具应该被重写成 MCP Server。它们首先仍然要在传统工程体系中稳定工作。

2. 很多 MCP Server 的底层仍然依赖 CLI、API 或 SDK ​

在不少实际实现中，MCP Server 本身并不直接完成所有业务，而是把已有能力通过协议重新暴露出来。

典型链路往往长这样：

text
AI / IDE
  -> MCP Client
    -> MCP Server
      -> CLI / SDK / HTTP API

也就是说，MCP 常常是“接入层”，不是“执行层”。它可能把现有的 CLI 包装成 tool，也可能调用内部 SDK 或 HTTP 服务。团队之所以能较快补上 MCP，通常正是因为底下已经有稳定的 CLI 或 API 能力可复用。

如果底层能力本身不清晰，直接上 MCP 往往只是在更高一层暴露混乱。

3. CLI 更适合独立调试和批处理 ​

从工程可维护性看，CLI 有一个非常现实的优点：它可以脱离宿主、脱离模型、脱离协议，单独验证。

例如一个失败的发布动作，如果你可以直接运行：

bash
deploy-cli --env staging --service order

就能快速看到日志、退出码和行为边界；而如果所有能力都先经过 MCP，再经过模型宿主，调试链路就会更长，定位成本也更高。

同样，批量任务、循环任务、流水线任务，本质上仍然更适合 CLI。shell 脚本、Makefile、CI job 对 CLI 的支持是天然的，而对 MCP 并非如此。

4. 不是所有环境都有 MCP，但几乎所有工程环境都有终端 ​

MCP 的价值建立在“宿主支持协议并具备工具调用能力”之上。CLI 则不依赖这类前提。只要有终端环境，CLI 就能工作。

这意味着 CLI 的兼容性边界更宽。对于需要跨环境、跨团队、跨基础设施复用的能力，CLI 往往仍然是最稳的基础形态之一。

五、团队应该如何理解这两者的关系 ​

如果站在团队建设和技术选型的角度，更合理的理解不是“CLI 和 MCP 选哪个”，而是“能力应该在什么层面暴露，以及应该先建设哪一层”。

一个比较中性的判断框架是：

1. 如果能力首先服务于开发者和流水线，优先考虑 CLI 或 API ​

例如构建、部署、数据修复、环境诊断、项目初始化，这些能力的直接消费者通常是人和自动化系统。此时优先把 CLI 或 API 设计清楚，收益最大，也最稳。

2. 如果能力要被 AI 助手稳定调用，再补 MCP 接入层 ​

例如希望 IDE 中的 Agent 能读项目文档、执行某些团队工具、查询系统状态或触发受控操作，这时 MCP 的价值就非常明显。它让模型不必理解每个工具的私有调用方式，而是通过标准协议统一接入。

3. 成熟团队往往是“CLI/API 打底，MCP 向上适配” ​

这通常是一条更健康的演进路径。底层能力先独立成立，再根据 AI 场景补标准化接入。这样既能保持传统工程体系的稳定性，也能逐步获得模型调用带来的效率提升。

如果反过来做，一开始只围绕 MCP 设计，而忽视 CLI/API 的独立性，容易导致能力与某个宿主强耦合，脱离 AI 环境后反而难以复用。

六、结语 ​

CLI 与 MCP 解决的是两个相邻但不同层级的问题。

CLI 是能力的直接入口，主要面向人、脚本和工程自动化；MCP 是能力的标准化接入层，主要面向模型和宿主程序。CLI 强在工程体系兼容性、脚本化和独立调试，MCP 强在模型工具调用、上下文整合和统一接入。

因此，问题不应当是“有了 MCP，还要不要 CLI”，而应当是“哪些能力应该先沉淀为稳定的工程接口，哪些能力需要进一步通过 MCP 暴露给模型”。

从长期看，这两者大概率会持续共存。对于团队而言，真正重要的不是站队，而是把能力边界、消费对象和接入层次设计清楚。只有这样，CLI 不会被误用成协议层，MCP 也不会被误当成执行层。

Last updated: