🚀🚀CLI 为什么在 2025 年突然复兴？看懂 Agent、Skill、MCP、CLI 四层架构

2024 年底到 2025 年初，一线科技公司集体押注 CLI：

GitHub 发布 Copilot CLI
Anthropic 发布 Claude Code
OpenAI 跟进 ChatGPT CLI
还有很多公司在研发 CLI 等等

CLI 这个诞生于 1960 年代的交互方式，在被 GUI 压制了 40 年后，为什么突然成了 AI 工具的主战场？

因为，AI 的未来不是"更智能的 GUI"，而是"能被自动化编排的执行引擎"。而 CLI 天生就是这个形状。 CLI 是 AI 的"母语接口"，文本进文本出，完全同构，能组合、能脚本化、能自动化。

但这只是表面。CLI 复兴的背后，是一个完整的四层架构在支撑：CLI、Agent、Skill、MCP。

读完这篇文章，你会发现：

为什么在 CLI 里说一句话，比在 GUI 里点 10 次鼠标更高效
Prompt 和 Skill 的区别，决定了你的 Agent 是"临时工"还是"专家"
不支持 Agent 调用的工具，正在被淘汰

CLI 是什么？为什么 AI 把它当"母语"？

CLI 就是不靠鼠标点按钮，而是在终端里敲文本命令来操作电脑（ls/cd/git 这些）。

GUI：给人用，靠眼睛和鼠标。（手动执行）
CLI：给"脑子"用，直接说要干什么。（自动化执行）

为什么 AI 天生适配 CLI？

完全同构：大模型是文本输入→文本输出，CLI 正好也是命令（文本）→结果（文本），不用中间转换
零视觉误差：GUI 对 AI 很麻烦，要"看懂"按钮位置、颜色、弹窗；CLI 是标准化文本，永远不会点错
母语训练：主流大模型（Claude、GPT-4、Gemini）训练数据里大量 Shell/CLI 命令，相当于"母语"

CLI 的硬核优势

可组合：命令输出可当另一个命令输入（管道、脚本），AI 能轻松串成复杂流程
稳定可靠：GUI 一改版按钮位置就崩；CLI 命令/参数不变就永远能用
效率极高：点 10 次鼠标 = 1 行命令；批量处理上千文件，CLI 秒杀 GUI
资源占用低：无界面渲染，远程 SSH/服务器必用 CLI

这就是为什么大厂集体押注 CLI ------ GUI 是给人点的，CLI 是给机器/AI 说的（牢记这句话）。

CLI 背后的四层架构

CLI 复兴不只是"把 ChatGPT 搬到命令行里"。它背后是一个完整的四层架构：

	是什么	解决什么问题	类比
CLI	交互界面	人和 AI 怎么对话？	门
Agent	决策引擎	谁来理解意图、制定计划、调度资源？	大脑
Skill	固化的行为单元	Agent 的行为怎么标准化？	肌肉记忆
MCP	通信协议	Agent 怎么统一访问外部系统？	通用插头

这四层不是嵌套关系（CLI 包着 Agent），而是平行协作：

scss 复制代码

┌─────────────────────────────────────┐
│  用户输入自然语言                      │
└──────────────┬──────────────────────┘
               │
        ┌──────▼──────┐
        │     CLI     │  接收输入，流式渲染输出
        └──────┬──────┘
               │
        ┌──────▼──────┐
        │     Agent   │  理解意图，拆解任务，动态规划
        └──────┬──────┘
               │
     ┌─────────┼─────────┐
     │         │         │
┌────▼───┐ ┌──▼────┐ ┌─▼──────────┐
│ Skill  │ │传统CLI│  │ MCP Server │
│(记忆)   │ │(工具) │  │(外部接口)   │
└────────┘ └───────┘ └────────────┘

接下来先看一个完整的例子，再逐层拆解。

🚀🚀先看一个完整的例子：四层是怎么协作的

你写完一个功能，想提交代码：

bash 复制代码

claude "帮我检查一下这次改动，没问题就提交"

执行流程：

CLI 接收自然语言，交给 Agent，准备流式渲染输出
Agent 理解意图，拆解任务：代码检查 → 跑测试 → 检查格式 → 提交
Agent 调度三类工具：
- 调用 Skill （/code-review）：按团队标准做代码审查
- 调用传统 CLI ：执行 npm test 和 eslint
- 调用 MCP：如果测试失败，通过 GitHub MCP 查同名 issue
Agent 汇总结果并决策：通过就提交，发现问题就报告
CLI 渲染结果：打印 commit hash 或问题清单

