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

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

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

刚开始我一直有个疑问：

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

后来真正做了一段时间 Agent，我发现自己一开始理解错了。

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

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

---

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

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

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

例如你说：

帮我启动项目。

Claude 很可能会执行：

pnpm install
pnpm dev

你说：

看一下最近有哪些提交。

它执行：

git log

你说：

帮我运行测试。

它执行：

pnpm test

整个过程几乎都是：

读取信息
↓

执行命令
↓

观察结果
↓

继续下一步

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

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

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

---

CLI 更像是在"执行任务"

CLI 最大的特点就是简单。

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

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

它只需要执行：

platform deploy

或者：

platform app create

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

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

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

---

但是 CLI 有一个天然的问题

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

company-cli

里面有几十个命令：

deploy
rollback
logs
project
member
permission
pipeline
...

问题来了。

Agent 怎么知道：

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

当然，它可以执行：

company-cli --help

或者：

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 不需要提前知道所有能力。

需要的时候，再执行：

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 做更好的规划。

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