---

---

引言

A2A协议是一个开放标准，它实现了人工智能代理之间的无缝通信和协作。它为使用不同框架和由不同供应商构建的agent提供了一种通用语言，从而促进了互操作性并打破了信息孤岛。agent是自主问题解决者，能够在各自的环境中独立行动。A2A协议使得来自不同开发者、基于不同框架构建、并由不同组织拥有的agent能够联合起来协同工作

理解A2A协议对理解A2A Agent、Multi Agent等架构是十分有必要的，A2A为agent协作提供了一个统一标准与协议。

A2A解决的问题

假设用户请求人工智能助手规划一次国际旅行。这项任务需要协调多个专业agent，例如：

• 机票预订agent
• 酒店预订agent
• 当地旅游推荐agent
• 货币兑换agent

如果没有 A2A，整合这些不同的agent将面临诸多挑战：

• 代理暴露：开发者通常会将agent封装成工具，以便将其暴露给其他agent，类似于多agent控制平台（模型上下文协议）中工具的暴露方式。然而，这种方法效率低下，因为agent的设计初衷是直接协商。将agent封装成工具会限制其功能。A2A 允许agent直接暴露，无需封装。
• 自定义集成：每次交互都需要自定义的点对点解决方案，从而造成巨大的工程开销。
• 创新速度缓慢：针对每个新集成进行定制开发会减缓创新速度。
• 可扩展性问题：随着agent和交互数量的增长，系统将变得难以扩展和维护。
• 互操作性：这种方法限制了互操作性，阻碍了复杂人工智能生态系统的自然形成。
• 安全漏洞：临时通信往往缺乏一致的安全措施。

A2A 协议通过建立人工智能agent之间可靠、安全的交互互操作性来应对这些挑战。

回到刚刚的例子，人工智能助手接收到提示后，意识到需要调用多个专业人员来完成请求。这些专业人员包括机票预订员、酒店预订员、货币兑换员和当地旅游agent

A2A的核心架构与概念

核心组成部分

• 用户：最终用户，可以是人工操作员，也可以是自动化服务。用户发起请求或定义目标，这些都需要一个或多个人工智能agent的协助。
• A2A客户端（客户端agent） ：代表用户执行操作的应用程序、服务或其他人工智能agent。客户端使用A2A协议发起通信。
• A2A 服务器（远程agent） ：一种人工智能agent或agent系统，它公开一个实现了 A2A 协议的 HTTP 端点。它接收来自客户端的请求，处理任务，并返回结果或状态更新。从客户端的角度来看，远程agent作为一个不透明（黑盒）系统运行，这意味着它的内部运作、内存或工具均不对外公开

基本通信要素

下表描述了A2A中的基本通信要素：

元素	描述	主要目的
Agent Card	描述代理的身份、功能、端点、技能和身份验证要求的 JSON 元数据文档。	使客户能够发现代理商并了解如何安全有效地与他们互动。
Task	由代理发起的有状态工作单元，具有唯一 ID 和已定义的生命周期。	便于跟踪长期运行的操作，并实现多轮交互和协作。
Message	客户与代理人之间的一次通信，包含内容和角色（“用户”或“代理人”）。	传达指令、背景信息、问题、答案或状态更新，但这些不一定是正式的文档。
Part	消息和工件中使用的基本内容容器（例如，TextPart、FilePart、DataPart）。	为代理提供了在消息和工件中交换各种内容类型的灵活性。
Artifact	代理在执行任务期间生成的有形输出（例如，文档、图像或结构化数据）。	提供代理人工作的具体成果，确保输出结构化且可检索。

交互流程（握手与协商）

A2A 不仅仅是发一个包就完事，它是一个状态机流转的过程。

假设 Agent A (Client) 要找 Agent B (Server) 办事，流程如下：

1. 服务发现 (Discovery) ：

   • Agent A 问注册中心（Registry）：“谁懂 Go 语言的基础知识？”
   • 注册中心返回 Agent B 的地址（URL 或 Queue Topic）。

2. 握手与能力协商 (Handshake & Negotiation) ：

   • A 发送：REQUEST { "task": "review_code" }
   • B 思考：（调用 LLM）“我有空吗？我懂这个语言吗？”
   • B 回复：PROPOSE { "cost": "0.05$", "time": "10s" } (或者直接 AGREE)
   • 注：这一步是传统微服务没有的，Agent 有拒绝权和谈判权。

3. 执行与回调 (Execution) ：

   • A 确认条件，发送数据。
   • B 执行任务（调用本地工具，如 SonarQube 或 LLM Review）。
   • B 发送 INFORM 消息返回结果。

agent的连接模式

中心化编排

架构：有一个“总控 Agent”，就像是Spring AI Alibaba的SupervisorAgent，消息都要流转到这个agent身上，并由其决定是否将其作为最终结果提交给用户。即便你用 Nacos 发现了 Agent A 和 B，但如果必须经过一个 Manager 来分配任务和流转状态，这依然是中心化的

去中心化模式

• 架构：不仅是 IP 发现，更是意图发现。

• 通信：Agent A 发布一个意图（广播或在全局黑板/Almanac），具备该能力的 Agent 竞价或自主接单。

• 本质：没有预定义的 service-name，只有 capability。

• 类比：滴滴打车。乘客发单，不指定哪个司机，由系统或司机抢单

路由器与注册表

当 Agent A 想找人干活时，它会将任务描述（Embedding 向量化）与注册表里的 Capabilities 进行语义匹配（Vector Search） ，找到最合适的 Agent B

状态管理

微服务通常是无状态的，但 Agent 必须是有状态的。

• 它需要记住：对话历史（Short-term Memory）、之前的经验（Long-term Memory）、当前的谈判进度。
• 技术栈：通常使用 Vector Database (如 Milvus) 存长期记忆，Redis 存短期对话上下文。

总结

A2A协议内容其实还有很多，这篇文章只讲了个大概，主要是想让读者了解全局，还有更多复杂的内容，比如生命周期、异步操作等等，由于篇幅的原因就不在此展开。