AWS打通跨组织A2A智能体协作与双向OAuth信任链

摘要：AWS发布基于A2A协议的跨组织多智能体参考架构：LangChain编排器运行于Amazon ECS，可通过Agent Card发现并调用部署在Amazon Bedrock AgentCore上的Strands智能体，双方还能借助独立Cognito身份池进行双向OAuth调用。方案以JSON-RPC承载结构化任务，不暴露内部工具、系统提示或SDK依赖，并通过七项令牌边界测试验证跨账户安全。工程上采用五套CloudFormation栈和三个Jupyter笔记本完成部署，但当前仅适合沙箱验证，生产环境仍需私有连接、密钥治理、审计和租户隔离。

---

跨框架、跨账户的智能体协作不再依赖私有集成

AWS给出了一套基于Agent-to-Agent（A2A）协议的跨组织多智能体参考架构：企业侧的LangChain编排器运行在Amazon ECS/Fargate上，第三方SaaS侧的合规智能体则运行在Amazon Bedrock AgentCore上并使用Strands Agents构建。双方通过JSON-RPC over HTTPS通信，不共享框架、SDK、密钥或内部工具定义。

更关键的是，这不是单向的“客户端调用服务端”模式。SaaS智能体可以回调企业的上下文智能体，以取得生产账号标识、内部策略和升级联系人，再生成综合报告。这种双向对等协作解决了现实中的信息所有权问题：被调用方需要调用方掌握的私有上下文，但又不能开放自己的系统提示、工具列表和模型实现。

Agent Card承担运行时能力发现与工具映射

每个智能体通过/.well-known/agent-card.json发布Agent Card，其中包含名称、端点、协议版本、技能描述、流式能力及安全方案。企业编排器启动时读取卡片，把每个技能转换为LangChain工具，模型再根据用户请求决定调用哪个外部智能体。

这一设计减少了传统的硬编码路由：第三方增加技能只需更新Agent Card，编排器重启后即可重新发现能力。但“自动发现”并不等于“自动信任”，生产实现仍需将卡片中的URL与注册阶段允许的端点、签发方、客户端和scope进行绑定，并防范卡片元数据被篡改。示例代码将Agent URL固定到发现阶段取得的地址，且拒绝跟随HTTP重定向，这是必要的边界控制。

SaaS侧Agent Card只发布一项经过整理的“合规扫描”技能，而不会暴露底层三个扫描工具。第三方因此可以替换内部工具、提示词或基础模型，而不破坏客户侧接口。

A2A与MCP分别处理智能体间和智能体到工具的连接

该架构清楚区分了两类协议：MCP用于智能体连接自己的工具和数据源，通常是客户端—服务器关系；A2A用于不同组织、不同框架的智能体作为对等节点协作。第三方合规智能体可以在内部通过MCP连接AWS Config、Security Hub或GuardDuty，在外部只暴露A2A接口。

这种分层能够稳定外部契约，但也增加了协议适配、错误映射和身份传播的复杂度。跨边界调用不能简单继承原始用户令牌，否则会把一个身份域的权限扩散到另一个组织；更稳妥的做法是每个方向分别签发最小权限的服务令牌，并审计令牌对应的客户端、scope和任务ID。

双向OAuth建立独立信任域

示例部署包含两个AWS账户和两个Amazon Cognito用户池。企业编排器使用企业池的令牌调用SaaS智能体；SaaS智能体则使用自己的令牌回调企业上下文API。双方仅交换身份提供方URL、client ID、scope和端点等公共注册信息，不共享client secret。

接收端通过JWT签发方、audience或client ID、scope和允许客户端列表限制令牌。Cognito的client-credentials令牌可能没有aud声明，此时API Gateway会依据client_id检查audience，而AgentCore侧应配置allowedClients并避免错误要求不存在的audience。示例还采用“失败关闭”策略：无法获取有效令牌时不发送A2A请求；遇到401时仅强制刷新并重试一次。

这一设计的优势是信任域清晰、撤销范围明确，代价则是令牌交换、密钥轮换和跨供应商身份映射会持续产生运维负担。官方还建议生产环境改用private_key_jwt或mTLS，而不是长期保存共享client secret。

端到端验证覆盖功能与信任边界

三个Jupyter笔记本分别完成企业注册、SaaS智能体部署、企业端服务部署和端到端测试，共创建五套CloudFormation栈。示例任务由编排器发现合规智能体，触发扫描；SaaS智能体再回调企业上下文智能体，最终返回合规发现和仅存在于企业侧的on-call轮换标识。

端到端测试还发送错误、缺失和伪造令牌，验证七种越权组合全部返回401。该测试比单纯检查“能跑通”更有价值，因为跨组织智能体最常见的生产事故往往不是模型错误，而是令牌在错误入口被接受。不过，它仍是固定场景下的功能测试，并未证明Agent Card供应链安全、提示注入防御、租户级数据隔离或大并发下的令牌服务稳定性。

成本、延迟与部署复杂度需要提前核算

企业账户中的常驻资源包括NAT Gateway、两个Fargate任务、内部NLB和两个VPC接口端点，此外还需支付Bedrock与AgentCore使用量。两个Fargate任务、NLB、跨账户HTTPS调用和多轮回调会叠加冷启动、网络往返与模型推理延迟。示例端到端请求通常需要1至3分钟，不应直接外推为高并发生产SLA。

Agent Card与技能描述也会进入模型上下文：技能越多，工具选择空间越大，提示Token、误调用概率和路由开销随之增加。生产系统需要限制卡片签名能力、审核技能描述、设置技能数量上限，并为工具路由建立确定性规则与模型选择的混合机制。

生产落地清单

• 为每个客户或租户使用独立运行时，或在统一入口前配置按客户隔离的OAuth客户端与回调。
• 使用AWS PrivateLink和VPC内TLS建立私有连接，避免跨账户流量依赖公网入口。
• 使用客户管理的KMS密钥保护S3、ECR、Secrets Manager、CloudWatch Logs及Bedrock Guardrails。
• 开启VPC Flow Logs、NLB访问日志和API Gateway访问日志，并对回调任务建立全链路关联ID。
• 为Cognito凭据配置Secrets Manager自动轮换，改用经认证的注册门户或API替代文件交换。
• 在Agent Card校验、工具描述注入、回调重放、超时和熔断方面补充生产级控制。

这套方案证明了A2A可以在不共享内部实现的情况下组合跨组织工作流；它的核心价值不是新增模型，而是把智能体发现、调用、回调和身份验证拆成可替换的协议层。真正进入生产前，仍需补齐多租户隔离、私网连接、密钥零共享、审计和协议供应链防护。

---

消息来源：AWS Machine Learning Blog (2026-11-12)

—— 完 ——

主题标签： #A2A协议 关注 #多智能体系统 关注 #OAuth 关注 #Amazon Bedrock AgentCore 关注 #LangChain 关注