A2A协议的互操作性幻觉：协议兼容≠真正协同

一个被过度乐观解读的协议

随着多智能体（Multi-Agent）系统成为AI应用的新范式，A2A（Agent-to-Agent）协议被寄予厚望，被视为解决智能体互操作性问题的关键一步。它确实在协议层提供了一套通用机制：让智能体互相发现彼此，并交换 Messages、Tasks、Parts、Artifacts 以及状态更新。这消除了大量定制化的集成工作。

但一位 Reddit 开发者提出了一个尖锐且值得深思的观点：协议兼容（protocol compatibility）与真正的互操作（true interoperability）是两回事。A2A 解决的是「能不能通信」的问题，却远未触及「通信之后能否协同工作」的深层挑战。这篇文章将顺着这个思路，拆解智能体互操作性背后被忽视的三个层次。

智能体互操作性的三个层次

作者将生产级的互操作性拆解为三层，这是整个讨论中最有价值的框架。

第一层：协议层——智能体能否正确通信

最基础的问题是：智能体之间能否正确通信？这正是 A2A 已经解决的部分。通过统一的消息格式和任务模型，不同框架构建的智能体可以在传输层握手、交换数据。这一层是标准化收益最明显的地方，也是当前各大框架争相支持 A2A 的原因。

A2A 协议由 Google 于2025年发布，是一个基于 HTTP 的开放协议，采用 JSON-RPC 2.0 作为消息格式，并通过「Agent Card」机制实现智能体能力的自我声明与发现。每个智能体可以暴露一个标准化的 .well-known/agent.json 端点，描述自身支持的技能（Skills）、输入输出格式以及认证方式。Tasks 是协议的核心抽象单元，代表一次有状态的工作请求，可以包含多个 Message 轮次，并通过 Artifacts 携带结构化的中间或最终结果。这一设计借鉴了 HTTP REST 的成熟理念，使得不同编程语言、不同框架构建的智能体在传输层具备了共同语言。与 MCP（Model Context Protocol）相比，A2A 更聚焦于智能体与智能体之间的异步、长时任务协作，而 MCP 更侧重于模型与工具/数据源之间的同步调用关系，二者在多智能体架构中通常被视为互补而非竞争的标准。

第二层：语义层——理解是否一致

真正的麻烦从这里开始。两个智能体可以都通过 A2A 声明自己具备「发票对账」（invoice reconciliation）能力，但它们对这个技能的理解可能天差地别：

• 输入输出的 schema 是否一致？
• 置信度（confidence）如何表达？
• 错误和部分结果（partial results）如何处理？
• 会产生哪些副作用（side effects）？
• 什么情况下需要升级到人工介入（human escalation）？

协议告诉你「这个智能体能做发票对账」，但没告诉你「它做发票对账时的假设和你的假设是否相同」。语义层的错位是隐蔽的——一切在协议层都看起来正常，问题却在业务逻辑中悄然发生。

第三层：运维层——工程可靠性能否保障

第三层关乎工程可靠性：当调用跨越智能体边界时，能否保持授权（authorization）、重试（retries）、幂等性（idempotency）、链路追踪（tracing）、预算控制（budgets）、评估（evaluations）和审批（approvals）？

作者一针见血地指出：传输层的重试机制并不能让一个非幂等操作变得可以安全重试。如果 Agent B 执行的是「转账」这类有副作用的动作，A2A 层面的自动重试反而可能酿成事故。运维层的一致性，是协议标准无法单独保证的。

幂等性（idempotency）是分布式系统工程中的核心概念，指同一操作执行一次与执行多次产生的效果完全相同。在单体系统中，开发者通常通过数据库事务来保障操作的原子性；但当操作跨越智能体边界时，事务语义随之瓦解。传统的微服务架构已经深刻揭示了这一痛点——「最终一致性」（eventual consistency）和「幂等键」（idempotency key）等模式正是为此而生。在多智能体场景下，这个问题被进一步放大：调用链可能跨越多个自治智能体，每个节点都可能独立决定重试策略，而协议层面的重试与业务层面的副作用之间并无天然隔离。这意味着多智能体系统的运维可靠性，本质上继承了分布式系统的所有经典难题，需要在架构层面主动设计幂等操作、引入分布式追踪（如 OpenTelemetry）并建立跨智能体的熔断与降级机制，而非期待协议标准自动兜底。

