AI Agent 协议说明：MCP、A2A、ACP 与 AG-UI 到底解决什么问题

技术架构AI 与 Web 协议（更新于 2026年7月15日）

快速结论

MCP、A2A、ACP 和 AG-UI 不是彼此的直接替代品。它们解决的是 Agent 系统里不同边界的通信问题。

协议 主要问题 典型边界
MCP AI 应用如何连接工具、数据、prompt 和上下文 Agent/宿主应用 到 工具/资源服务器
A2A 一个 Agent 如何把任务委派给另一个 Agent Agent 到 Agent 的任务协作
ACP Agent 如何以互操作服务形式暴露能力 Agent 服务互操作
AG-UI Agent 如何把状态和动作流式传给用户界面 Agent 后端 到 前端 UI

生产系统里，更好的问题不是“哪个协议会赢”，而是“我们要标准化哪一层边界”。

为什么 Agent 需要协议？

早期 Agent 系统通常把工具调用、UI 事件和多 Agent 委派都硬编码在一个应用里。原型阶段可以跑起来，但当工具、团队、供应商和前端越来越多时，这种方式会变得脆弱。

协议的价值是拆分职责：

  • 工具和数据源可以独立暴露，不必重写 Agent。
  • Agent 可以委派任务，而不暴露内部实现。
  • 前端可以一致地渲染进度、工具调用和中间状态。
  • 安全团队可以在清晰边界上做权限和审计。

关键是把协议放到正确边界上。

MCP：工具与上下文集成

MCP，即 Model Context Protocol，关注 AI 应用如何连接外部工具和上下文。它采用 client/server 模型，宿主应用可以发现和调用工具、读取资源、使用 prompt 模板。

适合使用 MCP 的场景：

  • AI 应用需要查询数据库、文件系统、API、代码仓库或业务系统。
  • 你希望工具服务器能被多个 Agent 客户端复用。
  • 你需要标准化暴露资源和 prompt。
  • 你希望工具 schema 和权限边界明确。

MCP 最强的边界是“Agent 调用工具”。它不是完整的多 Agent 编排协议，也不定义前端如何渲染 Agent 状态。

AI 应用 / Agent 宿主
  -> MCP client
  -> MCP server
  -> 数据库、文件系统、API、内部工具

实现建议：

  • 工具能力要窄而明确。
  • 避免暴露过宽的写权限。
  • 记录工具调用和参数。
  • 把工具返回当成不可信输入处理。
  • 修改行为时对工具 schema 做版本管理。

A2A：Agent 到 Agent 的任务协作

A2A，即 Agent-to-Agent，关注 Agent 之间如何协作。核心思路是一个 Agent 可以声明能力，并接收另一个 Agent 或编排器发来的任务。

适合使用 A2A 的场景：

  • 多个专业 Agent 需要协作。
  • 规划 Agent 需要把任务委派给专家 Agent。
  • Agent 由不同团队或服务拥有。
  • 长任务需要状态、产物和进度更新。

A2A 最强的边界是“Agent 把任务委派给另一个 Agent”。它不替代 MCP；一个 A2A Agent 内部仍然可以使用 MCP 调用工具。

编排 Agent
  -> A2A 任务请求
  -> 专家 Agent
  -> 状态更新和产物

实现建议：

  • 明确定义每个 Agent 可以做什么。
  • Agent 返回内容必须校验后再使用。
  • 设置超时和任务预算。
  • 记录任务归属和交接历史。
  • 避免循环委派。

ACP：可互操作的 Agent 服务

ACP 通常被理解为 Agent Communication Protocol 一类方案，目标是让 Agent 以服务形式被发现和调用。不同生态和实现可能不同，但设计目标类似：暴露 Agent 能力，让其他系统以可预测方式调用。

适合 ACP 风格方案的场景：

  • 希望 Agent 像网络服务一样被调用。
  • 能力发现很重要。
  • 不同运行时或供应商需要互操作。
  • 你需要服务边界，而不是进程内库调用。

ACP 和 A2A 在概念上可能有重叠。实际选型时，要评估具体实现：消息格式、认证、任务生命周期、流式能力、SDK 成熟度和治理方式。

AG-UI：Agent 到用户界面的事件流

AG-UI 关注前端边界。它标准化 Agent 后端如何把消息、工具调用、状态变化、进度和 UI 相关事件流式传给客户端。

