Agent2Agent(A2A)协议介绍

最新推荐文章于 2025-09-25 14:17:59 发布

原创最新推荐文章于 2025-09-25 14:17:59 发布 · 1.3k 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#AI Agent #LLM #A2A

谷歌在Google Cloud Next 25大会上（4月9号），开源了首个标准智能体交互协议Agent2Agent Protocol（简称A2A）。这是一种开放式互操作性协议，旨在实现跨不同框架和供应商的 AI 代理之间的无缝协作。

A2A 得到了包括 Salesforce、SAP、ServiceNow 和 MongoDB 在内的 50 多家技术合作伙伴的支持，为 AI 代理提供了一个通用框架，使其能够安全地交换信息、协调行动并跨企业平台集成。

背景

在本次大会上Agent成为了重点，除了A2A之外，谷歌还效仿OpenAI开源了Agent开发套件ADK，内部测试工具Agent Engine，新的Agent市场等。

过去几个月，至少有两个AI助手互操作标准出现：先是Anthropic推出了“模型上下文协议(MCP)”，然后思科带头搞了个叫做“AGNTCY”的联盟标准。这是因为大家越来越认识到，让不同公司开发的AI助手能够“互相说话”非常重要。

正是看到这个趋势，谷歌联合了50多家大厂一起上，包括Atlassian、Box、Cohere、Intuit、LangChain、MongoDB、Salesforce、SAP、ServiceNow、UKG和Workday等公司推出“Agent2Agent”(简称A2A)协议。旨在让A2A协议成为AI助手和AI应用之间的互操作语言。

A2A工作原理

A2A 促进了“客户端”代理和“远程”代理之间的通信。客户端代理负责制定和传达任务，而远程代理负责处理这些任务，以尝试提供正确的信息或采取正确的作。此交互涉及几个关键功能：

能力发现： 代理可以使用 JSON 格式的“代理卡”公布其功能，从而允许客户端代理确定可以执行任务的最佳代理，并利用 A2A 与远程代理进行通信。
任务管理：客户端和远程代理之间的通信面向任务完成，其中代理负责满足最终用户的请求。这个 “task” 对象由协议定义，并且有一个生命周期。它可以立即完成，或者对于长时间运行的任务，每个代理都可以进行通信，以便在完成任务的最新状态上彼此保持同步。任务的输出称为 “artifact”（工件）。
协作：代理可以相互发送消息以传达上下文、回复、构件或用户说明。
用户体验协商：每条消息都包含 “部分”，这是一个完全形成的内容，就像生成的图像一样。每个部分都有指定的内容类型，允许客户端和远程代理协商所需的正确格式，并明确包括用户 UI 功能的协商，例如 iframe、视频、Web 表单等。

简单来说，A2A协议主要是让两种AI助手互相交流：一种叫「客户端助手」，另一种叫「远程助手」。

这就像餐厅里的服务员和厨师的关系：服务员（客户端助手）接收你的点餐并传达给厨师，而厨师（远程助手）则负责根据这些要求烹饪美食。比如你问自家AI一个财务问题，它如果不懂，就可以去请教专门的财务AI，然后把答案告诉你，全程你不用操心。

A2A协议主要包括四项功能：

功能一，能力发现：助手可以通过JSON格式的“助手卡片”（技术上叫Agent Card）来展示它有什么能力，就像我们人类有个人简历一样，这样客户端助手就能确定最适合完成任务的远程助手。比如你问：“我想了解今年的税收政策变化”，你的个人助手可能对税务不精通，但它知道谁是税务专家，于是就会找到税务助手来合作。

功能二，任务管理：确保助手间的对话都是围绕完成任务展开的，并定义任务的生命周期。对于耗时较长的任务，两个助手会保持联系，互相更新最新进度。任务的最终结果被称为“工件（artifact）”。这就像你点了一道复杂的菜，厨师会不时告诉服务员：“已经开始准备食材了”、“马上就好了”，最后才端出成品。

功能三，协作功能：助手们可以互相发送消息，传递上下文、回复、工件或用户指令。就像服务员可能会告诉厨师：“客人对海鲜过敏”或“客人喜欢微辣口味”，AI助手之间也会分享这类重要信息，确保最终结果符合你的需求。

功能四，用户体验协商：每条消息都包含“一部分”内容，比如生成的图像。每个部分都有特定的内容类型，这样客户端和远程助手就能协商出正确的格式，并明确包括用户界面能力的协商：比如是否支持嵌入框架、视频、网页表单等等。这就像服务员知道，你是坐在高脚凳上还是在包厢里，从而决定如何最好地为你上菜。

