前言

过去一年，AI Agent 协议呈现「诸侯割据」态势：Anthropic 推出 MCP，Google 推出 A2A，IBM 推出 ACP，W3C 推进 ANP，还有一个专注支付的 AP2。表面上热闹，实际上给开发者带来选择困难。

一个常见误区是「找最优协议」。真实答案是：没有任何单一协议能覆盖所有场景。现代 Agent 系统需要的是协议组合，即在不同通信层次使用不同协议。

本文提出一个五层通信模型，结合实际场景给出选型建议。

为什么单一协议不够用

把 Agent 系统看作一座建筑，每层需要不同的「建筑材料」：

  • 地基：Agent 发现与身份认证
  • 墙体：Agent 之间的任务协调
  • 窗户：Agent 访问外部工具和数据
  • 门禁：支付与授权交易
  • 管道：跨组织边界通信

每个层次的问题域不同，单一协议无法同时优化所有维度。

五层通信模型

第一层：网络与发现层（Networking & Discovery）

解决的问题：Agent 如何找到彼此？如何验证身份？

核心协议：

  • ANP（Agent Network Protocol）：基于 W3C DID 的去中心化身份，支持端到端加密，适合跨组织通信
  • A2A（Agent-to-Agent）：通过 Agent Card（.well-known/agent.json）进行能力发现，适合企业内网

选择逻辑：

  • 跨企业通信 → ANP
  • 企业内部多 Agent 协作 → A2A

第二层：消息与协调层（Messaging & Coordination）

解决的问题：Agent 之间如何传递任务、协商、状态同步？

核心协议：

  • A2A：支持 Server-Sent Events（SSE）的长连接协调，适合实时状态更新
  • ACP：轻量级 REST，无需 SDK，适合快速原型或遗留系统集成

选择逻辑：

  • 需要长时间运行任务、状态回调 → A2A + SSE
  • 需要快速集成、不想引入额外依赖 → ACP

第三层：上下文与工具层（Context & Tool Use）

解决的问题：Agent 如何访问外部数据、调用工具？

核心协议：

  • MCP（Model Context Protocol）：JSON-RPC 2.0，标准化工具和数据源访问，带审计日志

这是目前最成熟的工具层协议。截至 2026 年 4 月，全球已有 10,000+ MCP 服务器，97M 月度 SDK 下载，OpenAI/Google DeepMind/Microsoft/AWS 均已支持。

第四层：支付与授权层（Payment & Authorization）

解决的问题：Agent 如何进行受控的金融交易？

核心协议：

  • AP2（Agent Payment Protocol）：通过加密签名的 Mandate（授权书）证明交易意图和权限

AP2 将支付责任分离：

  • Shopping Agent：负责找商品、组购物车，不接触财务信息
  • Credentials Provider：安全钱包，只在 Mandate 验证通过后释放 Token
  • Payment Processor：最终与支付网络通信

第五层：用户交互层（User Interface）

解决的问题：Agent 如何与人类用户交互？

核心协议：

  • AG-UI（Agent-User Interaction）：通过 SSE 或 WebSocket 向前端推送消息、工具调用状态、实时更新

场景化选型建议

场景一：企业级多 Agent 客服系统

背景：需要多个专业 Agent（订单查询、退换货处理、库存查询）协同处理用户请求。

协议组合：

  • 工具访问：MCP（连接 CRM、ERP、库存系统）
  • Agent 协调：A2A（订单 Agent 调用退换货 Agent）
  • 前端交互：AG-UI（实时向用户推送处理进度）

避坑：

  • ❌ 不要让所有 Agent 都用 REST 互调 → 导致长链路、低可靠性
  • ✅ 用 A2A 做协调，MCP 做工具，中间用 Task ID 关联状态

场景二：跨企业供应链 Agent 网络

背景：制造商、、物流商、海关 Agent 需要跨境协同，每个企业有自己的 Agent 系统。

协议组合：

  • 网络发现：ANP（去中心化 DID，无需中央注册机构）
  • 消息协调：A2A（RFC 8615 标准 Agent Card）
  • 工具访问：MCP（各方保留自己的 MCP Server）
  • 支付：AP2（跨境支付有 Mandate 凭证，兼容 SWIFT）

避坑：

  • ❌ 不要用单一云厂商协议 → 造成供应商锁定
  • ✅ 用 ANP + A2A 保持互操作性，底层工具链各自独立

场景三：金融合规监控 Agent

背景：需要实时监控交易系统，发现异常时自动拦截并上报。

协议组合：

  • 消息传递：ACP（轻量、低延迟，适合高频交易日志）
  • 工具访问：MCP（连接风控数据库、监管报告系统）
  • 支付拦截：AP2（发现可疑交易时冻结 Mandate）

避坑：

  • ❌ 不要在高频路径上用重协议 → 引入不必要延迟
  • ✅ 用 ACP 处理日志流，用 MCP 处理查询，用 AP2 处理干预

场景四：电商自动化购买 Agent

背景：用户授权 Agent 在特定条件下自动下单（如「演唱会门票开售时立即购买」）。

协议组合：

  • 支付授权：AP2（Mandate 机制让银行验证 Agent 的操作权限）
  • 商品搜索：MCP（连接电商平台 API）
  • 协调通知：A2A（向用户手机推送下单状态）

避坑：

  • ❌ 不要让 Agent 直接存储支付凭证 → 安全风险
  • ✅ 所有支付操作经过 AP2 的 Credentials Provider

协议互操作实践

MCP + A2A 组合（最常见）

这是目前最主流的组合：

用户请求
    ↓
A2A 协调层（Agent A → Agent B 任务分发）
    ↓
MCP 工具层（Agent B 调用外部工具）
    ↓
结果通过 A2A 传回

实现要点：

  1. 在 A2A 的 Task 中嵌入 MCP 的调用结果
  2. MCP Server 不感知调用来自哪个 Agent
  3. 审计日志在 MCP 层统一记录

多协议并存的治理问题

当系统中存在多个协议时，需要解决：

  1. 协议版本兼容：在 Agent Card 中声明支持的协议版本
  2. 安全边界：MCP 的 Capability Token 和 A2A 的 OAuth 2.0 需要互通
  3. 监控统一化：用 OpenTelemetry 追踪跨协议请求

常见误区

误区一：「我们只用 MCP 就够了」

MCP 擅长工具访问，但不解决 Agent 间协调问题。如果只用 MCP，Agent 之争需要用共享消息队列或数据库中转，增加复杂度。

误区二：「所有 Agent 必须支持所有协议」

实际应该按角色选择：

  • 工具型 Agent：MCP 为主
  • 协调型 Agent：A2A 为主
  • 边缘型 Agent：ACP 为主（减少依赖）

误区三：「协议选型一步到位」

协议选型是演进过程。建议：

  1. 第一阶段：用 MCP 连接核心工具
  2. 第二阶段：引入 A2A 做 Agent 协调
  3. 第三阶段：根据需要添加 ANP/AP2

下一步

如果你正在构建 Agent 系统，建议从 MCP 开始，因为它有最成熟的生态（MCP Servers、SDK 支持）。然后根据是否有跨 Agent 协调需求，评估是否引入 A2A。

以下是相关资源：