这个流程里：

CLI 是窗口（你和 AI 的交互界面）
Agent 是大脑（规划和决策）
Skill 是记忆（固化的标准流程）
传统 CLI + MCP 是手（一个操作本地，一个连接外部）

看完这个例子，再来看每一层的细节。

四层逐个拆解

CLI：从"记命令"到"说人话"

传统 CLI 和 AI 化 CLI 有什么本质区别？

	传统 CLI	AI 化 CLI
输入	精确语法（`git rebase -i HEAD~3`）	自然语言（"把最近三个提交合并"）
谁规划	你（人类）	Agent
错误处理	报错退出	Agent 尝试修复
可编程性	Shell 脚本	自然语言 + Shell 脚本

AI 化的 CLI 保留了传统 CLI 的可编程性（管道、重定向、脚本），但把"你必须记住所有命令"这个门槛去掉了。

想试试？ 安装 Claude Code：brew install claude-code，然后运行 claude "帮我找出最近一周改动最多的文件"

Agent：会思考的执行引擎

Agent 不是一个具体的程序，而是一个推理循环：

复制代码

感知（理解用户输入和当前状态）
  ↓
推理（决定下一步做什么）
  ↓
执行（调用工具、修改状态）
  ↓
观察（检查结果是否符合预期）
  ↓
重新感知......（直到任务完成）

Agent 和传统脚本的区别

	传统脚本	Agent
执行模式	线性（固定步骤）	动态（根据结果调整）
出错处理	报错退出	尝试修复或换方案
输入方式	结构化命令	自然语言
适用场景	已知流程	不确定性任务

举个例子：

bash 复制代码

# 传统脚本
git diff > changes.txt
eslint changes.txt
if [ $? -ne 0 ]; then exit 1; fi
git commit -m "fix"

# Agent
claude "检查代码，没问题就提交"
# Agent 自己决定：
#  - 要不要跑测试？
#  - 发现问题要不要尝试自动修复？
#  - commit message 写什么？

Agent 的核心能力是动态规划------它不是执行固定脚本，而是根据中间结果随时调整计划。

这背后是 LLM 的工具调用能力（Tool Use）。2024 年之前，LLM 只能输出文本；2024 年 GPT-4、Claude 3 的工具调用准确率突破 90%，Agent 才真正可用。

Skill：把最佳实践固化下来

如果 Agent 每次都从零推理"怎么做代码审查"，会有两个问题：

效率低：相同任务每次都要重新规划。
结果不稳定：同样的代码审查，今天严格明天宽松。

Skill 是固化的行为单元：

markdown 复制代码

Skill: /security-review
  触发：用户调用或 Agent 判断需要时
  流程：
    1. git diff 获取变更
    2. 静态分析扫描漏洞模式
    3. 检查依赖的 CVE
    4. 生成结构化报告
  输出：Markdown 格式的风险清单

Skill vs Prompt：不只是"预设话术"

	Prompt	Skill
本质	一段输入文本	完整的执行流程
包含什么	指令	指令 + 工具调用序列 + 结果处理
谁执行	LLM 解读后执行	Agent 按固定流程执行
可组合性	低	高（Skill 可以调用其他 Skill）
举例	"请帮我做代码审查"	`/code-review` 自动执行 git diff + lint + test + 生成报告

Skill 的价值：

让 Agent 行为可预测：团队知道 /security-review 每次都会检查哪些项
让最佳实践可沉淀：把"我们团队怎么做代码审查"封装成 Skill，新人也能用
让复杂流程可复用：Skill 可以被其他 Skill 调用，形成能力组合

实战提示 ：Claude Code 的 Skill 用 Markdown 文件定义，放在 .claude/skills/ 目录。5 分钟就能写一个简单的 Skill。

MCP：一次实现，到处可用

在 MCP（Model Context Protocol）出现之前，每个 AI 工具都要自己实现各种外部集成：

css 复制代码

Claude Code 接入 GitHub → 写一套 GitHub 集成
Copilot 接入 GitHub → 又写一套
Cursor 接入 GitHub → 再写一套

N 个工具 × M 个外部系统 = N×M 套集成代码

MCP 定义了一个统一协议：

css 复制代码

[任何 AI 工具]  ←→  MCP 协议  ←→  [任何 MCP Server]

一次实现，到处可用。

MCP vs OpenAI Function Calling：不只是"调用函数"

	Function Calling	MCP
