做了一段时间的AI coding后,我终于搞清了 CLI 和 MCP 的区别

如果你最近一直在用 Claude Code、Codex、Cursor 这些 AI Coding Agent,应该会发现一个现象。

一边是 MCP 越来越火,各种平台都在提供 MCP Server。

另一边,不少平台也开始推出自己的 CLI,甚至优先建设 CLI,而不是 MCP。

刚开始我一直有个疑问:

MCP 不是 Agent 的标准协议吗?为什么大家还在花精力做 CLI?

后来真正做了一段时间的 AI coding,发现自己一开始理解错了。

CLI 和 MCP 并不是同一层的能力,也不存在谁会取代谁。

它们解决的是两个不同的问题。

我们先看看 Agent 是怎么工作的

很多人第一次接触 Agent,总觉得它是在"调用工具"。

但如果你观察 Claude Code 的执行过程,会发现它更像一个开发者。

例如你说:

帮我启动项目。

Claude 很可能会执行:

复制代码
pnpm install
pnpm dev

你说:

看一下最近有哪些提交。

它执行:

bash 复制代码
git log

你说:

帮我运行测试。

它执行:

bash 复制代码
pnpm test

整个过程几乎都是:

复制代码
读取信息
↓

执行命令
↓

观察结果
↓

继续下一步

如果你把终端打开,会发现 Claude 大部分时间都在和 Terminal 打交道。

这也是为什么越来越多平台开始建设 CLI。

因为对于 Agent 来说,CLI 已经不仅仅是开发者工具,而是一种天然的工作接口。

CLI 更像是在"执行任务"

CLI 最大的特点就是简单。

Agent 不需要知道底层 API 长什么样。

也不用关心请求地址、认证方式或者参数拼接。

它只需要执行:

复制代码
platform deploy

或者:

lua 复制代码
platform app create

CLI 完成认证、参数校验、请求发送,再把结果返回给 Agent。

整个过程和开发者自己在终端输入命令几乎没有区别。

对于已经知道自己要做什么的任务来说,这种方式效率非常高。

但是 CLI 有一个天然的问题

假设现在给 Agent 一个新的 CLI。

复制代码
company-cli

里面有几十个命令:

sql 复制代码
deploy
rollback
logs
project
member
permission
pipeline
...

问题来了。

Agent 怎么知道:

  • 有哪些命令?
  • 每个命令是干什么的?
  • 哪些命令应该组合使用?
  • 哪些能力适合当前任务?

当然,它可以执行:

bash 复制代码
company-cli --help

或者:

bash 复制代码
company-cli deploy --help

一步步探索。

但这种探索本身就是有成本的。

特别是当 CLI 足够复杂的时候,Agent 需要不断查询帮助文档、阅读输出,再决定下一步。

这时候 MCP 的价值就体现出来了

很多文章喜欢说:

MCP 是一种协议。

但我觉得,从开发者角度来看,可以理解得更简单一点。

MCP 更像是一份能力说明书。

它提前告诉 Agent:

我有哪些能力。

每个能力是做什么的。

需要哪些参数。

返回什么结果。

也就是说。

CLI 更关注:

复制代码
怎么执行。

MCP 更关注:

复制代码
有哪些能力可以执行。

Token 成本

真正开始 AI coding 后,我越来越关注另一个问题。

Context。

假设一个平台提供了 100 个 Tool。

每个 Tool 都有:

  • 名称
  • 描述
  • 参数
  • Schema
  • 示例

这些内容最终都会进入模型上下文。

Tool 越多。

Context 越长。

Token 消耗也越高。

尤其是在长对话或者复杂工作流里,这部分成本并不低。

而 CLI 的思路完全不同。

Agent 不需要提前知道所有能力。

需要的时候,再执行:

bash 复制代码
company-cli --help

或者:

复制代码
company-cli project list

获取当前需要的信息。

换句话说。

MCP 更像是:

把一本说明书提前放在桌子上。

CLI 更像是:

需要的时候再翻说明书。

没有绝对谁更好。

只是两种不同的设计思路。

那到底什么时候适合 CLI?

如果 Agent 已经知道自己要完成什么任务。

例如:

  • 部署应用
  • 查看日志
  • 创建项目
  • 下载文件
  • 发布版本

这种目标非常明确的场景。

CLI 往往已经足够了。

Agent 直接执行命令。

读取结果。

继续下一步。

整个链路简单,而且稳定。

这也是为什么现在很多平台会优先提供 CLI。

因为它既可以服务开发者,也可以直接服务 Agent。

又什么时候更适合 MCP?

如果 Agent 面对的是一个能力非常复杂的平台。

例如:

  • 数百个业务接口
  • 多种资源对象
  • 多步骤工作流
  • Agent 需要自主规划执行路径

这时候,仅仅提供 CLI 就不一定够了。

因为 Agent 首先需要理解:

我有哪些能力?

哪个能力更适合当前任务?

这些能力之间应该怎么组合?

MCP 在这种场景下能够降低 Agent 的理解成本,也更容易完成复杂规划。

写在最后

我现在越来越觉得。

CLI 和 MCP 其实不像两个竞争产品。

更像两个不同层级的能力。

一种负责执行。

一种负责描述。

未来很多平台的形态,很可能会是:

CLI 负责把事情做完。

MCP 负责让 Agent 更容易知道有哪些事情可以做。

对于简单任务,Agent 完全可以直接调用 CLI。

对于复杂任务,MCP 又能帮助 Agent 做更好的规划。

两者并不是互相替代,而是在不同阶段发挥作用。

相关推荐
IT_陈寒4 小时前
JavaScript项目实战经验分享
前端·人工智能·后端
用户47949283569154 小时前
6w star,GitHub 趋势第一的 Ponytail,这个agent插件到底在火什么
前端·后端
薛定喵的谔6 小时前
我开源了一个精致的 Next.js 博客模板:Skyplume
前端·前端框架·next.js
张龙6876 小时前
构建生产级 AI Agent:工具调用与记忆架构实战指南
前端
小孔菜菜7 小时前
LLM / Agent / Skills / MCP 协同关系深度解析
agent
kyriewen7 小时前
2026 年了,还在用 Node.js?Bun 迁移实战:20 分钟搞定,附踩坑记录
前端·javascript·node.js
JouYY9 小时前
聊一下多 Agent 编排架构的应用实践
架构·llm·agent
青山Coding9 小时前
Cesium应用(八):物体运动的实现思路
前端·cesium
用户41659673693559 小时前
Android WebView 加载 file:// 离线页面调试教程
android·前端