智能体间通信协议（A2A）

现代 AI 系统常由多个专门智能体共同处理复杂任务。例如，Amazon 风格的购物助手可以分别设置商品搜索、推荐、库存检查和订单处理智能体。这些组件可能由不同团队使用不同框架构建，因此需要明确的通信方式。本课介绍 Agent-to-Agent（A2A）通信及协议设计，通过标准方式支持智能体协作。

此前课程已经使用 LangGraph、Agentic RAG 等构建智能体，并实现库存和用户评论搜索。本周将使用 CrewAI 增加购物车或订单智能体，同时研究如何连接这些组件，以及 A2A 通信的含义和必要性。

什么是 Agent-to-Agent 通信

A2A 指自主 AI 智能体之间直接交换消息。一个智能体可以请求另一个完成任务或提供信息，类似网络中的微服务和 API 交互。接收方作为具有内部决策能力的服务，接受请求、执行任务，并返回结果。

Google 于 2025 年 4 月与多家合作伙伴发布 Agent2Agent 开放协议，目标是让不同平台和框架中的智能体通过共同规则安全协作。智能体能够作为独立参与者交换任务，这对于组织跨多个 AI 组件的复杂流程很重要。

完整 A2A 协议包括能力发现、支持多种内容类型的结构化消息、长时间任务的生命周期与进度更新，以及认证和安全机制。协议基于广泛使用的网络技术；具体版本可以提供 JSON-RPC、HTTP/JSON 等绑定。智能体通过标准网络基础设施交换协议消息，复用已有的可靠性和安全措施。

为什么需要 A2A 通信

多个专门智能体能够提高模块化程度，同时带来协调问题。缺少共同协议时，每对智能体之间可能都需要自定义 HTTP 调用、JSON 格式和集成逻辑，维护成本随连接数量增加。

共同协议使兼容智能体能够直接交互，减少逐项编写适配器的工作。这对异构系统尤其重要：LangGraph 的 Python 智能体可以连接另一个环境中的 CrewAI 智能体。不同团队、架构甚至组织提供的组件，都可以通过约定接口协作。

购物助手最终可能包含 Supervisor、Ordering、Shopping Cart 和 Product Search 等角色。监督者需要将子任务交给专家，再汇集结果。A2A 为每个专家提供明确服务接口，例如向 Ordering Agent 提交商品订单任务，并接收结构化结果。系统由此能够通过标准消息完成委派。

异构智能体之间的互操作

互操作意味着不同系统能够共同工作并理解彼此。A2A 通过消息格式和交互规则连接不同框架或语言实现的智能体。

例如，LangGraph 管理者可以调用 CrewAI、Google ADK 或其他框架构建的服务。内部逻辑可以完全不同，只要双方遵循同一协议版本及对应消息结构，就可以交换请求和结果。

互操作通常需要考虑以下方面。

• 数据格式：采用 JSON 等共同格式，并约定请求与响应 schema。
• 传输协议：采用统一的 HTTP(S) 或 RPC 方式发送网络消息。
• 身份与角色：明确智能体身份及公开能力，支持发现和路由。A2A 使用 Agent Card 描述能力及服务端点。
• 共同语义：双方必须理解任务名称及字段含义，例如 PlaceOrder 的请求参数和结果要求。

这些约定使异构智能体可以组成相互连接的系统。用户看到的是能够处理完整请求的购物助手，无需了解内部如何交接任务。统一接口也能减少组件之间的直接依赖。

设计简化的智能体通信协议

以下使用一个简化教学协议说明结构化消息、发送者身份、任务意图和参数传递。此格式属于应用自行约定的协议；正式 A2A 实现需要使用对应版本的官方 schema。示例假设通过 HTTP 发送 JSON，也可以采用其他传输方式。

简化消息可以包含以下字段。

• sender：发送者名称或 ID，例如 LangGraphSupervisorAgent，用于日志及回复路由。身份认证仍需由实际安全机制完成。
• recipient：可选接收者。HTTP 端点通常已经确定接收方，但经过中间组件或同一服务提供多个智能体时，显式标记较有帮助，例如 CrewAIOrderingAgent。
• task 或 action：请求操作的短名称，例如 PlaceOrder、GetReviews 或 CheckInventory，类似 API 方法名。
• parameters 或 payload：完成任务所需的数据，例如商品 ID、数量和用户信息。接收方可以在内部调用多个工具完成任务。
• task_id：教学协议中的可选关联标识，用于匹配请求、结果和重试。正式 A2A 对任务、消息及传输请求标识分别规定其创建和使用方式。
• 其他可选元数据：例如时间戳、优先级或单向通知标记。基础示例暂不需要这些字段。

