A2A（Agent2Agent）

1. 调研缘由

A2A 被纳入本次简调，主要因为它已经从 Google Cloud 发起的 Agent 协议项目，演变成 Linux Foundation 托管的开放协议项目。Google 在 2025-04 发布 A2A 时称其获得 50+ 技术合作方和服务商支持。[S4] 2025-06，Linux Foundation 宣布接收 A2A 项目，并称其已有 100+ 公司支持。[S5] 到 2026-04，Linux Foundation 公告称 A2A 支持组织超过 150 家，并已进入 Google、Microsoft、AWS 等主要云平台集成与企业生产部署阶段。[S7]

这篇简调重点回答三个问题：第一，A2A 在 Agent 协议栈里补的是哪一层；第二，转入 Linux Foundation 后，它的治理和采用是否更接近中立标准；第三，v1.0 解决了哪些企业部署问题，哪些风险仍留在协议之外。

2. 简介与产品工作流

A2A，全称 Agent2Agent Protocol，是一个开放协议，用来让不同框架、不同厂商、不同服务器上的 AI agents 互相发现、通信和协作。这里的 agent 可以理解为“能接收目标、调用工具、执行任务并返回结果的软件代理”。A2A 不是模型，也不是 agent 开发框架；它更像 agent 之间的通信层。[S1][S2]

官方反复强调 A2A 面向“opaque agentic applications”。这里的 opaque 不是黑箱贬义，而是指一个 agent 可以和另一个 agent 协作，但不需要暴露自己的内部记忆、私有工具、提示词或业务逻辑。[S1][S3]

典型工作流可以拆成四步：

1. 一个 client agent 先通过 Agent Card 发现 remote agent 的能力、入口和连接信息；
2. client agent 判断对方是否适合执行某个任务；
3. client agent 通过 A2A 发起任务请求，remote agent 执行后返回消息、状态或 artifact；
4. 对于长任务，双方可以通过流式更新、异步通知或状态查询保持同步。[S1][S3]

A2A 的定位容易和 MCP 混淆。官方文档的边界比较清楚：MCP 主要解决 agent 到工具、API、数据源的连接；A2A 解决 agent 到 agent 的协作。简单说，MCP 让一个 agent “会用工具”，A2A 让多个 agent “会互相找人干活”。[S2][S12]

3. 团队与资本背景

A2A 最初由 Google Cloud 发布。Google 在发布文中称，A2A 设计来自其部署大规模 multi-agent systems 的内部经验，并与 Atlassian、Box、Cohere、LangChain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、UKG、Workday 以及多家咨询服务商一起推进。[S4]

2025-06，Linux Foundation 宣布 launch Agent2Agent Protocol Project，并称 A2A 是 Google 创建的开放协议，目标是支持跨系统、跨平台的 agentic AI interoperability 和 trusted agent communication。[S5]

A2A 当前由 Technical Steering Committee 管理。GitHub 的 GOVERNANCE.md 显示，TSC 初始有 8 个席位，分别来自 Google、Microsoft、Cisco、Amazon Web Services、Salesforce、ServiceNow、SAP 和 IBM Research；项目范围包括 A2A 协议本身、SDK、文档、测试、集成和其他推动部署与采用的产物。[S9]

作为开放协议项目，A2A 不适用传统公司融资轮次口径。本次未找到需要纳入的股权融资资料；与项目资源更相关的是 Linux Foundation 治理结构、大厂参与和云平台集成情况。

4. 技术基础与生态位

A2A 位于 AI 生态的 protocol-standard 层，同时贴近 infrastructure 和 dev-tools。它不提供基础模型，也不替开发者决定 agent 内部怎么推理；它定义的是 agent 之间如何发现能力、表达任务、传递消息、同步状态和返回结果。[S1][S3]

从技术实现看，A2A README 将核心特性概括为：JSON-RPC 2.0 over HTTP(S)、通过 Agent Cards 做 agent discovery、支持同步请求/响应、SSE 流式传输、异步 push notifications，并处理文本、文件和结构化 JSON 数据交换。[S1]

A2A v1.0 是一个重要节点。官方 v1.0 公告称，该版本是第一个 stable、production-ready 版本，重点加入 multiple protocol bindings、version negotiation 和 common semantic model，让 agents 能跨系统保持更可预测的互操作行为。[S6]

v1.0 的技术路线更靠近现有 Web 基础设施。官方说明 A2A 建在 HTTP、SSE、JSON-RPC 等既有标准上；GitHub 规范也写明，A2A 的目标包括发现彼此能力、协商交互模态、管理协作任务，以及在不访问对方内部状态、记忆或工具的情况下安全交换信息。[S3][S4]

A2A 和 MCP 的关系是互补而非替代。MCP 官方文档把 MCP 定义为包含 JSON-RPC 基础协议、生命周期管理、authorization、resources、prompts、tools 等组件的协议；A2A 官方则把自己定义为 agent-to-agent 层，用于独立 agent 之间的发现、委托和结果共享。[S2][S12]

5. 市场与外部信号