各框架的 A2A「边界」并不在同一处

作者观察了当前主流实现——Google ADK、Microsoft Agent Framework、CrewAI、LangGraph/LangSmith 以及 Lyzr Agent Studio——发现它们虽然都支持 A2A，但协议边界所处的位置各不相同：

• 有的把远端智能体（remote agent）作为边界；
• 有的将其封装为一个委托工具（delegation tool）；
• 有的对应一个已部署的图（deployed graph）；
• 有的则是编排流程中的一个节点（orchestration node）。

这意味着，即便大家都「支持 A2A」，实际的抽象层级和集成模式仍存在显著差异。表面的标准化之下，隐藏着架构假设的分歧。这也解释了为什么「支持 A2A」这个标签本身，并不足以保证跨系统的顺畅协作。

真正的互操作测试：可替换性而非可调用性

本文最具启发性的结论是对「互操作性测试标准」的重新定义。作者认为，衡量互操作性的问题不应该是：

我的系统能不能调用一个 A2A 智能体？

而应该是：

我能否替换掉 Agent B，而不必重建它周围的一切？

这个「可替换性」（substitutability）标准直击要害。可调用性只是最低门槛，而可替换性才检验了智能体之间是否存在真正松耦合的契约。如果替换一个「发票对账智能体」需要重写调用方的错误处理、schema 适配、审批流程和监控逻辑，那么所谓的互操作性其实只是幻觉。

「可替换性」这一标准在软件工程中有着深厚渊源，最直接的理论来源是面向对象设计中的里氏替换原则（Liskov Substitution Principle，LSP）：子类型对象应当能够透明替换父类型对象，而不破坏调用方的行为预期。将这一原则移植到多智能体语境，意味着两个声称具备同一技能的智能体，应当能够在不修改调用方逻辑的前提下互换。这也与微服务架构中的「契约测试」（contract testing）实践高度吻合——Pact 等工具正是通过消费者驱动的契约来验证服务间的可替换性，而非仅仅检查接口格式。对多智能体系统而言，建立类似的智能体契约测试机制，要求服务提供方在发布新版本时必须通过消费方的语义兼容性验证，或许是将「可替换性」从理念落地为工程实践的有效路径。

A2A一致性测试该覆盖哪些维度

沿着作者的思路，一个超越 schema 和协议检查的智能体一致性（conformance）测试，或许应当覆盖以下维度：

• 语义契约验证：不仅校验输入输出 schema，还要验证对同一技能的语义假设是否一致，包括置信度表达、部分结果的定义。
• 副作用声明：智能体是否明确声明其操作的幂等性与副作用，让调用方决定是否可安全重试。
• 错误与降级行为：面对异常、超时、人工升级时的行为是否可预测、可协商。
• 运维横切关注点：授权、追踪、预算、审批能否跨边界透传，而非在边界处断裂。
• 可替换性回归：以「替换同类智能体」为目标的集成测试，验证周边系统无需改动即可切换后端实现。

结语：协议标准化只是多智能体协作的起点

A2A 无疑是智能体生态走向成熟的重要一步，它降低了通信的门槛，值得肯定。但我们需要清醒地认识到，协议标准化只解决了三层挑战中的第一层。语义对齐与运维一致性，这两个更难标准化、更依赖工程实践和行业约定的层次，才是决定多智能体系统能否真正投入生产的关键。

对于正在构建多智能体系统的团队而言，与其满足于「我们支持 A2A」，不如认真回答那个更难的问题：如果换掉其中一个智能体，我需要重建多少东西？答案越接近「几乎不需要」，你的系统才越接近真正的互操作。