请求消息示例：

{
  "sender": "LangGraphSupervisorAgent",
  "recipient": "CrewAIOrderingAgent",
  "task": "PlaceOrder",
  "parameters": {
    "item_id": "SKU-12345",
    "quantity": 2,
    "user_id": "user-001"
  }
}

这条消息请求 Ordering Agent 代表 user-001 为 SKU-12345 创建两件商品的订单。字段明确发送者、接收者、所需操作和任务参数。

响应消息示例：Ordering Agent 完成请求后，可以返回以下 JSON。

{
  "sender": "CrewAIOrderingAgent",
  "recipient": "LangGraphSupervisorAgent",
  "task": "PlaceOrder",
  "status": "success",
  "result": {
    "order_id": "ORDER-12345",
    "status": "confirmed",
    "estimated_delivery": "2025-08-01"
  }
}

响应说明发送方，并可选地标记接收者；在 HTTP 响应中，接收者通常由原请求确定。task 关联操作，status 表示成功或错误。成功时，result 包含订单号、确认状态和预计配送日期等信息。失败时可以返回 "status": "error"，以及说明缺货等原因的 error_message。

这一教学格式体现以下概念。

• 智能体身份：标记消息的发送者和接收者，支持路由。
• 任务委派：task 明确需要另一智能体完成的工作，监督者可以将复杂请求分为多个任务。
• 结构化数据：JSON 支持嵌套参数和结果，便于解析与处理。正式协议也可以承载多模态内容及流式更新。
• 通用格式：双方约定新任务名称、参数和结果后，可以沿用相同消息结构。

生产设计中的挑战

生产环境中的通信还需要考虑状态、错误、监控和安全。

无状态与有状态通信

无状态交互中，每次请求提供完成操作所需的全部信息，接收者无需记住以前的请求。HTTP 请求可以按这种方式处理，便于负载均衡；一个实例不可用时，其他实例能够处理后续请求。

有状态交互在多条消息之间保留任务背景。例如，长时间任务通过任务 ID 关联进度、部分结果和补充输入。A2A v1.0.1 的任务 ID 由服务端创建，客户端通过 taskId 引用已有任务；messageId 由消息创建方生成。任务和上下文标识使不同更新能够归属同一任务。

快速的一次请求与响应通常适合无状态设计；长时间研究、多轮澄清或流式结果则需要保存相关状态。例如，监督者提交任务后，可以查询进度、接收更新，或提供后续参数。

应根据需求明确状态保存者和生命周期：远程智能体保存上下文，还是调用者每次重新发送。也可以采用混合设计，多数任务一次完成，长任务先创建标识，再通过后续调用查询状态或获取结果。

错误处理与重试

网络故障、服务不可用、输入不合法或内部错误都可能使调用失败。可靠设计需要以下机制。

• 错误响应：调用者始终检查状态并处理原因。例如，Ordering Agent 返回缺货后，监督者可以询问用户是否选择其他商品。
• 超时：设置合理等待时间。超时表示调用者未及时收到结果；具有副作用的操作可能已经执行，因此不能直接推断订单没有创建。
• 重试与幂等：暂时网络问题可以重试，但重复 PlaceOrder 不应创建多份订单。可以使用唯一业务请求标识或其他幂等机制，由接收者识别已处理请求，并核查不确定结果。
• 替代处理：主服务无法完成任务时，可以使用具备相同能力的其他智能体，但需要发现和路由逻辑，并确保不会重复执行已经成功的操作。

日志与监控

多智能体通信增加调试复杂度，因此需要清楚记录每次交互。

• 请求与响应：至少记录必要概要，调试模式可以记录适当的详细信息，以便还原消息往来。
• 关联 ID：双方日志使用共同请求、任务或订单标识，追踪任务经过的多个系统。
• 监控指标：记录委派数量、成功率、失败率和响应延迟，识别性能瓶颈，例如订单服务平均响应时间持续增加。
• 可观测性工具：网关或中间层可以捕获分布式追踪，利用传输头等机制关联不同服务，显示请求传播时间线。
• 审计：涉及敏感任务时，记录谁提出请求以及最终执行结果。

