Google A2A：多智能体通信协议

1- Google A2A：多智能体通信协议

在 MCP 生态日益壮大的今天（浅谈 Agent、MCP、OpenAI Responses API，深度解析：Anthropic MCP 协议），Google 又搞出了个 A2A 协议，意欲何为？为了搞清楚两个协议之间的关系，我画了一张 A2A 核心图解帮助大家快速理解。其实两者并非竞争关系，而是一种互补协议。

A2A 核心图解

1.1- 背景

跨系统、多代理协作的挑战

随着企业对 AI 代理的需求不断增长，这些能够自主处理日常繁琐或复杂任务的代理型系统已成为提升生产力的关键力量。然而，不同供应商或框架开发出的代理往往难以在同一环境中安全、可控、灵活地彼此协作，形成了数据与能力的 " 孤岛 "。

为了解决这种多代理生态的互操作难题，A2A 协议应运而生。它为代理之间的通信、任务分发与信息同步提供了统一标准，从而将分散的代理连接成一个高效、可扩展的协作网络。

Google 正式推出一个名为 Agent2Agent[1]（A2A） 的开放协议，得到包括 Atlassian、Box、Cohere、Intuit、Langchain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、UKG、Workday 等 50 多家技术合作伙伴的支持与贡献，以及来自 Accenture、BCG、Capgemini、Cognizant、Deloitte、HCLTech、Infosys、KPMG、McKinsey、PwC、TCS、Wipro 等领先服务提供商的参与。A2A 协议将使 AI 代理能相互通信、安全地交换信息，并在各种企业平台或应用程序之上协调行动。

Agent2Agent 合作伙伴

1.2- A2A 协议简介

A2A 协议

1.2.1- 设计原则

  • 拥抱代理能力：A2A 将代理视为具备自主推理能力的 " 实体 "，允许它们以自然的、非结构化的方式协作。协议并未强制代理共享内存或工具，也不把代理限定在某个 " 插件 " 式角色。正因如此，A2A 能支持真正的多代理场景，为各种复杂业务需求提供基础。
  • 基于已有标准：在协议设计上，A2A 借助了现有的成熟标准，如 HTTP、SSE、JSON-RPC。这样做的好处在于：
    • 更容易与现有 IT 系统集成：很多企业已在使用这些底层协议和技术栈。
    • 稳定且可扩展：能直接复用既有的网络通信与安全认证机制。
  • 默认安全：A2A 非常注重企业级的身份验证和授权，保证与 OpenAPI 等常见认证方式相匹配。在多代理协作的场景下，安全与权限控制至关重要，以确保敏感信息不在错误的代理间传递。
  • 支持长时任务：AI 代理可能执行从简短查询到大型研究项目等不同类型的任务。A2A 为此提供了灵活的任务管理机制，可在任务进行过程中持续更新状态、发送通知、同步进度，确保对长时运行的工作也能持续跟踪和协作。
  • 与模式无关：A2A 不仅支持文本，还包含对音视频流等多种传播模式的兼容。这为代理在更多场景下的协作奠定了基础，如实时语音对话、视频分析等。

📌 SSE

服务器发送事件（SSE：Server-Sent Events）是一种利用持久 HTTP 连接让服务器主动、持续地向客户端推送实时数据更新的技术，客户端无需频繁请求即可获得最新信息，适合用于实时更新场景，如社交媒体通知、股市行情和新闻推送等。

代码示例

为了直观感受 SSE，我用 node.js 创建了一个简单的 SSE 服务，在网页中定时打印信息。

SSE 示例 GIF

sse-demo/
├── public/
│   └── index.html
└── app.js

// app.js

const express = require('express');
const path = require('path');
const app = express();

// 提供 public 目录下的静态文件服务，避免跨域问题
app.use(express.static(path.join(__dirname, 'public')));

// SSE 路由，客户端通过该路径与服务器建立 SSE 连接
app.get('/sse', (req, res) => {
  res.set({
    'Content-Type': 'text/event-stream',  // 告知客户端该连接使用 SSE 协议
    'Cache-Control': 'no-cache',          // 禁止缓存
    'Connection': 'keep-alive'            // 保持长连接
  });
  res.flushHeaders();

    // 每秒向客户端发送一次当前时间
  const intervalId = setInterval(() => {
    const data = new Date().toLocaleTimeString();
    res.write(`data: ${data}\n\n`);
  }, 1000);

  // 当客户端关闭连接时，清除定时器
  req.on('close', () => {
    clearInterval(intervalId);
    res.end();
  });
});

