AWS 给 AI Agent 加了一层“网关”：企业落地 A2A 的关键不只在模型

AWS Machine Learning Blog 在 2026 年 7 月 1 日发布了一篇技术实践文章，介绍如何在 AWS 上构建一个 Serverless A2A gateway，用于 AI Agent 的发现、路由与访问控制。它并不是一个新的大模型产品，而是把企业内部多个 Agent 接入、权限、搜索、后端认证和流式响应放到统一入口里管理。对国内团队来说，这类架构的价值在于：当 Agent 从 Demo 走向多团队、多系统协作时，工程复杂度往往比模型调用本身更早暴露出来。

Agent 多了以后，问题会从“能不能调用”变成“怎么治理”

AWS 文章的核心判断很明确：企业在不同团队、供应商和基础设施上部署 AI Agent 后，点对点集成会带来连接、凭证和路由逻辑的膨胀。素材中提到，如果没有中央编排或统一入口，20 个 Agent 最多可能需要 190 条点对点连接。

这个数字不是在强调 Agent 数量本身，而是在提示一个常见落地问题：每新增一个 Agent，都可能带来新的鉴权配置、网络连通、接口适配和访问策略。短期看，团队可以靠脚本和约定解决；但一旦进入跨部门或跨系统协作，权限分散、凭证散落、路由逻辑重复，就会让后续维护成本快速上升。

AWS 给出的方案是网关模式：无论 Agent 运行在 Amazon ECS、AWS Lambda、Amazon Bedrock AgentCore Runtime，还是非 AWS 云或混合环境，都通过一个统一入口访问。客户端不再直接记住每个后端 Agent 的地址，而是访问类似 `/agents/{agentId}` 的路径，由网关完成后端路由和权限判断。

这套方案分三层：管理、控制、执行

从素材看，AWS 将这个 A2A 网关拆成三层。

第一层是管理层。它维护一个集中式 Agent Registry，用来登记 Agent ID、后端 URL、认证配置和缓存的 agent card。新 Agent 部署后，只需在网关注册一次，授权客户端就能发现它。网关还会把缓存 agent card 里的 URL 改写为网关地址，使客户端始终通过单一域名交互，而不是暴露后端 Agent 地址。

第二层是控制层。方案使用 Amazon Cognito 的 OAuth 2.0 client credentials flow 发放 JWT，token 中的 scope 决定调用方可以访问哪些 Agent。API Gateway 前面放置 Lambda authorizer，读取 JWT scope，再查询 DynamoDB 中的 Permissions 表，生成允许或拒绝访问特定 Agent 路径的 IAM policy。未授权请求会在 API Gateway 层被拒绝，不会到达后端 Lambda。

第三层是执行层。实际请求通过 Proxy Lambda 转发到后端 Agent。Proxy Lambda 从 AWS Secrets Manager 获取后端 OAuth 凭证，代客户端完成后端认证，并支持 Server-Sent Events，便于 Agent 返回增量响应。素材还提到，方案在代理层按用户和 Agent 维度做限流，使用 DynamoDB 原子计数器和 TTL，到达限额时返回 429 与 Retry-After header。

A2A 网关不是替代协议，而是补上企业级入口

这篇文章基于 Agent-to-Agent（A2A）协议展开。素材显示，网关支持 A2A 规范中的两类绑定：JSON-RPC 和 HTTP+JSON/REST。客户端可以通过 `GET /agents/{agentId}/.well-known/agent-card.json` 获取 Agent 能力，也可以向 `/agents/{agentId}` 发送消息请求，流式场景使用 `SendStreamingMessage`。

这里的关键点是：网关并没有要求标准 A2A 客户端做大改造。客户端只需把目标地址指向网关 URL，而不是具体后端 Agent URL。这样做保留了协议兼容性，同时把企业落地需要的发现、搜索、注册、状态管理和权限治理放到了网关侧。

AWS 还增加了非 A2A 原生端点，例如 `GET /agents` 用于列出当前调用方可访问的 Agent，`POST /search` 用于语义搜索，`POST /admin/agents/register` 用于注册 Agent，另有同步 agent card 和激活、停用 Agent 的管理接口。对企业来说，这些接口比单纯消息转发更接近真实运维需求。

语义搜索说明：Agent 目录正在变成一种内部基础设施

素材中提到，方案使用 Amazon Titan Text Embeddings in Amazon Bedrock 生成 Agent 描述向量，并存储在 Amazon S3 Vectors 中。这样客户端可以通过自然语言描述需求来发现 Agent，而不是必须知道精确名称。

这个设计反映出一个趋势：当 Agent 数量增加后，企业需要的不只是“调用某个 Agent”，还需要“找到合适的 Agent”。这类似过去企业内部 API 网关、服务目录和权限系统的演进，只是对象从服务接口变成了具备能力描述的 Agent。

但这也意味着治理边界会更复杂。Agent 描述是否准确、权限是否与能力匹配、搜索结果是否会暴露不应被发现的业务能力，都需要人工和系统共同管理。AWS 文章给出的是架构样例，不等于这些治理问题已经自动解决。

对国内团队的启发：先把 Agent 当成服务治理对象

国内企业做 Agent 落地时，容易把重点放在模型选型、Prompt、工具调用和知识库效果上。但如果目标是让多个 Agent 参与业务流程，网关、注册中心、访问控制和凭证管理会很快成为基础问题。

AWS 这套 Serverless A2A gateway 的参考意义在于，它把 Agent 当成一种需要治理的服务对象：有身份、有能力卡片、有访问范围、有后端认证、有生命周期状态，也有限流策略。这样的思路不依赖某一个前端聊天入口，更适合进入内部系统集成和自动化工作流。

同时，这仍是一篇厂商技术博客，素材中的实现大量依赖 AWS 托管服务，包括 API Gateway、Lambda、DynamoDB、Cognito、Secrets Manager、Bedrock、S3 Vectors 和 Terraform。国内团队如果采用类似模式，需要结合自身云环境、合规要求、权限体系和已有网关能力重新评估，而不是照搬服务清单。

来源

• AWS Machine Learning Blog：Building a serverless A2A gateway for agent discovery, routing, and access control

https://aws.amazon.com/blogs/machine-learning/building-a-serverless-a2a-gateway-for-agent-discovery-routing-and-access-control/