Google A2A 协议：采纳情况与技术挑战分析
A2A（Agent-to-Agent）协议是 Google 开发的框架，旨在让独立开发的 AI 代理能够相互发现并通信。虽然它提出了代理的“微服务架构”，但当前开发者的情绪表明，与新兴标准如模型上下文协议（MCP）相比，它面临着巨大的采纳障碍。
A2A 的核心价值主张
A2A 旨在解决自主代理之间的互操作性问题。通过提供一种标准化的代理交互方式，团队可以独立开发专用代理，然后通过将任务委派给最相关的代理来协同处理复杂查询。
关键实现路径包括：
- Google 生态系统集成：该协议对深度使用 Google 技术栈的用户最为可行。例如，
gemini-cli可以连接远程 A2A 代理，自定义 Google ADK “agents” 也可以通过 A2A 以最小配置暴露。 - 组织层级：一些开发者使用 A2A 构建层级化的代理，模拟组织结构，其中主代理与子代理协同工作。
- 独立开发：只要遵循 A2A 标准，就可以实现解耦架构，代理可以在不破坏整个系统的前提下更新或替换。
主要技术与概念批评
尽管目标明确，许多技术从业者认为 A2A 协议过度设计，或在代理身份的假设上根本存在缺陷。
身份悖论
一个重要的批评是 A2A 假设通过代理卡片拥有明确且持久的“代理身份”。批评者认为代理本身并没有固有的身份感，且代理与另一个实体通信与代理与自身未来版本通信之间往往没有功能上的区别。
实现开销
开发者指出了协议技术栈的多个摩擦点：
- gRPC 复杂性：使用 gRPC 被描述为增加了一层间接性和模糊性，使实现过程痛苦。
- 资源低效：部分用户声称该协议在设计时未充分考虑提示缓存、延迟或 token 成本。
- 过度工程：多位开发者建议，基于 Markdown 规范的简单 API 比正式协议更适合代理间通信。
A2A 与 MCP 及其他替代方案的比较
开发者正从 A2A 向模型上下文协议（MCP）或自研方案迁移的趋势明显。
MCP 的崛起
许多开发者报告从 MCP 转向 A2A 再回到 MCP。模型上下文协议因被 Claude、OpenAI 等主要玩家用于原生集成而被视为更具动能。目前构建 MCP 服务器的激励被认为高于构建 A2A 服务器。
新兴竞争者
除 MCP 外，其他协议也在针对特定细分市场出现。例如，VS Code 团队正在使用 Agent Host Protocol (AHP) 重建代理基础设施，该协议侧重于为多个代理及其 harness 提供统一的主机通信协议。
开发者观点摘要
社区的洞察凸显了标准化代理网络的理论价值与实际实现之间的鸿沟：
“A2A 解决了独立开发的代理相互通信的问题。更大的问题是‘我如何信任你的代理能正常工作？’……否则代理目录和自动调度几乎毫无用处。”
“我认为 A2A 或类似的东西会在一切成熟后变得重要。只是对我们的使用场景来说显得过于复杂。”
归根结底，虽然 A2A 为去中心化代理生态系统提供了蓝图，但其当前的复杂性以及缺乏可靠的“Agent Eval”系统来验证代理可靠性，阻碍了其广泛采纳。