Amazon Bedrock AgentCore Runtime 支持座席间（A2A）协议

📢 转载信息

原文链接：https://aws.amazon.com/blogs/machine-learning/introducing-agent-to-agent-protocol-support-in-amazon-bedrock-agentcore-runtime/

原文作者：Madhur Prashant, Eashan Kaushik, Jeffrey Burke, Sayee Kulkarni, Andy Palmer, Sriharsha M S, and Shreyas Subramanian

我们最近宣布 Amazon Bedrock AgentCore Runtime 支持座席间（Agent-to-Agent, A2A）协议。通过这项新增功能，座席可以使用标准化的通信方式，在不同平台之间发现同伴、共享能力并协调操作。

Amazon Bedrock AgentCore Runtime 提供了一个安全、无服务器的环境，专为部署 AI 座席和工具而设计。它与任何框架和模型协同工作，支持实时和长时间运行的工作负载，并支持会话隔离以及内置的身份验证。随着对 MCP 以及现已支持的 A2A 协议的支持，Bedrock AgentCore Runtime 实现了座席间的无缝通信。使用不同框架构建的座席，如 Strands Agents、OpenAI Agents SDK、LangGraph、Google ADK 或 Claude Agents SDK，可以以通用、可验证的格式共享上下文、能力和推理。

在本文中，我们将演示如何利用 A2A 协议，使不同框架构建的 AI 座席能够无缝协作。您将学习如何在 AgentCore Runtime 上部署 A2A 服务器、配置座席发现和身份验证，并构建一个用于事件响应的真实多座席系统。我们将涵盖完整的 A2A 请求生命周期，从座席卡发现到任务委托，展示标准化协议如何消除多座席协调的复杂性。

了解多座席系统

构建有效的座席系统需要几个基本组件。这些包括内存，包括用于维护对话上下文的短期内存和用于跨会话保留洞察的长期内存；座席可以通过原生方式或通过 MCP 服务器访问的工具；用于更安全身份验证和权限管理的身份，允许座席代表用户操作或自主访问资源；以及用于检测有害内容、帮助防止“幻觉”并确保响应符合策略和事实准确性的护栏（Guardrails）。

虽然 MCP 将单个座席连接到其工具和数据，但 A2A 允许多个座席相互协调。例如，零售库存座席可能会使用 MCP 查询产品数据库，然后使用 A2A 与外部供应商座席通信以下订单。

A2A 协议通过跨不同边界的无缝互操作性为多座席系统带来益处。使用 Strands 或 OpenAI 等不同框架构建的座席，由 Anthropic Claude、GPT-4 或 Llama 等各种 LLM 提供支持，并托管在 AWS 或边缘设备等不同系统上，可以轻松通信和协调，而无需复杂的翻译层。这种互操作性与松散耦合和模块化相辅相成，其中每个座席作为一个独立单元运行，可以开发、测试、部署甚至升级，而不会中断整个系统。新的专业座席可以无缝加入环境，并且由于定义明确的交互边界，一个座席的故障是隔离的，有助于防止系统级联故障。该协议还支持动态座席发现和编排。座席通过标准化架构公布其能力，而编排座席可以根据实时任务需求发现和调用专业座席。

Amazon Bedrock AgentCore Runtime 上的 A2A 请求生命周期

A2A 协议定义了一个结构化的请求生命周期，其中包含协同多座席通信所需的特定组件。以下是关键要素：

• 用户（User）：通过客户端座席发起请求，可以是人工操作员或自动化服务，用于定义需要多座席协助的目标。
• A2A 客户端（Client Agent）：代表用户行事，使用 A2A 协议发起通信，以发现远程座席并请求其任务。
• A2A 服务器（Remote Agent）：暴露实现 A2A 协议的 HTTP 端点，用于接收请求、处理任务并返回结果。不同的座席可以担任此角色，使用基于 HTTP/S 的 JSON-RPC 2.0 或服务器发送事件（Server-Sent Events）处理同步和异步交互。
• 座席卡（Agent Card）：每个座席发布的一个 JSON 元数据文件，用于公布其身份、能力、端点和身份验证要求。这实现了动态发现功能，即座席在委托任务之前会查询其同伴座席能做什么。
• 任务对象（Task Object）：代表流经系统的每个工作单元，具有唯一的 ID 和生命周期。随着座席的协调，任务可能是长时间运行的、涉及多个回合的，并且跨多个协同工作的座席。
• 产物（Artifact）：任务完成时产生的输出，可以包括结构化文本、JSON、图像、音频或其他多模态内容。座席在协作完成用户的原始请求时会交换这些产物。

多座席用例：监控和事件响应

