A2A

一种开放、厂商中立的协议,让基于不同框架构建的AI智能体能够相互发现并安全地协作完成任务。

ShellApache-2.0Agent
⭐ GitHubhttps://github.com/a2aproject/A2A
25,170
Star 数
+0
Star 增速
2026年8月1日
最后更新
1
点击数

1. 项目概述

A2A(Agent2Agent)是一种开放、厂商中立的协议,让由不同团队和公司基于不同框架构建的AI智能体能够相互发现并直接通信——解决了使用LangGraph、CrewAI、Semantic Kernel或任何其他技术栈构建的智能体之间没有通用通信方式的问题。

2. 背景与定位

随着AI智能体的激增,每个框架和厂商都倾向于构建自己封闭的智能体交互方式,形成了孤岛:在一个平台上构建的智能体通常无法将工作委派给在另一个平台上构建的智能体,也无法接收其返回的结果。A2A的创建就是为了打破这些孤岛,为智能体提供一种共享的、开放的协作协议——让它们能够以“智能体”的身份(拥有自身状态、记忆和推理能力的自主对等体)交换信息并协调任务,而不是被降级为通过固定API调用的简单工具。

该项目在其文档中阐述的核心使命是:实现复杂的多智能体协作,并推动智能体互操作方式的开放标准。智能体可以在无需共享内部内存、专有逻辑或特定工具实现的情况下协同工作——每个智能体仅通过标准化的“Agent Card”暴露其选择公开的内容,其余内部机制保持不透明。

A2A刻意与模型上下文协议(MCP)互补而非竞争。MCP标准化了单个智能体如何连接到工具、数据源和API。A2A则标准化了独立智能体如何跨组织和框架边界相互发现并通信。同时使用两者的系统,通过MCP为单个智能体提供工具,通过A2A让该智能体与其他智能体协作。

该协议作为Linux基金会项目进行治理,技术指导委员会成员来自AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP和ServiceNow,体现了其成为真正跨行业标准而非单一厂商产品的意图。

3. 功能类别

📜 协议规范

A2A消息格式、传输方式和行为的正式定义,维护在仓库的/specification目录下。

  • 基于HTTP(S)的JSON-RPC 2.0作为线上传输格式
  • 用于能力发现的Agent Card模式
  • 任务生命周期和状态转换规则
  • 流式传输和推送通知消息格式
  • 分层的扩展晋升流程,用于随时间添加新能力

目的:为实施者提供单一、有版本管理的权威来源,确保独立的A2A实现保持互操作。

🧰 语言SDK

