A2A：开启智能体协作的新时代

随着人工智能技术的飞速发展，智能体（Agent）已经成为 AI 应用的重要组成部分。然而，不同智能体之间的协作一直是一个挑战。Google 最近推出的 A2A（Agent-to-Agent）协议，为智能体之间的无缝协作提供了标准化的解决方案。本文将介绍 A2A 协议及其与 MCP（Model Context Protocol）的关系，探讨这两种协议如何共同构建未来的智能体生态系统。

一、A2A 协议概述：智能体协作的开放标准

在当今快速发展的 AI 领域，智能体（Agent）已成为执行复杂任务的关键组件。然而，随着各种 AI 智能体的出现，它们往往基于不同的框架构建，由不同的供应商开发，这导致它们之间难以有效地通信和协作。A2A 协议应运而生，旨在解决这一关键挑战。

1.1 A2A 的定义与目标

A2A（Agent-to-Agent）是一个开放的协议标准，旨在解决当前智能体生态系统中的互操作性问题。A2A 协议的核心目标是让这些独立的、不透明的智能体能够彼此无缝协作，同时也能与用户进行有效交互。这种标准化的协议为智能体之间的协作提供了基础，使得不同智能体可以共同完成复杂任务，而无需共享内存、资源或工具。

1.2 A2A 的主要特点

A2A 协议具有以下五个关键特点，使其成为智能体协作的理想解决方案：

1. 无缝智能体协作：提供标准协议，使不同框架和供应商构建的自主、不透明的智能体能够有效地相互通信和协作，解决当前智能体互操作性的缺乏问题。

2. 简化企业智能体集成：为将智能体集成到现有企业应用程序提供了简单直接的方法，使企业能够在其技术环境中充分利用智能体能力。

3. 支持关键企业需求：提供安全、企业级智能体生态系统所需的核心功能，包括能力发现、用户体验协商、任务和状态管理以及安全协作。

4. 动态多模态通信：支持智能体之间的动态、多模态通信，而无需共享内存、资源和工具。

5. 社区驱动的开放标准：A2A 是一个由社区驱动的开放标准，鼓励广泛参与和贡献。

二、A2A 的企业就绪性：安全与集成

在企业环境中部署任何新技术时，安全性、可靠性和与现有系统的集成能力都是关键考虑因素。A2A 协议在设计时充分考虑了这些企业级需求，特别是在安全性、身份认证、授权和可观察性等方面。

2.1 企业级安全设计

A2A 不会发明新的企业安全标准，而是无缝集成现有的基础设施。这种设计理念使企业能够利用已有的安全投资，同时享受智能体协作带来的创新。

A2A 将企业智能体建模为标准的、基于 HTTP 的企业应用程序，因此依赖于企业标准的身份验证、安全性、隐私、跟踪和监控。这是可能的，因为 A2A 智能体是不透明的，不共享工具或资源（因此适用"单一应用程序"客户端/服务器最佳实践）。

实际上，A2A 将大多数企业关注点排除在协议之外，而是要求具有开放身份验证和开放跟踪支持的企业级 HTTP。实施者应遵循与应用程序和用户级安全相关的所有企业最佳实践。

2.2 安全通信机制

2.2.1 传输层安全

A2A 建立在 HTTP 之上，任何生产环境的安装都应该要求使用现代 TLS 密码的 HTTPS。这确保了智能体之间通信的机密性和完整性，防止数据在传输过程中被窃取或篡改。

2.2.2 服务器身份

A2A 服务器以由知名证书颁发机构签名的数字证书形式在 TLS 协商过程中呈现其身份。A2A 客户端应在建立连接期间验证服务器身份。这种验证机制确保客户端只与合法的服务器建立连接，防止中间人攻击和身份欺骗。

2.3 身份认证与授权

2.3.1 客户端和用户身份