为了演示在 Amazon Bedrock AgentCore Runtime 上使用 A2A 进行的多座席系统的强大功能，我们将探讨一个企业级监控和事件响应解决方案。这个真实世界的用例展示了使用不同框架构建的专业座席如何通过 A2A 协议无缝协调，以应对复杂的运营挑战。

监控和事件响应解决方案实施了一个带有三个专业座席的中心辐射型（hub-and-spoke）架构，每个座席都使用 Amazon Bedrock AgentCore 功能——提供核心能力的模块化构建块，例如用于上下文感知响应的AgentCore 内存、使用 Amazon Cognito 实现更安全的座席身份验证和操作权限的AgentCore 身份、用于更安全和集中访问工具的AgentCore 网关，以及用于跟踪、调试和监控 AI 座席性能的可观测性。请查看下面的架构和演示视频以供参考：

多座席系统包含以下组件：

1. 宿主座席 (Google ADK)：充当座席交互的智能路由层和协调中心。它使用 A2A 演示跨系统互操作性。该座席在Amazon Bedrock AgentCore Runtime 上运行，使用Google 的智能座席开发工具包 (Agent Development Kit)，但通过标准化 A2A 协议与托管在 AWS 上的座席无缝通信。宿主座席的关键职责包括：
   • 动态座席发现：从 AWS Systems Manager Parameter Store 获取每个远程座席的身份提供商 (IDP) 配置，从而在多座席系统中实现更安全的身份验证
   • 能力感知：从每个 A2A 服务器检索座席卡，以了解可用的技能和端点
   • 智能路由：分析用户查询并根据能力将查询路由到适当的专业座席
   • 多座席协调：编排需要多个座席的复杂工作流
2. 监控座席 (Strands Agents SDK)：充当操作智能层，持续分析 AWS 服务的 CloudWatch 日志、指标、仪表板和警报。该座席专门负责从海量遥测数据中识别异常、跟踪错误模式并浮现可操作的洞察。当出现不寻常的模式时，监控座席会启动与其它专业座席的对话，以协调响应操作。监控座席的关键职责包括：
   • CloudWatch 集成：
     • 列出并分析 CloudWatch 仪表板
     • 获取特定 AWS 服务（Lambda、ECS、EC2）的日志
     • 监控警报和告警状态
     • 分析日志组以查找模式和错误
   • 跨账户访问：支持跨多个 AWS 账户的监控
3. 操作座席 (OpenAI SDK)：提供补救策略和外部知识集成。当监控座席检测到关键问题时，它会通过 A2A 与操作座席直接通信，提供有关问题的上下文并请求特定的补救操作。操作座席的关键职责包括：
   • 网络搜索：使用 Tavily API 搜索 AWS 最佳实践、故障排除指南和解决方案
   • 补救策略：根据检测到的问题提出解决方案

实施多座席监控解决方案

在探索了这三个专业座席如何协同处理 AWS 事件之后，让我们来看看如何使用 Amazon Bedrock AgentCore Runtime 构建和部署此多座席系统。

实施遵循渐进式方法：

1. 从基础开始——我们将部署一个简单的 A2A 服务器，以了解座席在 AgentCore Runtime 上的部署、身份验证和调用的核心机制
2. 构建监控系统——使用相同的部署模式，我们将构建每个专业座席（监控、操作和宿主座席）及其特定的工具和能力
3. 连接座席——配置座席之间的 A2A 通信通道，使它们能够通过标准化协议发现和调用彼此
4. 观察系统运行——观看演示视频，其中展示了实时事件检测、跨座席协调和自动化响应

此多座席监控系统的所有代码示例、完整的座席实现和部署脚本都可以在我们的GitHub 存储库中找到。

在 AgentCore Runtime 上开始使用 A2A

要了解在 Amazon Bedrock AgentCore Runtime 上部署 A2A 服务器的基本知识，包括创建、测试、部署和调用座席的分步说明，请参阅A2A 协议支持文档。本指南涵盖：

• 使用任何框架（Strands、OpenAI SDK、LangGraph）创建和配置 A2A 服务器
• 本地测试和验证
• 使用 AgentCore CLI 进行部署
• 身份验证设置（OAuth 2.0 和 AWS IAM）
• 座席卡检索和发现
• 用于调用已部署座席的客户端实现

一旦熟悉了这些基本知识，您就可以应用相同的模式来构建多座席监控系统的每个组件。

在此帖子中，我们将重点介绍此用例实现，请参阅此GitHub 示例中查看完整的示例。

先决条件

要部署多座席监控系统的实现，请遵循先决条件步骤：

