揭秘Google A2A协议：原理、应用与未来 精华

一、A2A 协议的核心原理

A2A 协议的设计基于五个核心原则，这些原则确保了协议的灵活性、安全性和广泛适用性。以下是对这些原则的详细解析，并结合技术机制进行说明。

1. 拥抱智能体特性（Embrace Agentic Capabilities）

A2A 协议专为具有自主性和复杂推理能力的 AI 智能体设计。不同于传统的工具调用（如 API 或数据库查询），A2A 允许智能体以自然、结构化的方式进行协作，而无需共享内存、工具或上下文。这种设计支持智能体在分布式环境中独立运行，同时保持高效的协作能力。

技术实现：

• 智能体之间的通信通过任务（Task）作为核心工作单元。任务可以是短期的（如生成报告）或长期的（如供应链优化）。

• 智能体通过消息（Message）交换信息，消息支持多模态内容（如文本、图像、视频），适应复杂场景。 

• 智能体不需要了解彼此的内部实现，只需遵循 A2A 协议的接口规范即可。

2. 基于现有标准（Build on Existing Standards）

A2A 协议利用成熟的 Web 技术，确保与现有 IT 架构的兼容性和易用性。

核心技术包括：

• HTTP/HTTPS：作为主要传输协议，生产环境中必须使用 HTTPS 和现代 TLS 加密。

• JSON-RPC 2.0：用于结构化数据交换，确保请求和响应的标准化。 - 服务器发送事件（SSE）：支持实时、单向的流式更新，适用于任务进度通知。

优势：

• 开发者无需学习新的协议栈，现有工具和库即可支持 A2A。 

• 企业可以轻松将 A2A 集成到现有的微服务架构中。

3. 默认安全（Secure by Default）

安全性是 A2A 协议的核心考量。协议内置了企业级认证和授权机制，包括： 

• OAuth 和 OpenAPI 认证：确保只有授权的智能体可以通信。

• 数字证书：A2A 服务器通过知名证书颁发机构签发的证书证明身份。

• 请求追踪：支持日志和事件队列，便于监控和审计。

技术实现：

• 智能体卡表（Agent Card）中包含认证要求，客户端智能体在发起任务前必须完成身份验证。

• 数据传输使用 HTTPS 加密，防止中间人攻击。

4. 支持长时间运行任务（Support for Long-Running Tasks）

A2A 协议不仅支持简单的请求-响应交互，还能处理需要数小时或数天的复杂任务。例如，供应链优化可能涉及多个智能体的协作，任务状态需要持续跟踪。

任务具有唯一 ID 和状态（如 submitted、working、completed、failed）。通过tasks/sendSubscribe 方法，客户端可以建立流式连接，接收任务的实时更新。任务状态通过 SSE 推送，确保客户端无需轮询。

5. 模态无关（Modality Agnostic）

A2A 支持多模态通信，智能体可以交换文本、图像、音频、视频或交互式内容（如 Web 表单）。这种设计适应了企业中多样化的数据需求。

消息中的“结构体（Part）”定义了内容类型，允许智能体协商适合的格式。例如，一个智能体可以返回图表数据（JSON）或渲染后的图像，具体取决于客户端的偏好。

二、A2A 协议的核心组件

A2A 协议的实现依赖于几个核心组件，这些组件共同构成了智能体间通信的框架。以下是对每个组件的详细说明。

1. 智能体卡表（Agent Card）

智能体卡表是 A2A 协议的入口点，用于描述智能体的身份和能力。它是一个 JSON 格式的元数据文件，通常托管在智能体的某个确定的路径下。

结构：

• 身份信息：包括智能体的名称、版本和托管地址（DNS 或 URL）。

• 能力描述：列出支持的功能（如流式传输、推送通知）和技能（Skills）。 

• 认证要求：指定 OAuth、API 密钥或 OIDC 等认证方式。 

• 端点：提供 API 端点的 URL（如 tasks/send）。

