我想要一項特定的覆蓋範圍：

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。我透過其 Responses 端點，以三種基準模式呼叫 Foundry 託管的協調器：

模式 路徑 觀察結果 配接器時間
mcp_only Foundry → local MCP 87.13800 EUR 359 ms
a2a_only Foundry → A2A → AgentCore 87.138 EUR 25,105 ms
verified 兩條路徑同時執行 完全一致 28,163 ms

驗證結果回報：

{
  "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 與驗證執行。

驗證是真正的跨雲問題

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 在執行階段是否運作無關。

煙霧測試結果

在驗證模式下，Foundry 啟動兩個配接器。其 MCP 端點回傳匯率 0.87138；AgentCore 專家回傳匯率 0.87138。確定性程式碼計算出相對差異為零，並標記報價為一致。

MCP 結果也帶有過時觀察警告。協調器保留它，而非讓模型將其平滑化。

託管回應端對端約需 45 秒，而測量的配接器工作耗時 28.2 秒。該差距包含模型與託管回應的額外負荷。僅有一次觀察，稱其中任一數字為基準都是不負責任的。

這證明了什麼——以及未證明什麼

已觀察到：

  • Foundry 託管主控協調器。
  • Foundry 的 MCP-only 路徑已完成。
  • Foundry 取得 OAuth 權杖，並透過 A2A 呼叫 AgentCore。
  • AgentCore 回傳結構化貨幣報價。
  • 驗證模式執行兩條路徑，並回報完全一致。
  • 在逾時修正後，三種模式的煙霧測試在無配接器失敗的情況下完成。

尚未確立：

  • 暖機與冷啟動延遲分佈；
  • 節流或權杖過期時的行為；
  • 完整的多貨幣矩陣；
  • 生產環境的密鑰輪替與可用性控制；
  • 任一框架或雲端的優越性。

這種區別正是此專案的意義所在。結果是覆蓋範圍，而非勝利宣言：Microsoft Foundry 可作為主要雲端運作，而 Amazon Bedrock AgentCore 可作為其已驗證的遠端 A2A 專家。