探索 Google A2A 协议，为不同智能体之间搭建高效沟通桥梁，促进 Agent 生态系统发展。
原文标题：A2A（Agent2Agent） 简介
原文作者：阿里云开发者
冷月清谈：
文章深入剖析了 A2A 的协议原理，包括核心三要素（User、Client Agent、Remote Agent）和核心概念（AgentCard、Task、Artifact、Message、Part），并阐述了 Client Agent 和 Server Agent 之间的通信和认证流程。此外，文章还对比了 A2A 和 MCP 协议，指出了 A2A 作为 MCP 补充的定位，以及其在工程领域和智能体互操作性上的优势。
最后，文章展望了智能体互联互通的未来趋势，强调了企业内部和外部智能体之间沟通协作的重要性，以及 A2A 在推动 Agent 生态系统发展中的作用。
怜星夜思：
2、文章提到 A2A 协议支持 Agent 之间的安全协作，通过引入认证/授权机制保证 Agent 之间的身份互信。那么，你认为在 Agent 时代，除了技术手段，我们还需要哪些法律法规或伦理规范来保障 Agent 之间的安全协作，以及 Agent 与人类社会的安全互动？
3、文章对比了 A2A 和 MCP 协议，指出 A2A 更强调 Agent 之间的对等互操作。那么，你认为在未来的 Agent 生态系统中，是 A2A 这种 Agent 之间直接互联互通的模式更有优势，还是 MCP 这种通过中心化平台进行调度的模式更有优势？或者说，这两种模式会长期共存，分别适用于不同的场景？
原文内容
阿里妹导读
本文主要介绍Google于2025年4月9日发布的Agent2Agent Protocol（简称“A2A”），这是一个旨在促进不同类型智能体（Agent）之间高效沟通与协作的开放协议。
序言
2025年4月9日，Google 正式发布了 Agent2Agent Protocol（以下简称 “A2A”）。该协议为不同类型的智能体之间搭建了一座高效沟通与协作的桥梁，无论是独立Agent与独立Agent、独立Agent与企业Agent，亦或是企业Agent与企业Agent，都能借助该协议实现通信交互和事务协作。
A2A 为 Agent生态 提供了一套标准协议标准，补充了 Agent生态 基础设施中至关重要的一块拼图，将有力推动 Agent生态系统 的完善与发展。
一、A2A 介绍
A2A 是一个用于链接不同封闭Agent，并实现其相互操作的开放协议。
1.1 A2A 诞生背景
目前为止，比较公认的一个观点是：2025年是 Agent元年。虽然说是元年，但是其爆发式的普及速度，远远超过了元年这个词的含义。所以，发展快是一个前提。
另外一点，Agent作为一个智能体，它本身具备自主性、主动性、社会性和反应性。其社会性在以人为本构建的产品和服务的世界中，并不能快速的成长。
举一个简单的例子：人与人之间可以通过各种各样的方式沟通：对话，眼神，肢体动作，画作等，这些可以帮助不同的人之间相互了解对方，并做出正确的动作，共同推动人类社会的发展，那么Agent之间沟通协作呢？Google给出了自己的答案：A2A 。
1.2 A2A 的功能特性
A2A 作为一个开放协议，充分考虑了 Agent 在和用户、企业打通的过程中所面临的一些挑战，其主要功能特性有以下四点：
-
安全协作(Secure Collaboration)：通过引入认证/授权机制，保证 Agent 之间的身份互信。
-
任务状态管理(Task and state mgmt)：实现了 Agent 之间互操作任务以及任务状态的可管理性。
-
用户体验协商(UX negotiation)：不同的 Agent 通过协商的方式，对用户提供无缝的体验。
-
功能发现(Capability discovery)：提供了 Agent 之间相互发现各自能力的机制。
除此之外，A2A 也在企业的无缝接入、简化集成方面，有比较好的考量。
二、A2A 协议原理
2.1 基本概念
2.1.1 核心三要素
A2A 中包含三个核心的参与者：
-
User
-
Client Agent
-
Remote Agent
User存在于协议中，主要的作用是用于 认证&授权 。Client Agent 指的是任务发起者，Server Agent 指的是任务的执行者。
Client 和 Server 之间的通信，可以理解为就是一个个简单的请求和结果的响应，只不过这个请求是一个个的任务。一个 Agent 既可以是 Client 也可以是 Server。
2.1.2 核心概念
这里主要介绍一下，Client Agent 和 Server Agent 交互的过程中，主要涉及到的一些Entity：AgentCard、Task 、Artifact 、Message、Part。
2.1.2.1 AgentCard
AgentCard 是 Server Agent 的名片，它主要描述了 Server Agent 的能力、认证机制等信息。Client Agent通过获取不同 Server Agent 的 AgentCard，了解不同 Server Agent 的能力，来决断具体的任务执行应该调用哪个 Server Agent 。
AgentCard 内容示例：
interface AgentCard { name: string; description: string; url: string; provider?: { organization: string; url: string; }; version: string; documentationUrl?: string; capabilities: { streaming?: boolean; pushNotifications?: boolean; stateTransitionHistory?: boolean; };
authentication: {
schemes: string;
credentials?: string;
};
defaultInputModes: string;
defaultOutputModes: string;
skills: {
id: string;
name: string;
description: string;
tags: string;
examples?: string;
inputModes?: string;
outputModes?: string;
};
}
2.1.2.2 Task
Task 是一个具有状态的实体，由Client Agent创建，其状态由Server Agent维护。一个Task用于达到特定的目标或者结果。Agent Client和Server Client在Task中交换Mesaage，Server Agent生成的结果叫做Artifact。
除此之外，每个Task有一个唯一的sessionId，多个Task可以使用一个sessionId，表明多个Task属于同一个会话的一部分。
Task 示例：
interface Task { id: string; sessionId: string; status: TaskStatus; history?: Message[]; artifacts?: Artifact[]; metadata?: Record<string, any>; }interface TaskStatus {
state: TaskState;
message?: Message;
timestamp?: string;
}interface TaskStatusUpdateEvent {
id: string;
status: TaskStatus;
final: boolean; //indicates the end of the event stream
metadata?: Record<string, any>;
}interface TaskArtifactUpdateEvent {
id: string;
artifact: Artifact;
metadata?: Record<string, any>;
}
interface TaskSendParams {
id: string;
sessionId?: string;
message: Message;
historyLength?: number;
pushNotification?: PushNotificationConfig;
metadata?: Record<string, any>; // extension metadata
}
type TaskState =
| “submitted”
| “working”
| “input-required”
| “completed”
| “canceled”
| “failed”
| “unknown”;
2.1.2.3 Artifact
Artifacts：Server Agent 在执行任务后生成的目标结果叫做 Artifact，一个 Task 可能生成一个或者多个 Artifact。
Artifacts 是不可变的，可以命名，并且可以有多个部分。流式响应可以分批次，将结果附加到现有 Artifacts上。
interface Artifact {
name?: string;
description?: string;
parts: Part[];
metadata?: Record<string, any>;
index: number;
append?: boolean;
lastChunk?: boolean;
}
2.1.2.4 Message
在 Task执行过程中，Server Agent和Client Agent之间是通过Message完成交流的，当然，这不包括Artifact。它可以包括：Agent的思考、用户上下文、指令、错误、状态或元数据。
一个Message可以包含多个Part，每个Part携带不同的内容。
Message 示例：
interface Message {
role: "user" | "agent";
parts: Part[];
metadata?: Record<string, any>;
}
2.1.2.5 Part
Part 是 Message 和 Artifact 的核心组成部分，代表了其携带的主要内容。每个 Part 都标识了内容类型和具体内容。
Part 示例：
interface TextPart {
type: "text";
text: string;
}
interface FilePart {
type: "file";
file: {
name?: string;
mimeType?: string;
// oneof {
bytes?: string; //base64 encoded content
uri?: string;
//}
};
}
interface DataPart {
type: "data";
data: Record<string, any>;
}
type Part = (TextPart | FilePart | DataPart) & {
metadata: Record<string, any>;
};
2.2 通信&认证
ClientAgent 和ServerAgent之间通过HTTP协议进行通信，使用经典的C/S模式，支持SSE流式数据传输，数据格式为JSON-RPC2.0。
A2A遵循Open API规范进行身份验证。A2A不会在协议中交换身份信息。相反，它们会在带外获取材料（如令牌），并在HTTP 头中传输。
2.3 核心流程
Client Agent 和 Server Agent 之间协同工作需要经过以下几个关键步骤：
-
Server Agent 在指定站点托管自己的 AgentCard；
-
Client Agent 主动发现 AgentCard；
-
Client Agent 发起一个 Task；
-
Client Agent 设置任务通知监听；
-
Server Agent 执行任务，返回 Artifact；
-
Client Agent 获取 Artifact。
2.3.1 AgentCard 托管 & 发现
官方建议将 AgentCard 托管在 https://${host}/.well-known/agent.json。
上面这种方式叫做 Open Discovery，除此之外，还有另外两种方式：Curated Discovery 和 Private Discovery，详见：https://google.github.io/A2A/#/topics/agent_discovery
Agent Client 可以通过请求https://${host}/.well-known/agent.json，获取到指定的 AgentCard，并集成到自己的提示词或者工具集中。
//agent card
{
"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"
],
// can return a video of the route
"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"]
}
]
}
2.3.2 发起Task
允许客户端向远程代理发送内容，以启动新任务、恢复中断的任务或重新打开已完成的任务。
{
"jsonrpc": "2.0",
"id": 1,
"method":"tasks/send",
"params": {
"id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
"message": {
"role":"user",
"data": [{
"type":"text",
"text": "tell me a joke"
}]
},
"metadata": {}
}
}
2.3.3 设置ClientAgent任务状态监听
ClientAgent 可以设置一个方法，给到 ServerAgent，当 ServerAgent 修改 Task 状态后，同步调用 ClientAgent 的监听方法。
//Request
{
"jsonrpc": "2.0",
"id": 1,
"method":"tasks/pushNotification/set",
"params": {
"id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
"pushNotificationConfig": {
"url": "https://example.com/callback",
"authentication": {
"schemes": ["jwt"]
}
}
}
}
//Response
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
"pushNotificationConfig": {
"url": "https://example.com/callback",
"authentication": {
"schemes": ["jwt"]
}
}
}
}
2.3.4 执行 Task，返回结果
Server Agent 执行任务，并以 Artifact 的形式，返回结果。
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
"sessionId": "c295ea44-7543-4f78-b524-7a38915ad6e4",
"status": {
"state": "completed",
},
"artifacts": [{
"name":"joke",
"parts": [{
"type":"text",
"text":"Why did the chicken cross the road? To get to the other side!"
}]
}],
"metadata": {}
}
}
2.3.5 获取 Artifact
这里需要注意的是，Client Agent 需要通过获取 Task 的方式，获取到Artifact
//Request
{
"jsonrpc": "2.0",
"id": 1,
"method":"tasks/get",
"params": {
"id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
"historyLength": 10,
"metadata": {}
}
}
//Response
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
"sessionId": "c295ea44-7543-4f78-b524-7a38915ad6e4",
"status": {
"state": "completed"
},
"artifacts": [{
"parts": [{
"type":"text",
"text":"Why did the chicken cross the road? To get to the other side!"
}]
}],
"history":[
{
"role": "user",
"parts": [
{
"type": "text",
"text": "tell me a joke"
}
]
}
],
"metadata": {}
}
}
三、 A2A vs. MCP
如果没有 A2A ,只使用 MCP 是否也可以实现 Agent 之间的互相调用？答案肯定是可以的。那为什么还要有 A2A 呢？
官方认为，A2A 是 MCP 的一个补充，相当于对子领域的一个增强。
我个人的看法是：MCP 还是传统的工程思维，A2A则是站在人的思维来看待世界。
首先，我们要理解MCP的定位：提供一个规范的方式，向LLMs/Agent提供上下文。MCP强调的是LLMs/Agent为主体，MCPServer为附属的模式。而A2A强调的是Agent和Agent之间的相互操作，协议双端是对等的。
下面两个官方的图示，可以帮助大家理解A2A和MCP 在工程领域的定位问题。
Agent-To-Agent
Agent-To-MCP-To-Agent
四、展望
Agent 相互之间的发现、了解和交互调用，是一个发展趋势。
首先，企业基于当前业务，都在探索、建立各种各样的 领域Agent 。在内部的各种 领域Agent 之间的沟通协作，是必须要面对和解决的一个问题。
其次，对于对外提供 Agent 服务的提供商来说，我如何让其他 Agent 主动发现我，就像SEO，吸引更多的流量，也是一个需要思考的问题。
参考资料：
[1] https://google.github.io/A2A/#/
[2] https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
[3] https://modelcontextprotocol.io/introduction
低成本、高性能的湖仓一体化架构
湖仓一体架构融合了数据湖的低成本、高扩展性，以及数据仓库的高性能、强数据治理能力，高效应对大数据时代的挑战。SelectDB 通过高性能数据分析处理引擎和丰富的湖仓数据对接能力，助力企业加速从 0 到 1 构建湖仓体系，降低转型过程中的风险和成本。
点击阅读原文查看详情。