Quartz 4

🔍 搜索

Agent 互操作协议综述：MCP、ACP、A2A、ANP

8 min read

Agent 互操作协议综述：MCP、ACP、A2A、ANP

原文：Agent Interoperability Protocols Survey
发表：arXiv 2505.02279
翻译整理：2026-06-16

背景：为什么需要 Agent 协议

随着 AI Agent 从单体应用走向多 Agent 协作系统，Agent 之间、Agent 与工具之间的互操作性成为关键问题：

  • 不同厂商的 Agent 如何交换任务？
  • Agent 如何发现和调用外部工具？
  • 跨组织的 Agent 如何建立信任？
  • 如何处理异步、长时间运行的 Agent 任务？

目前出现了四个主要协议，各自解决不同层次的问题。

四大协议详解

协议 1：MCP（Model Context Protocol）

提出方：Anthropic
架构：JSON-RPC 客户端-服务器模型
核心定位：标准化 LLM 如何获取工具、数据集和指令

四种能力类型

能力控制方描述
Tools（工具）模型控制LLM 可自主调用的 API（函数调用）
Resources（资源）应用控制应用程序选择注入的数据（文件、数据库）
Prompts（提示）用户控制用户可选择的提示模板
Sampling（采样）服务器控制服务器委托 LLM 生成文本的机制

工作方式

LLM ←→ MCP Client ←→ MCP Server ←→ 外部工具/数据
              JSON-RPC 2.0

MCP Server 暴露工具定义，MCP Client 将定义传给 LLM，LLM 决定调用哪个工具，Client 执行调用并返回结果。

最适合：用外部 API 或工具来增强现有 LLM 应用

协议 2：ACP（Agent Communication Protocol）

架构：带注册中心和路由的客户端-服务器
核心定位：支持多模态消息的基础设施级 Agent 交互

核心创新：有序消息部分（Ordered Message Parts）

ACP 引入了带 MIME 类型语义注解的多部分消息格式，使 Agent 之间可以传递富媒体内容：

消息
  ├── Part 1: text/plain  "分析结果如下："
  ├── Part 2: image/png   [图表截图]
  └── Part 3: application/json  {data: [...]}

与 MCP 的区别：MCP 是工具调用协议（Agent 调用工具），ACP 是 Agent 间通信协议（Agent 与 Agent 交流）。

特性：

  • 同步调用 + 异步流式传输双支持
  • Agent 注册中心（Registry）：Agent 发现和路由
  • 系统级策略执行：速率限制、权限控制

最适合：构建需要富类型消息交换的 Agent 基础设施

协议 3：A2A（Agent-to-Agent Protocol）

提出方：Google
架构：基于能力发现的点对点协议
核心定位：企业级任务委托和多 Agent 工作流

Agent Cards：能力广告机制

每个 Agent 发布一个 JSON 格式的「Agent Card」，描述自己的能力：

{
  "name": "CodeReviewAgent",
  "skills": ["python_review", "security_audit"],
  "input_schema": {"code": "string", "language": "string"},
  "output_schema": {"issues": "array", "severity": "string"},
  "auth": {"type": "oauth2", "endpoint": "..."}
}

其他 Agent 通过读取 Agent Card 了解如何与其交互，实现能力发现。

通信机制

  • HTTP：同步请求-响应
  • Server-Sent Events（SSE）：长时间运行任务的状态推送
Agent A 读取 Agent B 的 Card
  ↓
Agent A 向 Agent B 发送任务委托请求
  ↓
Agent B 开始执行，通过 SSE 推送进度
  ↓
任务完成，Agent B 返回结果 + Artifact

最适合：可信组织内部的 Agent 编排、动态能力协商

协议 4：ANP（Agent Network Protocol）

架构：基于去中心化身份（DID）的点对点
核心定位：开放互联网上的跨平台 Agent 发现与协作

去中心化身份（DID）

ANP 使用 W3C 标准的去中心化标识符（DID）解决开放互联网上的身份信任问题：

did:wba:agent.example.com:user:alice
  ↑    ↑                 ↑
DID  DID方法            特定标识符

无需中心化权威机构，Agent 可以通过密码学手段验证对方身份。

元协议协商器（Meta-Protocol Negotiator）

ANP 支持动态协议协商：两个 Agent 首次相遇时，先协商使用哪种通信协议，再开始实际交互。

最适合：开放互联网上需要无信任验证的跨组织 Agent 市场

四协议横向对比

维度MCPACPA2AANP
发现机制手动/静态 URL注册中心Agent Cards搜索引擎 + DID
身份验证TokenBearer + mTLS基于 DID 的握手DID:wba 方法
消息格式JSON-RPC 2.0多部分 MIMEHTTP + JSONJSON-LD + Schema.org
传输协议HTTP/Stdio/SSEHTTP 流HTTP + 可选 SSE仅 HTTPS
会话模型无状态（可选上下文）有会话感知客户端管理 ID无状态（Token 认证）
主要用途LLM 工具调用Agent 基础设施企业 Agent 编排去中心化 Agent 市场

分阶段采纳路线图

论文建议按以下顺序逐步引入协议，而非一次性全部采纳：

阶段 1：MCP
  建立工具调用和资源访问基础
  成本低，收益立竿见影
    ↓
阶段 2：ACP
  叠加多模态消息和异步通信能力
  用于需要富类型 Agent 间交互的场景
    ↓
阶段 3：A2A
  实现企业内部的多 Agent 编排
  需要组织内的信任基础已建立
    ↓
阶段 4：ANP
  扩展到去中心化开放互联网
  需要跨组织信任机制

论文结论：没有单一协议能满足所有场景，推荐分层互补采纳。

安全威胁矩阵

每个协议面临不同的安全风险，设计时需要针对性防护：

协议主要威胁推荐防护
MCP工具投毒、凭据窃取、沙箱逃逸数字签名、工具沙箱隔离
ACP元数据伪造、消息篡改、会话劫持mTLS、消息完整性校验
A2AAgent Card 篡改、任务注入Agent Card 版本控制、审计日志
ANP身份伪造、未验证 Agent 接入密码学 DID 验证、定期刷新描述

通用防护原则：数字签名 + mTLS + 密码学验证 + 审计日志 + 不可变版本化清单。

实践选型指南

场景 → 协议映射：

你的场景推荐协议
让 LLM 调用外部 API/工具MCP
构建 Agent 框架的消息基础设施ACP
企业内多个专业 Agent 协作A2A
开放市场上的 Agent 发现和交互ANP
从零开始构建 Agent 系统从 MCP 开始

Graph View