A2A 协议：打破代理系统之间的隔阂

在当今数字化时代，人工智能和自动化技术正以前所未有的速度发展。 随着各种智能代理系统不断涌现，如何让这些系统之间实现无缝协作， 成为了技术发展的一个重要课题。 谷歌推出的 Agent2Agent Protocol（A2A）协议，正是为解决这一问题而生。 A2A 协议旨在为代理系统之间搭建起一座沟通的桥梁， 让它们能够像人类一样高效地协同工作，共同为最终用户提供服务。

A2A 和 MCP ?

A2A 协议支持代理之间的通信，使它们能够协作完成任务并朝着共同目标努力。 与Anthropic 的模型上下文协议 (MCP)一样，A2A 旨在通过统一的方法消除多代理集成的复杂性。 而 MCP 规范了 AI 系统与工具和数据的连接方式，减少 AI和工具集成的复杂性。

• • A2A：负责 代理 - 代理 之间的通信。
• • MCP：负责 代理 - 工具 之间的通信。

核心理念与原则

A2A 协议的核心理念是让代理系统能够在 不共享内部记忆、思维或工具的情况下，完成任务。

这意味着每个代理系统都保持其独立性和自主性 ，它们通过交换上下文、状态、指令和数据来协作， 而不是通过共享内部逻辑或资源。 这种设计理念不仅保护了代理系统的隐私和安全性， 还使得不同类型的代理系统能够更加灵活地进行集成和协作。

也就是说我们这些年已经构建好的代理，逻辑都不用变化，只用做一层接口即可以把这些代理链接起来。

比如我们已经有很多代理：

• • 负责报销的AI代理
• • 负责订机票、酒店的AI代理
• • 复杂项目管理的AI代理

在之前，我们如果想要把这些代理整合起来，大致有两种做法，

• • 把所有智能体合并成一个大的智能体
• • 把所有智能体的流程串联起来，形成一个大的流程，预设逻辑调用不同的AI代理

无论是哪种方式，工作量都不小，而且难以维护和扩展（大部分人设计出来的架构扩展性和可用性都不会太高，当然也和投入的人力有关）， 常常遇到的问题可能有：

• • 整合复杂的流程，逻辑不清晰
• • 通信协议设计不合理，扩展不兼容（比如技术抽象的业务抽象的平衡）
• • 各个代理之间的数据边界不好定义，比如是否有全局状态等问题，常常导致数据混乱
• • ...

A2A 其实可以认为是第二中方案的一个高度抽象版本。 A2A 协议遵循几个关键原则，这几个原则也是指导解决我们上述问题的原则：

• • 简单性：协议尽量复用现有的标准，降低实现和集成的复杂性。
• • 企业级就绪：提供身份验证、安全性、隐私保护、追踪和监控等功能，满足企业级应用的需求。
• • 异步优先：支持长时间运行的任务和需要人工参与的任务，允许代理系统在后台处理任务，而不需要实时响应。
• • 模态无关性：支持多种交互模式，包括文本、音频/视频、表单、iframe 等，适应不同的应用场景。
• • 不透明执行：代理系统不需要共享它们的内部思维、计划或工具，确保了系统的独立性和安全性。

协议架构与关键组件

A2A 协议涉及三个主要角色：用户、客户端和远程代理（服务器）。

• • 用户是使用代理系统完成任务的最终用户，可以是人类或服务。
• • 客户端是代表用户向远程代理请求操作的实体，可以是服务、代理或应用程序。它是使用 A2A 服务的应用或代理。这是您的 “主”代理 ，负责整理任务并将其传达给其他代理。
• • 远程代理则是 A2A 服务器，它是一个不透明的『黑盒』代理，负责执行客户端请求的任务，也就是我们上面提到的各种待集成的 AI 代理。

在传输层面，A2A 协议使用 HTTP 作为客户端和远程代理之间的通信方式。 根据客户端和远程代理的能力，它们还可以利用服务器发送事件（SSE）来支持流式传输， 以便在连接状态下接收服务器的更新。A2A 采用 JSON-RPC 2.0 作为数据交换格式，确保了通信的高效性和灵活性。

为了支持异步通信，

• • A2A 协议允许客户端和服务器使用标准的请求/响应模式，并通过轮询获取更新。
• • 此外，协议还支持通过 SSE（连接时）和推送通知（断开连接时）进行流式更新。