A2A就像是给AI助手们创造了一种“通用语言”，让它们能够无障碍交流，共同为用户提供更全面、更智能的服务。

A2A 设计原则

拥抱代理能力 ：A2A 专注于使代理能够以自然、非结构化的方式进行协作，即使他们不共享内存、工具和上下文。我们正在实现真正的多代理场景，而不会将代理局局限于“工具”。
以现有标准为基础： 该协议建立在现有的流行标准（包括 HTTP、SSE、JSON-RPC）之上，这意味着它更容易与企业日常使用的现有 IT 堆栈集成。
默认安全 ：A2A 旨在支持企业级身份验证和授权，在启动时与 OpenAPI 的身份验证方案相同。
支持长时间运行的任务： A2A 设计灵活，并支持各种场景，它擅长完成从快速任务到深入研究的所有工作，而这些工作可能需要数小时甚至数天，而人类则需参与其中。在整个过程中，A2A 可以向其用户提供实时反馈、通知和状态更新。
模式不可知： 代理世界不仅限于文本，A2A设计用来支持各种模式，包括音频和视频流。

一个实例场景：候选人招聘

有了A2A，招聘一名软件工程师的过程可以变得很轻松：在Agentspace这样的统一界面中，招聘经理只需告诉自己的AI助手：“帮我找符合这个职位描述、在这个地区、具备这些技能的候选人。”

接下来：

你的AI助手会自动联系其他专门的招聘AI助手；
这些专业助手会帮你筛选潜在候选人；
你收到建议名单后，只需动动手指，就能指示助手安排面试；
面试结束后，另一个专门的AI助手还能帮你完成背景调查。

整个候选人寻找过程变得很流畅。

A2A与MCP

MCP 即模型上下文协议（Model Context Protocol），是由 Anthropic 公司于 2024 年 11 月推出的开放标准协议。旨在为大模型与外部工具、数据源和服务建立统一的交互接口，成为 AI 领域的 “USB - C 接口”，实现大模型与外部资源的即插即用。

MCP（模型上下文协议）， 用于工具和资源
- 通过结构化输入/输出将代理连接到工具、API 和资源。
- Google ADK 支持 MCP 工具。支持将各种 MCP 服务器与代理一起使用。
A2A （Agent2Agent 协议） 用于代理与代理之间协作
- 不同代理之间动态、多模式通信，无需共享内存、资源和工具

原因-智能体互操作性需求

各大组织和AI公司都认同一个观点：未来的世界不会只有一个AI模型称霸，而是多模型并存。这意味着AI助手也会基于不同的语言和框架构建。

一、技术瓶颈：异构系统协作的天然屏障

当前主流 AI 模型（如 GPT-4、Claude、Gemini）在架构设计、接口规范、通信协议等方面存在显著差异。这种异构性在多智能体协作场景中尤为突出。例如医疗诊断场景中，放射影像分析 Agent（基于 TensorFlow）与病理报告生成 Agent（基于 PyTorch）的协同，需投入大量资源解决模型间的兼容性问题。

二、产业需求：复杂场景催生协作刚需

随着 AI 从辅助工具向自主决策系统演进，单模型已无法满足企业级应用需求。例如金融风控：信贷审批 Agent 需调用征信数据 Agent、市场舆情 Agent、反欺诈 Agent 的信息，实时生成风险评估报告。传统 API 集成方式导致响应延迟超过 200ms，无法满足高频交易需求。

这些场景对协作的实时性、可靠性、安全性提出严苛要求，传统集成方案难以满足。

三、生态博弈：巨头竞逐标准话语权

AI 行业正经历 “协议战争”，头部企业通过标准化争夺生态主导权：

谷歌 A2A 协议：联合 50 + 企业（如 Salesforce、SAP）推出，基于 HTTP/JSON-RPC，支持能力发现、任务管理、多模态交互。其 “Agent Card” 机制可自动匹配最优协作 Agent，某电商场景中使跨平台协作效率提升 40%。
Anthropic MCP 协议：聚焦模型与外部资源交互，已集成到微软 Azure AI。某制造业案例显示，MCP 使设备数据调用延迟从 300ms 降至 80ms。
Cisco AGNTCY 联盟：联合 LangChain、LlamaIndex 等，制定跨框架通信标准。某金融场景中，AGNTCY 使不同 AI 系统的协作故障率下降 60%。

这些协议虽各有侧重，但均试图解决 “AI 孤岛” 问题。谷歌 A2A 与 Anthropic MCP 形成互补，前者聚焦 Agent 间协作，后者解决模型与工具交互，共同构建 “模型 - 工具 - Agent” 三位一体的生态体系。