A2A 架构中没有用户或客户端标识符的概念。相反，A2A 通过协议传达身份验证要求（方案和材料）。客户端负责与适当的身份验证机构（在 A2A 之外）协商并检索/存储凭证材料（如 OAuth 令牌）。这些凭证材料将在 HTTP 标头中传输，而不是在任何 A2A 有效负载中。

不同的身份验证协议和服务提供商有不同的要求，单个请求可能需要在特定于方案的标头中包含多个标识符和身份。建议客户端在向 A2A 服务器发出请求时始终提供客户端身份（代表客户端智能体）和用户身份（代表其用户）。

注意：多身份联合是一个开放的讨论话题。例如，用户 U 正在与需要 A 系统标识符的智能体 A 一起工作。如果智能体 A 然后依赖于需要 B 系统标识符的工具 B 或智能体 B，则用户可能需要在单个请求中提供 A 系统和 B 系统的身份。（假设 A 系统是企业 LDAP 身份，B 系统是 SaaS 提供商身份）。

目前建议，如果智能体 A 要求用户/客户端为任务的一部分提供替代身份，它会在 INPUT-REQUIRED 状态下发送更新，其中包含特定的身份验证要求（与 AgentCard 的身份验证要求结构相同）给客户端。然后，客户端在 A2A 之外，也在 A 系统之外，与 B 系统的授权机构协商以获取凭证材料。这些材料（如令牌）可以通过智能体 A 传递给智能体 B。智能体 B 在与其上游系统通信时将进行交换。

2.3.2 多身份联合认证工作流程

在企业环境中，多身份联合认证是一个常见的挑战。当一个智能体需要与多个系统交互，而这些系统各自有不同的身份认证要求时，就需要一种机制来协调这些不同的身份。

以下是多身份联合认证的典型工作流程：

1. 用户初始请求：用户通过客户端智能体发起请求，客户端智能体首先获取 A 系统的身份认证。
2. A 系统认证：客户端智能体使用 A 系统的认证服务获取令牌，并将其包含在对智能体 A 的请求中。
3. 需要 B 系统资源：智能体 A 在处理请求时，确定需要访问 B 系统的资源。
4. 请求 B 系统身份：智能体 A 返回 INPUT-REQUIRED 状态，要求客户端提供 B 系统的身份认证。
5. B 系统认证：客户端智能体与 B 系统的认证服务交互，获取 B 系统的令牌。
6. 提供 B 系统令牌：客户端将 B 系统的令牌提供给智能体 A。
7. 智能体间传递令牌：智能体 A 将 B 系统的令牌传递给智能体 B，以访问 B 系统的资源。
8. 完成请求：智能体 B 验证令牌，处理请求，并将结果返回给智能体 A，最终通过客户端智能体返回给用户。

下面是多身份联合认证的流程图：

目前建议，如果智能体 A 要求用户/客户端为任务的一部分提供替代身份，它会在 INPUT-REQUIRED 状态下发送更新，其中包含特定的身份验证要求（与 AgentCard 的身份验证要求结构相同）给客户端。然后，客户端在 A2A 之外，也在 A 系统之外，与 B 系统的授权机构协商以获取凭证材料。这些材料（如令牌）可以通过智能体 A 传递给智能体 B。智能体 B 在与其上游系统通信时将进行交换。

2.3.3 多身份联合认证的挑战与解决方案

多身份联合认证面临以下挑战：

1. 身份映射：不同系统之间的身份可能没有直接的映射关系。
2. 令牌格式：不同系统使用的令牌格式和认证协议可能不同。
3. 权限范围：不同系统的权限模型和范围定义可能不同。
4. 令牌生命周期：不同系统的令牌有效期和刷新机制可能不同。

解决这些挑战的方法包括：

1. 身份联合服务：建立一个中央服务，管理不同系统之间的身份映射。
2. 令牌转换：提供令牌格式之间的转换机制。
3. 权限映射：建立不同系统权限模型之间的映射关系。
4. 统一令牌管理：实现统一的令牌生命周期管理机制。

