解锁AI协作:Agent2Agent(A2A)协议深度解析

AI世界正在飞速发展,AI代理变得越来越复杂和强大。随着这些代理变得越来越普遍,它们之间对无缝沟通和协作的需求变得至关重要。Google的创新解决方案Agent2Agent(A2A)协议应运而生,旨在促进AI代理之间的互操作性和团队合作。

A2A的核心是一个框架,使AI代理能够有效地沟通和协作,而不管其底层架构或背后的供应商如何。它充当通用翻译器,弥合了不同AI系统之间的差距,并促进了无缝交互。可以将其视为一种通用语言,使AI代理可以和谐地协同工作,从而为解决复杂问题和自动化开辟了新的可能性。

A2A的起源:应对AI集成的挑战

要充分理解A2A的重要性,必须了解导致其创建的背景。像GPT-3.5这样强大的语言模型的兴起标志着AI采用的一个转折点,因为开发人员寻求扩展其功能的方法,而不仅仅是简单的聊天界面。

早期的一种解决方案是函数调用,该函数允许大型语言模型(LLM)以一对一的方式连接到外部API。但是,这种方法迅速导致生态系统碎片化,不同的AI供应商和实施者采用不同的集成方法,从而导致互操作性受到限制。

Anthropic的模型上下文协议(MCP)成为解决’NxM问题’的潜在解决方案,其中代理/AI系统(N)的数量乘以工具/数据源(M)的数量。 MCP旨在标准化上下文并简化集成,但Google意识到需要一种协议,使代理可以直接相互通信。

这就是A2A的用武之地。与MCP一样,A2A统一了AI代理的交互方式,但它不是专注于将代理连接到工具和数据,而是专注于将代理连接到其他代理。这是朝着构建真正协作的AI系统迈出的关键一步。

A2A的本质:AI代理的通用语言

A2A是一个开放协议,使AI代理可以相互通信,而不管其来源或设计如何。它充当翻译器,理解和解释各种语言和框架,例如LangChain、AutoGen和LlamaIndex。

A2A于2025年4月启动,与包括Atlassian、Salesforce、SAP和MongoDB等行业巨头在内的50多家技术合作伙伴合作开发。这种协作方法确保A2A不仅仅是Google的一项计划,而是更广泛的行业标准化努力。

A2A的核心是将每个AI代理视为具有标准接口的网络服务。这类似于Web浏览器和服务器使用HTTP进行通信的方式,但不是针对网站,而是针对AI代理。正如MCP解决了NxM问题一样,A2A简化了连接不同代理的过程,而无需为每个配对编写自定义代码。

A2A的核心功能:实现无缝协作

A2A建立在四个关键功能之上,这些功能使代理协作成为现实。要理解这些功能,重要的是要定义一些关键术语:

  • **客户端代理/A2A客户端:**使用A2A服务的应用程序或代理。这是启动任务并与其他代理通信的’主要’代理。
  • **远程代理/A2A服务器:**使用A2A协议公开HTTP端点的代理。这些是处理任务完成的补充代理。

考虑到这些定义,让我们探讨A2A的四个核心功能:

  1. **能力发现:**此功能回答了’你能做什么?’的问题。它允许代理通过’代理卡’来宣传他们的能力,代理卡是JSON文件,提供了代理的技能和服务的机器可读的配置文件。这有助于客户端代理识别最适合特定任务的远程代理。
  2. **任务管理:**此功能解决了’每个人都在一起工作吗,您的状态是什么?’的问题。它确保客户端和远程代理之间的通信集中于任务完成,具有特定的任务对象和生命周期。对于长时间运行的任务,代理可以进行通信以保持同步。
  3. **协作:**此功能专注于’上下文、回复、任务输出(工件)或用户指令是什么?’的问题。它使代理可以来回发送消息,从而创建会话流。
  4. **用户体验协商:**此功能解决了’我应该如何向用户显示内容?’的问题。每条消息都包含具有特定内容类型的’部件’,从而允许代理协商正确的格式并了解UI功能,例如iframe、视频和Web表单。代理会根据接收代理(客户端)可以处理的内容来调整其呈现信息的方式。