官方客户端和服务端库,让开发者无需手动实现线上协议。

  • Python SDK(a2a-sdk
  • JavaScript/TypeScript SDK(@a2a-js/sdk
  • Go SDK(a2a-go
  • Java SDK
  • .NET / C# SDK
  • Rust SDK

目的:让团队能够使用其智能体技术栈已有的语言采用A2A,无需手动处理协议处理逻辑。

📚 文档与指南

发布在项目文档站点的概念性和参考材料,涵盖核心概念、任务生命周期、智能体发现、企业特性、流式传输和多租户。

  • 各SDK的入门指南
  • 核心概念(Agent Card、Task、Message、Artifact)
  • 企业就绪指南(认证、可观测性)
  • 协议扩展机制

目的:帮助协议实施者和应用开发者理解并正确应用A2A概念。

🧪 示例与参考实现

在配套的a2a-samples仓库中维护的示例智能体及客户端/服务端配对,展示了跨框架的真实互操作场景。

目的:为采用者提供可运行、可参考的代码,而不是仅从规范文档开始。

4. 核心亮点

  • 标准化的智能体间消息传递 — 通信基于HTTP(S)上的JSON-RPC 2.0运行,这是一种广泛支持、易于理解的传输方式,而非专有协议。
  • 用于发现的Agent Card — 每个智能体发布一张机器可读的卡片,描述其能力,使其他智能体(或编排器)无需带外协调即可找到并正确调用它。
  • 多种交互模式 — 支持简单的同步请求/响应、用于流式传输长时运行响应的服务器发送事件(SSE),以及用于超出单次连接生命周期的任务的异步推送通知。
  • 丰富的内容交换 — 消息可以携带纯文本、文件和结构化JSON负载,而不仅仅是聊天式字符串。
  • 设计上的不透明性 — 智能体在协作任务时不会暴露内部内存、工具或专有逻辑,这在涉及不同组织的智能体时尤为重要。
  • 多语言、多厂商治理 — 官方SDK覆盖六种语言,协议本身由Linux基金会下的跨公司技术指导委员会指导,降低了单一厂商锁定的风险。

5. 按角色划分的使用场景

  • 普通开发者:在你选择的框架中构建智能体,并通过Agent Card将其暴露,使其能够被其他智能体或编排层发现和调用,无需为每个对端编写自定义集成代码。
  • 平台/集成工程师:将A2A用作内部智能体与第三方或合作伙伴智能体之间的互操作层,在保持双方内部实现私有的同时,实现子任务的委派。
  • 评估多智能体架构的项目经理/技术负责人:利用A2A的任务生命周期和流式模型,规划跨团队或跨厂商的长时运行、多步骤智能体工作流如何协调和监控。

6. 快速开始

找到所需内容 — 从协议文档站点和仓库中的规范目录开始,了解核心概念(Agent Card、Task、Message),然后选择SDK:

https://a2a-protocol.org/latest/

安装/集成 — 选择与你技术栈匹配的SDK:

pip install a2a-sdk          # Python
npm install @a2a-js/sdk      # JavaScript / TypeScript
go get github.com/a2aproject/a2a-go   # Go

然后在配套的示例仓库中探索可运行的示例:

https://github.com/a2aproject/a2a-samples

贡献 — 提交问题、参与讨论或针对规范或SDK发起拉取请求,遵循项目的CONTRIBUTING.md

https://github.com/a2aproject/A2A/blob/main/CONTRIBUTING.md

7. 项目结构

A2A/
├── specification/        # 正式的A2A协议规范(权威来源)
├── docs/                 # 文档站点内容和指南
├── scripts/              # 实用和维护脚本
├── CONTRIBUTING.md        # 贡献指南
├── LICENSE                # Apache-2.0许可证
└── README.md

关键目录:specification/定义了所有SDK和实现必须遵循的带版本管理的协议契约;docs/为a2a-protocol.org上的公开文档站点提供内容。语言SDK和示例智能体维护在同一个a2aproject GitHub组织下的独立配套仓库中(例如a2a-pythona2a-jsa2a-samples)。

8. 相关生态

  • 模型上下文协议(MCP) — 用于将单个智能体连接到其工具和数据源的互补标准;A2A和MCP通常在同一系统中配合使用。
  • 智能体框架 — LangGraph、CrewAI、Semantic Kernel及类似框架是A2A旨在实现互操作的系统类型。
  • Linux基金会 — 托管并治理该项目,设有跨公司技术指导委员会。
  • DeepLearning.AI — 已发布涵盖A2A协议的教育课程。
  • a2a-samples — 包含支持语言的可运行示例智能体和客户端的配套仓库。

9. 许可证

✅ 在Apache License 2.0下免费使用、修改和分发,包括商业产品。
✅ 与所有Apache-2.0许可项目一样,包含专利授权。
✅ 通过GitHub Issues、Discussions和拉取请求接受贡献。
❌ 不提供任何担保;软件按“原样”分发。
ℹ️ 根据Apache-2.0要求,重新分发或修改的版本必须保留原始版权、许可证及任何NOTICE文件中的署名。

10. 常见问题

问:A2A与MCP有何不同?
答:MCP标准化了单个智能体如何连接到其自身的工具和数据源。A2A标准化了独立智能体如何相互发现和通信。许多系统同时使用两者。

问:使用A2A是否要求所有智能体都用同一框架构建?
答:不需要——这正是A2A要解决的核心问题。基于不同框架(LangGraph、CrewAI、Semantic Kernel、自定义技术栈等)构建的智能体,只要各自暴露符合A2A的Agent Card和端点,即可实现互操作。

问:A2A使用什么传输方式?
答:基于HTTP(S)的JSON-RPC 2.0,支持用于流式传输的服务器发送事件(SSE)和用于长时运行任务的异步推送通知。

问:哪些语言有官方SDK?
答:Python、JavaScript/TypeScript、Go、Java、.NET/C#和Rust。

问:在将A2A集成到自己的智能体之前,在哪里可以看到可运行的示例?
答:a2a-samples仓库(https://github.com/a2aproject/a2a-samples)包含可运行的参考智能体和客户端。

11. 快速链接

12. 总结

A2A为AI智能体提供了一种通用、开放的语言,使它们能够跨框架、厂商和组织相互发现并协作,填补了框架特定工具无法自行解决的空白。它最适合构建必须与不受其控制的智能体互操作的多智能体系统的团队——包括内部平台团队、集成工程师,以及任何设计跨多个厂商或技术栈的智能体架构的人。