A2A 协议通过提供标准化的身份认证需求表达方式，为解决多身份联合认证问题提供了基础。

2.4 客户端认证

A2A 服务器应在其智能体卡片中发布支持和所需的身份验证协议。这些协议应该是标准的 OpenAPI 身份验证格式之一（如 API 密钥、OAuth、OIDC 等），但可以扩展到客户端和服务器都支持的另一种协议。

各个身份验证协议有自己的获取、刷新和质询凭证材料（如持有者或会话令牌）的机制。凭证获取和维护过程被视为 A2A 外部的过程。

A2A 服务器应该对每个请求进行身份验证，并使用标准 HTTP 响应代码（401、403）以及特定于身份验证协议的标头和正文（如带有 WWW-Authenticate 标头的 HTTP 401 响应，指示所需的身份验证方案，或在众所周知的路径上的 OIDC 发现文档）拒绝或质询请求。

2.4.1 身份验证最佳实践

在实施 A2A 协议的身份验证机制时，建议遵循以下最佳实践：

1. 使用标准协议：优先选择广泛采用的身份验证协议，如 OAuth 2.0、OpenID Connect 或 SAML，而不是自定义解决方案。

2. 令牌管理：实施安全的令牌存储、传输和刷新机制，包括适当的过期时间和撤销策略。

3. 最小权限原则：为每个智能体请求分配最小必要的权限，避免过度授权。

4. 多因素认证：在敏感操作或高风险环境中，考虑实施多因素认证。

5. 审计日志：记录所有身份验证尝试和授权决策，以便进行安全审计和问题排查。

授权和数据隐私

A2A 服务器应该基于用户和应用程序身份对请求进行授权。我们建议各个智能体至少在两个方面管理访问：

• 技能
  智能体应通过智能体卡片以技能的形式宣传其能力。建议智能体基于每个技能进行授权（例如，OAuthScope ‘foo-read-only’ 可以将访问限制为仅 ‘generateRecipe’ 技能）。

• 工具（操作和数据）
  建议智能体通过将敏感数据或操作放在工具后面来限制对它们的访问。当智能体流程或模型需要访问此数据时，智能体应基于应用程序+用户权限授权对工具的访问。我们强烈建议将 API 管理与工具访问结合使用。

数据隐私考虑

在实施 A2A 协议时，应特别注意以下数据隐私方面：

1. 数据最小化：智能体应只收集和处理完成任务所需的最少数据。

2. 数据分类：对数据进行分类，并根据敏感度级别应用不同的保护措施。

3. 数据保留：制定明确的数据保留政策，并在不再需要数据时安全删除。

4. 数据加密：在传输和存储过程中对敏感数据进行加密。

5. 用户同意：在收集和处理用户数据之前，获取明确的用户同意。

6. 数据访问控制：实施细粒度的访问控制，确保只有授权的智能体和用户可以访问特定数据。

7. 合规性：确保数据处理符合相关法规，如 GDPR、CCPA 等。

跟踪和可观察性

由于所有 A2A 请求都是"标准"HTTP 请求，客户端和服务器都应使用其企业标准工具和基础设施，理想情况下，这些工具和基础设施会添加适当的检测标头并将事件写入标准日志和事件队列。

可观察性最佳实践

为了确保 A2A 系统的可靠性、性能和安全性，建议实施以下可观察性最佳实践：

1. 分布式跟踪：使用 OpenTelemetry 或类似框架实现跨智能体的分布式跟踪，以便了解请求如何在多个智能体之间流动。

2. 结构化日志记录：采用结构化日志格式，包含关键元数据如请求 ID、用户 ID、智能体 ID 等，便于搜索和分析。

3. 指标收集：收集关键性能指标，如请求延迟、错误率、资源使用情况等，以监控系统健康状况。

4. 异常监控：实施异常检测机制，及时发现和响应异常行为。

5. 审计日志：记录所有敏感操作，包括身份验证、授权决策和数据访问，以便进行安全审计。

