将Amazon Bedrock AgentCore连接到跨账户知识库

了解Amazon Bedrock AgentCore代理如何从一个账户中从另一个账户由Amazon Redshift Serverless支持的Amazon Bedrock知识库生成答案,而无需复制源数据。本文涵盖架构、安全边界……

来源:亚马逊云科技 _机器学习

组织通常使用Amazon Bedrock AgentCore部署代理,这是一个可使用任何框架或模型大规模构建、连接和优化代理的平台。这些代理可能访问托管在单独AWS账户中的受管控知识库。这种跨账户分离有助于维护清晰的工作负载边界,但可能引入集成挑战。

本文说明AgentCore代理如何从一个账户中的知识库(使用Amazon Bedrock知识库,即完全托管的检索增强生成能力)生成答案,该知识库由另一个账户中的Amazon Redshift Serverless支持,而无需复制源数据。

本文涵盖了两种广泛可用的Amazon Bedrock AgentCore编排模型的架构、安全边界、请求流程和选择标准。附带的GitHub示例提供了这两种变体的部署过程和实现细节:

挑战

使用Amazon Bedrock构建AI代理的组织可以将结构化数据维护在Amazon Redshift Serverless中。这些数据存储库可以与其AI代理位于不同的AWS账户中。Amazon Bedrock知识库资源策略支持用于跨账户操作的Retrieve和GetDocumentContent。支持的资源策略操作不包括RetrieveAndGenerate。由于此解决方案需要RetrieveAndGenerate返回生成的答案,因此该工具在调用API之前先在知识库账户中承担一个范围严格限定的AWS Identity and Access Management角色。