// 启动服务器并监听 3000 端口
const PORT = 3000;
app.listen(PORT, () => {
  console.log(`服务器启动成功，访问地址： http://localhost:${PORT}`);
});

<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<title>SSE 示例</title>
</head>
<body>
<h1>服务器发送事件（SSE）示例</h1>
<div id="sse-data" style="font-size: 1.2em; color: #333;"></div>

<script>
    // 建立到 SSE 服务器的连接，这里无需指定完整地址，
    // 直接使用相对路径即可（避免跨域问题）
    const eventSource = new EventSource('/sse');

    // 监听接收到的消息，并显示在页面中
    eventSource.onmessage = function(event) {
      const outputDiv = document.getElementById('sse-data');
      outputDiv.innerHTML += '收到数据：' + event.data + '<br />';
    };

    // 处理连接错误
    eventSource.onerror = function(err) {
      console.error('EventSource 连接错误:', err);
    };
</script>
</body>
</html>

📌 JSON-RPC

JSON-RPC[2] 是一种使用 JSON 作为数据格式的远程过程调用（RPC）协议。它允许客户端通过网络调用服务器上的函数或方法，并将请求和响应都以 JSON 格式进行封装，从而使得通信既轻量又易于实现。由于其无状态、简单易读和跨平台兼容的特点，JSON-RPC 能够很方便地在分布式系统中传输数据。因符合现代 AI 系统对低延迟、快速响应以及系统间无缝交互的需求，也成为了许多 AI 应用和服务选择的协议格式（主要使用 JSON-RPC 2.0）。

1.2.2- 核心交互

在 A2A 的工作模型中，主要存在 " 客户端代理（client agent）" 和 " 远程代理（remote agent）" 两种角色：

  • 客户端代理：负责接收用户请求、制定具体任务，并向远程代理提出需求。
  • 远程代理：根据接收到的任务，执行相应操作或产出结果（“artifact”）。

二者的交互方式包括能力发现（capability discovery）、任务管理（task management）、协作（Collaboration）和用户体验协商（User experience negotiation）。其中，能力发现依赖 “Agent Card” 来告知代理所具备的能力，任务管理则通过协议定义的 “task” 对象实现可追踪、可更新的工作流程。

Agent2Agent 核心交互

用于连接代理的开放标准：

  • MCP（Model Context Protocol，模型上下文协议）—— 适用于工具和资源
    • 利用结构化的输入和输出，将代理连接至工具、API 和其它资源。
    • Google ADK (Python 版)[3] 支持 MCP 工具，从而使代理能够使用各种 MCP 服务器。
  • A2A（Agent2Agent Protocol，代理对代理协议）—— 用于代理之间协作
    • 不同代理之间无需共享内存、资源和工具，即可实现动态、多模态的通信。
    • 这是一个由社区推动的开放标准。
    • 目前已有使用 Google ADK[4]、LangGraph[5]、Crew.AI[6] 等工具的示例。

MCP 与 A2A 关系图

1.2.3- 场景举例：招聘流程的数字化协作

[Video: 招聘流程的数字化协作]

招聘一名软件工程师可能涉及多个环节：

  1. 发布岗位需求并收集应聘者信息；
  2. 与多个系统对接筛选候选人；
  3. 安排面试、评估结果；
  4. 背调及后续入职流程。

如果在同一个统一的工作界面（如 Agentspace）里，这些流程可由不同专业领域的代理来协作完成：

  • 一个代理负责解析岗位需求、初步筛选简历；
  • 另一个代理与社交平台或招聘系统交互，获取更详细的候选人信息；
  • 其他代理则可负责背景调查、面试日程安排等。

各代理之间通过 A2A 协议通信与同步，大幅简化人与系统间的切换与重复操作。

1.2.4- 行业影响

A2A 的出现意味着代理互操作性进入了新阶段。其统一的协议、开放的生态和模块化的设计，将为企业级 AI 代理部署带来显著价值，主要体现在：

  1. 扩展性：企业可以根据需求随时替换或新增代理，适配不同业务场景。
  2. 灵活性：不同供应商或框架的代理都能加入到同一协作网络中，避免因单一技术堆栈而被锁定。
  3. 可维护性：统一的标准便于企业对各种代理进行监控、管理和认证，减少因多套体系并行带来的复杂度。
  4. 创新性：凭借开放性与跨平台协作，更多创新型应用将涌现，例如多代理协作为用户提供多维度支持、AI 代理与 IoT 设备的联动等等。

值得一提的是，A2A 与 Anthropic 的 Model Context Protocol（MCP）形成了互补关系，A2A 侧重于代理间的通信与能力交换，而 MCP 则为代理提供更丰富的上下文和工具。二者结合可更好满足大规模复杂场景下对数据、逻辑和安全等多方面的需求。

