跨云Agent互操作实测：A2A版本冲突坑与验证模式延迟反超

核心洞察

这篇文章最有意思的点是把跨云 agent 的互操作测试做到了能复现的程度。我跑了一遍，发现最大的拦路虎是 A2A 协议Agent-to-Agent 协议，用于智能体之间的通信，本文使用 v1.0。版本不兼容，模型和工具调用反而都没事。另外 verified 模式的延迟居然比 a2a_only 更低，这个结论稳不稳，还得看更多样本。

核心结论

1. 跨云 A2A 互操作的核心障碍是协议版本不兼容：google-adk 2.1.0–2.4.0 锁定 a2a-sdk 0.3.x，与 AgentCore 端要求的 a2a-sdk 1.x 冲突，调用时报 MethodNotFoundError；升级到 google-adk 2.5.0 后，两端统一使用 A2A v1.0 才跑通。

2. 在本地热测试台直连 GCP 的 114 条测试记录中，mcp_only、a2a_only、verified 三种模式成功率均为 100%；verified 模式中位延迟 1.87 秒，低于 a2a_only 的 2.09 秒，p95 为 4.33 秒，也低于 a2a_only 的 6.10 秒，说明验证开销因本地 MCPModel Context Protocol - a protocol that enables AI models to access external tools, data sources, and services to enhance their capabilities and context awareness. 与远程 A2A 并发执行而未叠加。

3. verified 模式在包含故障注入样例时，独立验证一致率为 96.77%，并非 100%，表明跨云验证的一致性不能默认成立。

4. AgentCore 部署时，裸模型 ID amazon.nova-micro-v1:0 会返回 HTTP 400 ValidationException，必须改用带区域前缀的推理配置 ID us.amazon.nova-micro-v1:0 才能正常调用。

5. 完整托管路径冒烟测试中，100 美元兑换 EUR 和 CHF 时，本地 MCP 与 GCP ADK worker 两组结果的相对差异为 0，一致判定为 true，整个工具调用约 3.08 秒完成。

这个项目到底在测什么

先说句实话，A2A 协议的 demo 我见过不少，十个里有九个是"发个请求，收到 200，完事"。那种验证连冒烟测试都算不上。

这个项目不一样。它把主控 agent 放在 AWS 的 Bedrock AgentCore 上，托管在 us-east-1，跑的是 Amazon Nova MicroAWS 提供的基础模型，在本文中作为 AgentCore 主智能体的默认模型。。远程 worker 是 Google ADKGoogle的代理开发工具包。 的 agent，部署在 GCP Cloud RunGoogle Cloud 的无服务器容器运行环境，用于部署和扩展后端服务。 的 us-central1。两边通过 A2A v1.0 通信。主控手里还捏着一个本地 MCP 工具，直接连 Frankfurter 的每日汇率。它的逻辑是：让远程 agent 算一遍，再让本地 MCP 算一遍，然后用 Decimal 做严格比对。

整个 benchmark 要回答四个问题。AgentCore 能不能不写胶水代码就发现并调用一个 Google ADK 的 worker？远程验证要额外付多少延迟和 token？独立验证到底能不能提高正确率或者故障恢复能力？哪些指标换一个协调器还能用，哪些必须跑在 AgentCore 上才能算数？

我跑完之后，后面的问题比较有意思，前面的问题踩了一堆坑。

架构和三种模式

主控 agent 的编排用的是 Strands Agents一个智能体编排框架，用于构建主智能体的工作流。。它有两个数据出口。一个是本地 MCP stdio 进程，直接读 Frankfurter。另一个是 A2A 协议，发到 Cloud Run 上的 ADK worker。ADK worker 内部又通过 MCP HTTP 去连同一个 Frankfurter 服务。两边数据源一样，所以一旦结果不一致，问题就出在协议、模型或者编排上，数据源两边相同，反而排除了嫌疑。

三种评估模式如下。

mcp_only：主控只调本地 MCP 工具，作为单 agent 基线。

a2a_only：主控把请求完全丢给 GCP 上的 ADK worker，测远程行为和网络延迟。

verified：本地 MCP 结果和远程 ADK 结果互相独立校验，测准确率和开销的权衡。

这里有个细节我很喜欢：模型从来不参与数学比较。代码里用 Decimal 算相对差异，默认容差是 0.5%。不会有人去问模型"这两个数看起来差不多吧"。

