什么是 A2A？¶

A2A 协议是一个开放标准，可实现 AI 代理之间的无缝通信和协作。它为使用不同框架和不同供应商构建的代理提供了通用语言，促进了互操作性并打破了壁垒。代理是自主的问题解决者，在环境中独立行动。A2A 允许来自不同开发者、基于不同框架并由不同组织拥有的代理联合起来协同工作。

为什么使用 A2A 协议¶

A2A 解决了 AI 代理协作中的关键挑战。它为代理交互提供了一种标准化方法。本节将解释 A2A 解决的问题及其提供的优势。

A2A 解决的问题¶

考虑用户请求 AI 助手规划国际旅行。此任务涉及协调多个专业代理，例如

航班预订代理
酒店预订代理
当地旅游推荐代理
货币兑换代理

如果没有 A2A，集成这些不同的代理会带来几个挑战

代理暴露：开发者通常将代理封装为工具，以将其暴露给其他代理，类似于在多代理控制平台（模型上下文协议）中暴露工具的方式。然而，这种方法效率低下，因为代理旨在直接协商。将代理封装为工具会限制其功能。A2A 允许代理按原样暴露，无需这种封装。
自定义集成：每次交互都需要自定义的点对点解决方案，从而产生大量的工程开销。
创新缓慢：针对每个新集成进行定制开发会减缓创新。
可扩展性问题：随着代理和交互数量的增加，系统变得难以扩展和维护。
互操作性：这种方法限制了互操作性，阻碍了复杂 AI 生态系统的有机形成。
安全漏洞：临时通信通常缺乏一致的安全措施。

A2A 协议通过建立 AI 代理的互操作性来可靠且安全地交互，从而解决了这些挑战。

A2A 示例场景¶

本节提供了一个示例场景，以说明使用 A2A（Agent2Agent）协议进行 AI 代理之间复杂交互的优势。

用户的复杂请求¶

用户与 AI 助手交互，给出诸如“规划一次国际旅行”之类的复杂提示。

graph LR
    User --> Prompt --> AI_Assistant[AI Assistant]

协作的必要性¶

AI 助手收到提示并意识到它需要调用多个专业代理来完成请求。这些代理包括航班预订代理、酒店预订代理、货币兑换代理和当地旅游代理。

graph LR
    subgraph "Specialized Agents"
        FBA[✈️ Flight Booking Agent]
        HRA[🏨 Hotel Reservation Agent]
        CCA[💱 Currency Conversion Agent]
        LTA[🚌 Local Tours Agent]
    end

    AI_Assistant[🤖 AI Assistant] --> FBA
    AI_Assistant --> HRA
    AI_Assistant --> CCA
    AI_Assistant --> LTA

互操作性挑战¶

核心问题：代理无法协同工作，因为每个代理都有自己的定制开发和部署。

缺乏标准化协议的后果是这些代理无法相互协作，更不用说发现它们能做什么了。各个代理（航班、酒店、货币和旅游）是相互隔离的。

“使用 A2A”解决方案¶

A2A 协议提供标准方法和数据结构，使代理能够相互通信，无论其底层实现如何，因此相同的代理可以用作互连系统，通过标准化协议无缝通信。

AI 助手现在充当协调器，接收来自所有启用 A2A 的代理的连贯信息。然后，它将一个完整且连贯的旅行计划作为无缝响应呈现给用户的初始提示。

A2A Actors showing a User, A2A Client (Client Agent), and A2A Server (Remote Agent)

A2A 的核心优势¶

实施 A2A 协议在整个 AI 生态系统中提供了显著优势

安全协作：如果没有标准，很难确保代理之间的安全通信。A2A 使用 HTTPS 进行安全通信并维护不透明操作，因此代理在协作期间无法看到其他代理的内部工作原理。
互操作性：A2A 打破了不同 AI 代理生态系统之间的壁垒，使来自不同供应商和框架的代理能够无缝协作。
代理自治：A2A 允许代理在与其他代理协作时保留其独立能力并充当自治实体。
降低集成复杂性：该协议标准化了代理通信，使团队能够专注于其代理提供的独特价值。
支持 LRO：该协议支持长时运行操作 (LRO) 和使用服务器发送事件 (SSE) 进行流式传输以及异步执行。

A2A 的关键设计原则¶

A2A 开发遵循优先考虑广泛采用、企业级功能和面向未来的原则。