2- 扩展阅读

A2A 的技术文档挺长，感兴趣的可以去阅读文档（A2A Docs[7]），我这里仅分享文档中比较有意思的几个点。

2.1- 为什么需要协议？

随着 AI 代理在各领域的不断扩展，应用系统对 " 结构化工具（Tools）" 和 " 自主代理（Agents）" 之间的协作提出了更高要求。要让代理与外部工具或其他代理顺畅协同，缺少统一协议很容易造成互操作障碍。正是在这一背景下，A2A 与 MCP 顺势而生：

  • MCP：专门解决 " 代理对接工具与数据 " 的问题，聚焦 " 函数调用 " 层面的规范化。
  • A2A：则提供了一种高层次的通信方式，使代理能以近似人类对话的方式彼此沟通或与用户交流，不再仅限于工具调用级别的操作。

从功能定位来看，工具更像是具有固定行为与已知输入输出的 " 原语 "（primitives），而代理则拥有可针对场景进行推理和多轮对话的能力。MCP 统一了代理与工具的连接方式，并通过标准化 " 函数调用 " 来降低集成成本；A2A 则致力于让不同代理能充分交换上下文并协调行动，进而实现更为复杂的业务流程。

2.1.1- 举例说明

想象一家汽车修理厂，拥有可调用的各类专用设备（如举升机、电表、扳手等），这些设备能够通过 MCP 提供的接口与修理工（AI 代理）对接。但要让修理工与顾客及供应商之间进行多轮问答和需求确认，就需要借助 A2A 协议来承载他们的 " 自然语言交流 " 和持续协作。

  • MCP：让修理工得以精准操控设备，例如 " 升起汽车 2 米 " 或 " 以固定扭力旋紧螺帽 "。
  • A2A：使修理工能够就故障原因、修理进度或零件订购等问题与顾客和供应商反复讨论，动态调整方案。

通常，在实际系统中会把基于 A2A 开发的代理当作 MCP 的一种资源（通过 AgentCard 的形式来描述），从而既能用 A2A 来管理多代理的业务协同，又能透过 MCP 获得所需的工具功能与数据。对开发者和企业而言，这种双协议方案既提供了统一管理的便利，也保证了在开放生态里灵活扩展代理能力的可能性。

A2A 与 MCP 关系示意图

2.2- AgentCard

A2A 协议提供了统一的 AgentCard 格式，用于描述代理的关键属性和能力。但在实践中，如何让客户端发现这些 AgentCard 并不固定，依需求和场景可以有多种实现方式。以下是 Google 目前的思考，欢迎社区共同探讨。

2.2.1- 开放式发现（Open Discovery）

在开放式发现模式下，企业可以将自身的 AgentCard 放置在一个众所周知的路径，例如：

https://<域名>/.well-known/agent.json

当客户端获取了该域名后（DNS 解析），直接对上述路径执行一次 GET 请求，就能拿到对应的 AgentCard。这种模式下，网络爬虫和应用都能轻松读取代理信息，并且只需 " 发现一个域名 " 即可完成主要流程。

2.2.2- 精心筛选的发现（基于注册表，Curated Discovery / Registry-Based）

企业还可能通过 " 注册表（Registry）" 的形式来对外开放或内部共享代理目录，比如在公司层级或团队层级维护一份由管理员审核的代理列表。这类做法可以兼容更多企业应用场景，比如让特定人群或组织仅能访问经过认证或审核的代理。Google 也在考虑是否将 " 注册表支持 " 纳入协议规范，如果对此有意见或建议，随时分享反馈。

2.2.3- 私有发现（基于 API，Private Discovery / API-Based）

另外，某些组织会有私有的 " 代理商店 " 或定制化代理，不对外公开其 AgentCard，而是通过内部 API 实现独立的卡片交换和管理。这类私有 API 的发现方式目前不在 A2A 关注的重点范围内。如果你认为有必要将其纳入协议标准，也欢迎提出相关需求与场景。

2.2.4- AgentCard 的安全性（Securing Agent Cards）

由于 AgentCard 内可能包含敏感信息，实现方应采取合适的方式保护其安全。即便是放在 .well-known 路径下的卡片，也可结合 mTLS 或其他认证手段，让只有授权的客户端才能访问。对于基于注册表或私有 API 的场景，进一步的身份验证与访问控制同样不可或缺。需要注意的是，如果 AgentCard 中包含类似 API Key 这类敏感凭证，务必将其放在需要身份认证的访问范围内，避免将敏感信息暴露给未经授权的用户。