示例（简化版）：

{
  "name": "XX云服务",
  "version": "1.0.0",
  "endpoint": "https://mycloud.com/a2a",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": ["AI秘书", "订购助手"],
  "authentication": {
    "type": "OAuth",
    "url": "https://mycloud.com/"
  }
}

作用：

• 能力发现：客户端智能体通过读取智能体卡表了解远程智能体的功能，决定是否发起协作。

• 动态注册：对于服务端来说，智能体可以在运行时更新其能力，无需重启会话。

2. 任务（Task）

任务是 A2A 协议的核心工作单元，表示客户端智能体请求远程智能体执行的操作。任务具有明确的生命周期和状态管理。

生命周期：

• 提交（submitted）：任务被客户端发送到远程智能体。 

• 工作中（working）：远程智能体正在处理任务。 

• 需要输入（input-required）：任务需要额外信息暂停。

• 完成（completed）：任务成功结束，返回工件（Artifact）。

• 失败（failed）：任务因错误终止。

• 取消（canceled）：任务被客户端取消。

API 方法：

• tasks/send：同步请求，适合快速任务，客户端等待响应。

• tasks/sendSubscribe：建立流式连接，适合长时间任务，客户端接收 SSE 更新。

示例请求：

{
  "method": "tasks/send",
  "params": {
    "task": {
      "id": "task-123",
      "description": "请开通XX服务",
      "input": {
        "data": ["XX服务规格：..."]
      }
    }
  },
  "jsonrpc": "2.0",
  "id": 1
}

图示：

3. 消息（Message）

消息是智能体间通信的基本单位，表示一次交互的“回合”。消息支持多模态内容，并通过“Part”定义具体格式。

结构：

• 角色：user（客户端智能体）或 agent（远程智能体）。 

• 内容：包含多个部分（Part），每个部分指定内容类型（如 text/plain、image/png）。

• 元数据：包括消息 ID、时间戳等。

示例：

{
  "role": "agent",
  "parts": [
    {
      "contentType": "text/plain",
      "content": "Chart generated successfully"
    },
    {
      "contentType": "image/png",
      "content": "base64_encoded_image"
    }
  ],
  "id": "msg-456",
  "timestamp": "2025-04-24T22:00:00Z"
}

作用：

• 支持复杂的交互，如同时传输文本说明和可视化结果。

• 允许格式协商，例如客户端请求 JSON 数据而非图像。

4. 产出层：Artifact 管理

Artifact 是指任务的输出，通常是文件或结构化数据（如报告、图像）。工件与消息类似，但专注于任务的最终结果。

示例：

{
  "id": "artifact-789",
  "contentType": "application/pdf",
  "content": "XX服务已经订购成功",
  "taskId": "task-123"
}

作用：

• 提供标准化的输出格式，便于客户端处理。

• 支持大文件传输，通过分片或流式传输。

5. A2A 服务器与客户端

• A2A 服务器：实现 A2A 协议的 HTTP 端点，接收任务请求并执行操作。它托管智能体卡表并处理任务生命周期。

• A2A 客户端：发起任务的智能体或应用，通过 HTTP 请求与服务器交互。

交互流程：

• 客户端通过智能体卡表发现服务器。
• 客户端发送任务请求（tasks/send 或tasks/sendSubscribe）。
• 服务器处理任务并返回消息或工件。

三、技术细节

1. JSON Schema

A2A 协议的核心规范通过 JSON Schema 定义（a2a.json），详细描述了智能体卡表、任务、消息等对象的字段、类型和约束。开发者可以通过 JSON Schema 工具验证实现是否符合标准。

关键字段：

• AgentCard.capabilities：支持的功能，如streaming、pushNotifications。 - Task.state：任务状态枚举（submitted、working 等）。

• Message.parts：支持的内容类型（如 text/plain、application/json）。

2. 通信模式

A2A 支持两种通信模式： 

• 同步模式：通过 tasks/send 实现，适合快速任务。 

