最近一年，AI Agent 圈子里冒出了大量缩写：
CLI、MCP、A2A、A2UI、AG-UI……
很多人第一次看到时会有一种错觉：
怎么又发明了这么多协议？
实际上，如果把它们放在同一条技术演进线上看，会发现这些东西并不复杂。
它们解决的是同一个问题：
如何让 Agent 与外部世界协作。
只是协作对象不同，因此出现了不同层次的协议。
从 CLI 开始：人与程序的交互协议
最早的软件世界里，并没有 Agent。
程序之间协作最简单的方式就是：
git clone xxx
npm install
python main.py
这就是 CLI（Command Line Interface，命令行接口）。
CLI 本质上是一种约定：
- 输入参数
- 执行命令
- 返回结果
例如：
ffmpeg input.mp4 output.mp3
你不需要知道 ffmpeg 内部怎么实现。
只需要遵守它的参数规则即可。
因此：
CLI 本质上是 Human → Tool 的协议。
它解决的是：
人如何调用程序。
MCP：Agent 调用工具的协议
当 LLM 出现后，问题发生了变化。
以前是人调用工具：
git commit
现在变成 Agent 调用工具：
Agent:
需要获取浏览器内容
→ 调用 Browser Tool
问题来了：
Agent 怎么知道工具有哪些？
工具参数是什么？
返回结果长什么样？
如果每个工具都自己定义格式：
{
"tool": "browser"
}
或者：
{
"action": "open_browser"
}
Agent 根本无法通用。
于是 MCP 出现了。
MCP（Model Context Protocol）可以理解为：
AI 时代的 USB 接口。
无论是：
- Browser
- GitHub
- Notion
- Figma
- 数据库
都通过统一协议暴露能力。
例如：
{
"name": "search_docs",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string"
}
}
}
}
Agent 不需要提前适配每一个工具。
只要支持 MCP：
Agent
↓
MCP Client
↓
MCP Server
↓
Tool
即可完成调用。
所以：
MCP 本质上是 Agent → Tool 的协议。
A2A：Agent 与 Agent 的协议
有了 MCP 之后，Agent 可以调用工具了。
但很快又出现新问题。
现实中的复杂任务往往不是一个 Agent 能完成的。
例如：
招聘助手
↓
技术面试 Agent
↓
简历分析 Agent
↓
背景调查 Agent
或者：
旅行规划 Agent
↓
机票 Agent
酒店 Agent
攻略 Agent
这时候：
Agent 不再只是调用工具。
而是在调用另一个 Agent。
于是 Google 提出了 A2A（Agent to Agent）。
它关注的问题是：
- Agent 如何发现其他 Agent
- Agent 如何发送任务
- Agent 如何获取结果
- Agent 如何持续跟踪任务状态
例如：
Agent A
↓
发送任务
↓
Agent B
↓
执行完成
↓
返回结果
所以：
A2A 本质上是 Agent → Agent 的协议。
AG-UI：Agent 与前端的协议
很多人做 Agent 产品时都会发现一个问题。
Agent 的输出并不是一次性完成的。
例如：
思考中...
调用搜索...
分析结果...
生成答案...
整个过程是流式的。
如果后端只是返回：
{
"answer": "最终结果"
}
前端体验会很差。
因此出现了 AG-UI（Agent User Interaction Protocol）。
它关注的是：
Agent 运行过程中产生的事件如何传递给前端。
例如：
{
"type": "thinking"
}
{
"type": "tool_call"
}
{
"type": "message"
}
{
"type": "complete"
}
前端收到后即可实时更新界面。
例如：
✓ 搜索完成
✓ 数据分析完成
✓ 正在生成报告
因此：
AG-UI 本质上是 Agent → UI 的事件协议。
A2UI：Agent 直接生成界面的协议
AG-UI 解决的是：
Agent 如何告诉前端发生了什么。
但没有解决另一个问题：
Agent 如何决定界面长什么样。
例如用户问：
北京未来七天天气
理想情况不是返回：
周一 30℃
周二 29℃
...
而是直接返回天气卡片。
再比如：
查看销售数据
更适合：
- 图表
- 表格
- Dashboard
而不是纯文本。
于是出现了 A2UI（Agent to UI）。
它强调：
Agent 返回的不只是文字。
而是结构化 UI。
例如：
{
"component": "chart",
"data": [...]
}
或者：
{
"component": "weather-card"
}
前端根据协议直接渲染。
因此：
A2UI 本质上是 Agent → 界面描述协议。
五者之间到底是什么关系？
如果画成一张图，大概是这样：
┌──────────┐
│ User │
└────┬─────┘
│
▼
┌──────────┐
│ Agent │
└────┬─────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
MCP A2A AG-UI
│ │ │
Tool Agent Frontend
│
▼
A2UI
(UI Components)
换句话说：
| 协议 | 解决的问题 |
|---|---|
| CLI | 人如何调用程序 |
| MCP | Agent 如何调用工具 |
| A2A | Agent 如何调用 Agent |
| AG-UI | Agent 如何向界面发送运行事件 |
| A2UI | Agent 如何生成界面 |
最后
如果把过去几十年的软件演进浓缩成一句话：
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 替你敲了。