以下内容介绍了 A2A 在企业场景下的适用性，包括传输安全、身份验证、授权以及可观测性等方面的考量，重点强调了 " 不要重复造轮子 "，而是与现有的企业基础设施和最佳实践相结合。

2.3- 企业级

2.3.1- 传输层安全（Transport Level Security）

A2A 基于 HTTP 进行通信。在生产环境中，必须使用 HTTPS（配合现代 TLS 加密套件）来保护数据传输安全，避免敏感信息被窃听或篡改。

2.3.2- 服务器身份（Server Identity）

A2A 服务端需要通过 TLS 证书 来向客户端证明其身份，这些证书应由知名的证书颁发机构（CA）签发。客户端在建立连接时必须验证服务端证书，确保通信的对端确实是预期目标。

2.3.3- 客户端与用户身份（Client and User Identity）

A2A 的数据结构（schema）本身并不包含用户或客户端 ID 的概念，但会在协议层指出应该如何完成身份验证（包括所需的认证方案及凭证）。

客户端负责与相应的认证机构（通常独立于 A2A）协商和获取凭证（如 OAuth Token）。这些凭证通过 HTTP Header 传给 A2A 服务端，而不是放在 A2A 的载荷中。不同的认证协议和服务供应商可能有各自的要求，甚至在同一次请求中需要多个标识。通常建议客户端在请求中始终呈现 " 客户端身份 "（表示代理自身）和 " 用户身份 "（表示该代理所代表的用户），以便服务端基于身份进行更精细的授权和数据保护。

注意： 跨多身份系统（multi-identity federation）是一个尚在讨论中的话题。举例来说，如果用户 U 正在与代理 A 交互，而代理 A 又需要调用工具 B 或代理 B 的能力，那么有可能需要在同一个请求中同时提供 A 系统和 B 系统的不同身份凭证。当前的建议是：如果代理 A 需要用户或客户端为部分任务提供额外身份信息，可通过 “INPUT-REQUIRED” 状态来提示客户端。客户端再与 B 系统的认证机构单独协商，并将获得的凭证传回 A 代理，最终 A 代理再将这些凭证用于与 B 的通信。

2.3.4- 客户端认证（Authenticating Clients）

A2A 服务端会在 Agent Card 中声明其支持或要求的认证协议（例如 API Keys、OAuth、OIDC 等），也可使用扩展协议，前提是客户端和服务端均支持。

具体的认证流程（获取、刷新、质询、过期等）并不属于 A2A 协议范围，需要在外部独立实现。

A2A 服务端应对每次请求进行认证，若认证失败或权限不足，需返回标准的 HTTP 响应码（401、403）及协议特定的报文头/报文体（例如带有 WWW-Authenticate 的 HTTP 401 响应，或在一个 well-known 路径下提供 OIDC 发现文档）。

2.3.5- 授权与数据隐私（Authorization and Data Privacy）

A2A 服务端根据用户与应用身份对请求进行授权。 建议至少在两个层面控制访问权限：

  • 技能（Skills）： 代理通过 Agent Card 宣告其技能（如 “generateRecipe”）。服务端可基于用户/客户端权限以及 OAuth Scope 等控制对技能的访问，例如某些技能只能授予只读权限。
  • 工具（Actions and Data）： 推荐将涉及敏感操作或数据的部分抽象成 " 工具 "（Tools），仅在确定用户/客户端拥有对应权限时才允许访问。企业可结合 API Management 等措施，将对这些工具的访问权限与业务逻辑紧密结合。

2.3.6- 跟踪与可观测性（Tracing and Observability）

由于 A2A 的请求都是标准 HTTP 请求，客户端和服务端可以直接使用企业现有的监控、日志和分布式追踪工具（如在请求头中携带追踪信息），并将相关事件写入标准日志或事件队列中。这样可保证 A2A 代理在生产环境中的可观测性与可维护性。

2.4- 多智能体网页应用

该图演示了应用程序通过多个 A2A 协议与其他代理对话。

多智能体网页应用架构图

2.4.1- References

  1. Agent2Agent: https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability
  2. JSON-RPC: https://www.jsonrpc.org
  3. Google ADK (Python 版): https://github.com/google/adk-python
  4. Google ADK: https://github.com/google/A2A/tree/main/samples/python/agents/google_adk
  5. LangGraph: https://github.com/google/A2A/tree/main/samples/python/agents/langgraph
  6. Crew.AI: https://github.com/google/A2A/tree/main/samples/python/agents/crewai
  7. A2A Docs: https://google.github.io/A2A