这给拥有多账户架构的企业带来了挑战,他们希望:

  • 在Amazon Redshift Serverless中的结构化数据上生成自然语言答案。
  • 维护代理工作负载和数据工作负载之间的账户边界。
  • 避免将受管控的源数据复制到代理账户。
  • 通过专用的跨账户IAM角色授予最小权限访问。
  • 解决方案概述

    该解决方案以两种方式实现跨账户查询模式。变体1将一个Strands代理部署到AgentCore运行时。变体2使用声明式AgentCore harness。两种实现使用相同的数据访问边界。模型控制的工具通过AWS Security Token Service承担知识库访问角色,调用RetrieveAndGenerate,并将生成的答案和引用返回到编排层。两种变体的区别在于谁拥有代理循环以及工具如何托管。图1比较了两种编排路径及其共享的跨账户数据访问边界。

    图1:并排的AgentCore实现路径

    请求流程

    请求遵循以下顺序:

  • 用户通过Streamlit UI或AgentCore API提交自然语言问题。
  • Amazon Nova Pro决定调用query_knowledge_base工具。
  • 在变体1中,该工具在随AgentCore运行时打包的本地模型上下文协议子进程中运行。在变体2中,AgentCore harness通过AgentCore Gateway调用AWS Lambda工具,这是Amazon Bedrock AgentCore的一个功能。
  • 该工具使用AWS STS在知识库账户中承担bedrock_kb_access_role。
  • 承担角色的会话使用Claude Haiku 4.5调用RetrieveAndGenerate。知识库将问题转换为针对Amazon Redshift Serverless的结构化查询。
  • 生成的答案通过选定的编排路径返回给用户。
  • 图2显示了基于代码的Strands代理的请求路径。

    图2:基于代码的Strands代理架构

    图3显示了声明式AgentCore harness对应的托管路径。

    图3:声明式AgentCore harness架构

    选择最简单的足够模式

    在选择代理实现之前,先决定工作负载是否根本需要代理。这使设计能与所需行为相称。

  • 如果应用程序只需要检索内容,请评估使用知识库资源策略进行原生跨账户Retrieve。
  • 如果每个请求确定性地需要一个生成的答案,首先确认工作负载不需要工具选择、多步骤推理或对话状态。如果不需要,则承担知识库账户角色并直接从应用程序或AWS Lambda函数调用RetrieveAndGenerate。
  • 当模型必须在更广泛的对话或工具使用工作流中决定何时或如何查询知识库时,使用代理。
  • 何时使用每种AgentCore变体

    跨账户要求并不偏向某一变体。根据您的团队需要自定义和操作多少编排循环来选择。

    决策在于自定义控制与托管编排之间。

    先决条件

    在开始之前,请确认您具备以下先决条件:

  • 两个AWS账户:一个代理账户和一个代理-知识库账户。
  • AWS Command Line Interface v2.24.22或更高版本,并具备两个账户的凭证。
  • Python 3.10或更高版本以及jq。
  • 一个连接到Amazon Redshift Serverless的结构化Amazon Bedrock知识库。
  • 美国西部(俄勒冈)区域的模型访问:代理账户中的us.amazon.nova-pro-v1:0和代理-知识库账户中的us.anthropic.claude-haiku-4-5-20251001-v1:0。有关各区域的模型可用性,请参阅Amazon Bedrock中按AWS区域划分的支持模型。
  • 对于harness变体,除了基于代码的变体使用的Python bedrock-agentcore CLI之外,还需要安装当前的@aws/agentcore Node.js CLI。
  • 假设

    示例使用以下本地配置文件别名和占位符账户ID:

    示例使用美国西部(俄勒冈)区域(us-west-2)。配置文件名称是本地别名,因此请用您配置的配置文件名称替换它们,并发现账户ID而非硬编码。

    AGENT_PROFILE=agent
    AGENT_KB_PROFILE=agent-kb
    REGION=us-west-2
    
    AGENT_ACCOUNT=$(aws sts get-caller-identity \
    --profile "$AGENT_PROFILE" --query Account --output text)
    AGENT_KB_ACCOUNT=$(aws sts get-caller-identity \
    --profile "$AGENT_KB_PROFILE" --query Account --output text)
    aws bedrock-agent list-knowledge-bases \
    --profile "$AGENT_KB_PROFILE" --region "$REGION"

    实现详解

    本文侧重于架构和决策指导。部署过程维护在公共GitHub示例中。使用“实现详解”准备结构化知识库、跨账户IAM角色和AgentCore内存(Amazon Bedrock AgentCore的一项能力)。然后按照“运行代理”执行基于代码的Strands变体或“变体2 – 声明式harness”执行托管代理循环。示例还包括用于本地、AgentCore和Harness UI模式的Streamlit端到端客户端。

    验证

    在比较变体时,使用相同的问题、知识库ID、模型、检索次数和新会话。提示合约指示两个代理将用户的问题按原样传递给工具,但RetrieveAndGenerate仍然是生成式的。对于行级问题,请指定行数、日期范围和排序顺序。无界生成的SQL可能超出结果处理限制。针对直接工具响应和底层结构化数据验证业务事实。

    在Streamlit客户端中,在比较结果之前选择调用模式。对于AgentCore或Harness模式,确认相应的已部署资源Amazon Resource Name已填充。为每次独立的事实比较开始新对话。

    图4:在Streamlit侧边栏中选择本地、AgentCore或Harness

    图5显示了Harness模式下一次成功的带边界查询。

    图5:带已部署ARN和成功带边界查询的Harness模式

    TPC-H数据集的示例问题包括:

  • 沙特阿拉伯排名前5的客户是谁?
  • 美国按数量计算排名前列的零件供应商是谁?
  • 1998年各地区的总收入是多少?
  • 哪些产品在折扣后创造了最高收入?
  • 显示1997年10月1日至12月31日期间标记为1-URGENT的前100个最高价值订单。
  • 推荐实践

    在部署和验证任一变体时应用以下实践:

  • 为独立的实际比较使用新会话ID。
  • 记录确切的工具查询、知识库ID、模型ID和检索结果计数。
  • 使用经批准的策划SQL和列描述定义衍生的业务指标。
  • 用明确的行数、日期范围和排序顺序限定行级问题,以避免过大的SQL结果集。
  • 保持跨账户角色范围限定在所需的知识库和模型资源上。
  • 在长期运行的运行时和热AWS Lambda环境中使用可刷新的STS凭证。
  • 测试两种变体的系统提示、工具描述、IAM和应用程序行为。
  • 应用Amazon Bedrock Guardrails来评估用户问题和生成的答案是否存在有害内容、被禁止的主题和敏感信息。Guardrails是对最小权限访问、源数据治理、基于引用的验证以及重大决策人工审查的补充,而非替代。
  • 清理资源

    按照示例的清理部分获取当前命令和所需顺序。当两种变体都已部署时,首先完成harness清理,以便其AWS Lambda执行角色信任授权从共享知识库访问角色中移除。然后移除基于代码的运行时和共享IAM资源。脚本不会删除项目管理的AgentCore内存、知识库或Redshift Serverless资源。当不再需要时,请单独删除它们。

    总结

    本文描述了AgentCore代理如何从跨AWS账户边界的结构化Amazon Bedrock知识库返回生成的答案。两种实现都在数据账户中使用最小权限角色。架构选择在于谁拥有代理循环以及工具如何托管。当这些模式满足工作负载时,从原生Retrieve或直接RetrieveAndGenerate调用开始。当需要模型控制工具或会话编排时,选择基于代码的Strands变体以获得自定义循环行为和直接控制。当其托管循环适合且您的团队偏好配置优先的运营模式时,选择AgentCore harness。两者都是有效的、广泛可用的路径。这里是Amazon Bedrock AgentCore文档,您可以在此开始使用Amazon Bedrock AgentCore并查看代码示例。

    关于作者

    Kunal Ghosh

    Kunal是AWS技术专家。他热衷于在AWS上构建高效且有效的解决方案,尤其涉及生成式AI、分析、数据科学和机器学习。除了家庭时间,他喜欢阅读、游泳、骑自行车、看电影和探索美食。

    Arghya Banerjee

    Arghya是AWS旧金山湾区的高级解决方案架构师,专注于帮助客户采用和使用AWS云。他的关注领域包括大数据、数据湖、流式和批处理分析服务以及生成式AI。

    Indranil Banerjee

    Indranil是AWS旧金山湾区的高级解决方案架构师,专注于帮助高科技和半导体领域的客户使用AWS云解决复杂的业务问题。他的兴趣包括现代化、迁移、分析平台和生成式AI。

    Yoginder Sethi

    Yoginder是AWS战略账户解决方案架构团队的高级解决方案架构师。他在设计、构建和管理大规模云架构、DevOps工具和可观测性解决方案方面拥有丰富经验。他位于加利福尼亚州旧金山湾区,工作之余喜欢探索新地方、听音乐和徒步旅行。