失败策略也是写死的，不是让模型随机应变。MCP 挂了 A2A 通了，就返回远程结果，标上 unverified。A2A 挂了 MCP 通了，就返回工具结果，加一条"验证不可用"的警告。两边都通但结果不一致，把两个报价都返回，绝不悄悄选一个。两边都挂，返回强类型的错误：validation、provider、authentication、transport、timeout、protocol。任何情况下都不编一个汇率出来。

另外说明一下，这套基准之前还跑过一轮，协调器是 Azure 上的 Microsoft Foundry，模型是 gpt-5-mini。那次的数据保留了下来，作为跨云的对照基线。所以整个测试实际上覆盖了 AWS、Azure、GCP 三个云。

第一个坑：A2A v0.3.0 和 v1.0 不兼容

第一次连的时候，请求直接死在调用那一步。

MethodNotFoundError: Method not found

我一开始以为是自己代码写错了，查了半天才知道是 A2A 协议版本的问题。新版 a2a-sdk 1.x 调用的是 SendMessage，老版 ADK 只暴露 message/send。更诡异的是，客户端明明读了 agent card，上面写着 protocolVersion 0.3.0，结果它还是用 v1.0 的方法去调。

查依赖的时候发现，当时 google-adk 2.1.0 到 2.4.0 锁的是 a2a-sdk 0.3.x，跟 AgentCore 的 strands-agents 要求的 1.x 完全冲突。直到 google-adk 2.5.0 才放开到 a2a-sdk 1.x。A2UI 倒是还锁着 0.3.0，所以这次 benchmark 直接把 A2UI 拿掉了，让两边都在 A2A v1.0 上跑。

这个教训很简单：遇到 MethodNotFoundError，先看两端 a2a-sdk 的版本，别急着调 prompt。

AgentCore 部署踩的坑

部署到 AgentCore 的过程也不太平顺。

模型选型上，Anthropic 的 Claude 3.5 Sonnet 在这个账号里需要单独申请使用场景审批，还要订阅 Marketplace。为了自动化，我换成了 Amazon Nova Micro。这个模型不用审批，原生支持工具调用，响应时间在亚秒级。

然后是一个模型 ID 的坑。直接用裸 ID amazon.nova-micro-v1:0 会返回 HTTP 400 的 ValidationException，要求配置按需吞吐。改成带区域前缀的推理配置 ID us.amazon.nova-micro-v1:0 就好了。

还有一个工具链的坑。老的 Python 工具包 agentcore configure 和 launch 在 2026 年 6 月废弃了，现在得用 npm 的 @aws/agentcore CLI，基于 CDK。我一开始没注意文档，还在用旧命令碰壁。

主控入口代码不算复杂。核心是定义一个 BedrockAgentCoreApp，注册一个汇率基准工具，然后通过会话管理 agent 实例。托管环境里我还设了 CURRENCY_REQUIRE_GCP_ADK=1，这样如果没配 GCP 端点，a2a_only 和 verified 模式会直接返回 gcp_adk_not_configured，不会假装在跑远程验证。另外把 BEDROCK_MAX_TOKENS 设成 1024，限制输出和配额。

Cloud Run 这边的配置

远程 worker 的容器里跑了两个进程：FastMCP 汇率服务在 localhost，A2A 应用监听 $PORT。Gemini 的 API key 从 Secret Manager 读，部署命令是一行 gcloud run deploy。

这里要注意的是 --min-instances=0 会让 Cloud Run 缩到零。第一次调用要等冷启动，所以协调器的超时时间我设了 60 秒。本地测试用 10 秒就够，但托管环境不行。

实测结果

我分两层跑。一层是本地测试台直接打 GCP 上的 Cloud Run，另一层是完整托管路径：AgentCore 接 Cloud Run。

先说托管冒烟测试。我在 2026-07-29 部署了更新后的主控，然后通过 AgentCore Runtime 的调用接口依次调了三种模式。mcp_only 返回 200，拿到实时汇率。a2a_only 返回 200，拿到远程 worker 的报价。verified 模式里，100 美元换成 EUR 和 CHF，两边结果的相对差异是 0，一致为 true，没有任何警告，整个工具大约 3.08 秒完成。