6. 健康检查：提供健康检查端点，以便监控系统能够检测智能体的可用性。

7. 可视化和告警：使用仪表板可视化关键指标，并设置适当的告警阈值，以便在问题发生时及时通知。

通过实施这些可观察性最佳实践，企业可以确保其 A2A 系统的可靠性、安全性和性能，同时也便于问题排查和系统优化。

三、A2A 与 MCP：两种互补的协议

在理解 A2A 时，我们需要了解它与 MCP（Model Context Protocol）的关系。这两种协议虽然有所不同，但它们是互补的，共同构成了一个完整的智能体生态系统。

3.1 A2A 和 MCP 的关系：智能体生态系统的两个维度

想象一个智能体生态系统，就像一个由多个专业公司组成的商业网络。在这个网络中：

• MCP 就像是公司内部的基础设施：每个公司（智能体）都需要内部工具、资源和系统来完成自己的工作。MCP 协议使智能体能够连接到这些工具和资源，就像公司内部的 ERP 系统、数据库和专业软件一样。

• A2A 就像是公司之间的商业合作协议：当不同的公司需要合作完成一个大型项目时，它们需要一种标准化的方式来沟通和协作，而不需要共享内部系统或资源。A2A 协议就是这样一种标准，使不同的智能体能够协作，就像不同公司之间的商业合同和通信协议一样。

以一个具体的例子来说明：假设我们有三个智能体 - 一个研究智能体、一个写作智能体和一个设计智能体，它们需要共同完成一个项目报告。

1. 各自的内部能力（MCP）：

   • 研究智能体使用 MCP 连接到搜索引擎、学术数据库和数据分析工具
   • 写作智能体使用 MCP 连接到语法检查工具、文本编辑器和内容管理系统
   • 设计智能体使用 MCP 连接到图形设计软件、图像库和排版工具

2. 智能体之间的协作（A2A）：

   • 研究智能体完成研究后，通过 A2A 协议将研究结果传递给写作智能体
   • 写作智能体撰写报告后，通过 A2A 协议将文本内容传递给设计智能体
   • 设计智能体完成排版和设计后，通过 A2A 协议将最终成果返回给用户

在这个过程中，每个智能体都保持了自己的独立性和专业性，它们不需要了解其他智能体如何内部工作或使用什么工具，只需要通过标准化的 A2A 协议进行通信和协作。

上图展示了这种关系：每个智能体通过 MCP 连接到自己的工具和资源，同时通过 A2A 协议与其他智能体进行协作。这种架构使得智能体生态系统既灵活又强大，能够应对各种复杂的任务和场景。

3.2 MCP（Model Context Protocol）

MCP 专注于工具和资源的连接：

• 将智能体连接到工具、API 和资源，具有结构化的输入/输出
• Google ADK（Agent Developer Kit）支持 MCP 工具，使各种 MCP 服务器能够与智能体一起使用
• 主要解决的是智能体与外部工具、资源的交互问题

3.3 A2A（Agent-to-Agent Protocol）

A2A 专注于智能体之间的协作：

• 不同智能体之间的动态、多模态通信，无需共享内存、资源和工具
• 由社区驱动的开放标准
• 提供了使用 Google ADK、LangGraph、Crew.AI 等框架的示例
• 主要解决的是不同智能体之间的协作问题

简而言之，MCP 让智能体能够使用各种工具和资源，而 A2A 则让不同的智能体能够相互协作。这两种协议共同构成了一个完整的智能体生态系统，使得智能体不仅能够利用外部资源，还能与其他智能体协作完成复杂任务。

四、A2A 的应用场景

A2A 协议的出现，为智能体协作打开了新的可能性。以下是一些潜在的应用场景：

4.1 多智能体协作系统

多个专业智能体可以协同工作，共同解决复杂问题。例如，在软件开发中，一个智能体负责需求分析，一个负责代码生成，一个负责测试，它们通过 A2A 协议协作，完成端到端的软件开发流程。

