第20章 A2A与ANP：智能体间通信协议

本章来源：综合自 Agentic Design Patterns 第十五章（A2A协议深入分析）、Hello-Agents 第十章（三种协议对比与ANP实践）

核心问题 —— 本章要解答什么

上一章讨论了MCP如何标准化智能体与外部工具的通信。但当我们需要多个独立智能体相互协作时，另一个层次的通信问题浮现：如何让基于不同框架、运行在不同环境中的智能体彼此发现、通信和协作？

单个智能体即使具备先进能力，在处理复杂多方面问题时仍然面临局限性。A2A（Agent-to-Agent Protocol）和ANP（Agent Network Protocol）分别从"点对点协作"和"大规模网络发现"两个维度解决这一问题。

本章将深入分析这两种协议的架构设计，探讨它们与MCP的互补关系，并给出三大协议（MCP/A2A/ANP）在实际系统中的选型策略。

设计空间 —— 可选方案与取舍

20.1 A2A与MCP的互补定位

A2A与MCP解决的是不同层次的通信问题。理解它们的互补关系是选择正确协议的前提。

A2A与MCP协议比较

MCP关注"智能体如何使用工具"——为智能体构建上下文及其与外部数据和工具的交互提供标准化接口。它是智能体能力扩展的基础设施。

A2A关注"智能体如何与智能体协作"——促进智能体间的发现和通信，实现任务委派与协作。它是多智能体系统的通信基础。

两者的设计差异反映了根本不同的交互模型：MCP是"智能体→工具"的单向使用关系，而A2A是"智能体↔智能体"的对等协作关系。在实际系统中，一个智能体可能同时使用MCP访问外部工具、通过A2A与其他智能体协作。

20.2 协议选型的设计权衡

选择通信协议时需要在多个维度上做出权衡：

权衡维度	MCP倾向	A2A倾向	ANP倾向
通信对象	工具和资源	对等智能体	大规模智能体网络
发现方式	客户端查询服务器	Agent Card标准路径	去中心化服务注册
交互模式	请求-响应	同步/异步/流式/推送	服务发现+路由
透明度	客户端了解服务器能力	服务器对客户端"不透明"	去中心化透明
生态成熟度	最成熟	快速增长	概念验证阶段

架构解析 —— A2A协议深度分析

20.3 A2A核心概念

A2A（Agent2Agent）协议是 Google 于 2025 年 4 月提出的开放标准 [Google, 2025]，旨在实现不同AI智能体框架间的通信与协作。它获得了Atlassian、Box、LangChain、MongoDB、Salesforce、SAP、ServiceNow等超过 50 家技术公司的支持，Microsoft计划将其集成到Azure AI Foundry和Copilot Studio。

A2A智能体间通信模式

A2A的架构建立在以下核心概念之上：

核心参与者：A2A涉及三个实体——用户（发起请求）、A2A客户端/客户端Agent（代表用户请求操作或信息）、A2A服务器/远程Agent（提供HTTP端点处理请求并返回结果）。远程智能体以"不透明"方式运行，客户端无需了解其内部操作细节。

Agent Card（智能体卡片）：这是A2A协议最具特色的设计。每个智能体的数字身份由一个JSON文件定义，包含：

json

{
  "name": "WeatherBot",
  "description": "Provides accurate weather forecasts and historical data.",
  "url": "http://weather-service.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "authentication": {
    "schemes": ["apiKey"]
  },
  "skills": [
    {
      "id": "get_current_weather",
      "name": "Get Current Weather",
      "description": "Retrieve real-time weather for any location.",
      "examples": ["What's the weather in Paris?"]
    }
  ]
}

Agent Card承载了智能体的身份、端点URL、版本、支持的能力（流式传输、推送通知等）、具体技能、默认输入/输出模式和身份验证要求。这种自描述性设计使得智能体间的自动发现和能力匹配成为可能。

20.4 Agent发现机制

A2A提供了三种发现策略，适用于不同的部署场景：

标准URI（Well-Known URI）：智能体在标准化路径（如/.well-known/agent.json）托管其Agent Card。这种方法为公共或特定领域使用提供广泛的、通常自动化的可访问性。类似于网站的robots.txt约定。

精选注册表（Curated Registries）：提供集中目录，其中发布Agent Card，可根据特定标准查询。适合需要集中管理和访问控制的企业环境。

直接配置（Direct Configuration）：Agent Card信息被嵌入或私下共享。适用于紧密耦合或私有系统，其中动态发现并不关键。

无论选择何种方法，保护Agent Card端点都很重要——通过访问控制、双向TLS（mTLS）或网络限制，特别是当Card包含敏感信息时。