A2A 不是 SaaS 产品，未找到公开定价信息；它以开源协议、规范文档、SDK 和示例代码形式分发。截至 2026-07-14，GitHub 页面显示 a2aproject/A2A 仓库约 24.8k stars、2.5k forks，最新 release 为 v1.0.1，发布时间为 2026-05-28。[S1]

生态支持是 A2A 当前最明显的外部信号。Linux Foundation 在 2026-04 公告称，A2A 支持组织超过 150 家，并已在 Google、Microsoft 和 AWS 平台深度集成，涉及供应链、金融服务、保险和 IT 运维等行业的生产部署。[S7]

官方 partners 页面列出了 AWS、Microsoft、Cisco、Salesforce、SAP、ServiceNow、IBM Research、LangChain、LlamaIndex、Glean、UiPath、Workday、Zoom 等组织，说明 A2A 的参与方覆盖云平台、企业软件、agent 框架、咨询服务和开发工具多个层次。[S11]

微软的开发者博客在 2026-04 介绍 A2A v1 与 Microsoft Agent Framework for .NET 的结合，并把 v1.0 的稳定性、长期支持、多租户、Signed Agent Cards 和改进安全流列为企业级特性。[S15]

AWS 在 2025-11 宣布 Amazon Bedrock AgentCore Runtime 支持 A2A；AWS 文档显示，AgentCore 可部署和运行 A2A servers，并作为透明代理层保留 A2A 的 Agent Card discovery 和 JSON-RPC 通信，同时叠加 SigV4、OAuth 2.0、session isolation 和可扩展运行环境。[S16][S17]

A2A 社区路线图显示，项目已把 validation 放入后续重点，相关工具包括 A2A Inspector 和 A2A Protocol Technology Compatibility Kit（TCK）。这类工具用于验证 agent 是否符合协议，对企业采用和互操作测试比较关键。[S10]

6. 公开评价与主要分歧

正面评价（来源类型）：

• 官方/合作方：Google、Linux Foundation、Microsoft、AWS 都把 A2A 描述为解决 agent 孤岛和跨平台协作的基础协议。Google 强调 A2A 可以让不同供应商、不同框架的 agents 协作；Linux Foundation 强调 A2A 转入开放治理；Microsoft 强调 v1.0 的稳定性和企业级特性；AWS 则把 A2A 放进 Bedrock AgentCore Runtime，用于不同框架 agents 的协作与部署。[S4][S5][S15][S16]
• 独立研究：一篇对 MCP、ACP、A2A、ANP 的协议综述将 A2A 概括为通过 capability-based Agent Cards 实现 peer-to-peer task outsourcing，适合企业级协作任务执行；该文也把 A2A 放在 MCP 之后，作为从工具接入走向协作执行的一层。[S18]
• 独立研究：一篇关于 MCP 与 A2A 身份委托的论文认为，AI agents 越来越通过 MCP 调用工具、通过 A2A 委托给其他 agents，但两类协议在可验证 agent identity 和 delegation provenance 上仍有缺口。[S19]

主要批评/质疑（来源类型）：

• 独立研究：AIP 论文指出，MCP 与 A2A 在 agent identity、attenuated authorization、chained policy 和 provenance-oriented completion records 方面仍需要额外机制；该文提出的 AIP/IBCT 正是为了补这些身份与委托边界。[S19]
• 独立研究：一篇 2026 年关于 agent interoperability governance gaps 的论文认为，MCP、A2A、ACP、ANP、ERC-8004 已能支持 identity、capability discovery、tool access 和 message exchange，但对于 membership、deliberation、voting、dissent preservation、human escalation、audit/replay 等治理需求支持不足，完整的 agent community governance 更像是当前互操作协议之上的缺失架构层。[S20]
• 独立研究：一篇协议综述也指出，MCP、ACP、A2A、ANP 仍处在 emerging protocol 阶段，并从 interaction modes、discovery mechanisms、communication patterns 和 security models 等维度比较它们，说明 agent 互操作还没有完全收敛到单一范式。[S18]

存在分歧之处：

主要分歧不在于 A2A 是否“有用”，而在于它能解决到哪一层。官方和合作方更强调互操作、开放治理和企业部署；独立研究更关注身份、授权、治理、审计和协议组合后的复杂度。按本次资料，A2A 已经有较强的一手生态信号，但独立公开评价仍以研究论文和技术分析为主，普通开发者大规模实测反馈相对有限。

7. 同类对比（与头部/高知名度同类项目）

**主要对标项目：**MCP、ACP、ANP。

关键维度对比（事实，标来源）:

