殷龙飞的博客

A2A（Agent2Agent）系列专题 (一) 什么是 A2A？企业 AI 互操作性的新标准

 协议/大模型/A2A  2909  6 分钟

什么是 A2A？企业 AI 互操作性的新标准

摘要：A2A（Agent2Agent）是 Google 主导的开源协议，旨在解决企业 AI 代理之间的通信和互操作性难题。本文深入剖析 A2A 的背景、设计理念和技术架构，探讨其如何通过标准化协议打破 AI 系统孤岛，为多代理协作铺平道路。我们将结合 GitHub 仓库的实现细节和 Mermaid 图表，揭示 A2A 的硬核内核。

1. 引言：AI 代理的孤岛困境

在企业 AI 的浪潮中，代理（Agent）已成为自动化和智能化的核心。从处理费用报销的简单脚本到协调供应链的复杂系统，AI 代理无处不在。然而，现实却充满挑战：

  • 框架碎片化：TensorFlow、PyTorch、Hugging Face 等框架各有千秋，但缺乏统一接口。
  • 供应商壁垒：Google Cloud、AWS、Azure 的 AI 服务各自为政，难以跨平台协作。
  • 通信障碍：代理间缺乏标准协议，导致开发者和企业需要为每对交互编写定制代码。

这些问题催生了“AI 孤岛”：每个代理像一座孤立的堡垒，无法高效协同。Google 的 A2A（Agent2Agent） 协议应运而生，试图通过开源和标准化，打造 AI 代理的“互联网”。

A2A 是一个轻量级协议，定义了代理间通信的规则，允许不同系统、框架和供应商的代理无缝交互。根据 Google A2A GitHub 仓库，A2A 已在企业场景中获得初步验证（例如 Articul8 和 Arize AI 的支持）。本文将从技术视角深入剖析 A2A，揭示其设计理念和实现细节。

2. A2A 的核心理念：代理即服务

A2A 的核心思想是将 AI 代理抽象为“服务”，类似于微服务架构中的模块化组件。每个代理通过 AgentCard（代理卡片）声明自己的身份和能力，代理间通过标准化的任务接口（Task Interface）交换工作。以下是 A2A 的三大支柱：

  1. AgentCard：代理的“名片”，包含名称、描述、URL、支持的交互模式（文本、表单、音视频）等。
  2. 任务生命周期：任务从创建到完成的状态机，代理通过 HTTP 或 WebSocket 交换状态更新。
  3. 动态协商：代理在交互前协商通信方式（例如文本优先还是流式音视频），确保灵活性。

为了直观理解 A2A 的工作方式，以下是一个简单的架构图：

graph TD
    A[User] -->|提交任务| B[Host Agent]
    B -->|发现与协商| C[Remote Agent 1]
    B -->|发现与协商| D[Remote Agent 2]
    C --> E[A2A Protocol]
    D --> E
    E --> F[任务执行与结果返回]

在这个模型中，Host Agent 充当协调者，负责任务分发；Remote Agent 执行具体任务；A2A Protocol 则是连接它们的桥梁。

3. 为什么需要 A2A？从痛点到解决方案

3.1 企业 AI 的痛点

企业在部署 AI 代理时，常常面临以下问题：

  • 集成成本高：为不同代理编写定制通信逻辑，耗费时间和资源。例如，连接一个费用报销代理和汇率转换代理可能需要数百行胶水代码。
  • 扩展性差：当引入新代理时，系统需要重新设计接口，难以动态扩展。
  • 用户体验割裂：代理间的交互（如表单输入或音视频流）缺乏统一标准，导致前端开发复杂。

这些痛点源于 AI 生态的碎片化。传统的解决方案（如 REST API 或 gRPC）虽然能部分缓解，但无法满足 AI 代理的动态性和多模态需求。

3.2 A2A 的解决方案

A2A 通过以下方式应对挑战：

  • 标准化协议：基于 JSON Schema（a2a.json）定义 AgentCard 和任务结构，确保一致性。
  • 动态发现：代理通过交换 AgentCard 自动识别彼此的能力，无需手动配置。
  • 多模态支持：支持文本、表单、音视频等多种交互模式，适配复杂场景。
  • 开源生态：托管于 GitHub，鼓励社区贡献（例如 Google 的样本实现 google_adk）。

例如，GitHub 仓库中的 samples/python/agents/google_adk 展示了一个费用报销代理，能够通过 A2A 协议与前端和后端代理交互，完成从表单验证到结果返回的全流程。

4. A2A 的技术架构：硬核解析

A2A 的技术设计围绕 客户端-服务器模型，结合 HTTP 和 WebSocket 协议，确保高效和灵活。以下是其核心组件的深入剖析：

4.1 AgentCard：代理的身份证明

AgentCard 是 A2A 的基石，定义了一个代理的元数据。它的 JSON Schema（参考 a2a.json）包括以下关键字段：

  • name：代理的唯一名称（例如 “ExpenseAgent”）。
  • description：代理的功能描述。
  • url：代理的通信端点（例如 https://example.com/a2a）。
  • schemes：支持的认证方式（例如 OAuth）。
  • capabilities：功能描述，包括 streaming（是否支持流式传输）、pushNotifications（是否支持推送）等。

