構建無伺服器A2A閘道器：實現智慧體發現、路由與訪問控制

隨著企業在不同團隊、供應商和基礎設施中部署AI智慧體，管理智慧體間的通訊成為日益增長的運營負擔。如果沒有集中化層，每個新智慧體的整合都會增加點對點連線、獨立的憑據和自定義路由邏輯。團隊花費工程週期來構建連線，而非開發智慧體能力。訪問控制變得碎片化，缺乏單一位置來強制執行哪些客戶端可以訪問哪些智慧體。其結果是新的智慧體工作流上市速度變慢，由於不一致的身份驗證策略導致安全風險增加，以及每個新智慧體加入網路時運營開銷呈二次方增長。

閘道器模式透過在智慧體前端放置一個單一入口點來解決這一問題，無論智慧體執行在Amazon ECS、AWS Lambda、Amazon Bedrock AgentCore執行時、非AWS雲還是混合環境。它集中處理路由並強制執行細粒度許可權，而不將團隊繫結到特定的執行時、框架或編排層。該模式建立在智慧體間通訊協議（A2A）的基礎上，該協議標準化了智慧體之間的通訊方式。如果沒有中央編排器，20個智慧體的部署需要多達190個點對點連線。

本文中，你將學習如何在AWS上構建一個無伺服器A2A閘道器，該閘道器使用基於路徑的路由（/agents/{agentId}）將多個智慧體託管在單個域名下。標準A2A客戶端無需修改即可工作。該解決方案包含三個層面：管理層面（集中化智慧體註冊，支援發現和語義搜尋）、控制層面（使用JWT作用域和Lambda授權器實施細粒度訪問控制）、執行層面（單域路由，支援OAuth後端認證和SSE流式傳輸）。

架構

Amazon API Gateway（REST API）作為單一入口點。架構使用REST API，因為它支援響應流式傳輸。流式傳輸對於基於SSE的即時智慧體響應是必需的。Lambda授權器檢查JWT作用域，並生成允許訪問特定智慧體路徑（/agents/agent-a/*）而拒絕其他路徑的IAM策略。

Lambda函式實現閘道器邏輯：授權器驗證JWT並基於作用域到智慧體的對映生成IAM策略；登錄檔列出呼叫方可以訪問的智慧體，並將URL重寫為指向閘道器；搜尋使用Amazon Bedrock中的Amazon Titan文本嵌入進行語義智慧體發現；代理透過Lambda Web介面卡將請求路由到後端智慧體，支援SSE流式傳輸；管理用於智慧體註冊和生命週期管理。

Amazon DynamoDB儲存三個表：智慧體登錄檔、許可權表和速率限制計數器表。Amazon Cognito使用OAuth 2.0客戶端憑證流處理身份驗證。令牌中的作用域決定呼叫方可以訪問哪些智慧體。AWS Secrets Manager儲存後端憑據。

閘道器設計

A2A原生端點遵循A2A協議規範，並路由到後端智慧體。閘道器支援規範中定義的兩種協議繫結：JSON-RPC和HTTP+JSON/REST。此外，閘道器端點提供代理發現、搜尋和生命週期管理功能。

三層模型

隨著智慧體部署的增長，團隊需要了解可用內容。管理層面提供集中化登錄檔，其中智慧體及其功能、後端URL和狀態被編目。控制層面基於JWT作用域強制執行細粒度許可權，未授權的請求在API Gateway級別被拒絕。執行層面處理請求到後端智慧體的實際路由，支援SSE流式傳輸和OAuth身份驗證。

部署與測試

閘道器完全使用Terraform部署。前提條件包括Terraform >= 1.5.0、Python 3.12、配置了有效憑據的AWS CLI和Docker。程式碼可在 aws-samples GitHub倉庫中找到。克隆倉庫、配置變數、構建Lambda包並部署。測試包括獲取憑證、獲得JWT、部署示例智慧體、註冊智慧體到閘道器、更新許可權以及傳送訊息。

該解決方案提供了一個可擴充套件、安全且易於管理的智慧體通訊基礎設施，適用於企業級AI應用。