4.2 企业应用集成

A2A 协议使得企业可以轻松地将智能体集成到现有的应用程序中。不同部门的智能体可以协作，共享信息，提高整体效率。例如，销售部门的智能体可以与市场部门的智能体协作，共同制定营销策略。

4.3 个人助理生态系统

用户可以拥有多个专业的个人助理智能体，它们通过 A2A 协议协作，为用户提供全方位的服务。例如，一个智能体负责日程安排，一个负责信息检索，一个负责内容创作，它们协同工作，满足用户的各种需求。

4.4 教育和培训

在教育领域，不同的教学智能体可以协作，为学生提供个性化的学习体验。例如，一个智能体负责讲解概念，一个负责提供练习，一个负责评估学习效果，它们通过 A2A 协议协作，提供全面的教育服务。

五、智能体卡片（Agent Card）

在 A2A 协议中，智能体卡片（Agent Card）是支持 A2A 的远程智能体必须以 JSON 格式发布的描述文件，用于描述智能体的能力、技能和身份验证机制。客户端使用智能体卡片信息来识别最适合执行任务的智能体，并利用 A2A 与该远程智能体进行通信。

5.1 智能体卡片的表示

智能体卡片包含以下关键信息：

1. 基本信息：包括智能体的名称、描述、版本、URL、提供者等。
2. 能力（Capabilities）：描述智能体支持的功能，如流式传输、推送通知等。
3. 身份验证要求：指定与智能体交互所需的身份验证方案。
4. 默认交互模式：智能体支持的输入/输出模式（MIME 类型）。
5. 技能（Skills）：智能体可以执行的一组能力，每个技能都有唯一标识符、名称、描述、标签和示例。

以下是智能体卡片的数据结构：

 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
27
28
29
30
31
32
33

{
  "name": "智能体名称",
  "description": "智能体描述",
  "url": "智能体URL",
  "provider": {
    "organization": "提供组织",
    "url": "组织URL"
  },
  "version": "版本号",
  "documentationUrl": "文档URL",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": ["认证方案"],
    "credentials": "凭证信息"
  },
  "defaultInputModes": ["支持的输入MIME类型"],
  "defaultOutputModes": ["支持的输出MIME类型"],
  "skills": [
    {
      "id": "技能ID",
      "name": "技能名称",
      "description": "技能描述",
      "tags": ["标签1", "标签2"],
      "examples": ["示例1", "示例2"],
      "inputModes": ["特定技能支持的输入MIME类型"],
      "outputModes": ["特定技能支持的输出MIME类型"]
    }
  ]
}

5.2 智能体卡片示例

以下是一个 Google Maps 智能体的卡片示例：

 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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

{
  "name": "Google Maps Agent",
  "description": "Plan routes, remember places, and generate directions",
  "url": "https://maps-agent.google.com",
  "provider": {
    "organization": "Google",
    "url": "https://google.com"
  },
  "version": "1.0.0",
  "authentication": {
    "schemes": "OAuth2"
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/html"],
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "route-planner",
      "name": "Route planning",
      "description": "Helps plan routing between two locations",
      "tags": ["maps", "routing", "navigation"],
      "examples": [
        "plan my route from Sunnyvale to Mountain View",
        "what's the commute time from Sunnyvale to San Francisco at 9AM",
        "create turn by turn directions from Sunnyvale to Mountain View"
      ],
      "outputModes": ["application/html", "video/mp4"]
    },
    {
      "id": "custom-map",
      "name": "My Map",
      "description": "Manage a custom map with your own saved places",
      "tags": ["custom-map", "saved-places"],
      "examples": [
        "show me my favorite restaurants on the map",
        "create a visual of all places I've visited in the past year"
      ],
      "outputModes": ["application/html"]
    }
  ]
}

这个示例展示了一个 Google Maps 智能体，它提供路线规划和自定义地图两种技能，支持纯文本输入和 HTML/视频输出，并使用 OAuth2 进行身份验证。

