A2A协议由Google发布,旨在解决多智能体系统中不同Agent间的通信问题。它通过定义Agent Card、Task、Message等核心元素,以及三种交互机制,实现了Agent间的标准化协作。该协议使不同团队开发的Agent无需关心对方框架或语言,只需遵循协议即可互相调用,为构建大规模Agent协作系统奠定了基础。
引言
多智能体系统是目前 AI 工程领域最火热的话题之一。一个复杂任务,交给一个 Agent 去做,它可能搞不定;但如果有一个主助手负责协调,旁边还有专门负责订机票的 Agent、负责查天气的 Agent、负责写报告的 Agent,协作完成就容易多了。
这个设想很美好,但实际落地时会碰到一个现实问题:这些 Agent 可能是不同团队开发的,跑在不同的框架上,部署在不同的服务器里。它们怎么互相"说话"?
A2A(Agent2Agent)协议就是为了解决这个问题诞生的。2025年4月,Google 发布了这套开放协议,目标是让构建在不同框架、语言和平台上的 AI Agent 能够互相通信和协作,而且无需暴露各自的内部状态、内存或私有工具。
简单说:A2A 是 Agent 之间通信的"通用语言"。
两个角色:谁说话,谁干活
A2A 协议把交互的双方分成两个角色:
1. A2A Client(客户端 Agent)
直接面向用户的一方。用户发起请求后,由 Client Agent 理解意图,然后决定要调用哪些远程 Agent 来协助完成任务。可以把它理解成"项目经理"——接需求、拆任务、协调资源。
2. A2A Server(服务端 Agent)
也叫 Remote Agent,是真正干活的一方。它接收来自 Client 的请求,专注执行具体任务,然后把结果返回。它不需要知道调用方的内部逻辑,也不暴露自己的实现细节。
两者之间通过 HTTP 通信,Server 提供的接口需要符合 A2A 协议定义的规范。
五个通信元素
A2A 协议定义了五个核心通信元素。
Agent Card:智能体的"名片"
每个 A2A Server 都需要对外公开一份Agent Card,这是一个 JSON 格式的元数据文档,通常挂在/.well-known/agent.json路径下。
Agent Card 相当于这个 Agent 的"数字名片",告诉外界:
- 我是谁(名称、描述、版本)
- 我在哪里(服务端点 URL)
- 我能做什么(技能列表 skills)
- 我支持哪些通信能力(流式传输、推送通知)
- 如何验证身份(认证要求)
一个旅行助手的 Agent Card 大概长这样:
{ "name": "智能旅行助手", "description": "专业的旅行规划和预订服务", "url": "https://api.travelagent.com/a2a", "version": "1.0.0", "capabilities": ["streaming", "pushNotifications"], "authentication": { "schemes": ["Bearer"] }, "skills": [ { "id": "flight-booking", "name": "航班预订", "description": "搜索和预订国际航班", "inputModes": ["text", "data"], "outputModes": ["text", "data"] } ] }Client Agent 在决定调用哪个 Server 之前,会先读取对方的 Agent Card,确认它具备所需能力,再发起请求。
Task:一次完整任务的生命周期
Task是 A2A 协议里最核心的概念,代表一次完整的端到端协作实例。
用两个类比来理解:你去行政部门办理毕业证,这个"申请毕业证"的流程从提交申请到最终拿到证书,全程就是一个 Task——有唯一 ID,有明确状态,可以暂停、继续、取消。
持续交互也体现在 Task 上:对 AI 说"画一个风筝"是一个 Task,然后说"改成红色"、“加上云朵”,这些指令都在同一个 Task 上下文里累积,Agent 知道它们是同一件事。
Task 的完整生命周期包含以下状态:
Task 有几个设计亮点:
- 有状态:不同于无状态的 HTTP 请求,Task 维护完整的生命周期状态
- 上下文关联:多个 Task 可以通过
contextId归属于同一会话,方便管理关联交互 - 持续交互:同一个 Task 内可以多轮对话,累积上下文
- 历史记录:Task 可以携带历史消息,让 Agent 了解对话的完整上下文
Message:一次信息交换
Message代表 Client 和 Server 之间的一次信息交换,类似于对话中的一条消息。
每条 Message 有两个角色:
user:表示消息来自 A2A Client 端agent:表示消息来自 A2A Server 端
一条 Message 包含一个或多个Part,支持文本、文件、结构化数据等多种内容形式。每条消息还带有唯一的messageId,以及可选的元数据字段。
值得提前说明的是:Message 是过程中的沟通(进度更新、追问、确认),Artifact 才是任务的最终产出(报告、代码、图片)。这个区分在后面的 Artifact 章节会进一步展开。
Part:内容的原子单元
Part是构成 Message 和 Artifact 的最小内容单元,分三种类型:
| Part 类型 | 用途 | 典型场景 |
|---|---|---|
| TextPart | 纯文本 | 指令、问题、文字回答 |
| FilePart | 文件传输 | 文档、图片、数据文件 |
| DataPart | 结构化数据 | JSON 表单、参数、机器可读信息 |
这种设计让 A2A 协议天然支持多模态交互。一条消息里可以同时包含文字说明和图片附件,Agent 可以根据需要组合不同类型的 Part。
Artifact:任务的最终产出
Artifact(工件)代表 Task 完成后的输出结果。
当 Agent 完成任务时,结果通过 Artifact 对象返回,而不是直接塞在 Message 里。这个区分很有意思:
- Message是过程中的沟通,比如进度更新、询问确认
- Artifact是最终的交付物,比如生成的报告、代码、图片
Artifact 的几个特点:
内容通常是不可变的(一旦生成不再修改)
一个 Task 可以生成多个 Artifact
支持流式传输(大文件可以分块推送)
同样由一个或多个 Part 组成
三种交互机制
A2A 协议支持三种交互模式,根据任务特点选择:
- 请求/响应
- 适用场景:简单查询、秒级快速任务
- 技术实现:HTTP 请求,客户端按需轮询状态
- 特点:实现简单;长任务需反复轮询,效率较低
- 流式传输(Server-Sent Events)
- 适用场景:实时更新、增量结果(如 LLM 生成文字)
- 技术实现:SSE,服务端主动向客户端推送事件流
- 特点:实时性好,用户体验流畅;需维持持续连接
- 推送通知(Webhook)
- 适用场景:长期异步任务(分钟/小时级别)
- 技术实现:客户端注册 Webhook,服务端完成后主动回调
- 特点:客户端无需保持连接;部署和实现相对复杂
能力发现:Agent 怎么找到彼此
多智能体系统中,Client 需要知道"有哪些 Agent 可以用,它们能做什么"。A2A 协议设计了一套完整的能力发现机制,分三种方式:
Well-Known URI 发现
最直接的方式,访问标准路径即可:
GET https://{智能体服务器域名}/.well-known/agent.jsonServer 在这个标准路径提供 Agent Card,Client 通过 HTTP 请求获取。简单直接,适合已知服务器地址的场景。
目录式发现(Agent Registry)
Server 将自己的 Agent Card 注册到一个中央注册表,Client 通过查询注册表来发现可用的 Agent。
这种方式适合大规模的 Agent 生态系统,比如企业内部的 Agent 市场,或者行业联盟维护的公共目录。
私有发现
Client 直接在配置里写死 Agent Card 信息。适合内部系统,安全可控,不需要依赖外部注册表。
发现之后:能力匹配与动态重配置
找到 Agent 只是第一步,之后还有两个关键环节:
能力匹配:Client 读取 Agent Card 中的skills列表,根据任务需求(输入/输出类型、标签、业务领域)过滤出合适的 Agent。比如任务需要"生成财务报表",就去找声明了对应 skill 的 Agent,而不是随机选一个。
动态重配置:任务完成后,或者发现当前 Agent 能力不足时,Client 可以重新查询 Agent Registry,匹配新加入或升级的 Agent。这让整个系统在运行时也能动态适配变化——不需要重启服务就能接入新能力。
这两点是 A2A 比直接写死 API 地址更灵活的地方。
发现之后的完整流程
Client 找到合适的 Agent 之后,完整的协作流程大致如下:
发现标准化 + Task 生命周期 + 三种通信机制,这三者组合起来基本覆盖了 Agent 协作的所有场景。
用 Eino 框架跑起来
理论说够了,来看看实际代码。这里用 CloudWeGo 开源的 Eino Go 框架演示如何用 A2A 协议搭建 Agent 服务端和客户端。
先安装依赖:
go get github.com/cloudwego/eino go get github.com/cloudwego/eino-ext/a2a go get github.com/cloudwego/hertz服务端:把 Agent 暴露为 A2A 服务
func main() { ctx := context.Background() h := hertzServer.Default() // 注册 A2A 路由 r, _ := jsonrpc.NewRegistrar(ctx, &jsonrpc.ServerConfig{ Router: h, HandlerPath: "/a2a", }) // 创建 LLM 模型 chatModel, _ := ollama.NewChatModel(ctx, &ollama.ChatModelConfig{ BaseURL: "http://localhost:11434", Model: "Qwen3-32B", }) // 创建 Agent chatAgent, _ := adk.NewChatModelAgent(ctx, &adk.ChatModelAgentConfig{ Name: "book-recommender", Description: "A book recommender agent", Instruction: "根据用户输入,推荐5本相似的书籍", Model: chatModel, }) // 将 Agent 注册为 A2A 服务 eino.RegisterServerHandlers(ctx, chatAgent, &eino.ServerConfig{ Registrar: r, }) h.Run() }核心是最后两步:创建 Agent,然后通过RegisterServerHandlers把它包装成符合 A2A 协议的 HTTP 服务。框架会自动处理 Agent Card 生成、Task 生命周期管理、SSE 流式响应等细节。
客户端:调用远程 Agent
func main() { ctx := context.Background() // 连接到 A2A 服务 t, _ := jsonrpc.NewTransport(ctx, &jsonrpc.ClientConfig{ BaseURL: "http://127.0.0.1:8888", HandlerPath: "/a2a", }) aClient, _ := client.NewA2AClient(ctx, &client.Config{Transport: t}) // 创建支持流式的 Agent 代理 streaming := true a, _ := eino.NewAgent(ctx, eino.AgentConfig{ Client: aClient, Streaming: &streaming, }) // 发起任务,流式接收结果 runner := adk.NewRunner(ctx, adk.RunnerConfig{Agent: a, EnableStreaming: true}) run := runner.Run(ctx, []adk.Message{ schema.UserMessage("recommend a fiction book to me"), }) for { next, ok := run.Next() if !ok { break } fmt.Printf("%v\n", next.Output.MessageOutput.Message.Content) } }客户端的代码跟调用本地 Agent 几乎没有区别,底层的 A2A 协议通信被框架完全屏蔽了。
总结
A2A 协议解决的是一个很实际的问题:多智能体系统里,Agent 之间如何标准化通信。
它的设计思路清晰:用Agent Card声明能力,用Task跟踪任务生命周期,用Message/Part/Artifact承载交互内容,用三种交互机制适配不同场景,用能力发现机制让 Agent 生态可以动态扩展。
从工程角度看,A2A 的价值在于:不同团队开发的 Agent 只要遵循这套协议,就可以互相调用,不需要关心对方用的是什么框架、什么语言。这是构建大规模 Agent 协作系统的基础。
目前 A2A 还在活跃发展中,配套的工具链(比如 Eino 框架的支持)也在逐步完善。如果你正在探索多智能体架构,A2A 是一个值得关注的标准方向。
说真的,这两年看着身边一个个搞Java、C++、前端、数据、架构的开始卷大模型,挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis,稳稳当当过日子。
结果GPT、DeepSeek火了之后,整条线上的人都开始有点慌了,大家都在想:“我是不是要学大模型,不然这饭碗还能保多久?”
我先给出最直接的答案:一定要把现有的技术和大模型结合起来,而不是抛弃你们现有技术!掌握AI能力的Java工程师比纯Java岗要吃香的多。
即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地!大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇!
这绝非空谈。数据说话
2025年的最后一个月,脉脉高聘发布了《2025年度人才迁徙报告》,披露了2025年前10个月的招聘市场现状。
AI领域的人才需求呈现出极为迫切的“井喷”态势
2025年前10个月,新发AI岗位量同比增长543%,9月单月同比增幅超11倍。同时,在薪资方面,AI领域也显著领先。其中,月薪排名前20的高薪岗位平均月薪均超过6万元,而这些席位大部分被AI研发岗占据。
与此相对应,市场为AI人才支付了显著的溢价:算法工程师中,专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%;产品经理岗位中,AI方向的产品经理薪资也领先约20%。
当你意识到“技术+AI”是个人突围的最佳路径时,整个就业市场的数据也印证了同一个事实:AI大模型正成为高薪机会的最大源头。
最后
我在一线科技企业深耕十二载,见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事,早已在效率与薪资上形成代际优势,我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。
我整理出这套 AI 大模型突围资料包【允许白嫖】:
- ✅从入门到精通的全套视频教程
- ✅AI大模型学习路线图(0基础到项目实战仅需90天)
- ✅大模型书籍与技术文档PDF
- ✅各大厂大模型面试题目详解
- ✅640套AI大模型报告合集
- ✅大模型入门实战训练
这份完整版的大模型 AI 学习和面试资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
①从入门到精通的全套视频教程
包含提示词工程、RAG、Agent等技术点
② AI大模型学习路线图(0基础到项目实战仅需90天)
全过程AI大模型学习路线
③学习电子书籍和技术文档
市面上的大模型书籍确实太多了,这些是我精选出来的
④各大厂大模型面试题目详解
⑤640套AI大模型报告合集
⑥大模型入门实战训练
👉获取方式:
有需要的小伙伴,可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