• 异步模式：通过 tasks/sendSubscribe 和 SSE 实现，适合长时间任务。

SSE 示例：

GET /tasks/sendSubscribe?taskId=task-123 HTTP/1.1
Host: mycloud.com
Accept: text/event-stream

响应：

event: task-update
data: {"taskId": "task-123", "state": "working"}


event: task-update
data: {"taskId": "task-123", "state": "completed", "artifact": "artifact-789"}

3. 错误处理

A2A 定义了标准化的错误响应，基于 JSON-RPC 2.0。例如：

{
  "jsonrpc": "2.0",
  "error": {
    "code": 32600,
    "message": "认证失败"
  },
  "id": 1
}

四、行业案例

以运营商智能客服系统为例，演示 A2A 在通信行业的典型应用流程。

1. 背景

假设运营商在全国多个省部署了智能客服的智能体。用户在线咨询时，往往需要跨省调用多方能力，例如：

• 查询套餐余量（系统 A）

• 推荐个性化增值业务（系统 B）

• 处理投诉工单（系统 C）

2. A2A 集成流程

➢ 能力注册

各个省（比如安徽省）的智能客服系统分别发布自己的 Agent到中心节点：

anhui.xxx.com/.well-known/agent.json

jiangsu.xxx.com/.well-known/agent.json

center.xxx.com/.well-known/agent.json

➢ 发现与认证

主客服 Agent（客户当前所在地）在接到用户请求后，通过 HTTP GET 向中心节点拉取各 Agent Card，筛选出客户号码所在地的智能体地址。同时，使用 OAuth2 向目标 Agent 申请 Access Token。

➢ 任务分发

所在地的Agent 向目标 Agent 以 tasks/sendSubscribe 的方式发起 Task：

POST /tasks/sendSubscribe HTTP/1.1
Host: mycloud.com
Authorization: Bearer <token>
Content-Type: application/json


{
  "task": {
    "id": "task-123",
    "inputs": { "phoneNumber": "1234567890" },
    "metadata": { "operation": "推荐一个长期在外地（安徽）的流量套餐" }
  }
}

同时订阅 SSE，获取实时进度与结果。

➢ 结果聚合与回传

当 Agent 完成任务后，按照预定义的业务逻辑生成最终用户应答，并通过原始通道反馈给用户。

3. 应用效果

• 全程自主化：用户只需一个集成A2A的客户端比如手机，可以使用文字、语音等说出自己的需求，就能直接获取结果，无需考虑切换客服号码或者切换当地号码才能获取答案。

• 开发成本降低：无需为每对系统单独编写对接代码，只需遵循 A2A 规范。

• 可维护性增强：新增或替换智能体只需更新 Agent Card 与认证配置，无需改动主业务逻辑。

五、现有智能体如何集成A2A

当前A2A支持CrewAI、LangChain、Genkit、Google Agent Development Kit等创建的智能体，下面以LangChain为例，说明如何集成A2A。

1. 定义LangChain实现的智能体

class LangChainAgent:
  # ...

2. 定义智能体技能

skill = AgentSkill(
            id="mycloud",
            name="XX云",
            descriptinotallow="能够协助处理云服务相关问题",
            tags=["AI秘书", "订购助手"],
            examples=["请问XX服务有哪些规格"],
        )

3. 定义智能体卡表

agent_card = AgentCard(
            name="XX云智能体",
            descriptinotallow="XX云智能体",
            url=f"http://agentcard.mycloud.com/",
            versinotallow="1.0.0",
            skills=[skill],
        )

4. 启动A2A服务

server = A2AServer(
            agent_card=agent_card,
            task_manager=AgentTaskManager(agent=LangChainAgent(), notification_sender_auth=notification_sender_auth),
            host="mycloud.com"
        )
server.app.add_route(
            "/.well-known/jwks.json", notification_sender_auth.handle_jwks_endpoint, methods=["GET"]
        )

六、A2A 的优势与局限性

