By 黄金金枪鱼 
2025 年 4 月 Google 在 Cloud Next 上发布 A2A，2025 年 6 月 23 日在 Open Source Summit North America 由 Linux Foundation 接管 —— 一年之内，跨厂商 Agent 通信从"几家大厂的实验"变成了"百余家公司的开放标准"。本文拆解 A2A 的核心架构、与 Anthropic MCP 的边界，以及它对企业级 Agent 系统的实际影响。
核心事件
2025 年 4 月，Google 在 Cloud Next 大会与 50 余家合作伙伴联合发布 Agent2Agent (A2A) 协议 —— 一套用于不同供应商、不同框架构建的 AI Agent 之间互相发现、协商任务、交换产物的开放协议。两个月后的 6 月 23 日，Linux Foundation 在丹佛 Open Source Summit North America 宣布正式成立 Agent2Agent 项目，Google 将规范、SDK 与开发者工具整套移交基金会托管，AWS、Cisco、Microsoft、Salesforce、SAP、ServiceNow 六家作为创始成员加入，"目前支持该协议的公司已超过 100 家"。
这一动作把 A2A 从"Google 主推的协议"升格为"由中立的基金会治理、社区驱动演进的开放标准"。对开发者而言，最直接的含义是：未来跨厂商、跨云、跨框架的 Agent 协作不再需要为每个集成点写胶水代码，而是建立在同一套语义与传输之上。
A2A 的核心架构：7 个构件
A2A 的设计目标是让 Agent 之间像调用 HTTP 服务一样自然地协作。规范定义了 7 个核心构件：
- A2A Client（客户端 Agent）：发起请求、发现远端 Agent、委派任务
- A2A Server（远端 Agent）：暴露 HTTP 端点接收任务、处理并返回产物
- Agent Card：一个 JSON 元数据文件，类似 LLM 的 model card，包含名称、版本、端点 URL、支持的数据模态、认证要求 —— 可以理解成"Agent 的名片 / 简历"
- Task：一次协作的基本单元，拥有唯一 ID，生命周期走
submitted → working → input-required → completed / failed的状态机 - Message：消息，承载"实际内容"的容器，由若干 Part 组成
- Artifact：服务端最终产出的"实体成果"，如文档、图像、结构化数据，可以流式增量推送
- Part：最小的内容单位，三种类型 —— TextPart / FilePart / DataPart
与 MCP 的边界：互补而非竞争
A2A 经常和 Anthropic 在 2024 年推出的 Model Context Protocol (MCP) 一起被提及，但二者解决的问题域正交：
- MCP 解决的是"Agent ↔ 工具 / 数据源" —— Agent 如何访问数据库、调 Slack、读 GitHub
- A2A 解决的是"Agent ↔ Agent" —— 不同 Agent 之间如何协商任务、交换产物、协调长链路流程
IBM 在 Think 频道给出一个零售场景的对比：库存 Agent 用 MCP 查询 ERP 库存 → 发现库存不足 → 用 A2A 与外部供应商 Agent 通信下订单。两者并不冲突，实际生产系统往往需要同时用 MCP（拿数据/工具）和 A2A（跨 Agent 协作）。
传输与任务模型
A2A 协议在传输层选用了工业界最稳定的两条路径：
- 同步 / 流式响应：JSON-RPC 2.0 over HTTPS，对应短任务与单次问答
- 长任务与异步：Server-Sent Events (SSE) 做实时流式推送，Webhook Push Notification 做"客户端断开后仍能收到回调"
任务的生命周期是显式的、可被查询的：submitted（已受理）→ working（处理中）→ input-required（需要客户端补充输入）→ completed / failed。这套显式状态机让 Agent 协作具备了"可观测"的语义 —— 调用方可以随时查询 Task 的当前状态、已产出的 Artifact、消耗的资源。
关键点
- 协议中立化：从 Google 单家推动升级为 Linux Foundation 治理，避免单一厂商主导带来的 lock-in 风险
- 跨框架兼容：CrewAI、LangChain、AutoGen 这类框架原本只在自家生态内做编排，A2A 让它们可以无缝作为 Client 或 Server 加入跨厂商协作
- 显式任务状态机：
submitted → working → input-required → completed/failed让长任务可观测、可恢复、可审计 - 认证沿用 OpenAPI 规范：API Key、OAuth 2.0、OpenID Connect Discovery 都能直接复用，企业安全团队无需学新协议
- 100+ 公司支持：包括 AWS、Microsoft、SAP、Salesforce、ServiceNow、Cisco 等，生态密度已经接近"事实标准"门槛
行业影响
对企业落地而言，A2A 真正解决的是"Agent 编排碎片化"问题。当一家公司同时使用 Microsoft Copilot Studio、SAP Joule、自研 LangGraph Agent 时，过去只能通过 iPaaS 或自研胶水代码把三者串起来；A2A 让这三套 Agent 可以直接互相发现、互相委派任务，不再需要中间层。这也意味着供应商必须让自己的 Agent 同时"可被消费"和"可被调用"，否则会被边缘化。
对开发者社区的直接影响：Agent Card 的设计会成为新的"接口文档形态"，JSON 描述文件会像 OpenAPI/Swagger 一样流行；Agent 框架作者会开始默认提供 A2A Server 端点暴露能力；对求职者而言，"懂 A2A / MCP 这类协议栈"会从加分项变成硬性要求。
结语
A2A 一年内从 Google 实验项目走到 Linux Foundation 接管的开放标准，标志着 Agent 通信协议进入了"标准化时代"。对工程师而言，下一步值得跟踪的方向有三：一是 SDK 与参考实现的成熟度（目前主流语言实现仍在快速补齐）；二是与 MCP、ACP、ANP 等并立协议的边界收敛；三是大规模生产部署中"身份 / 授权 / 审计"等非功能性需求如何沉淀进规范本身。这些问题在 2026 年下半年会有更明确的答案。
参考资料
官方文档
- Google Developers Blog: Google Cloud donates A2A to Linux Foundation - 2025-06-23
- Linux Foundation Press Release: Agent2Agent Protocol Project Launch - 2025-06-23
- Google for Developers: A2A 项目首页 - 持续更新
开源项目
- GitHub google/A2A - 协议规范与参考实现
- GitHub a2aproject/A2A - 基金会托管下的项目仓库
行业报道
- IBM Think: What Is Agent2Agent (A2A) Protocol? - 2025
- DEV Community: Impact Analysis - Google Donating A2A Protocol to Linux Foundation - 2025
- Niklas Heidloff: Comparison of Agent Protocols MCP, ACP and A2A - 2025-06
社区讨论
- Reddit r/AI_Agents: Google Announces A2A - Agent to Agent protocol - 2025-04
- Reddit r/AgentsOfAI: A2A is one year old - 2026
对比基准
- Stride: A2A vs. MCP - When to Use Which? - 2025
- Medium / Sandi Besen: An Unbiased Comparison of MCP, ACP and A2A Protocols - 2025
本文由 AI 生成。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。