简洁性：A2A 利用现有标准，例如 HTTP、JSON-RPC 和服务器发送事件 (SSE)。这避免了核心技术的重复发明，并加速了开发人员的采用。
企业就绪：A2A 解决了关键的企业需求。它与用于强大的身份验证、授权、安全、隐私、跟踪和监控的标准 Web 实践保持一致。
异步：A2A 原生支持长时运行任务。它处理代理或用户可能无法持续保持连接的场景。它使用流式传输和推送通知等机制。
模态无关：该协议允许代理使用各种内容类型进行通信。这使得除了纯文本之外，还可以进行丰富而灵活的交互。
不透明执行：代理在不暴露其内部逻辑、内存或专有工具的情况下有效协作。交互依赖于声明的功能和交换的上下文。这保护了知识产权并增强了安全性。

理解代理堆栈：A2A、MCP、代理框架和模型¶

A2A 位于更广泛的代理堆栈中，其中包括

A2A：标准化不同组织中部署并使用不同框架开发的代理之间的通信。
MCP：将模型连接到数据和外部资源。
框架（如 ADK）：提供用于构建代理的工具包。
模型：作为代理推理的基础，这些可以是任何大型语言模型 (LLM)。

ADK versus MCP

A2A 和 MCP¶

在更广泛的 AI 通信生态系统中，您可能熟悉旨在促进代理、模型和工具之间交互的协议。值得注意的是，模型上下文协议 (MCP) 是一个新兴标准，专注于将大型语言模型 (LLM) 与数据和外部资源连接起来。

Agent2Agent (A2A) 协议旨在标准化 AI 代理之间的通信，特别是那些部署在外部系统中的代理。A2A 定位为 MCP 的补充，解决了代理交互中独特但相关的方面。

MCP 的重点：降低将代理与工具和数据连接起来的复杂性。工具通常是无状态的，并执行特定的预定义功能（例如，计算器、数据库查询）。
A2A 的重点：使代理能够在其原生模态中进行协作，允许它们作为代理（或作为用户）进行通信，而不是受限于工具般的交互。这使得复杂的、多轮交互成为可能，代理可以推理、规划并将任务委托给其他代理。例如，这有助于多轮交互，例如在下订单时涉及协商或澄清的交互。

ADK + MCP

将代理封装为简单工具的做法从根本上具有局限性，因为它未能捕捉代理的全部功能。这方面的关键区别在帖子《为什么代理不是工具》中进行了探讨。

有关更深入的比较，请参阅《A2A 和 MCP 比较》文档。

A2A 和 ADK¶

代理开发工具包 (ADK) 是 Google 开发的开源代理开发工具包。A2A 是一种代理通信协议，可实现代理之间的通信，无论用于其构建的框架如何（例如，ADK、LangGraph 或 Crew AI）。ADK 是一个灵活的模块化框架，用于开发和部署 AI 代理。虽然针对 Gemini AI 和 Google 生态系统进行了优化，但 ADK 独立于模型，独立于部署，并旨在与其他框架兼容。

A2A 请求生命周期¶

A2A 请求生命周期是一个序列，详细说明了请求遵循的四个主要步骤：代理发现、身份验证、sendMessage API 和 sendMessageStream API。下图更深入地探讨了操作流程，说明了客户端、A2A 服务器和身份验证服务器之间的交互。

sequenceDiagram
    participant Client
    participant A2A Server
    participant Auth Server

    rect rgb(240, 240, 240)
    Note over Client, A2A Server: 1. Agent Discovery
    Client->>A2A Server: GET agent card eg: (/.well-known/agent-card)
    A2A Server-->>Client: Returns Agent Card
    end

    rect rgb(240, 240, 240)
    Note over Client, Auth Server: 2. Authentication
    Client->>Client: Parse Agent Card for securitySchemes
    alt securityScheme is "openIdConnect"
        Client->>Auth Server: Request token based on "authorizationUrl" and "tokenUrl".
        Auth Server-->>Client: Returns JWT
    end
    end

    rect rgb(240, 240, 240)
    Note over Client, A2A Server: 3. sendMessage API
    Client->>Client: Parse Agent Card for "url" param to send API requests to.
    Client->>A2A Server: POST /sendMessage (with JWT)
    A2A Server->>A2A Server: Process message and create task
    A2A Server-->>Client: Returns Task Response
    end

    rect rgb(240, 240, 240)
    Note over Client, A2A Server: 4. sendMessageStream API
    Client->>A2A Server: POST /sendMessageStream (with JWT)
    A2A Server-->>Client: Stream: Task (Submitted)
    A2A Server-->>Client: Stream: TaskStatusUpdateEvent (Working)
    A2A Server-->>Client: Stream: TaskArtifactUpdateEvent (artifact A)
    A2A Server-->>Client: Stream: TaskArtifactUpdateEvent (artifact B)
    A2A Server-->>Client: Stream: TaskStatusUpdateEvent (Completed)
    end

下一步¶

了解构成 A2A 协议基础的关键概念。