一文讲清 CLI、MCP、A2A、A2UI 和 AG-UI

最近一年，AI Agent 圈子里冒出了大量缩写：

CLI、MCP、A2A、A2UI、AG-UI......

很多人第一次看到时会有一种错觉：

怎么又发明了这么多协议？

实际上，如果把它们放在同一条技术演进线上看，会发现这些东西并不复杂。

它们解决的是同一个问题：

如何让 Agent 与外部世界协作。

只是协作对象不同，因此出现了不同层次的协议。

从 CLI 开始：人与程序的交互协议

最早的软件世界里，并没有 Agent。

程序之间协作最简单的方式就是：

bash 复制代码

git clone xxx
npm install
python main.py

这就是 CLI（Command Line Interface，命令行接口）。

CLI 本质上是一种约定：

输入参数
执行命令
返回结果

例如：

lua 复制代码

ffmpeg input.mp4 output.mp3

你不需要知道 ffmpeg 内部怎么实现。

只需要遵守它的参数规则即可。

因此：

CLI 本质上是 Human → Tool 的协议。

它解决的是：

人如何调用程序。

MCP：Agent 调用工具的协议

当 LLM 出现后，问题发生了变化。

以前是人调用工具：

sql 复制代码

git commit

现在变成 Agent 调用工具：

makefile 复制代码

Agent:
需要获取浏览器内容
→ 调用 Browser Tool

问题来了：

Agent 怎么知道工具有哪些？

工具参数是什么？

返回结果长什么样？

如果每个工具都自己定义格式：

json 复制代码

{
  "tool": "browser"
}

或者：

json 复制代码

{
  "action": "open_browser"
}

Agent 根本无法通用。

于是 MCP 出现了。

MCP（Model Context Protocol）可以理解为：

AI 时代的 USB 接口。

无论是：

Browser
GitHub
Notion
Figma
数据库

都通过统一协议暴露能力。

例如：

json 复制代码

{
  "name": "search_docs",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string"
      }
    }
  }
}

Agent 不需要提前适配每一个工具。

只要支持 MCP：

arduino 复制代码

Agent
 ↓
MCP Client
 ↓
MCP Server
 ↓
Tool

即可完成调用。

所以：

MCP 本质上是 Agent → Tool 的协议。

A2A：Agent 与 Agent 的协议

有了 MCP 之后，Agent 可以调用工具了。

但很快又出现新问题。

现实中的复杂任务往往不是一个 Agent 能完成的。

例如：

markdown 复制代码

招聘助手
    ↓
技术面试 Agent
    ↓
简历分析 Agent
    ↓
背景调查 Agent

或者：

markdown 复制代码

旅行规划 Agent
    ↓
机票 Agent
酒店 Agent
攻略 Agent

这时候：

Agent 不再只是调用工具。

而是在调用另一个 Agent。

于是 Google 提出了 A2A（Agent to Agent）。

它关注的问题是：

Agent 如何发现其他 Agent
Agent 如何发送任务
Agent 如何获取结果
Agent 如何持续跟踪任务状态

例如：

css 复制代码

Agent A
 ↓
发送任务
 ↓
Agent B
 ↓
执行完成
 ↓
返回结果

所以：

A2A 本质上是 Agent → Agent 的协议。

AG-UI：Agent 与前端的协议

很多人做 Agent 产品时都会发现一个问题。

Agent 的输出并不是一次性完成的。

例如：

erlang 复制代码

思考中...
调用搜索...
分析结果...
生成答案...

整个过程是流式的。

如果后端只是返回：

json 复制代码

{
  "answer": "最终结果"
}

前端体验会很差。

因此出现了 AG-UI（Agent User Interaction Protocol）。

它关注的是：

Agent 运行过程中产生的事件如何传递给前端。

例如：

json 复制代码

{
  "type": "thinking"
}

json 复制代码

{
  "type": "tool_call"
}

json 复制代码

{
  "type": "message"
}

json 复制代码

{
  "type": "complete"
}

前端收到后即可实时更新界面。

例如：

复制代码

✓ 搜索完成
✓ 数据分析完成
✓ 正在生成报告

因此：

AG-UI 本质上是 Agent → UI 的事件协议。

A2UI：Agent 直接生成界面的协议

AG-UI 解决的是：

Agent 如何告诉前端发生了什么。

但没有解决另一个问题：

Agent 如何决定界面长什么样。

例如用户问：

复制代码

北京未来七天天气

理想情况不是返回：

erlang 复制代码

周一 30℃
周二 29℃
...

而是直接返回天气卡片。

再比如：

复制代码

查看销售数据

更适合：

图表
表格
Dashboard

而不是纯文本。

于是出现了 A2UI（Agent to UI）。

它强调：

Agent 返回的不只是文字。

而是结构化 UI。

例如：

json 复制代码

{
  "component": "chart",
  "data": [...]
}

或者：

json 复制代码

{
  "component": "weather-card"
}

前端根据协议直接渲染。

因此：

A2UI 本质上是 Agent → 界面描述协议。

五者之间到底是什么关系？

如果画成一张图，大概是这样：

markdown 复制代码

             ┌──────────┐
             │   User   │
             └────┬─────┘
                  │
                  ▼
             ┌──────────┐
             │  Agent   │
             └────┬─────┘
                  │
      ┌───────────┼───────────┐
      ▼           ▼           ▼

    MCP         A2A        AG-UI
      │           │           │

   Tool       Agent      Frontend

                              │
                              ▼

                            A2UI
                     (UI Components)

换句话说：

协议	解决的问题
CLI	人如何调用程序
MCP	Agent 如何调用工具
A2A	Agent 如何调用 Agent
AG-UI	Agent 如何向界面发送运行事件
A2UI	Agent 如何生成界面

最后

如果把过去几十年的软件演进浓缩成一句话：

objectivec 复制代码

CLI 时代：
Human → Software

AI 时代：
Human → Agent → World

而 MCP、A2A、AG-UI、A2UI，本质上都是在补齐这条链路上的不同环节。

它们不是互相竞争的关系。

而是分别回答了几个问题：

Agent 怎么用工具？（MCP）
Agent 怎么找 Agent？（A2A）
Agent 怎么通知前端？（AG-UI）
Agent 怎么生成界面？（A2UI）

至于 CLI？

它并没有过时。

很多 MCP Server 的底层，依然是在调用各种 CLI 工具。

只不过以前是人敲命令。

现在变成 Agent 替你敲了。