适合使用 AG-UI 的场景：

  • 你正在构建 copilot 或 assistant UI。
  • 前端需要展示工具调用、中间步骤或实时进度。
  • 用户需要在界面中审批动作。
  • Agent 状态需要与 React、Vue 或其他 UI 框架同步。

AG-UI 最强的边界是“Agent 后端与 UI 通信”。它不定义 Agent 内部工作流，也不定义工具如何托管。

Agent 后端
  -> 事件流
  -> 前端 UI
  -> 用户审批 / 输入
  -> 后端恢复流程

实现建议：

  • 保持事件类型稳定。
  • 区分用户可见状态和内部机密。
  • 处理重连和部分流。
  • 用户审批要显式且可审计。
  • 前端事件不能绕过后端权限检查。

它们如何组合？

这些协议通常是互补关系：

用户界面
  <-> AG-UI 事件
Agent 应用 / 编排器
  <-> A2A 或 ACP 做 Agent 协作
专家 Agent
  <-> MCP 调用工具、资源和 prompt
业务系统

一个客服自动化系统可能使用：

  • AG-UI 展示进度并请求用户确认。
  • A2A 把退款审核委派给财务 Agent。
  • MCP 调用订单、支付和工单工具。

一个开发助手可能使用：

  • AG-UI 处理编辑器 UI 事件。
  • MCP 连接代码仓库、终端、Issue 系统和文档。
  • 只有需要委派外部专家 Agent 时才使用 A2A 或 ACP。

对比矩阵

维度 MCP A2A ACP AG-UI
主要边界 Agent 到工具/上下文 Agent 到 Agent Agent 服务互操作 Agent 到 UI
主要对象 Tool、Resource、Prompt Task、Message、Artifact Capability、Agent、Message Event、State、Tool action
最适合 工具集成 委派和协作 跨 Agent 服务契约 交互式前端
替代应用逻辑？ 否 否 否 否
能否组合使用 可以 可以 可以 可以
主要风险 工具权限过大 委派无边界 实现分化或不成熟 UI 状态/安全泄露

选型建议

选择 MCP，如果你的主要问题是让 AI 应用连接工具或数据，并希望工具服务器可复用、schema 明确。

选择 A2A，如果一个 Agent 需要把任务委派给另一个 Agent，且任务状态、进度和产物很重要。

选择 ACP 风格方案，如果 Agent 需要作为服务端点暴露，能力发现和跨运行时互操作是核心需求，并且你选择的具体实现足够成熟。

选择 AG-UI，如果你正在构建交互式 Agent 前端，用户需要看到进度、审批动作或查看中间步骤。

常见误区

把协议当框架

协议定义通信边界，不替代编排、评测、安全、部署和产品设计。

简单工具调用却引入多 Agent 协议

如果 Agent 只需要查数据库或调用 API，MCP 风格工具集成可能已经足够。不要为了复杂而引入委派。

暴露过大的工具能力

工具服务器应提供窄操作。除非环境高度受控，不要暴露“执行任意 SQL”或“执行任意 shell 命令”。

不校验 Agent 输出

Agent 间通信仍然需要校验。返回产物应当作待检查数据，而不是直接可信结果。

让前端事件变成权限

前端审批事件只是交互信号，不是安全控制本身。权限必须由后端执行。

生产检查表

领域 需要回答的问题
认证 谁可以调用协议端点？
授权 哪些工具、Agent、任务或 UI 动作被允许？
审计 能否还原谁请求了什么、发生了什么？
超时 Agent 或工具卡住时怎么办？
预算 模型调用、工具调用和任务深度是否有限制？
校验 输入输出是否有 schema 检查？
可观测性 UI、Agent、工具和任务边界的 trace 能否串起来？
版本管理 schema 变化时能否不破坏客户端？

总结

MCP、A2A、ACP 和 AG-UI 更适合理解为边界协议。MCP 标准化工具和上下文，A2A 标准化 Agent 任务协作，ACP 风格方案关注 Agent 服务互操作，AG-UI 标准化交互式前端事件。成熟的 Agent 系统可能同时使用多个协议，但每个协议都应该只在它能让边界更清晰、更安全时引入。

本站提供浏览器本地工具，免注册即可试用 →

#MCP#A2A#ACP#AG-UI#AI Agent#协议#智能体