六、智能体发现（Agent Discovery）

A2A 协议中的智能体卡片（Agent Card）标准化了在发现过程中共享数据的格式，但是发现这些智能体卡片的方式有很多种。以下是目前的几种主要方式：

6.1 开放发现（Open Discovery）

推荐企业在一个众所周知的路径上托管他们的智能体卡片：https://DOMAIN/.well-known/agent.json。客户端将使用 DNS 解析已知或找到的域名，向该路径发送简单的 GET 请求，并接收智能体卡片。

这将使网络爬虫和应用程序能够轻松发现已知或配置域名的智能体。这实际上将发现过程简化为"找到一个域名"。

6.2 精选发现（Curated Discovery，基于注册表）

预计企业应用程序将通过目录界面提供精选的智能体注册表。这为更多企业场景打开了大门，例如由管理员策划的公司特定或团队特定的智能体注册表。

A2A 团队正在考虑将注册表支持添加到协议中 - 如果您认为这作为标准有价值，请向他们提供反馈。

6.3 私有发现（Private Discovery，基于 API）

无疑会有私有的"智能体商店"或专有智能体，其中卡片在自定义 API 后面交换。

A2A 团队目前不考虑将私有发现 API 作为 A2A 关注点 - 如果您认为这作为标准有价值，请向他们提供反馈。

6.4 保护智能体卡片（Securing Agent Cards）

智能体卡片可能包含敏感信息。实施者可能决定将其智能体卡片置于需要身份验证和授权的控制之后。例如，在组织内部，即使是在众所周知的路径上的开放发现也可能受到 mTLS 的保护，并限制特定客户端访问。注册表和私有发现 API 应该要求身份验证，并为不同的身份返回不同的工件。

需要注意的是，实施者可能在其智能体卡片中包含凭证信息（如 API 密钥）。建议这些信息在没有身份验证的情况下永远不可用。

七、A2A 的核心对象

A2A 协议定义了几个核心对象，用于实现客户端和远程智能体之间的通信。这些对象构成了 A2A 协议的基础，使得智能体之间能够有效地协作完成任务。

7.1 任务（Task）

任务是一个有状态的实体，允许客户端和远程智能体实现特定的结果并生成结果。客户端和远程智能体在任务内交换消息，远程智能体生成工件作为结果。

任务总是由客户端创建，状态总是由远程智能体确定。如果客户端需要，多个任务可以是同一会话的一部分（由可选的 sessionId 表示）。

任务的状态可以是以下之一：

• submitted（已提交）
• working（工作中）
• input-required（需要输入）
• completed（已完成）
• canceled（已取消）
• failed（失败）
• unknown（未知）

以下是任务对象的数据结构：

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

{
  "id": "任务ID",
  "sessionId": "会话ID",
  "status": {
    "state": "任务状态",
    "message": "状态消息",
    "timestamp": "时间戳"
  },
  "history": ["历史消息"],
  "artifacts": ["生成的工件"],
  "metadata": {}
}

7.2 工件（Artifact）

智能体生成工件作为任务的最终结果。工件是不可变的，可以命名，并且可以有多个部分。流式响应可以向现有工件附加部分。

单个任务可以生成多个工件。例如，“创建网页"可能会创建单独的 HTML 和图像工件。

以下是工件对象的数据结构：

1
2
3
4
5
6
7
8
9

{
  "name": "工件名称",
  "description": "工件描述",
  "parts": ["工件部分"],
  "metadata": {},
  "index": 0,
  "append": false,
  "lastChunk": false
}

7.3 消息（Message）

消息包含任何不是工件的内容。这可以包括智能体思考、用户上下文、指令、错误、状态或元数据等内容。

客户端的所有内容都以消息的形式出现。智能体发送消息以传达状态或提供指令（而生成的结果则作为工件发送）。

消息可以有多个部分，表示不同的内容片段。例如，用户请求可能包括用户的文本描述，然后是客户端用作上下文的多个文件。

