报告由ChatGPT Deep Research分析得出，耗时6分钟，综合检索了30个信息源。以下具体信息只作了初步核对，仅供参考。
摘要：Google在 2025 年推出的 Agent2Agent (A2A) 协议是一种开放的标准通信协议，该协议让不同供应商或框架构建的 AI 代理（Agent）能够直接协作交流developers.googleblog.com。A2A 借鉴了 Google 内部大规模代理系统的经验，建立在 HTTP、JSON-RPC 等现有技术之上，并辅以 SSE 等机制实现实时通信developers.googleblog.com。通过该协议，各类 AI 代理可以互相发现能力、交换信息、协调动作，并在企业环境中安全可靠地协同工作developers.googleblog.com developers.googleblog.com。本文将从技术架构、应用场景、安全性设计、与其他协议的比较以及协议实作细节五个方面对 Google Agent2Agent 协议进行深入分析。
一、技术架构
A2A 协议采用客户端-服务端（Client-Agent / Remote-Agent）架构，即由一个发起任务的“客户端代理”和一个执行任务的“远程代理”进行通信developers.googleblog.com。客户端代理负责构建和发送任务请求，远程代理则接收请求并尝试完成任务，返回结果或行动反馈developers.googleblog.com。这种设计使每个 AI Agent 可以被视作一个独立的服务，通过标准接口彼此交互，类似于微服务架构在 AI 代理上的应用dev.todev.to。为了在不同行业框架中通用，A2A 建立在通用Web标准之上：采用 HTTP(S) 作为传输协议，使用 JSON-RPC 2.0 标准格式封装请求/响应，并通过 Server-Sent Events (SSE) 实现服务端推送流式数据huggingface.cohuggingface.co。换言之，A2A 并未发明新的底层通信机制，而是构建于 HTTP、SSE、JSON-RPC 等成熟标准之上，便于集成进现有 IT 系统和网络基础设施developers.googleblog.com。
Agent Card 能力描述：为实现代理间的动态互发现，A2A 定义了“Agent Card”机制。这是在代理服务的公开入口（通常为/.well-known/agent.json）提供的 JSON 文件，用于描述代理的元数据和能力github.comgithub.com。Agent Card 中包括代理名称、描述、提供服务的 HTTP 端点 URL、所遵循的 A2A 协议版本，以及该代理支持的协议功能和所需的身份认证方式等huggingface.cohuggingface.co。例如，Agent Card 会声明代理是否支持流式响应（streaming能力）、是否支持推送通知（pushNotifications能力）、是否要求 OAuth2 Token 或 API Key 等认证方案huggingface.co。通过读取远程代理的 Agent Card，客户端代理可以发现对方具备哪些技能与接口，从而选择合适的代理协作并按其要求准备认证凭证github.comgithub.com。Agent Card 机制使代理的能力发现（Capability Discovery）成为可能developers.googleblog.com——每个代理相当于公开了一张“能力名片”，让其它代理能在无需人工配置的情况下自动了解如何与其通信。
任务模型与消息结构：在 A2A 中，任务（Task）是核心的工作单元github.com。一次完整的代理交互被抽象为对某个任务的创建和处理。每个任务由客户端代理分配一个唯一的任务ID，并具有明确的生命周期状态：创建后进入submitted状态，远程代理开始处理则为working状态，若需要额外输入则进入input-required暂停等待，最终结束于completed（成功）、failed（失败）或canceled（取消）等终止状态github.comgithub.com。任务的执行过程由双方通过消息（Message）进行交互驱动github.com。A2A 定义消息包含两个角色：由客户端代理发送的消息其role标识为“user”，远程代理回复的消息则role为“agent”github.com。每条消息可以包含一个或多个内容部件（Part）github.com。Part 是消息中的基本内容单元，用于支持多模态信息交换：例如文本内容用TextPart表示，二进制文件或图片用FilePart（可直接内嵌字节或提供URI），结构化数据（如表单JSON）用DataPart表示github.com。此外，远程代理在任务过程中生成的最终成果输出（Artifact）也采用与消息类似的结构（包含若干 Part）来表示，例如生成的文件、报告或图像等都作为 Artifact 附属于任务github.comcohorte.co。通过这种分层内容结构，A2A 协议使代理间可以协商和处理复杂的非纯文本内容——不仅局限于对话文本，还可以交换表格数据、图像文件甚至音视频流，从而具备模态无关性的优势developers.googleblog.com。
长连接与流式通信：针对不同持续时长的任务，A2A 支持两种通信模式：同步请求/响应和异步流式更新。对于快速即可完成的任务，客户端代理可以直接调用远程代理的tasks/send接口发送请求，远程代理处理完毕后在 HTTP 响应中直接返回完整的 Task 结果github.comcohorte.co。而对于需要较长时间运行的任务（例如涉及人类审批或耗时计算的任务），A2A 提供了tasks/sendSubscribe方法：客户端通过该方法订阅任务，并保持一个 SSE 连接以实时接收进度更新github.comgithub.com。远程代理在处理过程中会不断通过 SSE 推送任务状态更新事件（如 TaskStatusUpdateEvent 通知“仍在工作”或请求“需要输入”）以及部分成果事件（TaskArtifactUpdateEvent，发送中间输出)github.com。客户端代理通过监听这些事件，能够获取任务的实时进展和阶段性结果，从而实现对长时任务的监控与交互cohorte.cocohorte.co。如果远程代理进入input-required状态，需要额外信息才能继续任务，则会通过事件或消息告知具体需求；此时客户端（或其背后的用户）可通过再次调用tasks/send（携带相同任务ID）提供所需输入，任务即可继续cohorte.co。这样的多轮消息交互机制确保即使任务执行过程中需要多次往返沟通，所有消息都关联到同一任务上下文而不会混淆cohorte.co。除了 SSE 实时流，A2A 还支持Webhook 回调的推送通知：如果远程代理具备pushNotifications能力，客户端代理可以通过调用tasks/pushNotification/set注册一个回调URL，远程代理即可在关键事件时主动向该 URL 发送 HTTP 通知github.com。这些设计使 A2A 能灵活支持即时交互和长时对话，既可处理快速请求，也能胜任持续几小时乃至跨天的复杂任务而不中断developers.googleblog.comcohorte.co。
总的来说，A2A 的架构遵循以下设计原则：一是发挥代理智能，允许各代理以各自最自然的方式协作，不要求共享内部内存或工具，真正实现多智能体协同developers.googleblog.comdevelopers.googleblog.com；二是开放标准与现有技术结合，建立在 HTTP、JSON-RPC 等成熟协议上，方便与现有系统整合developers.googleblog.com；三是默认安全（下文详述），内建企业级身份验证和授权机制，确保代理通信的安全可信developers.googleblog.com；四是支持长任务，允许任务执行跨越较长时间且提供过程反馈developers.googleblog.com；五是模态无关，协议对文本、文件、音视频等各种内容形式均提供支持，前瞻性地满足多模态协作需求developers.googleblog.com。
二、应用场景
作为促进 AI 代理协作的“通用语言”，Agent2Agent 协议在 Google 内部和业界具有广泛的潜在应用场景。企业流程自动化是其中重要领域：大型企业的日常业务流程往往涉及多个系统和角色，通过 A2A，不同职能的AI代理可以共同完成端到端的自动化流程。例如，在 IT 运维中，一个“资产管理”代理可以通过 A2A 请求另一个“采购”代理为新员工自动下单配备笔记本电脑dev.todev.to。过去这些跨系统操作可能需要人工或定制集成，现在代理之间即可自主对接。又如在供应链管理场景，库存代理可以触发采购代理或物流代理协同工作，完成库存补货等复杂链条任务developers.googleblog.com。
多代理协同工作是 A2A 最直接的用途，即让多个专长不同的AI代理组成“团队”分工合作完成复杂任务。例如在人力资源招聘流程中，企业可部署不同AI代理：一个负责筛选简历，另一个安排面试时间，第三个回答候选人常见问题。借助 A2A，这些代理可以相互通知进展并共享信息：筛选代理筛出符合条件的简历后，通过协议将结果发送给面试安排代理，后者再通知面试官代理或发送面试邀请dev.todev.to。整个流程由多个代理衔接，实现招聘流程的高度自动化。Google 官方博客也提供了类似的候选人招聘协作案例：在一个统一界面中，招聘经理指派助手代理根据职位要求搜寻候选人，该助手再与其他专门代理（如候选搜索代理）互动获取名单，并继续安排下一步面试，最后还可调用背景调查代理完成背调developers.googleblog.com。通过这些代理链条协作，招聘流程各环节被自动化衔接起来，大幅提高效率developers.googleblog.com。
在智能个人助理方面，A2A 可以让助手的能力大大扩展，不再局限于单一AI模型，而是整合身后多个专长代理的结果。例如，一个个人AI助理要帮用户规划海外旅行行程，借助 A2A，它可以调用“航班预订代理”查询航班选项，再调用“行程优化代理”规划路线，甚至联系“翻译代理”获取当地语言帮助。所有这些子任务代理通过统一的A2A接口协同，使得个人助理能完成复杂的跨领域任务。类似地，在工作场所的企业助理场景，某部门的销售助理代理如果发现客户提出了技术问题，可以直接通过 A2A 通知技术支持代理跟进，从而实现部门间的智能协作dev.todev.to。以往各部门各自的AI工具彼此孤立，而现在因为有了统一协议，它们能够跨部门协同工作。
除此之外，A2A 的应用还可以延展到客户服务、电子商务物流、金融风控等众多领域dev.to。凡是需要多个智能体协同的场景，例如客服机器人需要向库存查询代理获取商品库存信息再答复客户，抑或多个风控代理串联分析交易、评估风险，A2A 都可以作为沟通桥梁使这些代理形成“合奏”。值得一提的是，Google 已将 A2A 集成到其云端 AI 工具中：例如 Google Cloud 的 Vertex AI Agent Development Kit (ADK) 框架支持使用 A2A 来连接不同生态的代理cloud.google.com。这意味着企业开发者可以用 ADK 快速构建支持 A2A 的多智能体系统，并与其他框架（如 LangChain、LangGraph、CrewAI 等）构建的代理互通cloud.google.com。超过50家合作伙伴（包括 Atlassian、Salesforce、SAP 等业内领先公司）已参与 A2A 标准制定并承诺支持这一协议developers.googleblog.com cloud.google.com。这种广泛的联盟表明业界对代理互操作的共同愿景：未来无论底层技术为何，AI 代理都能像网络服务那样自由“对话”和协作，为复杂业务流程提供前所未有的效率提升dev.to。
三、安全性设计
身份认证与授权：安全性是 A2A 协议设计的核心考量之一，官方原则即强调“默认即安全”（Secure by default）developers.googleblog.com。为满足企业级安全需求，A2A 支持完善的身份验证和授权机制。具体来说，每个代理的 Agent Card 中明确列出了其所要求的身份认证方法dev.to。例如，某代理服务可以在 Agent Card 的authentication字段中声明仅接受持有 OAuth2 Bearer token 的请求，或要求请求方提供 API Key 等cohorte.cocohorte.co。客户端代理在调用之前必须按照对方要求附带相应凭证，才能通过身份验证。这种机制确保只有获得授权的代理才能互相通信，杜绝未授权访问cohorte.cocohorte.co。A2A 协议的认证设计与常规 Web API 保持一致性——与 OpenAPI 定义的认证方案齐平developers.googleblog.com，支持诸如 OAuth2、API Key、Basic Auth 等业界通用方案，从而便于企业沿用既有的安全基础设施和策略cohorte.co。由于基于 HTTP 通信，A2A 自然可以运行在 TLS/HTTPS 之上实现传输加密，保障代理间交换的数据在网络传输过程中不被窃听或篡改cohorte.cocohorte.co。同时，协议标准化的认证流程也方便企业对大量代理实施统一的凭证管理和轮换，从而减少各自为政带来的安全漏洞dev.tocohorte.co。
访问控制与审计：通过集中定义认证要求，企业能够策略性地控制哪些代理有权限与哪些其他代理通信，以及可交换哪些数据dev.to。例如，企业可以配置只允许内部可信代理使用特定凭证访问某些敏感代理服务。所有代理交互都遵循统一协议，因此可以纳入集中监控与审计。相比过去每对集成接口各自实现安全控制，采用 A2A 后企业能获得对代理网络的整体视角，统一审计交互日志和数据交换，从而提高风控能力dev.to。此外，A2A 的通信模式只要求代理共享执行任务所需的输入和输出，不涉及代理内部的推理过程或机密状态dev.to。这一点对企业尤为重要：代理间即使协作，也无需暴露各自内部的算法细节、模型权重或私人数据库等。每个代理仍像“黑盒”一样保持内部独立，只通过清晰定义的接口传递必要信息dev.to。这使不同团队或供应商的代理在合作时依然保有各自的商业机密或合规要求，减少数据外泄风险。在大规模部署中，企业还可借助协议赋能跨平台的代理管理：随着越来越多系统采用 A2A，企业可对其“代理舰队”进行统一监控和优化，例如发现异常通信行为、统计代理性能、集中升级安全策略等dev.to。总之，A2A 从协议层面提供了标准化、可管控的安全框架，使企业在享受代理互操作带来效率提升的同时，不牺牲对安全与治理的掌控。
四、与其他协议的比较
作为一种新兴的多智能体通信协议，A2A 在设计理念、效率和安全性等方面与现有的多种协议有相似之处，也存在明显差异。下面将 A2A 分别与传统 RPC/gRPC 调用、XMPP 消息协议以及早期的开放代理架构 (OAA) 进行比较，并简要讨论其与当代相关协议的关系。
1. 与 RPC / gRPC 框架的比较
设计与集成：传统的远程过程调用（RPC）框架（如早期的XML-RPC或JSON-RPC）以及现代的 gRPC 都用于实现分布式系统中的服务通信。A2A 本质上采用了 JSON-RPC 2.0 规范来组织其请求和响应格式huggingface.co。这意味着每次 A2A 请求都包含类似{"method": "tasks/send", "params": {...}, "id": ...}的 JSON 结构，符合 JSON-RPC 的调用约定medium.com。与 gRPC 不同的是，JSON-RPC 是文本格式且无需预先定义接口的二进制模式文件，拥有更广泛的语言互操作性和易用性stackshare.io。gRPC 基于 Protocol Buffers 二进制序列化，运行效率更高，但需要编译生成客户端/服务端存根代码，在语言支持和调试便利性上略逊stackshare.io。A2A 选择 JSON-RPC + HTTP 的组合，牺牲了一定的性能换取了最大程度的兼容性和易集成——任何能够发出 HTTP 请求、解析 JSON 的环境都可以加入 A2A 网络，而无需特定的 gRPC 库支持cohorte.co。这一点对多供应商、多语言的代理生态尤为重要，因为各方实现A2A只需遵循公开规范，用各自熟悉的Web技术栈即可。
通信模式与效率：gRPC 的一大优势在于其原生支持双向流式通信和高吞吐，适合高性能微服务场景。而 A2A 则通过 HTTP 长连接 + SSE 实现了服务端单向流（server push），允许远程代理持续向客户端发送进度更新github.com。虽然 SSE 只能由服务器推送，客户端不能通过同一通道反向发送，但 A2A 利用任务ID关联多次请求，已能涵盖大部分交互需求（客户端需要回复时另行发送tasks/send请求即可）cohorte.co。在性能方面，JSON 编码比 Protobuf 冗长，但典型 A2A 交互中的主要开销往往是AI模型推理或外部操作等待，相比之下协议开销可以忽略不计。此外，HTTP/2 及 HTTP/3 的逐步普及也缩小了 JSON-RPC 与 gRPC 在传输性能上的差距。可以认为，A2A 优先考虑的是易用性和开放性，在可接受的性能范围内选择了最通用的Web技术，而 gRPC 更适用于对性能要求极高、环境统一可控的内部服务通信。
安全机制：gRPC 本身是传输层协议，可在 TLS 上运行并结合任意认证方案，但缺乏统一的应用层安全约定。A2A 则内置了应用层的认证/授权规范，直接在协议层要求使用 OpenAPI 风格的认证方案并写入 Agent Card 中developers.googleblog.comcohorte.co。这使得在实现代理时安全考量不可或缺且保持一致。相比而言，使用 gRPC 时安全逻辑通常由开发者自行在应用实现中处理，而 A2A 将其标准化为协议的一部分，使不同代理之间更容易进行信任校验与授权管理dev.tocohorte.co。总的来说，A2A 可以被视作专为多智能体交互定制的高层RPC协议：它利用JSON-RPC的通用调用格式和HTTP的普适传输，大幅降低集成门槛，并添加了任务上下文、流式更新、标准安全等高层功能，从而超越传统RPC的能力范围，满足复杂多步骤的代理协作需求。
2. 与 XMPP 等消息协议的比较
协议性质：XMPP（可扩展消息和存在协议）是即时通讯领域的开放标准协议，擅长低延迟消息传递和多方聊天室/发布订阅等模式。某种程度上，XMPP 也曾被用于代理或Agent系统的通信基础，例如一些早期智能体框架允许通过 XMPP 交换消息。然而，XMPP 本质上是一个通用消息路由协议，它并不直接提供像 A2A 那样针对“任务”或“能力协商”的高级抽象。A2A 则专注于请求-完成式的任务协作，消息始终围绕某个任务ID展开，并且在协议层定义了任务状态、结果产出等结构。相比之下，在 XMPP 上实现类似功能需要开发者自行规定XML消息的格式和语义，上层协议工作量更大。
架构与扩展性：XMPP 通常依赖一个中继服务器（XMPP服务器）来路由消息，各参与方通过长期保持的TCP连接加入网络。这为实时通信提供了便利，但也引入了部署复杂性，尤其在跨组织场景下需要联邦多个服务器。A2A 则采用直接的 HTTP 调用：客户端代理知道远程代理的服务 URL 后即可直接发起 HTTP(S) 请求，无需经过中间消息服务器cloud.google.com（除非企业有意在网关层设置代理目录或路由）。这种方式更贴合现代微服务和Web架构——每个代理服务可以部署在标准的 Web 基础设施上（如 Kubernetes、云函数），通过HTTPS被访问cohorte.co。对于防火墙和企业网络而言，HTTP/HTTPS 通常已被开放和监控，而引入 XMPP 则可能需要额外开放端口或部署协议网关。扩展能力方面，XMPP 使用 XML 格式，扩展字段需要考虑命名空间避免冲突；A2A 使用 JSON 结构，更易于解析且可自然映射为对象数据结构，更符合现代 Web API 的风格。另外，XMPP 提供状态通知（在线/离线）等功能，而 A2A 不涉及代理存在性的管理——它假定通过发现机制获取到服务URL，即表示该代理可用，由调用超时等机制处理不可达情况。这使 A2A 更加轻量直观，避免了引入复杂的网络状态管理。
性能与安全：在高频小消息场景下，XMPP 的持续连接和小尺寸 XML 消息可能更有效率，适合聊天或传感数据流。但对于 A2A 涉及的较大内容和任务结果传输，HTTP/2的多路复用和流控制同样可以胜任，且 SSE 机制已能满足单向实时更新需求github.com。安全方面，XMPP 通常通过 TLS 和 SASL 完成加密和认证，但这些认证多为固定机制（如用户名/密码、OAuth Bearer 等）且不直观地暴露在应用层协议中。A2A 则明确在应用协议中声明了安全要求，让开发者在对接时即可知悉需要什么令牌或凭证cohorte.co。可以说，A2A 将 Web API 安全的最佳实践直接融合进来了，对企业而言管理难度更低cohorte.codev.to。概括而言，XMPP 更类似一套实时消息传输的“底盘”，需要在上面自定义协议；而 A2A 是量身定制的“整车”，直接面向代理协作场景开箱即用。对于需要快速互通、强调任务和结果的AI代理系统，A2A 以较低的集成成本提供了即用型方案。
3. 与 Open Agent Architecture (OAA) 的比较
历史背景：Open Agent Architecture (OAA) 是上世纪90年代中期由 SRI International 等提出的开放代理框架，是较早探索异构软件Agent协作的体系结构之一。OAA 的架构特点是引入一个中央协调者（Facilitator）：所有 Agent 注册到 Facilitator，声明自身提供的能力或服务；当某个 Agent 提出任务请求时，由 Facilitator 来匹配合适的 Agent 执行，并在它们之间路由消息dev.todev.to。OAA 还设计了自己的通信语言（如基于KQML的消息格式）来表示 Agent 要求的目标和约束。这样的设计在学术上验证了异构代理协作的可行性，但在实际应用中部署较复杂，而且由于强依赖中心节点，系统扩展性和鲁棒性受制于 Facilitator 的性能和单点故障风险。
架构对比：A2A 与 OAA 在目标上有相似之处——都是为了让不同技术栈的 Agent 能互操作。然而实现方式却更符合现代理念。首先，A2A 无须中央调度者：它更倾向于点对点的直接通信，Agent Card 机制让每个代理都能独立发布自己的能力描述供他人发现github.comgithub.com。虽然在大型部署中可以配合服务目录提升发现效率，但协议本身并不强制依赖一个中心节点，减少了系统耦合。其次，A2A 使用简单直观的任务模型和JSON消息，降低了协议复杂度；而 OAA 的消息语言相对晦涩（如带有逻辑变量和约束求解的脚本格式），开发者学习和使用门槛高，兼容性也不如 JSON/Web 标准通用。再次，从效率和伸缩考虑，OAA 在上世纪90年代的网络环境下设计，主要面向局域网或单机多进程协作，未充分考虑互联网规模的高延迟和安全需求。而 A2A 则诞生于云计算和企业互联时代，设计时充分考虑了跨网络的大规模部署：使用HTTP方便穿透现有网络基础，标配认证保障跨组织安全，同时能借助云端基础设施实现水平扩展。可以认为，A2A 是站在前人（如 OAA、FIPA 等代理框架）肩膀上，结合当代技术发展制定的新标准，有望避免 OAA 那样止步于实验室的命运——尤其在 Google 等巨头推进及众多公司联合支持下，A2A 更有机会成为工业界普遍接受的代理通信规范developers.googleblog.com dev.to。
4. 其他相关协议
值得一提的是，当前业界还有其他致力于 AI 系统互操作的开放协议。例如 Anthropic 的 Model Context Protocol (MCP) 专注于标准化应用如何为大型模型提供上下文和连接外部工具github.com。与 A2A 不同，MCP 更多是让单个 AI 模型与外部数据源或工具交互的接口，被称作 AI 应用的“USB-C 接口”docs.anthropic.com。Google 明确表示 A2A 与 MCP 是互补关系而非竞争关系：MCP 提供将模型接入各种工具和数据的手段，而 A2A 则提供不同代理（每个代理内部或许使用了LLM+MCP等）之间协作的手段developers.googleblog.com。两者结合，可以让一个代理既能通过 MCP 使用工具，又能通过 A2A 与其他代理对话，共同完成更复杂的任务cloud.google.com cloud.google.com。此外还有 Cisco 等牵头的 AGNTCY 协议等探索venturebeat.com。可以预见，随着 agentic AI 的兴起，这一领域将涌现多种协议标准。但 A2A 凭借其开放中立和广泛支持，有机会成为事实上的基础“通用语言”，正如 HTTP 成为万维网通信基石一样dev.tocohorte.co。
五、协议实作细节
A2A 协议的详细规范已经在 GitHub 以 Apache 2.0 许可证开源公开，其中定义了消息格式、接口路径和交互流程等技术细节developers.googleblog.com。开发者可依据该规范实现兼容的 A2A 客户端或服务。下面从协议格式和交互流程两方面总结其实作要点：
（一）Agent Card 格式：Agent Card 是一个标准的 JSON 文件，其字段设计遵循协议规范。huggingface.co列出了主要字段及作用：
name：字符串，代理名称（供人读取识别）。description：字符串，可选，对代理功能的简要描述。url：字符串，A2A 服务端接口的基址 URL（客户端将向该 URL 发送 JSON-RPC 请求）huggingface.co。version：字符串，代理实现或所用 A2A 协议版本。capabilities：对象，描述代理支持的协议能力huggingface.co：streaming：布尔值，代理是否支持 SSE 流式 (tasks/sendSubscribe)。huggingface.copushNotifications：布尔值，代理是否支持 webhook 推送通知。stateTransitionHistory：布尔值，Task 对象中是否包含状态变迁的历史记录（便于调试或审计）。
authentication：对象，可选，指定所需身份认证方式huggingface.co：schemes：字符串数组，列出支持的认证方案，例如"bearer"表示需要附带OAuth Bearer Token，"apiKey"表示需要API密钥等huggingface.co。
通过 GET 请求获取该agent.json，客户端能够解析出目标代理的服务端 URL、所要求的认证类型，以及是否支持流式等高级功能，然后据此调整后续调用策略。例如，如果streaming=true，客户端就可以考虑用tasks/sendSubscribe订阅实时结果；若某代理要求"bearer"令牌，客户端则需准备好有效的 OAuth2 Token 放入 Authorization 头再调用。Agent Card 也可被托管在服务注册中心或企业内部目录中，方便集中管理。
（二）标准接口与消息流程：A2A 将代理服务的功能统一抽象为少数几个标准的 JSON-RPC 方法接口，所有符合协议的服务端都应实现这些方法。主要的方法包括：
tasks/send：提交一个任务请求，或在任务进行过程中发送新消息。huggingface.co该方法接受参数包括：id（任务ID，客户端生成的新UUID或现有任务ID用于续接）、message（本次发送的消息内容，含角色和Parts）等。调用成功时，服务端返回一个 Task 对象，包含当前最新的任务状态和可能的结果/Artifacts。当任务同步完成时，返回的 Task 即会标记状态为completed并附带最终 Artifacthuggingface.co。tasks/sendSubscribe：与tasks/send类似，但用于 订阅长任务。huggingface.co服务端在接收请求后通常快速响应接受订阅，并通过保持的 SSE 通道持续发送 Task 更新事件，客户端从事件流中获取任务最终结果。订阅期间，服务端不会在HTTP响应体中直接返回完整Task，而是通过事件通知完成。tasks/pushNotification/set：设置回调 URL，让服务端在任务状态变化时向该 URL 发送 HTTP POST 通知。github.com客户端提供一个 endpoint 以及期望接收的任务ID或范围，服务端收到后在后续任务更新时触发回调。这个接口可用于不方便保持 SSE 长连接的场景，实现类似功能。tasks/cancel：请求取消一个进行中的任务。服务端收到请求后应尝试取消执行并返回取消结果。
典型的 A2A 调用顺序如下：
- 发现（Discovery）：客户端知道某远程代理服务的地址后，首先获取其 Agent Card（通常通过
GET https://<host>/.well-known/agent.json）。解析后获取endpoint URL（即后续 JSON-RPC 调用的目标基址）以及认证要求、能力支持等。github.com - 任务发起（Initiation）：客户端生成一个全局唯一的任务ID（例如 UUID），构建初始请求消息（包含用户意图的文本或其他输入作为 Message 的各个 Part），然后调用远程代理的
tasks/send或tasks/sendSubscribe方法。github.com github.com如果预计任务耗时较长且目标代理支持streaming，可优先选择后者订阅模式以获取实时反馈。 - 任务处理与进度更新（Processing）：远程代理接收到任务后，进入处理流程。对于快速任务，远程代理可能在同一个响应中直接返回 Task 结果（此时 Task 状态为
completed，并带有输出 Artifact）cohorte.co cohorte.co。对于长任务，远程代理会先响应接受任务（状态submitted或working)，随后通过 SSE 推送状态更新事件，例如任务开始处理（进入working）、任务进度信息，甚至需要额外输入的通知（进入input-required）cohorte.co cohorte.co。客户端持续监听 SSE 事件来获知任务进展和中间产物。值得注意的是，如果目标代理不支持 SSE，客户端也可以选择轮询tasks/getStatus之类的扩展方法（若有）或通过tasks/send定期查询，但 SSE 无疑是更高效的模式。 - 交互（Interaction，可选）：当远程代理发送
input-required指示时，意味着当前任务需要客户端提供额外信息才能继续（例如用户需填写验证码，或澄清之前的问题）。此时任务暂停等待输入cohorte.co。客户端收到该状态后，可以提示用户并收集输入，然后再次调用tasks/send，附上先前的任务ID和新的 Message（角色通常仍标记为“user”），以继续原任务。cohorte.co远程代理收到后改变任务状态为working继续处理。这样的交互可进行多轮，直到任务能够完成。 - 完成（Completion）：最终，任务要么顺利完成（状态变为
completed并产出最终 Artifact），要么失败（failed，通常伴随错误信息），或被取消（canceled）。客户端在收到任务终止状态后，即可提取最终结果 Artifact 作后续处理huggingface.co。对于 SSE 订阅模式，远程代理通常会在任务结束时发送最终状态事件并关闭 SSE 流。若使用同步模式调用tasks/send，则终止状态和结果直接包含在响应中huggingface.co。
上述流程体现了 A2A 任务为中心的异步协作模型：通过任务ID串联起多次消息往返，保证对话上下文一致；任务状态机提供了标准的过程控制，使客户端可对不同状态进行相应处理（如展示进度、提示输入或错误重试）。同时，以 JSON-RPC 接口形式暴露，使不同语言和框架能够轻松对接。
（三）参考实现与工具：Google 提供了丰富的开源示例和工具来帮助开发者理解和实现 A2Agithub.com。在官方仓库中，包含用 Python 和 JavaScript 编写的示范性 A2A 客户端/服务端实现github.com，以及演示多代理协作的 Web 应用和 CLI 工具github.com。另外还有适配主流代理开发框架的示例（如针对 LangChain、ADK 等的 sample agents）github.com。通过研读这些示例代码，可以看到 A2A 抽象在实际代码中的映射：例如 Python 示例中定义了 Task、Message、Artifact 等数据类，与规范中的 JSON 结构对应；客户端示例展示了如何构造 JSON-RPC 请求以及处理 SSE 事件流huggingface.co。这些资源为开发者提供了实作蓝本。更详细的协议字段解释和交互示例，可参阅官方公布的协议草案文档以及技术博客说明developers.googleblog.com。总之，A2A 的实现在技术上并不复杂——正如 Cohorte 的工程解读所言：“任何能够发出 HTTP 请求并解析 JSON 的环境都可以参与 A2A”cohorte.co。这也验证了 A2A 设计的初衷：以尽可能简单和开放的技术，构建出灵活强大的多智能体协作网络。
结语
Google 的 Agent2Agent 协议以开放互操作为目标，提供了一套面向未来的多代理通信标准。通过统一的任务语义和丰富的协商机制，A2A 打破了不同 AI Agent 框架之间的壁垒，让“AI 代理生态”成为可能：企业能够像管理微服务那样管理各种智能代理，让它们各司其职又相互配合，自动化完成过去需要人为协作的复杂流程。与传统通信协议相比，A2A 在设计上融合了分布式AI的特定需求，例如能力发现、长任务支持、富媒体交互和内置安全developers.googleblog.com developers.googleblog.com。它并非凭空创造，而是站在 HTTP/JSON-RPC 等巨人肩膀上，充分利用既有技术并结合新思路。随着众多行业领导者的加入支持developers.googleblog.com，A2A 有望发展为跨平台代理通信的通用标准。这将提升 AI 系统的模块化和可组合性，正如 TCP/IP 协议栈奠定了互联网那样，A2A 将为 AI 代理的互联互通奠定基础cohorte.co。展望未来，Agent2Agent 协议所引领的代理互操作趋势，预示着一个由协作智能体构成的网络正在形成——各个AI代理将不再孤立工作，而是能够彼此对话、协同决策，组成更强大的智慧系统来服务人类。
参考资料：
- Google Developers Blog – “Announcing the Agent2Agent Protocol (A2A)”developers.googleblog.com developers.googleblog.com
- Google Cloud 官方博客 – “Build and manage multi-system agents with Vertex AI”cloud.google.com cloud.google.com
- Google A2A GitHub 项目 README – “Agent2Agent Protocol A2A – Core concepts”github.com github.com
- Cohorte Engineering Blog – “Google’s Agent2Agent (A2A) Protocol: A New Era of AI Agent Interoperability”cohorte.co cohorte.co
- DEV.to 技术解读 – “深入研究 Google Agent2Agent (A2A) 协议”dev.todev.to
- HuggingFace Blog – “What is The Agent2Agent Protocol (A2A) and Why You Must Learn It Now”huggingface.co huggingface.co
- Google Developers Blog – “A real-world example: candidate sourcing with A2A”developers.googleblog.com
- Blott Studio – “How the Agent2Agent Protocol (A2A) Actually Works”cohorte.co cohorte.co
- VentureBeat – “Google’s Agent2Agent protocol aims to standardize agentic communication”venturebeat.com venturebeat.com
- 经典研究 – “Open Agent Architecture (OAA)”dev.todev.to