Google A2A协议详解:实现两个Agent对接的完整指南
A2A协议概述
什么是A2A协议? A2A(Agent-to-Agent)协议是由Google于2025年4月9日推出的一个开放通信协议,旨在让不同AI智能体(Agent)之间能够互相沟通、协作、派发任务并同步结果【1†source】。它的核心目标是解决“多个智能体如何像一个团队一样配合工作”的问题【1†source】。通过A2A协议,原本孤立运行的AI代理可以跨越不同框架和供应商的界限,实现跨平台、跨组织的协同工作,从而打破系统孤岛,释放智能体的集体潜力【2†source】。
为何需要A2A协议? 在A2A出现之前,不同AI代理往往各自为政,缺乏统一的“语言”进行交流。例如,一个企业可能同时使用多个来自不同供应商的AI助手(如Atlassian的Jira助手、Salesforce的智能客服、SAP的财务助手等),这些助手无法直接对话,导致用户需要手动在它们之间传递信息,效率低下【2†source】。A2A协议的推出正是为了填补这一空白,它为智能体提供了一套标准化的交互规则,使得它们能够像团队成员一样协作,共同完成复杂任务【1†source】。这标志着智能体生态从“孤立运行”迈向“开放协作”的关键转折【10†source】。
A2A协议的意义。 谷歌联合了包括Salesforce、SAP、ServiceNow、MongoDB等在内的50多家企业共同参与A2A协议的制定与推广【2†source】。这种广泛的行业支持意味着A2A有望成为智能体领域的“通用语言”,类似互联网世界的HTTP协议【13†source】。通过A2A,企业可以更轻松地集成来自不同厂商的AI服务,构建“数字工作团队”,提升自动化水平和生产效率【2†source】。同时,A2A作为一项开源协议,鼓励开发者社区共同参与,有望催生一个繁荣的“智能体经济”【10†source】。
A2A协议的核心概念与架构
A2A协议通过定义一系列标准化的接口和数据结构,为智能体之间的通信提供了清晰的框架【1†source】。下面将从核心参与者、关键组件、通信机制等方面进行深入解析。
核心参与者
A2A协议定义了三个主要的参与角色【3†source】:
- 用户(User):最终的使用者,可以是人类用户或自动化系统,负责发起任务请求或定义需要多个智能体协作完成的目标【3†source】。
- 客户端智能体(Client Agent):代表用户向其他智能体请求操作的实体【3†source】。客户端负责解析用户需求,构造符合A2A协议的请求,并将任务委派给合适的远程智能体执行。
- 远程智能体(Remote Agent):一个不透明(黑盒)的远程代理,即A2A服务器【3†source】。远程智能体接收来自客户端的请求,执行具体的任务,并将结果或状态更新返回给客户端。
这种角色划分使得A2A协议能够支持客户端-服务器模式的交互:客户端负责发起和协调任务,远程智能体负责执行任务【11†source】。值得注意的是,一个智能体在不同交互中既可以充当客户端,也可以充当服务器,这取决于它在某次协作中是发起任务还是执行任务【12†source】。
关键组件
A2A协议围绕几个核心概念构建,这些概念共同确保了智能体之间能够发现彼此、理解能力、交换信息并协同完成任务【5†source】。以下是A2A协议的关键组件:
Agent Card(智能体名片)
Agent Card是A2A协议中用于能力发现的核心组件【4†source】。它是一个标准的JSON元数据文件,通常托管在智能体的/.well-known/agent.json路径下,供其他智能体或客户端获取【4†source】。Agent Card相当于智能体的“名片”,详细描述了该智能体的身份、能力、服务端点以及认证要求等信息【4†source】。通过读取Agent Card,客户端可以了解一个智能体能做什么(支持的技能和功能)、如何与之交互(支持的输入/输出格式、通信模式)以及如何安全地访问它(所需的认证方案)【4†source】。这种机制实现了智能体的动态发现:客户端无需预先硬编码对远程智能体的了解,只需通过标准接口获取其Agent Card,即可判断该智能体是否适合处理特定任务【4†source】。Agent Card的标准化结构包括智能体的名称、描述、版本、提供者信息、能力(如是否支持流式传输或推送通知)、默认的输入输出模式、技能列表以及认证方式等【4†source】。例如,一个智能体可以在Agent Card中声明自己支持文本和图像两种输入模式,具备“翻译”和“图像识别”两项技能,并要求使用API密钥进行认证【4†source】。这些信息对于客户端选择合适的智能体以及正确地与之交互至关重要。
Task(任务)
Task是A2A协议中的基本工作单元,代表客户端请求远程智能体完成的一项具体任务【5†source】。每个Task都有一个唯一的ID,用于跟踪其状态和结果【5†source】。Task具有完整的生命周期管理,其状态可以包括“已提交”(submitted)、“处理中”(working)、“等待输入”(input-required)、“已完成”(completed)、“已取消”(canceled)或“失败”(failed)等【5†source】。这种生命周期机制确保了任务从发起、执行到结果返回的全过程都可被监控和管理【5†source】。例如,当客户端通过A2A协议提交一个任务后,远程智能体会首先将其状态置为“submitted”,随后开始处理,状态更新为“working”。如果在处理过程中需要用户进一步的信息(例如在多轮对话中需要澄清),则状态会变为“input-required”,等待客户端提供额外输入后再继续【5†source】。最终,任务会达到“completed”(成功完成)或“failed”(执行失败)的终止状态【5†source】。Task机制为长时间运行的任务提供了良好的支持,因为客户端可以通过订阅状态更新来实时了解任务进展,而无需反复轮询【5†source】。
Message(消息)
Message是客户端与智能体之间交换信息的载体【5†source】。每条Message都有一个角色(role),用于标识消息的发送者,可以是“user”(用户)或“agent”(智能体)【5†source】。Message的内容由一个或多个Part组成【5†source】。Part是消息的基本内容单元,可以是文本、文件或结构化数据【5†source】。例如,一个Message可以包含一个文本Part(用户的问题)和一个文件Part(用户上传的图片),从而实现多模态的信息传递【5†source】。Message机制支持智能体之间进行多轮对话:客户端可以发送初始Message启动任务,智能体在处理过程中或完成后返回包含结果的Message,如果需要,客户端还可以发送后续Message提供更多输入或指令【5†source】。这种设计使得A2A协议能够处理复杂的交互场景,例如需要上下文澄清或人机协作的任务。
Artifact(工件)
Artifact是智能体在执行任务过程中生成的输出结果【5†source】。它可以是一个文档、一张图片、一段视频、一份结构化数据报告等【5†source】。与Message类似,Artifact也由多个Part组成,用于承载不同类型的内容【5†source】。例如,一个任务完成后,智能体可以返回一个Artifact,其中包含一个文本Part(任务执行的总结报告)和一个文件Part(生成的PDF文档)【5†source】。Artifact机制确保了任务结果的结构化交付:客户端可以按照预定义的格式获取智能体的输出,便于后续处理或展示【5†source】。此外,A2A协议支持在任务执行过程中增量返回Artifact,这对于长时间运行的任务尤为重要,客户端可以逐步获取部分结果,而不必等待整个任务完成【5†source】。
Push Notifications(推送通知)
推送通知是A2A协议提供的一种可选机制,用于在任务状态发生变化时,由服务端主动通知客户端,而无需客户端频繁轮询【5†source】。这对于长时间运行的任务或客户端可能离线的场景尤为有用【5†source】。客户端可以在发起任务时或之后,通过tasks/pushNotification/set接口提供一个回调URL(Webhook),以及可选的认证令牌【5†source】。当任务状态发生重要变化(例如从“working”变为“completed”)时,服务端会向该回调URL发送一个HTTP POST请求,将更新信息推送给客户端【5†source】。这种机制提高了系统的实时性和效率,特别是在客户端无法保持持久连接(如移动端应用或无服务器函数)的情况下,仍能及时收到任务更新【2†source】。同时,A2A协议也支持客户端通过订阅SSE(Server-Sent Events)来获取实时更新,这为推送通知提供了另一种实现方式【2†source】。
Streaming(流式传输)
流式传输是A2A协议支持的一种高级功能,用于处理长时间运行的任务或需要实时反馈的场景【2†source】。通过SSE,服务端可以持续向客户端推送任务状态更新和部分结果,而不必等待整个任务完成【2†source】。客户端在发起任务时,可以选择使用tasks/sendSubscribe接口,以订阅SSE流【2†source】。一旦任务开始执行,服务端会通过SSE发送一系列事件,包括TaskStatusUpdateEvent(任务状态更新)和TaskArtifactUpdateEvent(任务工件更新)【2†source】。例如,在生成一份长文档的任务中,智能体可以每完成一部分就通过SSE发送一个Artifact更新事件,让客户端能够实时查看已生成的内容【2†source】。流式传输机制确保了在高延迟或人机交互的任务中,用户能够获得即时的反馈,提升用户体验【2†source】。同时,A2A协议还定义了断线重连的机制(通过tasks/resubscribe方法),以应对网络不稳定的情况,保证客户端在重新连接后能够继续获取任务的后续更新【2†source】。
通信机制与交互流程
A2A协议的通信基于现有的成熟Web标准,包括HTTP、JSON-RPC 2.0和SSE等【2†source】。这种设计确保了协议的易用性和兼容性,开发者可以利用熟悉的Web技术栈来实现智能体之间的通信【2†source】。下面将介绍A2A协议的通信机制以及典型的交互流程。
通信协议基础。 A2A协议使用HTTP作为底层传输协议,并采用JSON-RPC 2.0格式来封装请求和响应【2†source】。JSON-RPC是一种轻量级的远程过程调用协议,它定义了请求对象(包含方法名、参数和ID)和响应对象(包含结果或错误以及对应的ID)的结构【2†source】。通过JSON-RPC,A2A协议能够以结构化的方式调用远程智能体的方法,并获取返回值【2†source】。例如,客户端可以通过发送一个JSON-RPC请求来调用远程智能体的tasks/send方法,以提交一个新任务【2†source】。同样地,远程智能体对任务的响应也是以JSON-RPC格式返回,其中包含任务的状态、结果或错误信息【2†source】。这种基于JSON-RPC的通信方式使得A2A协议能够跨语言、跨平台工作,因为JSON-RPC和HTTP在主流编程语言和框架中都有广泛支持【2†source】。
典型的交互流程。 一个完整的A2A交互通常包括以下几个关键步骤【4†source】:
- 服务发现与认证:客户端首先需要发现目标智能体并获取其能力信息。这通过读取目标智能体的Agent Card来实现【4†source】。Agent Card通常托管在标准的URL路径(如
https://agent.example.com/.well-known/agent.json),客户端只需发送一个HTTP GET请求即可获取【4†source】。通过解析Agent Card,客户端可以了解该智能体支持哪些技能、使用何种认证方式、支持哪些输入输出模式等【4†source】。如果智能体要求认证,客户端需要在后续请求中提供相应的凭据(如API密钥或OAuth令牌)【4†source】。这一步确保了客户端与智能体之间的安全连接和能力匹配。 - 任务初始化:客户端根据用户需求构造一个任务请求,并通过A2A协议将其发送给远程智能体【4†source】。任务请求通常使用
tasks/send或tasks/sendSubscribe方法【2†source】。请求中包含一个唯一的任务ID、初始的Message(用户的问题或指令)以及可选的配置(如是否启用流式传输)【2†source】。远程智能体接收到请求后,会创建一个Task对象,并将状态置为“submitted”,然后返回给客户端一个确认响应,其中包含任务ID和初始状态【2†source】。此时,任务的生命周期正式开始。 - 任务处理:远程智能体开始执行任务。在执行过程中,智能体可能需要与用户进行交互,例如请求更多输入或澄清【4†source】。A2A协议支持多轮对话:如果任务进入“input-required”状态,智能体会通过Message向客户端发送一个请求,要求提供额外信息【4†source】。客户端收到后,可以发送包含用户输入的新Message,继续任务【4†source】。这种机制使得智能体能够处理复杂、需要人机协作的任务,例如在用户未提供足够信息时,智能体可以主动提问【4†source】。对于长时间运行的任务,智能体可以周期性地更新任务状态(例如从“working”变为“working”,并附带进度百分比),并通过SSE或推送通知告知客户端【2†source】。这保证了客户端能够实时了解任务的进展。
- 结果获取:当任务执行完成或失败时,远程智能体会将最终结果返回给客户端【4†source】。如果任务成功完成,智能体会返回一个包含结果的Artifact【4†source】。Artifact中可能包含文本报告、生成的文件、结构化数据等,取决于任务的性质【4†source】。客户端可以通过解析Artifact来获取任务的输出。如果任务失败,智能体则返回一个错误响应,其中包含错误代码和描述,帮助客户端了解失败原因【4†source】。无论成功与否,任务都会进入一个终止状态(“completed”或“failed”),客户端可以据此判断任务是否结束【4†source】。
通过上述流程,A2A协议实现了客户端智能体与远程智能体之间的协同工作:客户端负责发起和协调任务,远程智能体负责执行任务并返回结果【11†source】。这种职责分离使得多个智能体可以像一个团队一样配合,共同完成用户的目标。
A2A协议的设计原则
Google在设计A2A协议时遵循了五个关键原则,这些原则确保了协议的灵活性、安全性和与企业现有系统的兼容性【2†source】。理解这些原则有助于更好地把握A2A协议的定位和价值。
- 拥抱智能体能力(Unleashing Agent Power):A2A协议专注于让智能体以自然、非结构化的方式进行协作,即使它们不共享内存、工具或上下文【2†source】。这意味着A2A并不试图将智能体局限为单一的“工具”,而是允许它们以各自的原生模式工作,从而实现真正的多智能体场景【2†source】。智能体可以保持其内部的独立性和不透明性,只需通过A2A协议交换必要的信息即可协同完成任务【2†source】。这种设计尊重了智能体的自主性,使其能够充分发挥各自的优势。
- 基于现有标准构建(Built on Existing Standards):A2A协议并非凭空创造全新的技术栈,而是建立在广泛接受且成熟的标准之上,包括HTTP、SSE(Server-Sent Events)和JSON-RPC等【2†source】。这种选择极大地降低了A2A协议的采用门槛,因为开发者无需学习全新的协议或技术,只需利用熟悉的Web技术即可实现智能体之间的通信【2†source】。同时,基于现有标准也意味着A2A协议能够无缝集成到企业现有的IT基础设施中,无需大规模改造【2†source】。例如,企业可以使用现有的API网关、负载均衡器、监控系统等来管理A2A通信,从而加速协议的落地。
- 默认安全(Secure by Default):安全性是A2A协议的核心考量之一【2†source】。协议在设计上支持企业级的身份验证和授权,其安全级别与OpenAPI规范对等【2†source】。A2A协议要求智能体在Agent Card中明确声明其认证要求,并支持多种认证方案(如API密钥、OAuth 2.0、JWT等)【4†source】。此外,协议推荐使用HTTPS进行通信,确保数据在传输过程中的机密性和完整性【4†source】。通过将安全作为默认要求,A2A协议旨在让企业能够放心地让不同智能体之间交换敏感数据,而无需担心未经授权的访问或数据泄露【2†source】。
- 支持长时间运行的任务(Support for Long-running Tasks):A2A协议设计灵活,能够处理从快速任务到可能需要数小时甚至数天的复杂研究等各种场景【2†source】。对于长时间运行的任务,协议提供了实时反馈、通知和状态更新的机制【2†source】。例如,智能体可以通过SSE持续推送任务进度,或者在任务完成时通过Webhook通知客户端【2†source】。这种能力确保了用户或客户端无需一直等待,可以及时了解任务的进展,这对于需要人工介入或计算密集型的任务尤为重要【2†source】。同时,A2A协议也支持任务的暂停与恢复(通过任务ID和会话ID),使得长时间任务可以分阶段进行,提高系统的健壮性。
- 模态无关(Modality Agnostic):A2A协议并不局限于文本交互,它支持多种模态的内容交换,包括音频、视频等【2†source】。这通过Message和Artifact中的Part机制实现:Part可以是文本、文件引用或结构化数据,从而允许智能体之间传递图像、音频、视频、表单等不同类型的内容【5†source】。例如,一个智能体可以发送包含音频文件的Message给另一个智能体,请求其进行语音转文本;另一个智能体在完成任务后,可以返回包含视频文件的Artifact【5†source】。这种模态无关的设计使得A2A协议能够适应各种应用场景,无论是纯文本的客服对话,还是包含多媒体的创意协作,都能得到支持【2†source】。
A2A与MCP协议的关系
在讨论A2A协议时,不可避免地会提到由Anthropic公司提出的模型上下文协议(Model Context Protocol,简称MCP)。MCP协议与A2A协议在目标上有所重叠,但侧重点不同,两者之间是互补而非竞争的关系【10†source】。
MCP协议概述。 MCP协议旨在解决智能体与工具/数据之间的交互问题【10†source】。它提供了一种标准方式,让AI模型(或智能体)能够连接各种外部工具和数据源,从而扩展模型的能力【10†source】。可以将其理解为一种“应用商店”协议:智能体通过MCP可以方便地调用各种工具(如数据库查询、API调用、文件操作等)并获取上下文信息,就像用户在手机上安装各种应用一样【10†source】。MCP协议关注的是单个智能体如何更有效地利用外部资源,提升其内部能力【10†source】。
A2A与MCP的互补性。 相比之下,A2A协议关注的是智能体与智能体之间的交互【10†source】。它并不直接涉及智能体内部如何使用工具,而是解决多个智能体如何协同工作的问题【10†source】。简而言之,MCP让智能体“更聪明”(通过连接工具和数据),A2A让智能体“更团结”(通过彼此通信协作)【10†source】。这两者可以结合使用,以构建更强大的AI系统【10†source】。例如,一个智能体可以通过MCP调用外部工具来增强自身能力,同时通过A2A与其他智能体协作来完成任务。这种结合可以实现1+1>2的效果:智能体既拥有强大的工具支持,又能够与其他智能体协同,从而处理更复杂的任务【10†source】。
如何结合使用A2A和MCP。 一种可能的架构是:将每个智能体视为一个MCP的“资源”,并通过A2A协议让这些智能体相互发现和调用【10†source】。具体而言,每个智能体可以提供一个Agent Card,其中列出它通过MCP支持的技能(即它可以调用的工具)【10†source】。其他智能体通过A2A发现该智能体后,可以发送任务请求,要求它使用特定的MCP工具来完成某项工作【10†source】。这样,A2A负责智能体间的“对话”,MCP负责智能体“做事”的能力,两者协同工作,构建一个既开放又强大的AI生态系统【10†source】。谷歌官方也建议将A2A智能体建模为MCP资源,通过A2A实现智能体间的通信,从而与现有的MCP基础设施相融合【10†source】。
A2A协议的实践应用
A2A协议的推出为AI智能体在企业中的实际应用带来了广阔的前景。通过A2A,企业可以构建跨部门、跨系统的智能体协作网络,实现工作流程的自动化和智能化。下面将从企业级应用场景和开源生态支持两个方面进行介绍。
企业级应用场景
A2A协议在企业环境中有着丰富的应用场景,能够显著提升效率和自动化水平。以下列举几个典型的例子:
- 招聘流程自动化:假设一家公司需要招聘一名软件工程师。招聘经理可以通过统一的界面(如Google的Agentspace)向自己的HR智能体下达指令:“帮我找到符合这个职位描述、在这个地区、具备这些技能的候选人”【13†source】。HR智能体接收到任务后,会自动联系其他专业智能体协同工作:一个负责在LinkedIn上搜索简历,一个负责筛选候选人,一个负责安排面试,还有一个负责背景调查【13†source】。这些智能体分别来自不同的平台(如LinkedIn、面试系统、背景调查服务),但通过A2A协议,它们可以无缝地交换信息、协调任务,最终将一份完整的候选人名单和面试安排反馈给招聘经理【13†source】。整个过程无需人工干预,极大提升了招聘效率。
- 客户服务与支持:在客户服务场景中,A2A协议可以让多个专业智能体协同为客户提供更优质的服务。例如,一个电商平台的客服智能体在接收到用户关于“订单物流”的咨询时,可以通过A2A将任务委派给物流查询智能体,获取订单的实时物流状态;如果用户询问“产品使用方法”,客服智能体可以调用产品知识库智能体获取详细的使用指南;如果用户提出“退换货”请求,客服智能体则可以联系库存和订单管理智能体来处理退换货流程【13†source】。通过A2A,这些原本孤立的系统(物流、知识库、库存)可以协同工作,为客户提供一站式、无缝的服务体验,而无需用户在不同系统之间来回切换。
- 金融与财务分析:在金融领域,A2A协议可以用于构建多智能体协作的分析系统。例如,一个投资分析智能体在接收到“分析某股票的投资价值”的任务时,可以同时调用多个专业智能体:一个负责获取最新的财务报表数据,一个负责进行技术分析(如趋势、指标计算),一个负责进行基本面分析(如行业对比、估值模型),还有一个负责综合所有信息并生成投资建议报告【13†source】。这些智能体可能分别部署在不同的系统上(财务数据库、行情分析服务、报告生成系统),但通过A2A协议,它们可以共享信息、协同工作,最终输出一份全面的分析报告给用户。这种协作方式比单一智能体更加全面和准确,因为每个智能体都专注于自己的领域,并通过A2A实现了优势互补。
- 智能制造与物联网:在工业4.0和智能制造场景中,A2A协议也有广泛的应用潜力。例如,一个工厂的中央调度智能体可以协调多个设备智能体协同完成生产任务。当生产线出现故障时,设备智能体可以通过A2A通知调度智能体,调度智能体再委派维修智能体进行诊断,同时通知供应链智能体暂停相关物料的供应。维修智能体在诊断过程中,可能需要调用传感器数据智能体获取实时设备状态,或者调用知识库智能体查找维修手册。所有这些智能体通过A2A协议实时交换信息,确保故障得到快速、准确的响应,减少停机时间。此外,在智能家居场景中,A2A协议可以让各种设备(如智能灯泡、音响、安防摄像头)协同工作,根据用户的需求提供连贯的服务体验【13†source】。
这些场景只是冰山一角。A2A协议的开放性和标准化意味着它几乎可以应用于任何需要多个AI系统协同工作的领域,从供应链优化、医疗诊断辅助到创意内容生成等,都能通过A2A实现更高效的自动化流程。
A2A协议的开源生态与支持
A2A协议自发布以来,就得到了业界的广泛关注和积极参与。谷歌开源了A2A协议的规范和示例代码,并联合了众多企业共同推动其发展【2†source】。这种开放的模式为A2A协议的生态繁荣奠定了基础。
开源协议与示例。 A2A协议的规范和实现细节都是公开的,开发者可以自由地获取、学习和贡献【2†source】。谷歌在GitHub上提供了官方的A2A示例代码库(google/A2A),其中包含多种语言的实现示例(如Python、Go等)【14†source】。这些示例涵盖了从简单的“回声”智能体到复杂的货币转换智能体等不同场景,为开发者提供了上手实践的起点【14†source】。通过开源,谷歌希望降低A2A协议的采用门槛,鼓励社区共同完善协议规范和实现。
企业参与和联盟。 除了开源,A2A协议还吸引了众多企业的直接参与和支持。在协议发布之初,就有包括Salesforce、SAP、ServiceNow、MongoDB等在内的50多家企业宣布加入A2A协议的阵营【2†source】。这些企业涵盖了从企业软件、数据库到云服务的各个领域,它们的加入意味着A2A协议将在各自的平台上得到原生支持【2†source】。例如,Salesforce可能在其CRM智能体中内置A2A支持,SAP可能在其ERP智能体中支持A2A,ServiceNow可能在其IT服务管理智能体中支持A2A,等等。这种跨行业的联盟极大地增强了A2A协议的影响力和实用性,因为它意味着企业无需自行开发定制接口,就可以直接利用A2A将不同厂商的智能体连接起来【2†source】。随着更多企业的加入,A2A协议的商业价值将得到指数级提升,推动整个智能体生态的快速发展【6†source】。
开发者工具和资源。 为了帮助开发者快速上手A2A协议,谷歌及其合作伙伴也提供了丰富的工具和资源。谷歌发布了Agent Development Kit (ADK),这是一个用于构建智能体的开发套件,支持多种编程语言和框架【4†source】。ADK内置了对A2A协议的支持,开发者可以方便地使用ADK来创建符合A2A标准的智能体【4†source】。此外,谷歌还推出了Agent Engine,这是一个内部测试工具,用于模拟和调试智能体之间的交互【4†source】。社区方面,也有开发者创建了各种A2A相关的库和工具,例如用于Python的a2a-sdk(官方Python SDK)【24†source】、用于Go的trpc-a2a-go【5†source】等。这些工具降低了开发A2A兼容智能体的技术门槛,加速了协议的普及。
总之,A2A协议正朝着构建一个开放、繁荣的智能体生态系统迈进。开源协议提供了标准,企业参与提供了应用场景,开发者工具提供了实现手段,三者相辅相成,共同推动A2A协议成为智能体时代的基石。
使用A2A实现两个Agent对接的步骤
了解了A2A协议的原理和优势后,接下来将通过一个具体的实践示例,演示如何使用A2A协议实现两个Agent之间的对接。本节将以Python为例,从环境搭建到代码实现,一步步讲解如何创建一个简单的A2A服务端和一个客户端,并让它们协同工作。
步骤1:准备开发环境
在开始编码之前,需要先准备好开发环境。A2A协议的实现需要一定的工具和依赖,以下是具体步骤:
- 安装Python:A2A协议的官方示例和SDK主要基于Python,因此需要安装Python 3.10或更高版本【15†source】。建议使用较新的Python版本(如3.12+),以获得更好的性能和兼容性【15†source】。可以通过Python官网或系统包管理器进行安装。
- 安装Git:用于克隆A2A协议的官方示例代码仓库【15†source】。确保系统中已安装Git,并且能够通过命令行使用。
- 克隆A2A示例仓库:打开终端或命令行,运行以下命令来克隆谷歌提供的A2A示例代码库【15†source】:
这将下载A2A协议的Python示例代码到本地,并切换到示例目录【15†source】。示例代码中包含了多个子项目,如git clone https://github.com/google/A2A.git cd A2A/samples/pythonhelloworld(简单的回声智能体)、currency(货币转换智能体)等,供参考和学习【14†source】。 - 创建并激活虚拟环境:为了避免依赖冲突,建议在项目目录下创建一个Python虚拟环境【15†source】。在Windows上,可以使用以下命令:
在macOS或Linux上,可以使用:python -m venv .venv .venv\Scripts\activate
这将创建一个名为python -m venv .venv source .venv/bin/activate.venv的虚拟环境,并激活它【15†source】。激活后,终端提示符通常会发生变化,表示已进入虚拟环境。 - 安装依赖:进入示例代码目录后,需要安装项目所需的Python包以及A2A相关的库【15†source】。运行以下命令来安装依赖:
该命令会读取pip install -r samples/python/requirements.txtrequirements.txt文件,并安装所有列出的依赖包,包括A2A协议的Python SDK、FastAPI(用于构建HTTP服务)、uvicorn(用于运行ASGI服务器)等【15†source】。安装完成后,可以通过运行pip list来确认已安装的包,或者直接尝试导入A2A SDK来验证是否成功【15†source】。如果看到类似“A2A SDK imported successfully”的输出,说明环境准备就绪【15†source】。
经过以上步骤,开发环境已经搭建完毕,可以开始编写A2A兼容的智能体代码了。
步骤2:创建A2A服务端Agent
在本示例中,我们将创建一个简单的回声智能体(Echo Agent)作为A2A服务端。这个智能体的功能非常简单:接收来自客户端的消息,并在消息前加上“Hello”作为问候后返回【12†source】。通过这个示例,可以演示A2A协议的基本通信流程,包括Agent Card的暴露、任务的接收与处理、结果的返回等。
- 定义Agent Card:首先,需要为我们的智能体创建一个Agent Card,用于描述其身份和能力【4†source】。Agent Card是一个JSON对象,通常包含智能体的名称、描述、版本、提供者、支持的技能、认证要求等信息【4†source】。对于回声智能体,Agent Card可以定义如下:
上述Agent Card声明了一个名为“EchoAgent”的智能体,它有一个“Echo Skill”技能,能够回显输入消息并加上问候语【12†source】。该智能体不支持流式传输或推送通知,仅接受纯文本输入并返回纯文本输出【12†source】。由于这是一个示例,我们将其认证方式设为空(即不需要认证)【12†source】。在实际应用中,应根据需要配置相应的认证方案。{ "name": "EchoAgent", "description": "Echoes back your message with a greeting", "url": "http://localhost:8000", "version": "1.0", "capabilities": { "streaming": false, "pushNotifications": false }, "defaultInputModes": ["text/plain"], "defaultOutputModes": ["text/plain"], "skills": [ { "id": "echo", "name": "Echo Skill", "description": "Echoes the input message with a greeting", "tags": ["echo", "greeting"], "examples": ["Hello", "Echo this"], "inputModes": ["text/plain"], "outputModes": ["text/plain"] } ], "authentication": { "schemes": [] } } - 搭建HTTP服务端:A2A协议要求智能体提供一个HTTP端点,用于接收来自客户端的请求【4†source】。我们将使用FastAPI框架来快速搭建一个HTTP服务器,用于处理A2A协议相关的请求【12†source】。创建一个名为
echo_server.py的文件,并编写以下代码:
上述代码使用FastAPI创建了一个简单的HTTP服务器【12†source】。它定义了两个路由:from fastapi import FastAPI, Request from pydantic import BaseModel import uvicorn定义A2A Task结构
class Task(BaseModel): task_id: str message: dict初始化FastAPI应用
app = FastAPI()定义Agent Card(元数据)
agent_card = { "name": "EchoAgent", "description": "Echoes back your message with a greeting", "endpoint": "http://localhost:8000/tasks/send", "capabilities": ["text"], }暴露Agent Card在/.well-known/agent.json
@app.get("/.well-known/agent.json") async def get_agent_card(): return agent_card处理incoming任务
@app.post("/tasks/send") async def handle_task(task: Task): user_message = task.message.get("parts")[0].get("text") response_text = f"Hello, {user_message}" return { "task_id": task.task_id, "state": "completed", "messages": [ {"role": "user", "parts": [{"text": user_message}]}, {"role": "agent", "parts": [{"text": response_text}]} ] }if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0", port=8000)
GET /.well-known/agent.json:用于返回我们之前定义的Agent Card【12†source】。客户端可以通过访问这个URL来获取智能体的元数据。POST /tasks/send:用于接收来自客户端的任务请求【12†source】。我们使用Pydantic的Task模型来解析请求体,提取出用户发送的消息文本,然后构造一个响应消息,在原消息前加上“Hello,”作为问候语【12†source】。最后,返回一个符合A2A协议格式的响应,包含任务ID、状态(这里直接置为“completed”,因为我们的示例是即时完成的)以及对话消息列表【12†source】。
- 运行服务端:保存上述代码后,在终端中运行以下命令来启动我们的EchoAgent服务器:
如果一切正常,你将看到类似如下的输出,表示服务器已启动并监听在8000端口:python echo_server.py
至此,我们的A2A服务端已经准备就绪,可以接收来自客户端的请求了。INFO: Started server process [xxxxx] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
步骤3:创建A2A客户端Agent
接下来,我们将创建一个A2A客户端,用于向之前启动的EchoAgent发送任务请求,并获取响应。客户端将模拟一个用户,向EchoAgent发送一条消息,并打印出EchoAgent返回的问候语。
- 获取Agent Card:客户端首先需要发现并获取目标智能体的Agent Card,以了解其能力和端点【4†source】。在我们的示例中,EchoAgent的Agent Card可以通过
http://localhost:8000/.well-known/agent.json获取【12†source】。客户端可以使用HTTP库(如httpx)发送一个GET请求来获取该JSON文件【12†source】。 - 构造并发送任务请求:获取到Agent Card后,客户端需要构造一个符合A2A协议的任务请求,并通过HTTP POST发送给EchoAgent的
/tasks/send端点【12†source】。任务请求的格式遵循JSON-RPC 2.0规范,包含方法名、参数和请求ID【2†source】。以下是一个示例请求:
上述请求中,{ "jsonrpc": "2.0", "method": "tasks/send", "params": { "id": "task-123", "message": { "role": "user", "parts": [ {"type": "text", "text": "A2A Protocol"} ] } }, "id": 1 }"method": "tasks/send"表示我们要调用远程智能体的tasks/send方法【2†source】。"params"对象包含了任务的具体参数,其中"id"是客户端为任务分配的唯一ID,"message"是用户发送的消息内容【2†source】。消息中包含一个角色为“user”的Part,文本内容为“A2A Protocol”【2†source】。"id": 1是JSON-RPC请求的ID,用于匹配响应【2†source】。 - 发送请求并获取响应:客户端可以使用
httpx库发送上述POST请求,并等待EchoAgent的响应【12†source】。由于EchoAgent是即时完成的,我们预期会收到一个包含结果的响应。响应的格式也是JSON-RPC 2.0,例如:
响应中,{ "jsonrpc": "2.0", "id": 1, "result": { "task_id": "task-123", "state": "completed", "messages": [ {"role": "user", "parts": [{"text": "A2A Protocol"}]}, {"role": "agent", "parts": [{"text": "Hello, A2A Protocol"}]} ] } }"result"字段包含了任务的结果【2†source】。我们可以看到,EchoAgent返回了一个状态为“completed”的任务,以及对话消息列表:第一条是用户发送的消息,第二条是智能体返回的问候语“Hello, A2A Protocol”【12†source】。这正是我们期望的结果。 - 解析响应:客户端在收到响应后,可以解析出智能体返回的消息,并将其呈现给用户。在我们的示例中,客户端可以简单地打印出智能体返回的文本,即“Hello, A2A Protocol”【12†source】。这样,一个完整的A2A交互流程就完成了:客户端发送消息,服务端处理并返回结果,客户端获取并展示结果。
通过上述步骤,我们成功实现了一个简单的A2A客户端-服务器交互示例。这个示例虽然功能简单,但涵盖了A2A协议的核心要素:Agent Card的暴露、任务的发送与接收、消息的传递、结果的返回。开发者可以基于这个基础,进一步扩展智能体的功能,例如添加更多的技能、支持流式传输、集成大模型等,从而构建更复杂的智能体系统。
步骤4:运行与测试
为了验证我们的实现是否正确,可以按照以下步骤运行和测试:
- 启动EchoAgent服务器:确保在终端中运行了
echo_server.py,并且服务器已启动在8000端口【12†source】。如果之前已经启动且没有关闭,可以跳过此步。 - 运行客户端脚本:打开另一个终端,激活相同的虚拟环境,然后运行我们编写的客户端脚本。例如,假设客户端脚本保存为
test_client.py,则运行:python test_client.py - 观察输出:客户端脚本执行后,应该会向EchoAgent发送消息并打印出响应。如果一切正常,你将看到类似如下的输出:
这表示EchoAgent成功接收到了客户端发送的消息“A2A Protocol”,并返回了加上问候语的响应“Hello, A2A Protocol”【12†source】。同时,在EchoAgent服务器的终端日志中,也可以看到收到请求和返回响应的记录,证明通信正常。Hello, A2A Protocol - 验证Agent Card:为了进一步确认,可以直接在浏览器或使用curl访问
http://localhost:8000/.well-known/agent.json,查看EchoAgent的Agent Card是否正确返回【12†source】。你应该会看到我们之前定义的JSON内容,这证明Agent Card的暴露也正常工作。
通过以上测试,我们可以确信:两个Agent已经成功通过A2A协议实现了对接。客户端Agent(我们的测试脚本)和远程Agent(EchoAgent)遵循了A2A协议的规范,完成了发现、通信、协作的全过程。这为后续构建更复杂的多智能体系统打下了坚实的基础。
步骤5:扩展与集成
掌握了基本的A2A对接流程后,开发者可以在此基础上进行各种扩展和集成,以满足实际应用的需求。以下是一些常见的扩展方向:
- 添加更多技能:为智能体添加更多的技能(Skills),使其能够处理不同类型的任务。例如,可以扩展EchoAgent,使其不仅支持回显,还支持翻译、计算等技能。只需在Agent Card中声明新的技能,并在服务端代码中实现对应的处理逻辑即可。
- 支持流式传输:对于可能耗时较长的任务,可以实现流式响应。这需要在服务端支持SSE,并在客户端订阅
tasks/sendSubscribe接口【2†source】。通过流式传输,客户端可以实时获取任务进度或部分结果,提升用户体验。 - 集成大模型:将A2A智能体与大语言模型(如Gemini、GPT等)结合,赋予智能体更强大的理解和生成能力。例如,可以创建一个智能体,它接收到任务后,调用大模型来生成回答,然后再将结果返回给客户端。这种结合可以让智能体处理更复杂的请求,而不仅仅是简单的规则匹配。
- 安全与认证:在生产环境中,应启用认证机制,确保只有授权的客户端才能访问智能体。可以在Agent Card中声明支持的认证方案(如API密钥、OAuth等),并在服务端实现相应的验证逻辑【4†source】。同时,使用HTTPS来加密通信,保护数据传输的安全【4†source】。
- 与现有系统集成:将A2A智能体与企业现有的系统和数据源集成,使其能够访问和操作真实业务数据。例如,可以创建一个智能体,它通过A2A接收任务,然后调用企业的ERP系统API来查询库存,或调用数据库来获取用户信息。这种集成使得智能体能够真正为企业创造价值,而不仅是一个孤立的演示。
通过不断扩展和迭代,开发者可以将简单的A2A对接示例演变为功能完备的企业级智能体服务。A2A协议的标准化特性确保了在扩展过程中,不同智能体之间依然能够保持兼容和互操作,从而构建一个强大、灵活的智能体生态系统。
总结
Google推出的A2A协议为AI智能体之间的协作提供了一套开放、标准的解决方案。它通过定义Agent Card、Task、Message、Artifact等核心概念,以及基于HTTP/JSON-RPC的通信机制,使得不同框架、不同供应商的智能体能够相互发现、理解能力、交换信息并协同完成任务【4†source】。A2A协议的设计遵循拥抱智能体能力、基于现有标准、默认安全、支持长时任务和多模态等原则,确保了协议的灵活性、兼容性和实用性【2†source】。
与MCP协议相比,A2A专注于智能体间的通信协作,而MCP专注于智能体与工具/数据的连接,两者相辅相成,共同构建更强大的AI系统【10†source】。A2A协议自发布以来,得到了业界的广泛支持,包括Salesforce、SAP、ServiceNow等50多家企业的参与,预示着其将在企业智能体生态中扮演关键角色【2†source】。
通过本文的实践示例,我们演示了如何使用A2A协议实现两个Agent的对接。从环境搭建、Agent Card定义,到服务端和客户端的代码实现,再到运行测试和扩展方向,读者可以全面掌握A2A协议的使用方法。这为开发者在实际项目中应用A2A协议提供了清晰的指引。
展望未来,A2A协议有望成为智能体时代的基石,推动AI从“单兵作战”走向“团队协作”。随着更多开发者和企业的加入,一个开放、繁荣的智能体生态系统将加速形成,为各行各业带来更高效、更智能的自动化解决方案。A2A协议的出现,标志着我们正迈向一个智能体互联互通的新时代,一个真正由AI驱动的协同工作时代。【10†source】