A2A架构详解

《AI Agent智能体与MCP开发实践 基于Qwen3大模型 清华大学出版社 王晓华 著 著 人工智能技术丛书 新华正版书籍包邮 图书》【摘要 书评 试读】- 京东图书

A2A是一项新的开放标准，它为AI智能体提供了一种通用的通信协议，使它们能够无缝协作与交流。想象一下，你拥有一支由超级智能AI助手组成的团队：一个擅长数据分析，另一个能撰写优秀的报告，还有一个专门负责管理你的日程。单独来看，它们都非常出色，但问题在于它们彼此之间并不了解对方的存在，当需要在同一个项目上协作时，就会显得力不从心。

图8-1  A2A架构

A2A正是为了改变这一现状而诞生的，它致力于实现智能体之间的跨平台交流。简而言之，A2A的重要性在于它有潜力打破AI智能体之间的孤岛，让它们像一个协调良好的团队一样高效合作，而不是各自为战。

8.1.1  A2A的功能与定义

A2A被定义为一个用于AI智能体的通信协议。可以把它想象成一种标准化的通用语言，任何AI智能体都可以用它来与任何其他智能体对话，而无论它是由谁构建的，或者运行在什么框架上。

如果没有A2A，如果试图让智能体A直接与智能体B对话，这将是一件比较困难的事情。因此A2A应运而生，它是让不同智能体互相共享信息、寻求帮助、协调任务的桥梁，是不需要自定义的“胶带代码”。

简单来说，A2A之于AI智能体，就像互联网协议之于计算机—它赋予智能体一种通用的网络语言。在框架A中构建的智能体A可以向在框架B中构建的智能体B发送消息或任务请求，智能体B将理解并做出适当的响应。它们不需要了解彼此“内部大脑”或代码的凌乱细节，这些均由A2A负责翻译和协调。

因此，A2A协议允许智能体彼此通信，安全地交换信息，并在不同平台之间协调行动。至关重要的是，智能体以对等方的身份进行此操作，而不仅仅是工具—这意味着每个智能体在协作的同时保留其自主性和特殊技能。

让我们发挥想象力。想象一间繁忙的办公室，但里面不是人类，而是AI智能体。里面有电子表格专家小雪、邮件高手小华和客户支持机器人安格。在正常情况下，小雪可能需要小华向客户发送安格提供的一些数据的摘要，但小雪说Excel语，小华说JSON语，安格则用自然语言解答常见问题。混乱随之而来—小雪输出的CSV文件小华不知道如何阅读，小华发送的邮件安格无法解析，安格记录了一个问题但从未回到小雪那里。

现在想象一间带实时翻译功能的神奇会议室，小雪用Excel语说：“我需要最新的销售数据。”翻译器（A2A）用安格的语言转达：“嘿，安格，你能获取销售数据吗？”安格获取数据并用白话回答，翻译器确保小雪用Excel语听到。与此同时，小华自动插话说：“我将用这些数据起草一封邮件。”翻译器帮助小华和安格协调内容。突然间，三个AI同事开始顺畅地协作，每个人都发挥自己的长处，没有误解。

这个翻译器就是A2A。它确保当一个智能体“说话”时，另一个能够“听到”并做出适当的响应，即使其中一个内部是使用LangGraph构建的，另一个是使用AutoGen（AG2）构建的。A2A为智能体提供了通用语言和礼仪：如何自我介绍，如何向他人寻求帮助，如何交换信息，以及如何礼貌地说“明白了，这是您想要的结果”。就像一个好的通用翻译器一样，A2A承担了沟通的繁重工作，以便智能体可以专注于手头的任务。

此外，A2A协议从一开始就被设计为安全考虑—内置了身份验证、授权和治理，因此智能体只共享它们被允许共享的内容。智能体可以协同工作，而无须彼此暴露它们的“秘密武器”（内部内存或专有工具）。这就像医生在不泄露患者隐私的情况下就一个病例进行会诊，是一种兼顾隐私的协作。

8.1.2  A2A通信与交互模块详解

A2A协议建立在开发者熟悉的网络技术之上：其核心通信方式是JSON-RPC 2.0 over HTTP(S)，如图8-2所示。

图8-2  A2A通信协议

换句话说，智能体之间通过标准的网络请求发送结构化的JSON消息进行交流，包括请求、响应等基本元素。没有晦涩难懂的专有二进制格式，只有通过HTTP传输的纯文本JSON—这种设计非常友好，就像使用所有Web服务都能理解的“HTML通用语言”一样畅通无阻。

不仅如此，A2A还支持一些增强功能，如SSE（Server-Sent Events，服务器推送事件）用于流式数据更新，异步回调用于通知机制。这意味着当智能体A向智能体B提出一个耗时较长的问题（比如需要两分钟的数据处理）时，智能体B可以逐步向智能体A发送部分结果或状态更新，而不是让智能体A空等。这正是高效协作应有的模样。