维度	A2A	MCP	ACP	ANP
主要问题	agent 与 agent 之间的发现、委托、通信、状态同步和结果共享。[S1][S2]	AI 应用或 agent 与外部系统连接，包括 resources、prompts、tools 等 server features。[S12]	连接 AI agents、applications 和 humans，通过标准 RESTful API 支持 agent interoperability；ACP 现已并入 A2A。[S8][S13]	面向开放互联网的 agent 发现与访问，强调 JSON-LD agent discovery documents 和 .well-known/agent-descriptions 入口。[S14]
典型通信对象	client agent 与 remote agent。[S3]	MCP client 与 MCP server，所有消息遵循 JSON-RPC 2.0。[S12]	ACP agents、applications 和 humans。[S13]	拥有 agent description document 的 agent 与其他 agent 或搜索服务。[S14]
发现机制	Agent Cards，描述能力、连接信息和协议接口。[S1][S3]	server 通过 resources、prompts、tools 等 primitives 暴露上下文和能力。[S12]	ACP 文档写明支持 online/offline agent discovery，但 ACP 已并入 A2A。[S8][S13]	通过 JSON-LD discovery document 和 .well-known/agent-descriptions 发现公开 agent descriptions。[S14]
协议/传输	JSON-RPC 2.0 over HTTP(S)，支持 SSE 和 push notifications；v1.0 强调多协议绑定、版本协商和共同语义模型。[S1][S6]	基础协议为 JSON-RPC；包含 lifecycle、authorization、resources、prompts、tools 等组件。[S12]	RESTful API；官方文档称支持 synchronous/asynchronous communication、streaming interactions、stateful/stateless patterns。[S13]	JSON-LD 作为发现文档格式，使用 .well-known URI 作为主动发现入口。[S14]
治理与状态	Google 发起，现由 Linux Foundation 托管；TSC 包括 AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNow；v1.0 已发布。[S5][S6][S9]	MCP 是开放协议，官方文档以 versioned specification 形式维护，当前文档列出 2025-06-18 版本。[S12]	LF AI & Data 2025-08 公告称 ACP officially merging with A2A，ACP 团队将停止 active development 并把技术与经验贡献给 A2A。[S8]	ANP 官方规范仍以独立协议形式维护，重点放在 agent discovery 与 agent description。[S14]
与 A2A 的关系	本项目。	A2A 官方称 MCP 与 A2A 不是竞争关系：MCP 管 agent-to-tool，A2A 管 agent-to-agent。[S2]	ACP 已并入 A2A。[S8][S13]	独立综述把 ANP 归为更偏 open-network discovery 和 decentralized identifiers/JSON-LD graphs 的方向。[S18]

公开评价中的对比（标源，非个人裁决）：

独立协议综述把 MCP、ACP、A2A、ANP 放在不同部署语境下比较：MCP 偏 JSON-RPC client-server tool invocation，ACP 偏 REST-native messaging 和 multimodal responses，A2A 偏 capability-based Agent Cards 支持的 peer-to-peer task outsourcing，ANP 偏 DID 与 JSON-LD graphs 支持的开放网络发现与协作。[S18]

A2A 官方则只明确处理与 MCP 的边界，强调二者互补：MCP 用于给单个 agent 配工具和上下文，A2A 用于让 independent agents 发现彼此、委托任务和共享结果。[S2]

ACP 与 A2A 的关系已经从并列转向合并。LF AI & Data 公告称 ACP officially merging with A2A，ACP 团队将 winding down active development，并提供迁移路径。[S8]

8. 信息缺口与后续观察

1. 生产部署细节仍不充分。 Linux Foundation 已披露 A2A 存在多行业生产部署，但公开案例的架构、规模、失败模式、成本与运维指标仍有限。
2. 独立实测仍偏少。 当前较强信号来自官方、合作方和研究论文；普通开发者的长期使用反馈、踩坑记录和迁移成本总结还不够多。
3. 安全与治理仍需继续看。 Signed Agent Cards、OAuth 2.0、multi-tenancy、TCK 都是生产化方向，但跨组织 agent 协作里的权限委托、责任归属、日志审计和失败追踪仍需要更多公开最佳实践。
4. ACP 并入后的技术吸收效果待复查。 ACP 官方已转入 A2A，但哪些 ACP 设计会进入 A2A 主规范、哪些停留在适配器或生态层，需要后续看 roadmap、release notes 和 migration docs。
5. 与 MCP 的组合边界需要观察。 官方说二者互补，但实际工程里任务什么时候该被建模为“tool call”，什么时候该被建模为“remote agent delegation”，仍需要更多框架级范式和案例。

9. 归纳洞察 ★

A2A 反映了 Agent 生态正在从“单个 agent 能不能调用工具”，进入“多个 agent 如何跨框架、跨组织协作”的阶段。MCP 把工具、数据源和外部系统接入标准化；A2A 则把 agent 间的发现、委托和结果交换标准化。两者放在一起看，协议层正在成为 Agent 应用基础设施的一部分。

A2A 从 Google 项目转到 Linux Foundation，并吸收 ACP，是一个标准收敛信号。它不说明所有 agent 通信都会统一到 A2A，但说明大厂、企业软件和 agent 框架都在减少各自为政的通信接口，转向能被多方实现和验证的公共协议。

A2A v1.0 的重点不是展示新的模型能力，而是补生产环境需要的“硬边界”：身份、签名、租户、版本、协议绑定、迁移和验证工具。这说明 Agent 协议竞争的焦点已经不只是能不能跑 demo，而是能否在企业系统里被安全、可观测、可迁移地接入。

10. 来源与更新时间

• 信息截至(as_of): 2026-07-14
• 最后复查(last_checked): 2026-07-14
• 最后更新(last_updated): null