1为什么需要 A2A 协议:Agent 互操作的碎片化困局
2025 年到 2026 年,AI Agent 生态呈现爆炸式增长。但繁荣背后隐藏着一个致命的结构性问题——不同厂商、不同框架开发的 Agent 之间无法直接通信。
想象互联网早期的场景:每个网络服务提供商都有自己的私有协议,用户必须安装对应的客户端才能访问对应的服务。如果浏览器 A 不能访问网站 B,搜索引擎 C 不能索引网页 D,互联网就不可能成为今天的基础设施。Agent 生态正面临同样的碎片化危机。
在 A2A 协议出现之前,Agent 之间的协作只能通过以下方式实现:第一种是硬编码集成——开发者为每对需要协作的 Agent 编写专用的接口适配层,复杂度呈平方级增长;第二种是统一框架绑定——在 LangChain、CrewAI 或 AutoGen 等单一框架内开发所有 Agent,虽然框架内通信简单,但被锁定在特定生态中,无法跨框架调用;第三种是自定义消息队列——通过 Kafka、RabbitMQ 等中间件传递消息,但这只解决了传输层问题,消息的语义格式、工具调用协议、任务状态管理等核心问题仍然没有标准。
A2A 协议的核心使命就是解决这个碎片化问题——定义一套开放的、厂商中立的 Agent 间通信标准,让任何 Agent 都能与任何其他 Agent 协作,无论它们运行在哪个平台、使用哪个框架、由哪个厂商提供。这就像 HTTP 之于 Web、SMTP 之于邮件——协议层的统一将释放生态级的协作潜力。
理解 A2A 的一个类比:它之于 Agent 生态,就像 HTTP 之于 Web——协议层的统一释放生态级协作。
不要将 A2A 与 MCP 混淆。MCP 解决的是 Agent 如何调用工具的问题,A2A 解决的是 Agent 如何与其他 Agent 通信的问题。两者互补而非替代。
2A2A 协议的起源与发展历程
A2A 协议由 Google 于 2025 年 4 月首次引入,最初作为 Google AI Agent 生态的内部通信标准。随着多厂商 Agent 协作需求激增,Google 决定将这一标准开放给整个行业。
2025 年 Q3,Google 将 A2A 提交给 Linux Foundation,正式开启标准化流程。这标志着 A2A 从「Google 的私有协议」转变为「行业的公共基础设施」。
2025 年 Q4 到 2026 年 Q1,A2A 技术治理委员会(TSC)成立,成员包括 AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP 和 ServiceNow 八大科技巨头。TSC 负责定义协议演进方向、审核版本变更、确保协议的厂商中立性。
2026 年 5 月,A2A 迎来两个里程碑:一是 v1.0 正式发布,标志着协议进入生产就绪阶段,核心规范(Protocol Buffers .proto 文件)通过严格的向后兼容性测试——0.3 版本服务端与 1.0 版本客户端可正常通信;二是生态规模突破 150 家组织,已进入 AWS、Google Cloud、Azure 等主流云平台。
A2A v1.0 的兼容性测试由 Google Developer 论坛主导,专门建立了版本兼容性矩阵,评估所有 Client-Server 版本组合。测试结果表明,A2A 通过 Protocol Buffers 的向前兼容特性实现了跨版本互操作。
| 时间 | 里程碑 | 关键变化 | 影响 |
|---|---|---|---|
2025 年 4 月 | Google 首次引入 | 内部 Agent 通信标准 | Google 生态内可用 |
2025 年 Q3 | 提交 Linux 基金会 | 从私有到开放标准 | 行业标准化启动 |
2025 年 Q4 | TSC 成立 | 8 大厂商加入 | 厂商中立性保障 |
2026 年 Q1 | 生态快速扩张 | 主流框架开始适配 | LangChain 等集成 |
2026 年 5 月 | v1.0 正式发布 | 生产就绪 + 150+ 组织 | 企业级部署开始 |
A2A 的核心规范基于 Protocol Buffers(.proto 文件),这确保了跨语言、跨平台的类型安全和向后兼容性。
A2A 协议仍在快速演进中。v1.0 虽然生产就绪,但后续版本可能引入变更。建议通过 A2A Executor 抽象层来隔离协议版本差异。
3A2A 协议核心架构解析
A2A 协议的核心设计思想非常简洁:将 Agent 包装为标准化的服务端(A2A Server),通过统一的通信协议让其他 Agent(A2A Client)能够发现和调用它。
整个架构围绕四个核心概念展开。
第一是 Agent Card——一个 JSON 文件,类似于 OpenAPI/Swagger 规范,描述 Agent 的能力范围、支持的输入输出格式、认证方式、端点地址等元数据。Agent Card 可通过 URL 直接访问,使得 Agent 的发现变得像访问网页一样简单。
第二是 A2A Server——任何 AI Agent 都可通过 A2A Executor 组件包装为标准服务端。Executor 负责将 Agent 内部逻辑转换为标准接口:接收任务请求、返回任务状态、流式输出中间结果等。Agent 开发者只需关注业务逻辑,Executor 处理所有协议细节。
第三是 A2A Client——嵌入在调用方 Agent 中的组件,负责发现远程 Agent(读取 Agent Card)、构造任务请求、发送请求、处理响应和状态更新。Client 和 Server 之间基于 HTTP/JSON 通信,兼容所有标准 Web 基础设施。
第四是 Task 模型——A2A 中所有交互都围绕「任务」展开。一个 Task 有唯一 ID、明确的输入消息、执行状态(pending/working/completed/failed)、以及可选的流式输出。这种设计借鉴了异步任务队列模式,天然支持长时间运行的 Agent 任务。
// A2A Agent Card 示例
// 通过 https://agent.example.com/.well-known/agent.json 访问
{
"name": "代码审查 Agent",
"description": "自动审查 PR 的代码质量、安全性和性能",
"url": "https://agent.example.com/a2a",
"version": "1.0.0",
"capabilities": {
"inputModes": ["text", "code"],
"outputModes": ["text", "json"],
"skills": [
{
"id": "code-review",
"name": "代码审查",
"description": "对代码进行质量审查,返回问题列表和修复建议",
"inputSchema": {
"language": "string",
"code": "string",
"reviewLevel": "basic | detailed | security"
}
}
]
},
"security": {
"schemes": { "bearer": { "type": "http", "scheme": "bearer" } }
}
}// A2A Client 调用示例
async function delegateToAgent(
agentUrl: string,
task: string,
skillId?: string
): Promise<string> {
const response = await fetch(agentUrl, {
method: 'POST',
headers: {
'Content-Type': 'application/a2a+json',
'Authorization': 'Bearer YOUR_TOKEN'
},
body: JSON.stringify({
taskId: crypto.randomUUID(),
message: {
role: 'user',
parts: [{ type: 'text', text: task }]
},
metadata: skillId ? { skillId } : undefined
})
});
const result = await response.json();
return result.status.message?.parts?.[0]?.text || '';
}
// 使用示例:委托代码审查任务
const review = await delegateToAgent(
'https://code-review-agent.example.com/a2a',
'审查以下 Python 代码的安全性',
'code-review'
);Agent Card 是 A2A 的「名片」——设计良好的 Agent Card 包含清晰的能力描述,让其他 Agent 快速理解如何协作。
Agent Card 暴露的信息可能被攻击者利用。生产环境中建议通过认证机制保护 Agent Card 的访问。
4A2A vs MCP:互补而非竞争
A2A 和 MCP(Model Context Protocol)是 2026 年 Agent 生态中最重要的两个开放标准。很多开发者容易混淆,但理解它们的关系对正确选择架构至关重要。
MCP 解决的是 Agent 如何调用工具的问题——它定义了 Agent 与工具 Server 之间的通信协议,让 Agent 以统一方式连接文件系统、数据库、API 等工具。MCP 是 Agent 向外的「手」。
A2A 解决的是 Agent 如何与其他 Agent 通信的问题——它定义了 Agent 之间的任务委托和协作协议,让不同厂商、不同框架的 Agent 能够互相调用。A2A 是 Agent 之间的「嘴」。
两者在架构中的位置完全不同:MCP 在 Agent 内部,连接 Agent 和工具;A2A 在 Agent 之间,连接 Agent 和 Agent。 一个完整的 Agent 系统可以同时使用两者——通过 MCP 连接本地工具,通过 A2A 委托任务给远程 Agent。
更重要的是,A2A 和 MCP 的 TSC 成员存在重叠(Google、Microsoft),确保两者在设计上保持兼容互补,不会走向竞争对立。
| 维度 | MCP | A2A | 关系 |
|---|---|---|---|
解决的问题 | Agent ↔ 工具通信 | Agent ↔ Agent 通信 | 互补 |
架构位置 | Agent 内部 | Agent 之间 | 不同层级 |
核心概念 | Client-Server, Tool | Task, Agent Card | 各自独立 |
通信协议 | JSON-RPC 2.0 | HTTP/JSON | 不同协议 |
治理方 | Linux Foundation | Linux Foundation | 同一基金会 |
生态规模 | ~2000+ MCP Server | 150+ 组织 | 各自增长 |
架构设计建议:优先使用 MCP 连接本地工具,仅在需要跨组织、跨平台委托任务时才使用 A2A。
不要用 A2A 替代 MCP 来连接工具——A2A 的任务模型太重(Task ID、状态管理、流式输出),不适合高频低延迟的工具调用。
5Task 模型与状态机
A2A 协议中所有交互都围绕 Task(任务) 展开。理解 Task 模型是理解 A2A 的基础。
Task 的完整生命周期包含五个状态:Pending(待处理)——任务已创建但尚未执行;Working(执行中)——任务正在处理,可流式返回中间结果;Completed(已完成)——任务成功完成;Failed(失败)——任务执行失败并返回错误信息;Canceled(已取消)——调用方主动取消。
A2A 支持两种查询模式:轮询模式——Client 定期 GET 请求查询状态,适用于中等时长任务;流式模式——Server 通过 SSE 持续推送状态更新,适用于需要实时进度的长任务。
每个 Task 消息使用 Part 数组 结构——每个 Part 可以是纯文本、文件引用或结构化数据。这种设计借鉴了 OpenAI 和 Anthropic 的消息格式标准,确保与主流 LLM API 的兼容性。
// A2A Task 完整类型定义
type TaskStatus = 'pending' | 'working' | 'completed' | 'failed' | 'canceled';
interface A2ATask {
id: string;
sessionId?: string; // 多轮对话会话
status: {
state: TaskStatus;
message?: {
role: 'user' | 'agent';
parts: Array<{
type: 'text' | 'file' | 'data';
text?: string;
}>;
};
timestamp: string;
};
history?: any[];
artifacts?: any[];
}
// Task 轮询示例
async function pollTaskStatus(
taskUrl: string,
maxAttempts = 30,
intervalMs = 2000
): Promise<A2ATask> {
for (let i = 0; i < maxAttempts; i++) {
const response = await fetch(taskUrl, {
headers: { 'Accept': 'application/a2a+json' }
});
const task: A2ATask = await response.json();
if (task.status.state === 'completed') return task;
if (task.status.state === 'failed')
throw new Error('任务失败');
if (task.status.state === 'canceled')
throw new Error('任务已取消');
await new Promise(r => setTimeout(r, intervalMs));
}
throw new Error('任务超时');
}Task 的 sessionId 支持多轮对话场景——同一会话内多个任务共享上下文,使得 Agent 间能有状态地连续协作。
轮询间隔不宜过短(<1s)或过长(>10s)。建议根据任务预期时长动态调整。
6实战:构建 A2A 兼容的代码审查 Agent
本节展示如何将已有代码审查 Agent 包装为符合 A2A v1.0 标准的服务端,供其他 Agent 调用。
这个代码审查 Agent 的功能:接收代码片段和审查级别,返回代码质量评估报告。我们使用 Node.js + Express 构建 A2A Server,展示从 Agent Card 配置到任务处理的完整流程。
// A2A Server 实现(Node.js + Express)
import express from 'express';
import { randomUUID } from 'crypto';
const app = express();
app.use(express.json());
const tasks = new Map<string, any>();
// Agent Card 端点
app.get('/.well-known/agent.json', (_req, res) => {
res.json({
name: "代码审查 Agent",
description: "自动审查代码质量、安全性和性能",
url: "http://localhost:3000/a2a",
version: "1.0.0",
capabilities: {
inputModes: ["text"],
outputModes: ["text"],
skills: [{
id: "code-review",
name: "代码审查",
description: "审查代码返回问题列表"
}]
}
});
});
// 创建任务端点
app.post('/a2a', async (req, res) => {
const taskId = randomUUID();
const task = {
id: taskId,
status: {
state: 'working' as const,
message: {
role: 'agent' as const,
parts: [{ type: 'text' as const, text: '正在审查...' }]
},
timestamp: new Date().toISOString()
},
history: [req.body.message]
};
// 异步执行审查
executeReview(taskId, req.body.message.parts[0].text)
.then(result => {
tasks.get(taskId)!.status = {
state: 'completed' as const,
message: {
role: 'agent' as const,
parts: [{ type: 'text' as const, text: result }]
},
timestamp: new Date().toISOString()
};
});
tasks.set(taskId, task);
res.json(task);
});
// 查询任务状态
app.get('/a2a/:taskId', (req, res) => {
const task = tasks.get(req.params.taskId);
if (!task) return res.status(404).json({ error: 'Not found' });
res.json(task);
});
async function executeReview(_id: string, code: string): Promise<string> {
await new Promise(r => setTimeout(r, 3000));
const issues: string[] = [];
if (code.includes('eval(')) issues.push('⚠️ 使用 eval() 有注入风险');
if (!code.includes('try ')) issues.push('💡 建议添加 try-catch');
return issues.length === 0 ? '✅ 代码质量良好' : issues.join('\n');
}
app.listen(3000, () => console.log('A2A Server :3000'));生产环境中 A2A Server 的任务存储不应使用内存 Map——应使用 Redis 或数据库来持久化任务状态。
Agent Card 中的 skills 字段定义了 Agent 能力清单。务必为每个技能提供清晰的 id 和 description,Client 据此决定是否调用。
7A2A 在多云 Agent 编排中的应用
A2A 最具价值的应用场景是多云/跨组织的 Agent 编排。真实企业环境中,不同团队使用不同的 Agent 平台。A2A 提供了统一的连接方式,让异构 Agent 协同工作。
典型场景是跨部门工单处理。假设一家公司有三个 Agent:IT 部门使用 Microsoft Copilot Studio 构建的 IT 支持 Agent,财务部门使用 Google Vertex AI 构建的财务审批 Agent,HR 部门使用 Anthropic Claude 构建的员工服务 Agent。在没有 A2A 的情况下,这三个 Agent 之间无法直接协作。有了 A2A,可以构建一个编排 Agent,通过 A2A 协议将工单的不同部分委托给对应部门 Agent。
截至 2026 年 5 月,A2A 已进入 AWS、Google Cloud、Azure 等主流云平台,企业可直接使用云服务商提供的托管 A2A 服务。
// 编排 Agent:跨部门工单处理
const DEPT_AGENTS = [
{ name: "IT", url: "https://it-agent.company.com/a2a", skills: ["设备配置"] },
{ name: "财务", url: "https://finance-agent.company.com/a2a", skills: ["预算审批"] },
{ name: "HR", url: "https://hr-agent.company.com/a2a", skills: ["员工录入"] }
];
async function handleOnboarding(employee: {name: string, dept: string, role: string}) {
// 并行委托三个部门 Agent
const results = await Promise.allSettled([
delegateToAgent(DEPT_AGENTS[0].url, `为新员工 ${employee.name} 配置 IT 设备`),
delegateToAgent(DEPT_AGENTS[1].url, `为 ${employee.name} 开通财务权限`),
delegateToAgent(DEPT_AGENTS[2].url, `录入新员工 ${employee.name}`)
]);
for (const [dept, result] of Object.entries({IT: results[0], 财务: results[1], HR: results[2]})) {
if (result.status === 'fulfilled') {
console.log(`${dept}: ${result.value}`);
} else {
console.error(`${dept}: 处理失败`);
}
}
}编排 Agent 的核心原则:编排逻辑(路由、聚合、错误处理)与业务逻辑完全解耦。
跨组织 A2A 通信必须考虑安全。Agent Card 不应暴露敏感信息,任务传输应使用 TLS 加密,且需要认证授权机制。
8A2A 协议的安全与治理
A2A 协议在设计时就内置了安全考虑,但协议层安全不等于应用层安全。
认证与授权是第一道防线。Agent Card 的 security 字段定义了支持的认证方式(Bearer Token、OAuth 2.0 等)。调用方必须携带有效凭证。
任务级别的权限控制是核心。每个请求应携带调用方身份,被调用方 Agent 可据此决定允许调用哪些技能、返回哪些级别的结果。
审计与合规方面,所有 A2A 通信都应记录完整的审计日志:谁在何时通过什么方式调用了哪个 Agent,结果是什么。这不仅是安全追溯,也是满足企业合规要求(SOC 2、ISO 27001)的必要条件。
| 安全层 | 机制 | 实现位置 | 覆盖范围 |
|---|---|---|---|
传输安全 | HTTPS/TLS 1.3 | 网络层 | 加密传输 |
身份认证 | Bearer Token / OAuth 2.0 | Agent Card + Header | 验证调用方 |
技能授权 | 按调用方控制可用技能 | A2A Server 逻辑 | 限制功能 |
数据过滤 | 按权限过滤结果 | A2A Server 逻辑 | 防止泄露 |
调用链审计 | 完整记录调用链 | 日志系统 | 合规追溯 |
实施 A2A 安全时建议采用最小权限原则——每个调用方 Agent 只授予完成其任务所需的最小技能集合。
A2A 的 metadata 字段可携带任意数据——恶意调用方可能注入恶意 payload。Server 必须对所有 metadata 进行验证和消毒。
9未来展望与建设建议
截至 2026 年 5 月,A2A 已从实验性标准成长为拥有 150+ 组织、覆盖三大云平台的产业级基础设施。
短期展望(2026 下半年):预计 A2A v1.1 将引入对Agent 信任链的标准化支持,解决跨组织调用链中的身份传递和权限委托问题。同时,A2A 工具市场(Agent Marketplace) 概念正在被讨论——类似 npm 之于 JavaScript、Docker Hub 之于容器镜像。
对开发者的建设建议:第一,尽早让你的 Agent 支持 A2A——即使只需在单一平台内开发,通过 A2A Executor 包装也不增加太多成本,但保留了未来跨平台协作的可能性。第二,精心设计 Agent Card——它是 Agent 在 A2A 生态中的「简历」。第三,关注 TSC 路线图——参与社区讨论能帮助塑造协议方向。
A2A 是 Agent 生态的 HTTP 时刻——就像 HTTP 统一了 Web 通信一样,A2A 将统一 Agent 通信。尽早适配意味着先发优势。
A2A 仍在演进中。建议通过 A2A Executor 抽象层隔离协议版本差异,避免 Agent 业务逻辑直接依赖特定版本。