1. AWS 账户：您需要一个具有适当权限的有效 AWS 账户
   • 创建 AWS 账户
   • AWS 管理控制台访问权限
2. AWS CLI：安装并使用您的凭证配置 AWS CLI
   • 安装 AWS CLI
   • 配置 AWS CLI
3. 安装 uv。
4. 支持的区域：此解决方案当前在以下AWS 区域进行了测试和支持。

注意：要在其他区域进行部署，您需要在 cloudformation/vpc-stack.yaml 中更新 DynamoDB 前缀列表映射。有关详细信息，请参阅VPC 堆栈文档。

部署步骤

本指南将引导您使用基础设施即代码在 AWS 上部署多座席系统。部署此解决方案的最简单方法是使用我们的自动化部署脚本：

步骤 1：克隆存储库

git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git cd 02-use-cases/A2A-multi-agent-incident-response

步骤 2：运行部署脚本

此部署脚本将验证是否安装并配置了 AWS CLI，检查 AWS 凭证是否有效，确认区域设置为 us-west-2，交互式收集所需参数，生成唯一的 S3 存储桶名称，并自动按正确顺序部署所有堆栈。预计部署时间约为 10-15 分钟。

uv run deploy.py

步骤 3：提供运行时 CLI 参数

接下来，提供部署时使用的参数。按 Enter 键接受每个选项的默认 Amazon Bedrock 模型 ID 和每个座席的 CloudFormation 堆栈名称。

API 密钥：您需要以下 API 密钥（部署脚本会提示输入）：

• OpenAI API 密钥：从 OpenAI 平台获取
• Tavily API 密钥：从 Tavily获取
• Google API 密钥：从 Google AI Studio获取

配置完信息后，启动部署过程并在 AWS 控制台和终端中跟踪它。

步骤 4：提供运行时 CLI 参数

使用以下命令运行前端。这会设置并运行 React 前端 UI，允许用户通过协调的 A2A 座席与多座席事件响应系统交互，以监控 AWS 基础设施、查询 CloudWatch 指标和日志，以及搜索补救策略。

cd frontend npm install chmod +x ./setup-env.sh ./setup-env.sh npm run dev

此部署在 Amazon Bedrock AgentCore Runtime 上创建了一个由 A2A 协议编排的多座席 A2A 系统，其中有三个专业 AI 座席。Cognito 堆栈通过创建一个带有四个独立客户端应用程序（WebSearch、监控、网关和宿主座席客户端）的 Cognito 用户池，来配置基于 OAuth 2.0 的机器到机器身份验证。

监控座席（使用 Strands SDK 构建）通过使用 Smithy 模型定义和用于事件跟踪的自定义语义内存策略的 AgentCore 网关连接到 CloudWatch 指标和日志。

操作座席（使用 OpenAI Agents SDK 构建）负责与 Tavily API 接口以进行补救研究，而宿主座席（使用 Google ADK 构建）充当协调器，使用 HTTP 协议将任务委托给两个专业 A2A 座席。

端到端事件响应工作流

在本节中，我们将完成一个端到端的工作流，其中宿主座席管理对话，从用户处获取需求，并选择最佳座席来路由请求（监控座席或操作座席）。监控座席和操作座席会公开其座席卡，供宿主座席用于编排。在此示例中，我们将使用对各种日志组的简单错误分析和搜索补救策略进行测试。

工作流包括以下步骤：

1. 初始问候：用户向宿主座席发送问候消息“嗨！你好吗？”。宿主座席处理请求。宿主座席以友好的问候“我很好，谢谢！”回应用户。
2. 能力查询：用户询问宿主座席“你们有什么能力？”以了解其职能。宿主座席向用户解释，它是基于其可访问的远程座席连接而设计的、用于 AWS 监控和操作的编排座席。
3. 列出日志组和仪表板：用户请求宿主座席列出其 AWS 账户中的日志组和仪表板。宿主座席识别出这是一个监控任务，并执行 transfer_to_agent 工具将工作委托给监控座席。请求通过座席间（A2A）的 Json RPC 传输协议从宿主座席转移到监控座席。监控座席检索信息并返回结果，显示在账户中找到了 0 个仪表板和 153 个日志组。宿主座席接收来自监控座席的结果，并向用户显示仪表板和日志组信息。
4. 分析特定日志组：用户请求宿主座席在特定日志组路径 /aws/bedrock-agentcore/runtimes/hostadk-<runtimeId>-DEFAULT 中查找错误。宿主座席确定这需要监控专业知识，并执行 transfer_to_agent 工具。请求被转移到监控座席，并指示其分析指定的日志组以查找错误。监控座席分析日志组并发现 9 个错误和 18 个警告，特别是确定了 OTLP 导出失败。宿主座席接收分析结果，并向用户显示详细的错误分析报告。
5. 调试和修复建议：用户请求宿主座席调试错误并提供所需的修复报告。请求被转移到操作座席，以搜索与 OTLP 导出失败相关的解决方案。操作座席使用 A2A JsonRPC 传输协议尝试搜索，并执行网络搜索以提供解决方案。