以下是 AgentCard 的简化结构（Mermaid 类图）：

classDiagram
    class AgentCard {
        +String name
        +String description
        +String url
        +Array schemes
        +Object capabilities
        +Boolean streaming
        +Boolean pushNotifications
    }
    class AgentAuthentication {
        +Array schemes
        +String credentials
    }
    class AgentCapabilities {
        +Boolean streaming
        +Boolean pushNotifications
        +Boolean stateTransitionHistory
    }
    AgentCard --> AgentAuthentication
    AgentCard --> AgentCapabilities

4.2 任务生命周期：状态机的艺术

A2A 的任务（Task）遵循明确的状态机，从创建到完成经历以下阶段：

  1. Created：任务被提交，等待分配。
  2. In Progress：代理开始执行任务。
  3. Completed：任务成功完成，返回结果。
  4. Failed：任务失败，返回错误信息。

任务状态通过 HTTP 或 WebSocket 实时更新。以下是一个任务生命周期的流程图：

flowchart TD
    A[Task Created] --> B[In Progress]
    B --> C{Outcome}
    C --> D[Completed]
    C --> E[Failed]
    D --> F[Result Returned]
    E --> G[Error Reported]

4.3 通信机制：HTTP 与 WebSocket 的融合

A2A 支持两种通信协议：

  • HTTP：适合简单的请求-响应场景，例如提交任务或查询状态。
  • WebSocket：适合实时交互，例如流式传输音视频或推送任务更新。

例如，一个简单的 HTTP 请求可能如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

POST /a2a/task HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "taskId": "123",
  "type": "expense",
  "data": {
    "amount": 100,
    "currency": "USD"
  }
}

WebSocket 则用于持续通信，代理可以通过 streaming 模式实时发送数据片段。

4.4 动态协商：多模态交互的基石

A2A 的亮点之一是代理间的动态协商。例如，Host Agent 可能请求文本交互，而 Remote Agent 提议表单输入。这种协商通过 AgentCard 的 capabilities 字段实现，允许代理在运行时调整交互模式。

以下是一个协商过程的时序图：

sequenceDiagram
    participant C as Client Agent
    participant S as Server Agent
    C->>S: Request AgentCard
    S-->>C: Return AgentCard (text, form)
    C->>S: Propose text interaction
    S-->>C: Suggest form instead
    C->>S: Agree to form
    C->>S: Submit Task (form data)
    S-->>C: Task Result

5. 代码示例：从 GitHub 到实践

为了展示 A2A 的实际应用，我们基于 GitHub 仓库的 samples/python/agents/google_adk 提供一个简单示例：一个费用报销代理。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 简单的 A2A 服务器实现
from a2a import A2AServer, AgentCard

class ExpenseAgent(A2AServer):
    def __init__(self):
        super().__init__(card=AgentCard(
            name="ExpenseAgent",
            description="Handles expense reimbursements",
            url="https://example.com/a2a",
            capabilities={"streaming": False, "pushNotifications": True}
        ))

    def handle_task(self, task):
        if task["type"] == "expense":
            amount = task["data"]["amount"]
            currency = task["data"]["currency"]
            # 模拟处理逻辑
            return {
                "status": "completed",
                "result": f"Processed {amount} {currency}"
            }
        return {"status": "failed", "error": "Invalid task type"}

if __name__ == "__main__":
    server = ExpenseAgent()
    server.run(port=8080)

这个代理监听 HTTP 请求，处理费用报销任务，并返回结果。开发者可以基于此扩展更复杂的功能，例如连接数据库或调用外部 API。

6. A2A 的潜力与挑战

6.1 潜力

A2A 的标准化设计使其在以下场景中大有可为：

  • 企业自动化：连接财务、物流、客服等代理，打造端到端流程。
  • 跨平台协作：打破供应商壁垒，让 Google、AWS、Microsoft 的代理协同工作。
  • 开源生态：通过 GitHub 吸引开发者贡献，加速协议演进。

6.2 挑战

尽管前景光明，A2A 仍面临技术挑战：

  • 认证与安全：当前的 AgentAuthentication 方案较为简单，GitHub Issues 提到未来需支持更复杂的授权机制。
  • 性能瓶颈：多代理系统可能因网络延迟或任务调度影响效率。
  • 社区采用：A2A 需要更多企业支持，才能成为行业标准。

7. 结语：A2A 的未来

A2A 不仅是 Google 对 AI 互操作性的一次探索，也是多代理系统标准化的一步尝试。通过 AgentCard、任务生命周期和动态协商，A2A 为企业 AI 提供了灵活而强大的通信框架。结合 GitHub 仓库的开源实现，开发者可以快速上手，构建自己的代理网络。

在后续系列中，我们将深入探讨 A2A 的 JSON Schema、代理发现机制和多模态交互，带你从理论到实践全面掌握这一协议。欢迎加入 A2A GitHub 社区，一起推动 AI 代理的未来！

updatedupdated2025-04-172025-04-17

相关文章：