开发者 xbill 用同一套货币兑换基准，在 AWS、Azure、GCP 三大云之间搭建了全部六个方向的 A2A 代理互操作链路，并逐一部署实测。结论先行：A2A v1.0 协议在六个方向全部互通，协议本身既不是瓶颈，也不是故障源；真正的难点集中在身份认证、依赖打包和超时策略上。
六条链路覆盖微软 Foundry、AWS Bedrock AgentCore、Google ADK 三种框架的两两组合。每次运行都采用三种模式：MCP 直连、纯 A2A 委托、以及两者并发校验。实测数据显示，A2A 单跳延迟从 1.69 秒到 25.1 秒不等，差距达 15 倍，但差异完全由远端模型和托管运行时决定，与协议无关。部署在 Cloud Run 容器上的 gemini-2.5-flash 响应最快，而两个托管代理运行时（Foundry 托管和 AgentCore Runtime）的单次调用成本高出一个数量级。
校验模式的实际开销只相当于一次远程调用，因为 MCP 与 A2A 并发执行。在正常路径上，所有跨云校验结果完全一致，准确率差异为零；校验的真正价值在于独立故障检测——当工具被篡改、数据过期或出错时，第二个云上的独立实现会明确报警。六次构建中反复出现的故障集中在 A2A 协议版本不匹配（v0.3 与 v1.0 互不兼容，且无回退协商）、依赖包版本互斥、以及默认超时设置过短（本地 10 秒足够，跨云必须放宽到 60-120 秒）。
身份认证是跨云 A2A 的最大工程。调用 Foundry 需要正确的数据面角色和 token audience；调用 AgentCore 则需处理 SigV4 签名问题，Azure 侧用自定义 JWT 授权器解决，GCP 侧采用无密钥联合身份认证，通过 STS 换取临时凭证。作者特别提醒：Google 的 audience 条件键实际对应的是 azp 声明而非 aud，必须用 oaud 固定；仅校验 audience 不等于授权，还需绑定 subject。此外，镜像打包与本地源码树不一致的问题在三次构建中出现，所有通过本地测试却在部署后暴露的缺陷都属于打包或边界问题。
作者强调，这组数据并非全面基准：六条链路中仅两条跑完完整 38 用例矩阵，两条为单次冒烟测试，两条为五次运行的中位数；token 消耗和云成本均未测量。所有相关仓库、部署脚本和原始结果已公开，欢迎有跨云 A2A 经验的开发者交流比对。
GitHub
GitHub
#GitHub #开源 #A2A #AI代理 #AWS #Azure #GCP #互操作 #MCP
@GitHubTrendingHub