如何通过A2A协议掌握多Agent协作中的Agent通信技巧？
摘要：本文介绍了A2A的三个主要角色（User、Client 和 Remote Agent）和 四个核心对象（Agent Card、Task、Artifact 和 Message），并通过简单的例子介绍了A2A协议的典型工作流程，相信对于你加深了
大家好，我是Edison。
上一篇，我们了解了A2A协议的基本概念，还通过A2A组件实现了一个Hello World的Demo，有了一个快速的感性认识。这一篇，我们来了解下A2A协议的三大角色、四大对象 以及 工作流程，有了这些基础的认知后会对我们全面认识A2A有所帮助。
A2A协议的三大角色
A2A 即 Agent-to-Agent，它定义了三个关键的角色，它们各司其职+互相配合，支撑多个Agent的运行。
那么，都是哪几个角色呢？下面告诉你：
角色1：用户（User）
即终端用户（可能是人类 或 服务），需要使用Agent来完成某个任务。
角色2：客户端（Client）
一个代表用户向 远程Agent 发送请求的实体，它发送的请求是严格按照A2A协议的。它的表现形式可以是一个应用程序、服务 或 一个Agent。
例如，我们在上一篇的Demo中开发的一个控制台应用程序通过引用A2A包来向远端的Agent发送请求。
角色3：远程Agent（Remote Agent）
一个执行实际任务的Agent（部署在某个远端Server上），对于客户端来说是“黑盒”一样的存在，仅仅通过Agent Card声明自己提供的接口或技能，但内部实现细节或工作机制是不透明的，即一个“黑盒”。
例如，我们在上一篇的Demo中开发的一个WebAPI项目EchoAgent，提供了一个ProcessMessage的技能 以及 声明了一个AgentCard公开了一些元数据。
A2A的四大对象
A2A中定义了一套完整的对象体系，其中最核心的就是下面这四个核心对象：
第一个对象：Agent Card（又称Agent名片）
每个A2A的远程Agent都需要发布一个JSON格式的名片，被称为“Agent Card”，用于描述这个Agent具有哪些技能 及其 认证机制，便于Client可以获得这些信息并选择合适的Agent来完成任务。
其实，它就和我们在做后端服务开发中的服务注册和发现的机制差不多，只不过这个注册的信息被标准化了，下面我们可以看看一个典型的Agent Card的JSON格式：
{
"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"
],
"outputModes": ["application/html", "video/mp4"]
}
]
}
这个JSON数据简要描述了一个名为"Google Maps Agent"的Agent定义。这个Agent的主要功能是规划路线、记住地点和生成导航指示。这个应用由Google提供，版本号是1.0.0，采用OAuth2身份验证。它支持文本和HTML格式的输入和输出，具有流媒体功能，但不支持推送通知。