以下是消息对象的数据结构：

1
2
3
4
5

{
  "role": "user或agent",
  "parts": ["消息部分"],
  "metadata": {}
}

7.4 部分（Part）

部分是客户端和远程智能体之间作为消息或工件的一部分交换的完整内容片段。每个部分都有自己的内容类型和元数据。

A2A 支持三种类型的部分：

1. 文本部分（TextPart）：包含纯文本内容
2. 文件部分（FilePart）：包含文件内容，可以是字节数据或 URI
3. 数据部分（DataPart）：包含结构化数据

以下是部分对象的数据结构：

 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

// 文本部分
{
  "type": "text",
  "text": "文本内容",
  "metadata": {}
}

// 文件部分
{
  "type": "file",
  "file": {
    "name": "文件名",
    "mimeType": "MIME类型",
    "bytes": "base64编码内容",
    // 或者
    "uri": "文件URI"
  },
  "metadata": {}
}

// 数据部分
{
  "type": "data",
  "data": {},
  "metadata": {}
}

7.5 推送通知（Push Notifications）

A2A 支持一种安全的通知机制，通过该机制，智能体可以通过 PushNotificationService 在连接会话之外通知客户端更新。在企业内部和跨企业，智能体验证通知服务的身份、向服务验证自身身份并提供将通知与执行任务关联的标识符至关重要。

以下是推送通知配置的数据结构：

1
2
3
4
5
6
7
8

{
  "url": "通知URL",
  "token": "任务/会话唯一令牌",
  "authentication": {
    "schemes": ["认证方案"],
    "credentials": "凭证信息"
  }
}

八、A2A 的实现和示例

A2A 协议目前处于开发阶段，Google 已经提供了初步的规范、文档和示例代码。以下是一些可用的资源：

1. 示例 A2A 客户端/服务器：提供了基本的 A2A 客户端和服务器实现，可以用于理解 A2A 协议的工作原理。

2. 多智能体 Web 应用：展示了如何在 Web 环境中使用 A2A 协议构建多智能体应用。

3. 命令行界面（CLI）：提供了通过命令行与 A2A 智能体交互的工具。

4. 示例智能体：包括使用 Google ADK、CrewAI、LangGraph 和 Genkit 等框架构建的示例智能体。

这些资源为开发者提供了学习和实验 A2A 协议的机会，有助于推动 A2A 生态系统的发展。

九、A2A 的未来展望

A2A 协议仍处于早期阶段，预计将根据社区反馈不断发展和完善。Google 表示，他们将继续更新规范、示例和库，当规范和示例达到生产质量时，将宣布 1.0 版本并维护稳定的发布版本。

随着 A2A 协议的成熟，我们可以期待：

1. 更广泛的采用：更多的智能体框架和平台将支持 A2A 协议，形成一个繁荣的生态系统。

2. 更丰富的应用场景：A2A 协议将在更多领域得到应用，推动智能体技术的创新和发展。

3. 更完善的标准：A2A 协议将根据实际应用需求不断完善，形成更加成熟的标准。

4. 更多的工具和库：将出现更多支持 A2A 协议的开发工具和库，降低开发者的使用门槛。

十、结语

A2A 协议的出现，标志着智能体技术进入了一个新的阶段。通过提供标准化的智能体协作协议，A2A 为智能体之间的无缝协作铺平了道路，使得构建复杂的多智能体系统成为可能。

与 MCP 协议相互补充，A2A 和 MCP 共同构成了一个完整的智能体生态系统，为 AI 应用的发展提供了强大的基础设施。随着这些协议的不断发展和完善，我们可以期待看到更多创新的 AI 应用出现，为各行各业带来变革。

如果你对 A2A 协议感兴趣，可以访问 A2A GitHub 仓库 了解更多信息，或者阅读 A2A 博客文章 了解 A2A 的设计原则和支持 A2A 的外部合作伙伴。