智能体间协议(Agent-to-Agent Protocol, A2A)

A2A 是一个开放协议,使彼此独立的 AI 智能体——即使它们由不同公司基于不同框架构建——也能够互相发现, 并直接协作以完成一项任务。

A2A 究竟是什么?

设想你的购物智能体(比如运行在某公司的基础设施上)需要与另一家物流公司的智能体协调,才能完成一笔订单。 这两个智能体不仅基于不同的框架构建,而且彼此都完全无法直接访问对方的代码或数据库。A2A 正是为这种场景而设计的: 一种共同的语言,让相互独立的智能体能够将各自的任务(Task)委托给对方,而无需了解对方内部的实现细节。

既然有了 MCP,为什么还需要 A2A?

这两个协议标准化的是两种完全不同的关系。MCP 解决的是"智能体到工具/数据"的关系(一个智能体连接到数据库或 API)。A2A 解决的是"智能体到另一个智能体"的关系—— 也就是说,对方本身就是一个拥有自身逻辑和目标的独立决策者,而不是一个被动的工具。

Agent Card

每个支持 A2A 的智能体都会发布一份名为 Agent Card 的公开 JSON 文档——类似于一张机器可读的名片。 这张卡片包含智能体的名称、其能力(Skills)的描述、端点地址,以及身份验证要求。从概念上讲,它扮演的角色 与商店的 ucp.json 文件完全相同;只不过这一次,"商店"变成了另一个智能体。

智能体发现(Discovery)

在任何交互之前,发起方智能体首先需要了解目标智能体到底具备哪些能力。根据 A2A 规范,每个智能体都会在一个 标准、众所周知的地址上发布自己的 Agent Card:/.well-known/agent.json。这意味着,仅凭一个域名, 就可以发现一个未知智能体的能力——无需人工编写文档,也无需两个开发团队事先协调。

Task 生命周期

A2A 中的核心工作单元是一个 Task,它会经历明确的几个阶段:

1. submitted — 发起方智能体提交任务
2. working — 目标智能体正在处理(可能会发送中间消息/状态)
3. input-required — 如果需要更多信息,会向发起方智能体询问
4. completed / failed — 任务以最终结果(Artifact)或错误结束

消息与 Artifact

智能体在一个 Task 期间通过交换消息(Message)进行沟通(文本、文件或结构化数据), 而最终结果则以一个或多个 Artifact(例如一份文档、一张图片或一条 JSON 记录)的形式交付。

流式更新与推送通知

许多任务无法立即完成——例如"预订运输"可能需要几分钟甚至几个小时。为此,A2A 提供了两种机制:

• 使用 SSE(Server-Sent Events)流式传输 — 当两个智能体都保持在线并连接时,目标智能体可以在生成 Task 的中间状态后,立即通过一个开放连接以流式方式发送。
• 推送通知(Webhook) — 对于长时间运行、不适合保持实时连接的任务,发起方智能体提供一个 Webhook 地址,目标智能体在 Task 状态发生变化时(例如从 working 变为 completed),会向该地址发送一个 HTTP 请求。

在这两者之间做出选择,取决于两个智能体能否在整个 Task 执行期间保持一个开放连接。

A2A 与 MCP 的对比

示例:一个简单的 Agent Card

{
  "name": "LogisticsAgent",
  "description": "为在线商店提供运输跟踪与预订服务",
  "url": "https://logistics.example.com/a2a",
  "skills": [
    { "id": "create_shipment", "description": "登记一个新的运输单" },
    { "id": "track_shipment", "description": "跟踪运输单状态" }
  ],
  "authentication": { "schemes": ["bearer"] }
}

常见问题