优势

1.互操作性：打破不同框架的孤岛，降低集成成本。

2.企业级特性：内置安全性和长时间任务支持，适合复杂场景。

3.社区驱动：开源协议，得到广泛支持，生态持续扩展。

局限性

1.文档等完善度：当前文档缺乏详细的跨供应商示例和多模态处理指南。

2.智能体发现：尽管目前的智能体通过卡表发现，但是卡表如何部署、如何确保安全和公信力成为一个亟待解决的问题，Google官方也说明这是一个开放性的问题，可以在社区讨论：如果是中心化部署要考虑大流量和高延时的问题，如果是类似DNS这种分层次的部署，那是否要定义一种新的大家都遵守的卡表发现协议？

3.sdk支持较少: 目前仅仅支持python 、js开发的智能体,并且支持的开源智能体框架也比较少。

七、MCP、Manus 和 A2A 的关系与互补性

MCP、Manus 和 A2A 代表了 AI 生态系统中不同层面的创新，都在发布时就爆火，它们在功能和定位上互补但各有侧重： 

MCP（数据平面）：专注于模型与工具/数据的交互，提供标准化的上下文输入和输出接口。

Manus（框架层）：提供多智能体协作的框架，强调自主性和任务编排，但缺乏标准化通信协议。

A2A（控制平面）：专注于智能体间的通信与协作，定义了智能体如何发现、协商和协调任务。

互补性：

• MCP 为智能体提供访问外部资源的能力，A2A 则让智能体能够相互通信。例如，在一个汽车维修场景中，MCP 允许智能体调用工具（如“将平台提升 2 米”），而 A2A 协调智能体与客户的交互（如“发送左轮照片”）。

• Manus 可以在 MCP 和 A2A 的基础上运行，利用 MCP 访问工具，借助 A2A 与其他智能体协作。

未来一种可能的协作如图所示：

总结

A2A 协议通过智能体卡表、任务、消息等核心组件，为 AI 智能体间的通信提供了标准化框架。其基于 HTTP、JSON-RPC 和 SSE 的设计确保了易用性和兼容性，而企业级安全性和多模态支持使其适用于复杂场景。通过以上详细的原理分析和图示，我们可以看到A2A如何通过能力发现、任务管理和实时更新实现高效协作。尽管仍有一些改进空间，A2A 的开源性质和广泛支持为其成为 AI智能体通信的“HTTP”奠定了基础。

参考文献

Manus, 2025-03-25

​​https://manus.monica.cn/​​

Google A2A, 2025-04-19

​​https://google.github.io/A2A/#/​​

Teneo.ai, MCP and A2A Protocols Explained, 2025-04-10

​​https://www.teneo.ai/blog/mcp-and-a2a-protocols-explained-the-future-of-agentic-ai-is-here​​

Koyeb, A2A and MCP: Start of the AI Agent Protocol Wars, 2025-04-11

​​https://www.koyeb.com/blog/a2a-and-mcp-start-of-the-ai-agent-protocol-wars​​

Blott Studio, MCP vs A2A: Which Protocol Is Better For AI Agents, 2025-04-09

​​https://www.blott.studio/blog/post/mcp-vs-a2a-which-protocol-is-better-for-ai-agents​​

Saptak Sen, Agent2Agent vs MCP, 2025

​​https://saptak.in/writing/2025/04/10/agent2agent-vs-mcp​​

Anthropic, Introducing the Model Context Protocol, 2024-11-25

​​https://www.anthropic.com/news/model-context-protocol​​

Hugging Face, MCP is All You Need, 2025-03-18

​​https://huggingface.co/blog/LLMhacker/mcp-is-all-you-need​​

VC Cafe, The future of AI tooling is Interoperable, 2025-04-10

​​https://www.vccafe.com/2025/04/10/the-future-of-ai-tooling-is-interoperable-mcp-and-agent2agent/​​

本文转载自​​AI遇见云​​，作者：王亚平