日志应便于人类阅读，也应支持机器筛选，例如使用 JSON 或键值记录，同时避免记录敏感内容。

其他考虑

• 安全：验证智能体身份并授权具体任务。Agent Card 可以声明所需认证方案，生产通信应使用适当的安全传输和凭据管理。Ordering Agent 必须检查调用者是否有权执行请求；消息中的 sender 字符串不能代替认证。
• Schema 演进：修改消息格式或新增任务时，需要版本管理及兼容策略。例如，声明协议版本，并明确未知字段的处理方式。
• 性能：序列化与网络往返会增加开销。通信过于频繁时，可以结合任务或缓存结果。
• 测试：将智能体接口视为公共 API，测试给定请求能否返回预期结果，并检查监督者如何处理成功、失败和异常响应。测试替身可用于隔离接口测试，实际服务集成仍需独立验证。

A2A 协议的角色与发现机制

正式协议中，智能体可以在不同交互中担任客户端或服务端。同一个 Agent A 或 Agent B 都可以发起请求，也可以接受任务。

• User：提出目标或请求的人类用户，也可以是外部服务。
• A2A Client：代表用户构造任务请求，发现合适远程智能体，并使用协议发送消息。
• A2A Server：提供符合协议的服务接口，接收任务，返回结果和状态更新。

Agent Card 与服务发现

通信之前，客户端需要知道远程智能体的能力和访问方式。Agent Card 是机器可读取的 JSON 元数据文档。早期版本的公开发现地址采用以下形式。

https://{agent_host}/.well-known/agent.json

A2A v1.0.1 的标准发现路径为 /.well-known/agent-card.json。Agent Card 通过 supportedInterfaces 声明 url、protocolBinding 和 protocolVersion，并通过 securitySchemes 与 securityRequirements 描述安全要求。客户端也可以通过企业智能体目录或预先配置发现服务。实现时应固定协议版本，并使用对应 schema。

Agent Card 中通常需要表达以下信息。具体字段是否存在、名称和类型如何，均以采用的协议版本为准。

• name：便于人类理解的名称。
• description：用途或专业领域说明。
• url：早期格式中的服务地址；较新版本可以通过支持接口列表描述地址及协议绑定。
• version：智能体自身版本。
• capabilities：支持的流式输出、推送更新等能力。早期示例也包含 stateTransitionHistory。
• skills：可完成的高层任务。每项通常包含 id、name、description、支持的 inputModes 和 outputModes，以及可选 examples。模态值及必填字段需要遵循对应 schema。
• defaultInputModes 与 defaultOutputModes：默认输入和输出内容类型。
• 协议与端点：公开支持的协议版本和访问接口。应用扩展有时使用 supportedProtocols 或 endpoints 等名称，这些名称不能直接视为所有 A2A 版本共有的字段；早期文档中的 /tasks/send 也应结合相应绑定理解。
• 认证要求：早期示例使用 authentication，实际应用应依据版本规定的安全方案字段，声明所需 API key、OAuth 等认证方式。
• 其他资料：服务提供者、组织、文档地址，以及协议允许的扩展信息。

Agent Card 也可以通过其他发现渠道提供，例如应用通过 MCP 资源公布智能体描述。

早期 Agent Card 结构示例：以下为订单智能体的历史教学格式，用于理解身份、能力和技能的组织方式。生产实现需根据所选版本转换字段，并完成 schema 验证。

{
  "name": "Example Order Agent",
  "description": "An agent that manages warehouse inventory and performs Orders.",
  "url": "https://order.swirlai.com/agent",
  "version": "1.0.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false,
    "stateTransitionHistory": true
  },
  "authentication": {
    "schemes": []
  },
  "defaultInputModes": ["text"],
  "defaultOutputModes": ["text"],
  "skills": [
    {
      "id": "order_creation",
      "name": "Order Creator",
      "description": "Creates orders based on the item requests received.",
      "inputModes": ["text"],
      "outputModes": ["text"]
    }
  ]
}

A2A v1.0.1 的 JSON-RPC 发送方法为 SendMessage，HTTP/JSON 绑定使用 POST /message:send。具体接口参阅 A2A v1.0.1 规范；协议后续发展可查阅 A2A 最新规范。