作用域	单次对话内的函数调用	跨工具、跨会话的能力共享
标准化程度	仅定义调用格式	定义完整协议（认证、能力发现、状态同步）
可移植性	绑定在特定 LLM/工具上	任何支持 MCP 的工具都能用
生命周期	对话结束就失效	持久化，可跨会话复用
举例	在 ChatGPT 对话里调用天气 API	GitHub MCP Server 同时被 Claude、Copilot、Cursor 使用

MCP 定义了三种标准能力：

Tools ：Agent 可调用的函数，如 create_pr()、query_db()
Resources：Agent 可读取的数据源，如文件系统、数据库、API
Prompts：预定义的提示词模板，如代码审查、安全扫描的标准 Prompt

想接入 MCP？ 官方 MCP Server 列表：github.com/modelcontex... ------ GitHub、Slack、PostgreSQL 等常用服务都有现成的 MCP Server。

四者的核心区别（重点）

四层的边界容易搞混，重点看这一组对比：

最重要的区别：CLI vs Agent --- 接口 vs 引擎

	CLI	Agent
本质	交互界面	决策引擎
有没有推理能力	无	有
角色	接收输入、渲染输出	理解意图、制定计划
举例	终端窗口、命令解析器	Claude、GPT、Copilot

CLI 是"接口形态"（对比 GUI、语音），Agent 是"能力内核"。你可以有 CLI 但没有 Agent（传统命令行工具），也可以有 Agent 但没有 CLI（纯 GUI 的 AI 助手）。

其他三组区别

Skill vs MCP --- 菜谱 vs 采购协议

	Skill	MCP
本质	固化的行为流程	通信协议
解决什么	Agent 行为标准化	外部系统接入标准化
包含推理吗	包含（固化的推理步骤）	不包含（只负责传输）
类比	菜谱（怎么做一道菜）	采购协议（怎么从供应商拿食材）

Skill 关注"怎么做事"，MCP 关注"怎么拿数据/调工具"。Skill 可以调用 MCP，但 MCP 不包含 Skill。

Skill vs Prompt --- 流程 vs 话术

	Prompt	Skill
本质	一段输入文本	完整的执行流程
包含什么	指令	指令 + 工具调用 + 结果处理
谁执行	LLM 解读后执行	Agent 按固定流程执行
可复用性	低（需要每次手动触发）	高（可被 Agent 自动调用）

举例：

Prompt："请帮我做代码审查，重点检查安全问题"
Skill：/security-review 自动执行 git diff + 静态分析 + CVE 检查 + 生成报告

Skill vs 传统 CLI vs MCP --- Agent 调用的三种工具

Agent 执行任务时会调用三类工具，它们的定位完全不同：

	Skill	传统 CLI	MCP Server
是什么	封装的最佳实践流程	操作系统原生工具	外部系统的标准接口
Agent 怎么用	调用 Skill 名称	执行 shell 命令	通过 MCP 协议调用
推理能力	包含固化的推理步骤	无	无
何时用	团队有标准化流程	通用系统操作	需要外部系统数据
举例	`/security-review`	`git commit`、`npm test`	GitHub API、DB 查询
可移植性	中（需要 Skill 系统）	低（依赖系统环境）	极高（任何 MCP 客户端）

这对我们意味着什么？

CLI + Agent 正在改变开发者的工作方式：

会用 Agent 编排的开发者，一句话完成多步操作，效率提升好几倍。
还在手动点 GUI 的开发者，重复劳动，容易被 AI 替代。

具体怎么做？

使用 CLI 工具：Claude Code、GitHub Copilot CLI、ChatGPT CLI ------ 选一个装上，用自然语言试试
关注 MCP 生态：看看有哪些 MCP Server 能连接你常用的服务（GitHub、Jira、数据库）
把团队最佳实践封装成 Skill：代码审查、部署流程、安全检查 ------ 固化下来，新人也能用。（相信这个很多团队都在做）

如果你在做开发者工具，问自己一个问题：你的产品能被 Agent 调用吗？ 如果不能，考虑暴露 MCP 接口。

总结

三个最容易搞混的：

CLI ≠ Agent（接口 vs 引擎）
Skill ≠ Prompt（流程 vs 话术）
MCP ≠ Function Calling（协议栈 vs 单次调用）

如果我们只是把 CLI 当作 Claude Code "能聊天的命令行"，那么我们可能会错过整个 AI 工作流的重要一环。

你认为呢？欢迎在评论区一起讨论！也希望这篇文章对你有所帮助、有所借鉴。