我想要一段非常具体的覆盖：

Microsoft Foundry (master)
    ├── MCP ──> live exchange-rate baseline
    └── A2A ──> Amazon Bedrock AgentCore (remote specialist)

Enter fullscreen mode Exit fullscreen mode

2026 年 7 月 30 日，这个方向实现了端到端打通。

这之所以重要，是因为我此前已经测试过反向拓扑——AgentCore 作为协调器，Foundry 作为远程。仅凭单一方向的跨云结论是不充分的。本次运行证明了 Foundry 可以拥有请求，执行其本地的 MCP 基线，调用一个 AgentCore A2A 代理，并应用确定性验证。

代码与脱敏证据位于 xbill9/foundry-bedrock-a2a-currency。

实际通过的内容

输入为 100 USD → EUR。我通过 Foundry 托管的协调器在 Responses 端点上调用了全部三种基准模式：

模式 路径 观测结果 适配器耗时
mcp_only Foundry → local MCP 87.13800 EUR 359 ms
a2a_only Foundry → A2A → AgentCore 87.138 EUR 25,105 ms
verified both paths concurrently exact agreement 28,163 ms

verified 模式返回的结果：

{
  "relative_difference": "0",
  "agreed": true,
  "failures": {}
}

Enter fullscreen mode Exit fullscreen mode

这只是一个烟雾用例，而不是延迟分布，也不是完整的基准矩阵。有效的结论更窄：Foundry 作为主控的云边界是可行的，包括认证、发现、调用和确定性比对。

该仓库还通过了 66 个确定性测试；一个可选的集成测试因缺少外部依赖而被跳过。

模型并不做数学运算

货币换算使互操作性易于证伪。每条报价都包含金额、汇率、换算后金额、观测时间、来源和适配器延迟。金额和汇率均使用 Python Decimal。

协调器——而非 LLM——负责检查一致性：

difference = abs(primary.converted_amount - verifier.converted_amount)
relative_difference = difference / abs(primary.converted_amount)
agreed = relative_difference <= Decimal("0.005")

Enter fullscreen mode Exit fullscreen mode

模型处理意图并选择一次工具调用。框架无关的代码负责算术、并发、超时策略和失败报告。

翻转后依然稳定的边界

稳定的应用依赖两个接口：

  • 一个基于 MCP 的 ExchangeRateTool；
  • 一个基于 A2A 的 RemoteCurrencyAgent。

Microsoft Agent Framework 和 Foundry 托管位于这些接口之外。Strands 和 AgentCore 位于另一侧。翻转云平台并不需要重写领域服务。

这比仅仅把两个 SDK 塞进一个进程更有价值。每个云都可以独立部署，而基准测试仍可比较 MCP-only、A2A-only 和 verified 执行。

认证才是真正的跨云难题

AgentCore 默认的运行时授权是 IAM/SigV4。这对 AWS 调用者是合适的，但 Foundry 托管的容器不会自动拥有 AWS 凭证。

本次测试我为 AgentCore 配置了自定义 JWT 授权器，并使用 Cognito 的机器对机器客户端：

Foundry container
    ├── client_credentials ──> Cognito token endpoint
    └── Bearer JWT ──────────> AgentCore A2A runtime

Enter fullscreen mode Exit fullscreen mode

协调器的 A2A 适配器现已支持 OAuth 客户端凭证，可在令牌即将过期前缓存令牌，并保留静态 bearer 支持以兼容其他对等配置。AgentCore 授权器验证发行者、客户端以及所需的 currencybench/invoke 作用域。

没有任何令牌参与领域层。

绿灯运行前曾出现的问题

成功的示意图掩盖了大部分工作。这些是观测到的失败，而非假设的风险。

1. AgentCore 的 A2A 服务器与客户端期望不同的 SDK 世代

协调器客户端使用 A2A 1.x。AgentCore 的 A2A 扩展目前要求部署的服务器包使用 0.3 系列。在同一包中同时安装两者会产生不可满足的依赖关系。

解决方案是架构性的：将 AgentCore 应用包固定在其兼容的 A2A SDK 上，同时保持 Foundry 端客户端独立。网络协议可互操作，尽管 Python 包未共享版本。

2. IAM 授权未能跨越云边界

直接使用 AWS CLI 调用可行，但 Foundry 容器无法对 AWS 请求签名。将运行时切换为自定义 JWT 授权并添加 OAuth 适配器，使远程调用无需嵌入 AWS 凭证。

3. 默认的十秒超时是虚假的信心

首次托管的 a2a_only 调用干净地失败：

{
  "failures": {
    "a2a": "timeout: adapter timed out"
  },
  "elapsed_ms": 10010
}

Enter fullscreen mode Exit fullscreen mode

一次直接远程调用已耗时约 25 秒。适配器工作正常；基准策略对冷跨云路径过于激进。托管超时现已设为 60 秒。后续的 A2A-only 调用在 25.1 秒内完成。

4. Foundry 的源构建找不到镜像

托管代理的远程构建反复以 ImageError: Container image not found 结束。我切换到 Azure Container Registry 中预构建且固定摘要的镜像。

下一个失败更具体：注册表身份验证。可见三个身份——Foundry 账户、项目以及每个代理的运行时身份。镜像拉取使用 项目托管身份。授予另外两个 AcrPull 权限无效。

在执行以下操作后，部署才变为活动状态：

  • 启用 ACR 身份验证即 ARM；
  • 授予项目身份仓库读取/拉取权限；
  • 重新部署同一固定摘要的镜像。

5. Azure 资源状态和 RBAC 均有记忆

一个软删除的 Foundry 账户在被清除前阻止了重新创建。项目角色分配也需要时间传播。这些是部署层事实，与 A2A 是否在运行时工作无关。

烟雾测试结果

在 verified 模式下，Foundry 启动了两个适配器。其 MCP 路径返回汇率 0.87138；AgentCore 专家返回汇率 0.87138。确定性代码计算相对差异为零，并将报价标记为一致。

MCP 结果还附带了陈旧观测警告。协调器保留了该警告，而非让模型将其抹平。

托管响应端到端耗时约 45 秒，而测量的适配器工作耗时 28.2 秒。两者差值包含模型和托管响应开销。仅凭一次观测，将任一数字称为基准都是不负责任的。

这证明了什么——以及没有证明什么

已观测到：

  • Foundry 托管了主协调器。
  • Foundry 的 MCP-only 路径已完成。
  • Foundry 获取了 OAuth 令牌并通过 A2A 调用了 AgentCore。
  • AgentCore 返回了结构化的货币报价。
  • verified 模式运行了两条路径并报告完全一致。
  • 在超时修正后，三种模式的烟雾测试在无适配器故障的情况下完成。

尚未建立：

  • 冷热延迟分布；
  • 节流或令牌过期时的行为；
  • 完整的多币种矩阵；
  • 生产级密钥轮换与可用性控制；
  • 任一框架或云的优越性。

这种区分正是该项目的意义所在。结果是覆盖，而非胜利宣言：Microsoft Foundry 可作为主云，Amazon Bedrock AgentCore 可作为其已认证的远程 A2A 专家。