AWS 发布无服务器 A2A 网关，用中央注册表替换 190 条点对点连接

随着企业中 AI 智能体数量的增长，缺乏中央协调所带来的运营混乱也随之加剧。Amazon Web Services 发布了无服务器 A2A 网关的开放参考架构，在基础设施层面解决这一问题。

为何不断增长的智能体数量会产生连接问题？

这个问题易于描述，但在实践中却相当严峻。两个智能体之间的每条直接连接都需要自己的身份验证、自己的路由逻辑和自己的访问控制。对于 N 个智能体，此类点对点连接的最大数量为 N×(N−1)/2。

对于 10 个智能体，这意味着 45 条连接。对于 20 个智能体——这在企业部署中并不罕见——系统可能需要多达 190 条直接连接。每条连接都有自己需要轮换的凭证、自己的错误处理逻辑和自己的授权代码。碎片化程度变得如此复杂，以至于添加一个新智能体本身就成了一个项目。

A2A 网关将这一切简化为单一入口点。

三层架构

管理层

管理层维护中央智能体注册表并启用智能体发现。每个智能体只需注册一次，网关会自动生成并缓存 agent-card.json，可在标准化路径 GET /agents/{agentId}/.well-known/agent-card.json 访问。卡片中的 URL 被重写为网关域名，因此客户端永远不会直接与后端通信。

智能体发现支持两种方式：精确名称匹配或自然语言语义搜索。智能体描述通过 Amazon Bedrock Titan Text Embeddings 建立索引并存储在 Amazon S3 Vectors 中。客户端可以发送诸如「分析合同的智能体」之类的查询，无需知道确切名称即可获得语义相关智能体列表。

控制层

控制层管理授权和速率限制。身份验证基于通过 Amazon Cognito 的 OAuth 2.0 客户端凭证流——客户端获得包含与特定智能体访问权限绑定的 scope 的 JWT 令牌。

Lambda 授权器在每次请求时评估 JWT scope。速率限制按用户-智能体组合应用，并通过 Amazon DynamoDB 中的原子计数器实现——这意味着即使是并发请求也无法绕过限制，得益于 DynamoDB 的原子操作。

执行层

执行层是代理，它接收经过授权的请求，从 AWS Secrets Manager 获取后端凭证，向目标智能体进行身份验证并将响应转发给客户端。通过 Lambda Web Adapter 还支持 Server-Sent Events 流式传输，这意味着客户端可以实时接收部分响应而无需阻塞。

客户端侧的零凭证模型

安全设计的出发点是客户端不应访问任何指向后端的密码或 OAuth 密钥。所有后端凭证专由 Secrets Manager 保管；客户端仅通过限时有效的作用域 JWT 令牌与网关通信。

结合可选的私有 VPC 部署（网关和所有 AWS 服务仅在私有网络内可用，无公共互联网）以及用于本地智能体的 AWS Direct Connect 连接，该架构满足了具有高安全要求的企业环境需求。

实现支持开放 A2A 协议

网关明确实现了 A2A（Agent-to-Agent）协议——一种用于不同供应商 AI 智能体之间互操作性的开放标准。同时支持 JSON-RPC 和 HTTP+REST 绑定，这意味着在不同平台上构建的智能体可以通过同一个网关进行通信，客户端无需做任何更改。

整个基础设施代码以 Terraform 配置形式提供（版本 1.5.0 或更高）。Terraform 自动配置智能体注册表的 DynamoDB 表、权限和速率限制计数器、Cognito 用户池、用于所有操作的 Lambda 函数、API Gateway 和 IAM 角色。Lambda 容器的 Docker 构建代理会在 terraform apply 过程中自动运行。

实际背景

参考架构不是生产就绪的服务，而是团队可以根据需要进行定制的文档化模式。AWS 强调网关旨在作为基础，组织在其上添加特定于自身领域的安全层、监控和日志记录。后端本身必须实现针对提示注入攻击的防护——网关确保谁可以访问智能体，但不分析消息内容。