跳到主要内容

跨 Agent 通信协议:A2A 与 ANP

MCP 解决了"Agent 连工具",但 Agent 之间怎么协作?A2A(Agent-to-Agent)和 ANP(Agent Network Protocol)是两条正在成型的标准答案。本文讲清它们的定位、核心机制与选型。

一、为什么需要跨 Agent 协议​

当多智能体协作走出单机(见《多智能体编排》),问题就出现了:用 LangGraph 编排的 Agent,怎么调用 Salesforce 生态里另一个公司开发的 Agent?

没有标准时,只能点对点定制接口——每个 Agent 都要知道对方的私有协议。跨 Agent 协议的目标:像 HTTP 之于网站一样,让 Agent 能互相发现能力、委派任务、交换结果,而无需知道对方内部实现。

二、A2A:面向企业协作的开放标准​

  • 发起方:Google 于 2025 年 4 月开源发布;2025 年 6 月移交 Linux Foundation 治理
  • 现状:一周年(2026 年 4 月)150+ 组织支持,Google/Microsoft/AWS 三大云集成,多行业生产使用
  • 版本:v0.3 引入 gRPC 支持、签名安全卡、Python SDK 扩展

核心机制​

概念作用
Agent Card每个 Agent 公开展示"我是谁、能做什么、支持哪些安全模式",JSON 描述,可被发现
Task(任务委派)客户端 Agent 创建任务,服务端 Agent 执行并回报状态(working / completed / failed)
Message(消息流)任务执行过程中的流式消息交换(文本、部分结果、人工介入请求)
安全基于 HTTP + JSON,鉴权方案按 OpenAPI 风格声明,v0.3 支持签名安全卡

设计取舍:A2A 默认状态型交互(任务有生命周期),适合企业级长任务(审批流、多轮协作);HTTP 承载使其可直接穿透现有企业网络设施。

三、ANP:面向"智能体互联网"的去中心化网络​

  • 发起方:开源社区项目,愿景是成为"智能体互联网时代的 HTTP"
  • 定位:不只是一对一协作,而是智能体网络——跨组织、去中心化的连接与交易

三层协议体系​

层职责
身份与加密通信层基于 W3C DID 去中心化身份 + 端到端加密,解决"我是谁、通信是否安全"
元协议协商层动态协商能力与接口(调用 URL、binding、可协商对象、安全配置)
应用协议层垂直领域协议:支付、授权、认证、商务等

核心差异:ANP 把身份、发现、支付做成协议一等公民——不只是"Agent 能对话",而是"Agent 能跨组织交易"(如一个 Agent 付费调用另一个 Agent 的服务)。

四、三者对比:MCP / A2A / ANP​

维度MCPA2AANP
解决的问题Agent ↔ 工具/数据Agent ↔ Agent(企业协作)Agent ↔ Agent(去中心化网络)
治理方Anthropic → 开放治理Linux Foundation开源社区
身份机制应用级鉴权声明式鉴权(OpenAPI 风格)W3C DID 去中心化身份
传输HTTP+SSE / Streamable HTTPHTTP / gRPCHTTP + 加密通道
典型场景给 Agent 接数据库、API、文件跨公司 Agent 委派任务、协作流程开放智能体市场、跨组织交易
成熟度最成熟(2024 发布)生产可用(150+ 组织)早期(白皮书 + 草案)

五、选型建议(FDE 视角)​

  • 给客户的 Agent 接工具/数据 → MCP(见《MCP Server 实战》)
  • 客户的多个系统(不同厂商)的 Agent 要协作 → A2A:发布 Agent Card,标准任务委派,生态支持最广
  • 构建开放的 Agent 服务平台/市场(多组织互操作、需身份与支付) → 关注 ANP,先做概念验证
  • 自用多 Agent 编排(单团队、代码内) → 不需要跨 Agent 协议,直接走《多智能体编排》

六、与本站其他章节的关系​

  • 《MCP Server 实战》:Agent-工具标准,本文是它的"横向扩展"
  • 《多智能体编排》:单进程内编排模式;跨进程/跨组织协作才需要本文协议
  • 《生产部署》《安全与 Guardrails》:跨 Agent 通信的鉴权与安全边界,复用同一套生产纪律

一句话总结:MCP 给 Agent 手,A2A 给 Agent 同事,ANP 给 Agent 市场。 2026 年的生产系统里,三者会长期并存——先掌握 MCP,再用 A2A 打通跨系统协作,最后关注 ANP 的演进。