A2A的内部工作原理:AI通信的客户端-服务器模型

A2A在客户端-服务器模型上运行,在该模型中,代理使用结构化的JSON消息通过标准Web协议(例如HTTP)进行通信。这种方法可确保与现有基础架构的兼容性,同时标准化代理通信。

为了理解A2A如何实现其目标,让我们分解协议的核心组件,并探讨’不透明’代理的概念。

A2A的核心组件:构建AI协作的基石

  • **代理卡:**此JSON文件通常托管在一个众所周知的URL(例如,/.well-known/agent.json)中,描述了代理的功能、技能、端点URL和身份验证要求。它充当代理的机器可读’简历’,帮助其他代理确定是否与其交互。
  • **A2A服务器:**使用A2A协议公开HTTP端点的代理。这是A2A中的’远程代理’,它接收来自客户端代理的请求并处理任务。服务器通过代理卡宣传其功能。
  • **A2A客户端:**使用A2A服务的应用程序或AI系统。客户端构造任务并根据其能力和技能将其分发给适当的服务器。这是A2A中的’客户端代理’,它使用专用服务器协调工作流程。
  • **任务:**A2A中的核心工作单元。每个任务都有一个唯一的ID,并通过定义的状态(例如,submittedworkingcompleted)进行。任务充当所请求和执行的工作的容器。
  • **消息:**客户端和代理之间的通信交换。消息在任务的上下文中交换,并包含传递内容的部件。
  • **部件:**消息或工件中的基本内容单元。部件可以是:
    • TextPart:用于纯文本或格式化内容
    • FilePart:用于二进制数据(带有内联字节或URI引用)
    • DataPart:用于结构化的JSON数据(例如表单)
  • **工件:**代理在任务期间生成的输出。工件还包含部件,并表示从服务器返回到客户端的最终可交付成果。

不透明代理的概念:保护知识产权和确保安全

术语’不透明’在A2A的上下文中表示代理可以在不透露其内部逻辑的情况下协作执行任务。这意味着:

  • 代理只需要公开它可以执行哪些任务,而不是如何执行它们。
  • 专有算法或数据可以保持私有。
  • 只要代理支持相同的功能,就可以用替代实现替换代理。
  • 组织可以集成第三方代理而无需担心安全问题。

A2A的方法简化了复杂的多代理系统的开发,同时保持了高安全标准并保护了商业秘密。

典型的A2A交互流程:分步指南

当代理通过A2A进行通信时,它们遵循一个结构化的顺序:

  1. **发现阶段:**想象一下用户询问其主要的AI代理,’你能帮我计划下个月去东京的出差吗?’ AI认识到需要找到专门的代理来处理航班、酒店和当地活动。客户端代理识别可以协助完成每个任务的远程代理,并检索其代理卡以评估其适用性。
  2. **任务启动:**团队组建完毕,是时候分配工作了。客户端代理可能会对机票预订代理说,’查找5月15日至20日从东京起飞的航班。’ 客户端将请求发送到服务器的端点(通常是POST到/taskssend),创建一个具有唯一ID的新任务。这包括详细说明客户端希望服务器执行的操作的初始消息。
  3. **处理:**预订专家代理(服务器/远程代理)开始搜索符合条件的可用航班。它可能会:
    • 立即完成任务并返回工件:’这是可用的航班。’
    • 请求更多信息(将状态设置为input-required):’您是否喜欢特定的航空公司?’
    • 开始处理长时间运行的任务(将状态设置为working):’我正在比较价格以找到最优惠的价格。’
  4. **多轮对话:**如果需要更多信息,客户端和服务器会交换其他消息。服务器可能会提出澄清问题(’可以转机吗?’),客户端会回复(’不,只允许直飞。’),所有这些都在同一任务ID的上下文中。
  5. **状态更新:**对于需要时间才能完成的任务,A2A支持多种通知机制:
    • 轮询:客户端定期检查任务状态。
    • 服务器发送事件(SSE):如果客户端已订阅,则服务器会流式传输实时更新。
    • 推送通知:如果提供,服务器可以将更新POST到回调URL。
  6. **任务完成:**完成后,服务器将任务标记为completed并返回包含结果的工件。或者,如果遇到问题,它可能会将任务标记为failed,或者如果任务已终止,则标记为canceled