Amazon Bedrock AgentCore Runtime 上的 A2A 安全性

Amazon Bedrock AgentCore Runtime 支持两种身份验证方法来保护 A2A 通信：

OAuth 2.0 身份验证：A2A 客户端向外部授权服务器进行身份验证以获取 JSON Web Token (JWT)，然后将其包含在所有发往 A2A 服务器的请求中。这种基于令牌的方法支持使用机器到机器 (M2M) 凭证或用户联合进行标准化安全身份验证，允许 A2A 服务器验证客户端身份并根据令牌的声明强制执行访问控制。

AWS IAM 身份验证：A2A 客户端承担一个具有调用 A2A 服务器座席权限的 IAM 角色。这种方法利用 AWS SigV4 请求签名和 IAM 策略来控制访问，无需外部令牌管理，同时提供细粒度的权限。

Amazon Bedrock AgentCore Runtime 中 A2A 支持的内容

Amazon Bedrock AgentCore Runtime 为 A2A 通信提供了全面的支持。查看一些受支持的功能：

• 无状态服务器：Amazon Bedrock AgentCore Runtime 可以托管 A2A 服务器，这些服务器公开 HTTP 接口，在端口 9000 上运行无状态 HTTP 服务器并支持 JSON-RPC 消息传递。运行时充当透明代理，按原样传递 JSON-RPC 请求和响应，以保持协议保真度。
• 已身份验证的座席卡：支持在 /.well-known/agent-card.json 处进行已身份验证的座席卡，其中包含其能力和技能，允许其他座席自动发现它。
• 安全入站身份验证：Amazon Bedrock AgentCore Runtime 通过AWS SigV4 和 OAuth 2.0 支持安全身份验证，确保座席间通信已授权且安全。A2A 服务器使用 HTTP 标头中提供的凭证对每个传入请求进行身份验证，利用Amazon Bedrock AgentCore Identity。
• 安全出站授权：Amazon Bedrock AgentCore Runtime 通过 IAM 执行角色和 AgentCore Identity 支持安全的出站授权。每个座席都承担一个定义的 IAM 执行角色，授予其访问 AWS 资源的必要权限，从而提高安全性。对于与外部服务的交互，座席可以使用 Amazon Bedrock AgentCore Identity，它为 Google、GitHub、Slack 等第三方身份提供商提供托管的 OAuth 2.0 支持。
• VPC 连接性：您可以配置 Amazon Bedrock AgentCore Runtime 以连接到Amazon 虚拟私有云 (VPC) 中的资源。通过配置VPC 连接性，您可以启用对 VPC 内私有资源（如数据库、内部 API 和服务）的安全访问。
• 利用 AWS PrivateLink：Amazon Bedrock AgentCore 使用AWS PrivateLink 在您的虚拟私有云 (VPC) 和 AgentCore 服务之间实现安全、私密的连接。通过创建接口 VPC 端点，您可以将 A2A 服务器通信保留在 VPC 内部，而无需通过公共互联网传输。
• 生命周期管理：Amazon Bedrock AgentCore Runtime 允许您配置生命周期规则，使用 idleRuntimeSessionTimeout 和 maxLifetime 管理资源使用情况。空闲或长时间运行的会话会自动终止，以实现高效的资源利用并保持系统性能。

结论

Amazon Bedrock AgentCore Runtime 中的座席间协议支持为构建可扩展、可互操作的多座席系统提供了基础。通过为 AI 座席提供标准化通信，无论其底层框架、模型或托管基础设施如何，组织都可以利用 A2A 协议来组合复杂的座席解决方案。AWS 监控和事件响应示例展示了这种方法的实际威力：一个基于 Google ADK 的编排器与使用 Strands 和 OpenAI SDK 构建的座席进行协调，所有这些都部署在 AgentCore Runtime 上，协同工作以检测问题、搜索解决方案并推荐修复措施。这种级别的互操作性传统上需要大量的自定义集成工作，但 A2A 通过标准化协议使其变得简单直接。随着 AI 系统从单一用途工具发展为协作环境，A2A 和 MCP 等协议正成为必要的构建块。它们创造了一个未来，座席可以被动态发现、组合和编排，使组织能够“构建一次，集成到任何地方”。

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。