在一个Agent与其他Agent进行交互时，每个Agent都需要彼此通知和了解相互之间的功能与能力。为此，A2A构建了一个客户端-服务器方式的交互模型：当智能体A需要帮助时，它扮演客户端角色，向远程智能体B（服务器）发出请求。A2A负责协调整个过程，包括：

• 能力发现：智能体可以使用JSON格式的“智能体卡片（Agent Card）”来宣传其能力，允许客户端智能体识别能够执行任务的最佳智能体，并利用A2A与远程智能体通信。
• 任务管理：客户端和远程智能体之间的通信面向任务完成，智能体在其中努力满足最终用户的请求。这个“任务”对象由协议定义并具有生命周期。它可以立即完成，或者对于长时间运行的任务，每个智能体可以进行通信，并以完成任务的最新状态保持同步。任务的输出被称为“工件（Artifact）”。
• 协作：智能体可以相互发送消息以传达上下文、回复、工件或用户指令。
• 用户体验协商：每条消息包含“部分（Parts）”，这是一个完全成型的内容片段，如生成的图像。每个部分都有指定的内容类型，允许客户端和远程智能体协商所需的正确格式，并明确包括用户UI能力的协商，例如iframes、视频、Web表单等。

这一切都基于开放、标准的Web技术栈，使得现有系统可以轻松集成。如果读者熟悉浏览器如何与Web服务器通信（即请求与响应模式），那么A2A的设计理念就不陌生—它只是将这一逻辑扩展到了AI智能体之间的对话中，从而实现了最大化的兼容性和互操作性。

1. 智能体卡片（Agent Card）—能力发现模块

每个采用A2A的智能体都会提供一张“智能体卡片”，它是一个标准化的JSON格式文件，相当于AI智能体的数字名片或LinkedIn个人资料。这张卡片包含智能体的基本信息、版本、描述、可用技能列表等内容，如图8-3所示。

图8-3  智能体卡片

借助智能体卡片，其他智能体可以轻松发现和验证目标是否具备完成特定任务的能力。在智能体A向智能体B请求帮助之前，它可以先查看智能体B的卡片，确认智能体B是否拥有相关技能。这种方式避免了盲目调用带来的低效与错误。

2. 技能清单（Skill List）—能力清单模块

技能是智能体对外提供的具体功能，列在智能体卡片中。每个技能都有唯一的ID、可读性强的名称、详细的描述，甚至附带使用示例。例如，schedule_meeting是日程机器人的一个技能，描述为“根据给定日期范围安排参与者之间的会议”。

这些技能定义就像智能体的服务菜单，明确告知外界它可以处理哪些类型的请求，从而确保任务分配精准有效。

3. 任务与工件（Task&Artifact）—任务管理模块

当智能体A希望智能体B执行某项工作时，它会发送一个结构化的任务请求。这个任务被A2A协议定义为一个JSON对象，其中包含所需执行的操作、输入参数及上下文信息。例如，“任务：请使用你的schedule_meeting技能，输入X、Y、Z。”如图8-4所示。

图8-4  任务管理

任务具有生命周期，从创建、执行到完成，这个过程中智能体可以交换多条消息进行协调。完成后，结果将被打包为工件返回，作为任务的交付成果。例如，调度任务的工件可能是日历邀请或确认邮件。

对于长时间运行的任务，A2A支持持续的状态更新和中间结果反馈（如“还在处理……快完成了……”），确保协作过程透明顺畅，不会因超时而被中断。

4. 消息（Message）—协作对话模块

消息是智能体之间实际交换的内容，包括问题、上下文、中间结果、确认信息等。A2A允许消息携带多种内容类型，不仅限于纯文本，还可以是结构化数据、文件甚至多媒体内容。每条消息可以包含多个部分，每个部分标注内容类型，例如一段文本（text/plain）和一幅图片（image/png）。A2A的协作对话如图8-5所示。

图8-5  A2A的协作对话

更进一步，A2A引入了用户体验协商机制，允许智能体协商接收内容的最佳形式。例如，如果智能体A无法直接显示图像，智能体B可改为提供URL或文本描述。这一特性确保了不同能力的智能体之间也能实现无缝沟通。

5. 安全协作（Security）

A2A在设计之初就考虑到了企业级安全性。协议内置身份验证机制（如API密钥、OAuth等），确保只有授权的智能体才能发起或响应任务请求。同时，智能体无须暴露其内部实现细节，例如模型架构、提示历史等敏感信息。它们只需交换完成任务所需的必要信息，保护各自的知识产权与隐私。

A2A在智能体之间建立了一个客户端-服务器模型：当智能体A需要某物时，它充当客户端智能体，智能体B充当远程智能体（服务器）角色。A2A处理客户端如何找到正确的远程智能体（通过智能体卡片），如何发送任务（JSON-RPC消息），远程智能体如何流式传输响应或给出最终结果，以及两者如何始终保持同步。所有这些都使用网络友好的标准，以便易于插入现有应用程序。这听起来有点像网络浏览器如何与网络服务器对话（请求和响应），这并非巧合，A2A本质上是将类似的概念应用于智能体与智能体对话，这是最大化兼容性的逻辑方法。