什么是 Agent2Agent(A2A)协议?
Agent2Agent(A2A)协议是由谷歌发布的全新开放标准,旨在解决当前 AI 代理之间协作困难的问题。目前的 AI 代理虽然能够完成特定任务,但在相互传递工作时需要依赖定制化的代码,这使得跨代理协作变得复杂且不灵活。A2A 协议通过定义一种轻量级的通信机制,允许一个代理发现、认证并从另一个代理接收结果流,无需共享提示上下文或重新实现认证机制。
A2A 协议的出现是为了解决多代理协作中的痛点,例如不稳定的交接、安全限制以及供应商锁定等问题。它通过定义“代理卡”(Agent Card)、“任务”(Task)状态机以及流式传输的“消息”(Messages)或“工件”(Artifacts),使得客户端代理能够与远程代理进行安全且高效的通信。A2A 协议并不取代现有的模型上下文协议(MCP),而是作为其补充,填补了代理之间的协作空白。
在 A2A 协议中,客户端代理负责发现远程代理的代理卡,决定是否满足其认证方法,并通过 JSON-RPC 消息创建任务。任务一旦创建,客户端代理将作为任务的管理者,监听状态事件、转发远程代理请求的输入,并最终收集工件以供后续使用。而远程代理则负责执行任务的核心工作,并通过流式事件向客户端代理反馈任务状态和工件更新。
A2A 协议的通信机制是单向的,仅客户端代理能够发起 JSON-RPC 请求,而远程代理则负责更新任务状态。这种通信模式类似于“前台与后台”的协作关系,客户端代理负责接收新订单并传达澄清信息,远程代理则专注于完成任务,直到结果交付。
A2A 协议在架构上位于 MCP 之上,与工作流编排工具并行。它专注于网络层面的代理间通信,而 MCP 则专注于单个代理内部的工具调用。这种分层设计使得框架和供应商能够在底层进行创新,同时保持协议的简洁性和通用性。
在安全性方面,A2A 协议通过签名代理卡、多种认证方式以及运行时策略来确保通信的安全性。代理卡可以通过 JSON Web Signature(JWS)进行签名,客户端代理可以验证签名以防止代理卡被篡改。此外,A2A 协议还支持多种认证方式,包括简单的 Bearer 令牌、双向 TLS 以及企业级的单点登录流程。远程代理还可以在模型运行前对负载进行检查,拒绝过大或风险较高的负载。
在可观察性方面,A2A 协议的每个状态或工件事件都携带时间戳、任务 ID 和可选的跟踪头。通过将 A2A 客户端包装在 OpenTelemetry 中间件中,可以轻松实现端到端的跟踪,无需手动解析 JSON 数据。这些跟踪数据可以被集成到企业的可观察性平台中,以便在问题影响客户之前及时发现并解决。
在发现机制方面,目前 A2A 协议的发现机制主要依赖于团队内部的 YAML 文件或谷歌的 Vertex AI 目录。未来,随着公共注册中心的成熟,可能会出现类似 npm 的代理注册中心,但目前还没有统一的“验证徽章”。
A2A 协议相比 MCP 在安全性上有显著提升。MCP 会暴露工具的自然语言提示,容易受到注入攻击和参数篡改。而 A2A 协议将这些细节隐藏在远程代理的内部,客户端代理只能看到高级任务和受限的工件,从而消除了整个类别攻击的可能性。
尽管 A2A 协议的愿景非常美好,但截至 2025 年 5 月,其实际应用仍处于早期阶段。大约有 50 家供应商宣布支持 A2A 协议,但大多数代理仍处于“私信获取演示”的阶段。目前,LangGraph、CrewAI 和 AutoGen 的适配器已经较为成熟,而 Flowise 和 n8n 仍处于社区测试阶段。此外,目前还没有公共注册中心,团队主要依赖 YAML 文件或 Vertex AI 的私有目录来管理代理。很少有代理提供签名的代理卡,而速率限制或计费上限则需要通过自定义中间件实现。在性能方面,谷歌的参考服务器在本地测试中每个跳数增加约 30 毫秒的延迟。
A2A 协议适用于跨供应商工作流、安全敏感的黑盒代理、混合技术栈以及需要进度更新的长时间运行任务。它为不同供应商的代理提供了共享握手、认证和流式通信的能力,而无需暴露底层提示细节。然而,对于运行在同一进程中的代理、小型脚本任务、一次性数据拉取或主要依赖复杂参数验证的工具,A2A 协议可能过于复杂,直接使用 API 调用或简单的 REST 端点可能更为合适。
A2A 协议为 AI 代理之间的协作提供了一种标准化、安全且高效的解决方案。尽管目前其生态系统仍在发展和完善中,但它已经为原型开发和内部工作流提供了足够的支持,有望在未来推动多代理协作的广泛应用。
#Google #AI #Agent2Agent
https://www.builder.io/blog/a2a-protocol