20.5 通信与任务模型

A2A的通信围绕异步任务结构化。每个任务被分配唯一标识符，并通过一系列状态（submitted→working→completed/failed）移动。

消息结构：通信包含属性（描述消息的键值元数据，如优先级或创建时间）和一个或多个部分（承载实际内容，如纯文本、文件或结构化JSON数据）。

工件（Artifacts）：智能体在任务期间生成的有形输出，可在结果可用时逐步流式传输。

上下文连续性：使用服务器生成的contextId来分组相关任务并保留上下文，支持多次交互间的连续性。

所有通信通过HTTP(S)进行，使用JSON-RPC 2.0协议作为有效载荷。

20.6 四种交互机制

A2A提供四种交互方法以适应不同的应用需求：

同步请求/响应：客户端发送请求并等待完整响应。使用sendTask方法，适用于快速、即时的操作。

json

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "sendTask",
  "params": {
    "id": "task-001",
    "message": {
      "role": "user",
      "parts": [{"type": "text", "text": "What is the exchange rate from USD to EUR?"}]
    }
  }
}

异步轮询：客户端发送请求后获得任务ID，可周期性检查状态直至完成或失败。适用于耗时较长的任务。

流式更新（Server-Sent Events）：使用sendTaskSubscribe方法建立持久单向连接，服务器可持续推送更新。适用于需要实时增量结果的场景。

推送通知（Webhooks）：客户端注册webhook URL，服务器在任务状态显著变化时异步通知。适用于非常长时间运行或资源密集型任务，避免频繁轮询。

Agent Card中声明了智能体支持哪些交互机制。A2A是模态无关的，不仅支持文本，还支持音频、视频等多模态数据。

20.7 安全机制

A2A内置了多层安全机制：

双向TLS（mTLS）：建立加密和认证连接，防止未经授权访问和数据拦截
全面审计日志：所有智能体间通信均被详细记录，支持问责和安全分析
Agent Card声明：身份验证要求在Agent Card中明确声明，集中管理认证
凭据处理：通过HTTP头传递OAuth 2.0令牌或API密钥，防止凭据暴露在URL或消息正文中

架构解析 —— ANP协议分析

20.8 ANP的定位与设计

ANP（Agent Network Protocol）是一个概念性的协议框架，由中国开源社区（AgentNetworkProtocol 项目）维护。如果说MCP解决"如何访问工具"，A2A解决"如何与其他智能体对话"，那么ANP解决的是"如何在大规模网络中发现和连接智能体"。

ANP设计思想

ANP的核心能力包括：

服务注册：智能体在网络中注册自己的能力和端点信息，使其对其他智能体可见。

服务发现：根据能力描述、服务类型等条件在网络中搜索可用的智能体服务。

路由机制：在大规模网络中确定从一个智能体到另一个智能体的最优通信路径。

python

from hello_agents.tools import ANPTool

anp_tool = ANPTool()

# 注册服务
anp_tool.run({
    "action": "register_service",
    "service_id": "calculator",
    "service_type": "math",
    "endpoint": "http://localhost:8080"
})

# 发现服务
services = anp_tool.run({"action": "discover_services"})

需要注意的是，ANP目前还没有成熟的生态，更多处于概念验证和社区探索阶段。但它所解决的大规模智能体网络治理问题是多智能体系统发展的必然需求。

关键实现决策 —— 三大协议的协同使用

20.9 协议栈的层次关系

三种协议形成了一个互补的协议栈，各自覆盖不同的通信层次：

层次	协议	解决的问题	类比
工具访问层	MCP	智能体如何使用外部工具和数据	应用层API
智能体协作层	A2A	智能体之间如何通信和协作	服务间RPC
网络发现层	ANP	如何在大规模网络中发现智能体	DNS/服务发现

在一个典型的多智能体系统中，这三种协议可能同时被使用：智能体通过ANP发现网络中的可用服务，通过A2A与其他智能体协商和委派任务，通过MCP访问各自需要的外部工具。

20.10 实际系统中的协议选择

对于不同规模和复杂度的系统，推荐的协议选择策略：

单智能体+多工具：仅需MCP。智能体通过MCP连接文件系统、数据库、API等外部服务。

固定多智能体团队：MCP + 框架内置编排。使用CrewAI、AutoGen等框架的内置协调机制，每个智能体通过MCP访问自己的工具。

跨框架多智能体协作：MCP + A2A。不同框架（ADK、LangGraph、CrewAI等）构建的智能体通过A2A协议实现跨框架通信。

大规模智能体生态：MCP + A2A + ANP。在包含大量智能体的网络中，增加ANP层实现动态服务发现和路由。