在整个过程中,主要代理可能会同时与其他专家代理合作:酒店专家、本地交通专家、活动策划大师。主要代理将通过将所有这些结果合并到全面的旅行计划中来创建行程,然后将其呈现给用户。

从本质上讲,A2A使多个代理可以为实现共同目标做出贡献和协作,客户端代理组装的结果超过了其各部分的总和。

A2A与MCP:AI集成的协同伙伴关系

虽然A2A和MCP可能看起来在争夺相同的空间,但它们旨在协同工作。它们解决了AI集成的不同但互补的方面:

  • MCP将LLM(或代理)连接到工具和数据源(垂直集成)。
  • A2A将代理连接到其他代理(水平集成)。

Google有意识地将A2A定位为对MCP的补充。这种设计理念在其Vertex AI代理构建器的发布中显而易见,该构建器具有内置的MCP支持以及A2A。

为了说明这一点,请考虑以下类比:如果MCP使代理可以使用工具,那么A2A是他们在工作时进行的对话。 MCP为单个代理配备了功能,而A2A帮助他们协调这些功能作为一个团队。

在一个全面的设置中,代理可能会使用MCP从数据库中检索信息,然后使用A2A将该信息传递给另一个代理进行分析。这两种协议可以协同工作,为复杂任务创建更完整的解决方案,同时简化自LLM成为主流以来一直存在的开发挑战。

A2A安全标准:确保企业级保护

A2A的开发以企业安全为主要考虑因素。除了专门使用不透明代理之外,每个代理卡都指定了所需的身份验证方法(API密钥、OAuth等),并且所有通信都设计为通过HTTPS进行。这使组织可以建立策略来管理哪些代理可以相互通信以及可以共享哪些数据。

与MCP规范中的授权类似,A2A利用现有的Web安全标准,而不是创建新的模式,从而确保与当前身份系统的即时兼容性。由于所有交互都通过定义明确的端点进行,因此可观察性变得简单,从而使组织可以集成其首选的监视工具并获得统一的审计跟踪。

A2A生态系统和采用:不断增长的支持社区

A2A协议已启动,获得了50多家技术合作伙伴的重大支持,其中许多合作伙伴当前支持或打算通过自己的代理支持A2A。Google已将A2A集成到其Vertex AI平台和ADK中,为Google Cloud生态系统中的开发人员提供了简化的入口点。

考虑实施A2A的组织应考虑以下事项:

  1. **降低集成成本:**开发人员可以普遍实施A2A,而不是为每个代理配对构建自定义代码,从而降低集成成本。
  2. **相对较新的版本:**A2A仍处于广泛发布的早期阶段,这意味着它尚未经过大规模发现潜在缺陷所需的广泛实际测试。
  3. **面向未来:**作为一种开放协议,A2A允许新旧代理集成到其生态系统中,而无需额外的工作。
  4. **代理限制:**虽然A2A代表了真正自主AI的重大进步,但它仍然是面向任务的,并且不能完全独立运行。
  5. **供应商不可知论:**A2A不会将组织锁定到任何特定的模型、框架或供应商,从而允许他们在整个AI领域中进行混合和匹配。

Agent2Agent协议的未来:无缝AI协作的愿景

展望未来,如协议路线图中所述,A2A有望得到进一步改进。计划的增强功能包括:

  • 代理卡中正式的授权方案和可选凭据。
  • 正在进行的任务中的动态UX协商(例如,在对话中添加音频/视频)。
  • 改进的流媒体性能和推送通知机制。

也许最令人兴奋的长期可能性是,A2A将成为代理开发,就像HTTP对Web通信一样:创新爆炸的催化剂。随着采用率的提高,我们可能会看到专门针对特定行业的预先打包的代理’团队’,并最终看到客户端可以利用的无缝全球AI代理网络。

对于探索AI实施的开发人员和组织而言,现在是学习和使用A2A的理想时机。A2A和MCP共同代表着一种更标准化、更安全和更适合企业使用的AI方法的开始。