这种异步机制使得代理系统能够像企业应用程序一样运行，快速实现代理之间的互操作性。

在身份验证方面，A2A 遵循 Open API 的身份验证规范。 代理系统不会在 A2A 协议内部交换身份信息， 而是通过带外方式获取身份验证材料（如令牌）， 并通过 HTTP 头传输这些材料，而不是在 A2A 负载中传输。

• • 服务器会在 A2A 负载中发送身份验证要求，
• • 客户端需要使用服务器发布的身份验证协议来验证其身份并获取身份验证材料。
• • 服务器会对每个请求进行身份验证， 并使用标准的 HTTP 响应代码（如 401、403）以及身份验证协议特定的头和正文来拒绝或挑战请求。

Agent Card：代理系统的能力名片

为了让客户端能够了解远程代理的能力和身份验证机制， A2A 协议要求支持 A2A 的远程代理必须发布一个名为 Agent Card 的 JSON 格式文件。

Agent Card（代理卡）就像是每个代理的能力 名片 。

Agent Card 包含了代理系统的详细信息，如名称、描述、托管地址、服务提供商、版本、文档链接等。 更重要的是，它还列出了代理系统所支持的技能（Skills）， 包括每项技能的唯一标识符、名称、描述、标签、示例场景以及支持的输入和输出模式。

Agent Card 的发现机制将 Agent Card 文件托管在远程代理的基础 URL 的 『/.well-known/agent.json』 路径下。 这种方式与 DNS 方法兼容，客户端可以通过 DNS 找到服务器的 IP 地址， 然后发送 HTTP GET 请求来获取 Agent Card。 此外，系统还可以维护私有注册表，如 『代理目录』 或私有市场等，以便更好地管理和发现代理系统。

我们每个 远程代理服务，都有一个代理卡，比如我们请假的远程代理地址是 12.x.x.x:8000，那么访问 12.x.x.x:8000/.well-known/agent.json 就可以获取到代理卡信息。

代理之间的通信：任务驱动的协作

A2A 协议的核心是任务（Task）驱动的通信模式。 任务是一个有状态的实体，允许客户端和远程代理共同实现特定的结果并生成结果。 客户端和远程代理通过在任务中交换消息（Messages）来协作， 而远程代理则生成结果作为工件（Artifacts）。 任务始终由客户端创建，而状态则由远程代理确定。 客户端还可以为任务设置可选的会话 ID，以便将多个任务组织在一个会话中。

任务的状态可以是

• • 『已提交』、
• • 『正在处理』、
• • 『需要输入』、
• • 『已完成』、
• • 『已取消』、
• • 『失败』或
• • 『未知』。

远程代理可以根据任务的状态和需求， 立即完成请求、安排后续工作、拒绝请求、协商不同的交互模式、 向客户端请求更多信息或委托给其他代理和系统。 即使任务目标已经完成，客户端仍然可以请求更多关于该任务的信息或更改任务的上下文。

任务用于传输工件（结果）和消息（包括代理的思考过程、用户上下文、指令、错误、状态或元数据等）。 任务维护一个状态和可选的历史记录，其中包含状态和消息的变更历史。

核心对象：任务、工件、消息和部分

除了任务，A2A 协议还定义了几个核心对象，包括工件、消息和部分（Part）。

工件是代理系统完成任务后生成的最终结果，它们是不可变的，可以被命名，并且可以包含多个部分。 例如，一个任务可能是创建一个网页，而这个任务可能会生成单独的 HTML 和图像工件。

消息包含除工件之外的任何内容，如代理的思考过程、用户上下文、指令、错误、状态或元数据等。客户端发送的所有内容都以消息的形式出现，而代理则通过消息向客户端传达状态或提供指令（生成的结果则作为工件发送）。消息可以包含多个部分，以表示不同的内容。例如，用户请求可能包括用户提供的文本描述以及客户端提供的多个文件作为上下文。

部分（Part）是客户端和远程代理之间交换的完整内容单元，可以是文本、文件或数据。每个部分都有自己的内容类型和元数据。

推送通知：实时更新与离线通知