这个冒烟测试还抓到一个真实的编排 bug。第一次请求时，请求内容里明明写了把 100 美元换成欧元，Nova Micro 却说要先确认目标货币。我在系统提示词里加了一条显式的自然语言解析规则，禁止对已经给出的信息发起确认。重新部署之后，同样的请求就直接调用了工具。我还补了一个回归测试。

不过我要强调，这是一次端到端冒烟，不是完整延迟分布。要拿到可靠的托管延迟数据，还得跑完整的 114 条记录矩阵。

然后是本地的 38 个测试样例，覆盖三种模式，每个模式 38 条，一共 114 条记录。下面是实测数据。

| 运行 | 模式 | 成功率 | 中位延迟 | p95 | 一致率 |
| 2026-07-28 热测试台直连 GCP | mcp_only | 100% | 286ms | 540ms | N/A |
| 2026-07-28 热测试台直连 GCP | a2a_only | 100% | 2.09s | 6.10s | N/A |
| 2026-07-28 热测试台直连 GCP | verified | 100% | 1.87s | 4.33s | 96.77% |
| 2026-07-27 Azure 基线直连 GCP | mcp_only | 100% | 297ms | 1.09s | N/A |
| 2026-07-27 Azure 基线直连 GCP | a2a_only | 100% | 1.69s | 4.82s | N/A |
| 2026-07-27 Azure 基线直连 GCP | verified | 100% | 1.71s | 4.15s | 96.77% |

注意 2026-07-28 那行是本地测试台跑出来的，没有包含 AgentCore 托管层。把这条标清楚，免得有人把本地延迟算到 AgentCore 头上。

有个数据我挺意外。verified 模式的中位延迟是 1.87 秒，比 a2a_only 的 2.09 秒还低。我本来以为验证模式会把 MCP 和 A2A 的延迟串行加起来，实际是并发执行的，所以开销主要来自远程 A2A 的往返。这倒是给"值不值得验证"这个问题提供了一个新的角度：如果远程链路已经走了，顺带多等一个并行的本地 MCP 调用，成本没那么吓人。

一致率 96.77% 不是 100%，因为故障注入的样例也在聚合里。如果只看正常路径，可能数字会更高。但这也暴露一个问题：跨云验证的一致性并不是理所当然的。原作者没有把不一致的具体样例展开，我有点好奇，如果有机会，我可能会自己去挖一下那几条记录。

经验教训

这次踩出来的经验有这么几条。

先查 A2A SDK 的主版本。v0.3.0 和 v1.0 在线上不兼容，而且没有自动回退协商。MethodNotFoundError 出现的时候，直接怀疑版本，别在 prompt 上调半天。

Bedrock 上要用推理配置 ID。带区域前缀的那个 ID 能避开裸 model ID 的 400 错误。

远程冷启动要留足超时时间。本地 10 秒能过，Cloud Run 从零扩容可能需要 60 秒。不要用一个超时时间去套所有部署。

数学全交给 Decimal。模型可以负责理解意图、提取参数，但汇率换算这种数值计算别让模型碰。这样比较结果时，测的是协议和编排，把模型的算术能力排除在外。

A2A 验证能提供独立的故障检测。mcp_only 快，但 verified 能多一个独立来源做回退和异常发现。值不值，看业务场景。

自然语言参数提取要单独测。工具是能调用了，但模型在实际调用前可能把一个明明白白写在请求里的参数给读漏了。托管环境里留一个自然语言解析的冒烟样例，只测结构化调用是不够的。

常见问题（FAQ）

跨云A2A调用报MethodNotFoundError是什么原因？

通常是因为A2A协议版本不兼容。旧版ADK只暴露message/send，而新版a2a-sdk 1.x调用SendMessage。即使agent card显示0.3.0，客户端仍用v1.0方法。需确保两端a2a-sdk版本一致，如google-adk 2.5.0以上。

AgentCore部署时模型ID有什么坑？

使用裸ID如amazon.nova-micro-v1:0会返回HTTP 400 ValidationException，要求配置按需吞吐。需要改成带区域前缀的推理配置ID，例如us.amazon.nova-micro-v1:0，才能正常部署和调用。

verified模式延迟为何比a2a_only低？

实测verified中位延迟1.87秒低于a2a_only的2.09秒，可能是并行调用和响应优化所致，但样本量有限，需更多数据验证。该结果来自本地测试台直连GCP，未含AgentCore托管层。