大多数跨云A2A示例止步于看到HTTP 200就收工，但真正的互操作性远不止这一次冒烟测试。第三次同款跨云货币基准测试，这次换Google ADK当主控，调用亚马逊Bedrock上的Strands Agents干活，结果一下撞见六处协议“暗礁”，其中五个是本地单元测试无论如何都抓不到的。
整个调用的身子骨其实很直白：Cloud Run上的ADK进程拿着Gemini 2.5 Flash的算力做策略判断，通过A2A v1.0链路把任务甩给us‑east‑1的Bedrock AgentCore工人，工人跑完再借用MCP汇率工具交叉对账。前一轮方向刚好相反——Bedrock当主控、ADK当工人——这次反转本以为只是一次纯粹的部署切换，连比较逻辑都没动，结果版本、依赖、鉴权全炸出了新花样。
头一道坑在A2A协议版本没商量。工人那边用的是a2a‑sdk < 0.4的老接口（v0.3的message/send），主控这边却已经升到a2a‑sdk 1.x（v1.0的SendMessage），服务器卡片不带任何版本协商。v1.0的客户端根本调不动v0.3的服务端。解决办法是让Strands Agents只管理任务循环，直接用a2a‑sdk手搭v1.0的服务面，锁死依赖版本，防止悄悄升级捅出新篓子。
第二道坑藏在Python包的可选依赖里。Cloud Run容器本地一切绿灯，上线直接崩：ModuleNotFoundError，找不到sse_starlette。ADK的to_a2a()背后引用了a2a.server.routes，而这东西非得a2a‑sdk[http‑server]这个尾巴跟着不可。
google‑adk[a2a]本身不拽这个可选包，裸的a2a‑sdk也不会。吃了一次滚动重启的憋后，两边部署描述全都加上了a2a‑sdk[http‑server]，从此硬性声明该有的都得有。
第三道坑踩在跨云鉴权的链条上。协调节点手里一把AWS密钥都没有，全靠元数据服务器发的Google OIDC令牌，传入STS的AssumeRoleWithWebIdentity换成临时凭证，再SigV4签名去打Bedrock。
信任策略稍一没对齐，云端就别想连上。这类问题纯靠本地mock根本冒不出来，非得真正跨云跑一遍才现形。
这些缺陷的共同尴尬是：单机测试永远觉得“没问题”，因为本地能模拟的只是协议载荷，没法复现真实的版本差异、运行时依赖缺漏和云端鉴权链条。作者把这次测试切成三种模式，就是为了把“远程验证的代价”从“干活的代价”里单独剥离出来，用Decimal做算术比对而不是让模型拍脑袋说两个数字像不像。六处互操作缺陷就是这笔代价的清单，也恰好说明了为什么A2A的落地，不能只靠一个200状态码就宣布胜利。
热门跟贴