AI 应用开发中的四类协议：从 MCP 到 AG-UI

AI 应用逐渐从单轮问答走向工具调用、多 Agent 协作和实时界面交互。随着系统变复杂，单靠一段 Prompt 很难解决不同组件之间的通信问题。

我在整理 Agent 相关资料时，遇到了一组比较容易混淆的协议：MCP、A2A、ACP 和 AG-UI。它们都和 Agent 有关，但解决的不是同一层问题。

先看整体分层

可以先用下面的方式理解：

协议	主要连接对象	解决的问题
MCP	Agent 与工具、数据	Agent 如何调用外部能力
A2A	Agent 与 Agent	不同 Agent 如何协作
ACP	Agent 与 Agent	消息的语义和协商方式
AG-UI	Agent 与用户界面	Agent 如何实时驱动 UI

它们不是简单的替代关系，更像是不同层次的协议。

MCP：连接工具和数据

MCP 可以理解为 Agent 使用外部工具和上下文的统一接口。它采用客户端与服务端的模式，由 MCP Server 暴露资源和工具，Agent 通过 MCP Client 进行调用。

MCP 常见的三个核心概念是：

• Resources：模型可以读取的资源，例如文档、数据库查询结果
• Tools：模型可以请求执行的动作，例如创建工单、查询接口
• Prompts：可以复用和管理的提示模板

它的价值在于把“模型能看到什么”和“模型能做什么”从具体应用中抽离出来，工具提供方不需要为每一个模型单独实现一套接口。

A2A：Agent 之间如何协作

一个 Agent 负责搜索资料，另一个 Agent 负责整理数据，还有一个 Agent 负责生成页面，这时就会涉及 Agent 之间的通信。

A2A 关注的是 Agent 的发现、任务生命周期、消息和最终产物。一个 Agent 可以通过 Agent Card 描述自己支持的能力，其他 Agent 再根据能力发起任务。

submitted → working → input-required → completed
                         ↓
                       failed

它适合长时任务和多 Agent 协作场景，任务不一定在一次请求中完成，也可以通过流式事件持续返回进度。

ACP：让消息表达清楚意图

ACP 更强调 Agent 消息的语义。例如一条消息到底是通知、请求、建议、接受还是拒绝，不应该只靠自然语言猜测。

在拍卖、合同协商和工作流编排中，消息的意图非常重要。虽然 ACP 的部分理念后来被其他 Agent 协议吸收，但它强调“消息动作语义”的思路仍然值得参考。

AG-UI：让 Agent 进入前端界面

如果 Agent 只在后端运行，用户通常只能等最终结果。但实际产品往往需要显示“正在查询”“正在调用工具”“需要用户确认”等中间状态。

AG-UI 采用事件流的方式，让 Agent 在运行过程中向前端发送标准化事件。例如文本消息可以拆成开始、增量内容和结束三个阶段，前端就能实现流式输出。

工具调用也可以实时展示：

TOOL_CALL_START
       ↓
TOOL_CALL_ARGS
       ↓
TOOL_CALL_END

此外，AG-UI 还支持状态快照、状态增量和人在回路。当 Agent 需要用户审批时，可以暂停任务，等待用户确认后继续执行。

我对这组协议的理解

如果把 AI 应用看成一个完整系统，MCP 解决的是“它能使用哪些工具”，A2A 和 ACP 解决的是“多个 Agent 如何协作和表达意图”，AG-UI 解决的是“用户如何看到并参与这个过程”。

协议的意义不只是统一名词，更重要的是把原本耦合在业务代码里的边界拆开。未来开发 Agent 应用时，除了关注模型效果，也需要关注工具权限、任务状态、事件流和用户确认机制。