20.11 A2A实现参考

以下展示了如何使用Google ADK构建一个A2A兼容的智能体服务：

python

skill = AgentSkill(
    id='check_availability',
    name='Check Availability',
    description="Checks a user's availability using their Google Calendar",
    tags=['calendar'],
    examples=['Am I free from 10am to 11am tomorrow?'],
)

agent_card = AgentCard(
    name='Calendar Agent',
    description="An agent that can manage a user's calendar",
    url=f'http://{host}:{port}/',
    version='1.0.0',
    defaultInputModes=['text'],
    defaultOutputModes=['text'],
    capabilities=AgentCapabilities(streaming=True),
    skills=[skill],
)

这段代码展示了A2A实现的两个核心步骤：定义智能体的技能（AgentSkill）和构建智能体卡片（AgentCard）。技能描述了智能体具体能做什么，卡片则是智能体在网络中的数字身份。

前沿动态 —— 最新进展

20.12 协议标准化趋势

A2A协议正在快速获得行业支持。Microsoft、Salesforce、SAP等企业级平台的接入标志着从实验性标准向生产级标准的转变。社区贡献的多框架示例（LangGraph、CrewAI、Azure AI Foundry、AG2等）展示了A2A在实际跨框架协作中的可行性。

一个值得关注的趋势是协议融合。A2A和MCP正在从各自独立的标准走向互操作：A2A用于高层次的任务管理和智能体间工作流编排，MCP用于底层的工具访问和上下文获取。未来的智能体框架很可能同时原生支持两种协议。

20.13 Agent Card的演进

Agent Card作为A2A的核心创新，其设计正在向更丰富的方向演进。除了基本的身份和能力描述，未来可能包含：

SLA声明：响应时间保证、可用性承诺
成本模型：使用该智能体的计费方式
数据治理：数据处理政策、隐私承诺
版本兼容性：与其他智能体的兼容性矩阵

这种演进方向将Agent Card从简单的能力描述文件转变为智能体之间建立信任关系的契约基础。

⚠️ 已知局限：A2A 和 ANP 协议目前均处于早期阶段，面临显著的成熟度挑战。A2A 虽获得多家企业支持，但跨框架互操作的实际验证案例仍有限——不同框架对 Agent Card 的解析和能力匹配存在语义歧义，导致自动发现的智能体配对准确率在复杂场景下可能低于 70%。ANP 更处于概念验证阶段，缺乏生产级实现。此外，两种协议均面临延迟开销问题：A2A 的 JSON-RPC over HTTP 通信在多轮交互中引入的累积延迟可达数百毫秒级别，对实时性要求高的场景构成瓶颈。安全层面，智能体间的信任建立机制（Agent Card 的真实性验证、能力声明的可信度）仍缺乏标准化的解决方案。

本章小结

A2A和ANP分别从"点对点协作"和"大规模网络发现"两个维度扩展了智能体通信的能力空间。

A2A的核心设计贡献在于：Agent Card机制实现了智能体的自描述和自动发现；多种交互模式（同步/异步/流式/推送）覆盖了从简单查询到长时间运行任务的完整场景谱系；不透明设计允许不同框架的智能体无需了解彼此内部实现即可协作。

ANP虽然尚处于早期，但它提出的去中心化服务发现思路指向了多智能体系统的必然演进方向——当网络中的智能体数量达到一定规模后，中心化的配置管理将不再可行。

在实际系统设计中，MCP、A2A、ANP三者形成互补的协议栈：MCP负责智能体的"手"（操作工具），A2A负责智能体的"嘴"（与同伴对话），ANP负责智能体的"眼"（发现网络中的服务）。理解这三者的定位和互补关系，是设计健壮多智能体系统的基础。

第20章 A2A与ANP：智能体间通信协议 ​

核心问题 —— 本章要解答什么 ​

设计空间 —— 可选方案与取舍 ​

20.1 A2A与MCP的互补定位 ​

20.2 协议选型的设计权衡 ​

架构解析 —— A2A协议深度分析 ​

20.3 A2A核心概念 ​

20.4 Agent发现机制 ​

20.5 通信与任务模型 ​

20.6 四种交互机制 ​

20.7 安全机制 ​

架构解析 —— ANP协议分析 ​

20.8 ANP的定位与设计 ​

关键实现决策 —— 三大协议的协同使用 ​

20.9 协议栈的层次关系 ​

20.10 实际系统中的协议选择 ​

20.11 A2A实现参考 ​

前沿动态 —— 最新进展 ​

20.12 协议标准化趋势 ​

20.13 Agent Card的演进 ​

本章小结 ​