A2A 协议还支持推送通知机制，使得代理能够在与客户端断开连接的情况下， 通过推送通知服务向客户端发送更新。这种机制对于实时性和可靠性要求较高的应用场景非常关键。 代理需要验证推送通知服务的身份，使用身份验证令牌与服务进行身份验证，并提供一个与正在执行的任务相关联的标识符。

推送通知的目标服务器被视为一个独立的服务， 它负责对代理进行身份验证和授权， 并将经过验证的通知代理到适当的端点（可以是消息队列、电子邮件收件箱或其他服务等）。 在一些特定场景下， 例如在隔离的客户端-代理对（如在受限的虚拟私有云中）或没有企业级安全问题的环境中， 客户端可以选择直接作为自己的推送通知服务。

然而，在企业级实现中，通常会有一个集中化的服务来对远程代理进行身份验证，并处理在线和离线场景。

示例方法与 JSON 响应

A2A 协议提供了多种方法和 JSON 响应格式， 用于实现客户端与远程代理之间的各种交互。 例如，

• • 客户端可以通过『tasks/send』方法向远程代理发送内容， 以启动新任务、恢复中断的任务或重新打开已完成的任务。
• • 远程代理则可以通过『tasks/get』方法检索任务生成的工件， 或者通过『tasks/cancel』方法取消之前提交的任务。
• • 此外，客户端还可以通过『tasks/pushNotification/set』和 『tasks/pushNotification/get』方法配置和检索任务的推送通知设置。

多轮对话与流式支持

A2A 协议支持多轮对话， 当任务需要额外的用户输入时， 任务会在『需要输入』状态暂停。 客户端需要提供额外的输入，任务才能在远程代理上恢复执行。 在这种情况下，代理会向客户端发送包含详细信息的消息，说明客户端需要做什么。 如果需要，代理还可以发送结构化数据作为消息的一部分。

此外，A2A 还支持流式传输。 对于支持 HTTP 和 SSE 的客户端和远程代理， 客户端可以在创建新任务时使用『tasks/sendSubscribe』方法发送 RPC 请求。 远程代理可以以流的形式响应任务状态更新事件和任务工件更新事件。 任务工件更新事件可以向现有工件追加新部分。 客户端可以使用『task/get』方法在流式传输之外检索整个工件。 代理必须在流结束时或需要额外用户输入时设置『final:true』属性。

非文本媒体与结构化输出

A2A 协议不仅支持文本数据，还支持非文本媒体数据的交互。 例如，客户端可以向代理发送包含文本和文件（如 PDF 报告）的消息， 请求代理对文件进行分析并生成高级概述。代理可以处理文件，并将结果作为工件返回给客户端。

此外，客户端和代理还可以请求对方提供结构化输出。 例如，客户端可以请求代理以 JSON 格式返回数据， 代理则可以根据请求生成相应的结构化数据作为响应。

错误处理

当服务器在处理客户端请求时遇到错误时，A2A 协议定义了错误消息格式， 以便服务器能够向客户端发送详细的错误信息。 错误消息包含错误代码、描述性消息以及可选的附加数据。 协议还定义了一系列标准的 JSON-RPC 错误代码，用于处理不同的错误场景， 如

• • JSON 解析错误、
• • 无效请求、
• • 方法未找到、
• • 无效参数、
• • 内部错误、
• • 服务器错误、
• • 任务未找到、
• • 任务无法取消、
• • 推送通知不支持、
• • 不支持的操作
• • 以及不兼容的内容类型等。

A2A 和 MCP 的互补

尽管 A2A 和 MCP 看似在争夺同一领域，但它们实际上是为协同工作而设计的。它们分别针对人工智能集成的不同（且互补）方面。 就像我们前面提到的，

• • MCP将 LLM（或代理）连接到工具和数据源（垂直集成）
• • A2A将代理与其他代理连接起来（水平集成）

总结

A2A 协议为代理系统之间的互操作性提供了一个开放、灵活且安全的解决方案。 通过定义清晰的角色、通信机制和核心对象，A2A 使得不同的代理系统能够无缝协作， 共同完成复杂的任务。 随着人工智能和自动化技术的不断发展， A2A 协议有望成为推动智能代理系统发展的关键力量，

如果你在过去两年内已经构建了 AI 代理系统，不妨试一试用 A2A 把他们集成起来。

参考 ：

• • https://google.github.io/A2A/^[1]

引用链接

[1]: https://google.github.io/A2A/