详细内容或原文请订阅后点击阅览
将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角色。
这给拥有多账户架构的企业带来了挑战,他们希望:
解决方案概述
该解决方案以两种方式实现跨账户查询模式。变体1将一个Strands代理部署到AgentCore运行时。变体2使用声明式AgentCore harness。两种实现使用相同的数据访问边界。模型控制的工具通过AWS Security Token Service承担知识库访问角色,调用RetrieveAndGenerate,并将生成的答案和引用返回到编排层。两种变体的区别在于谁拥有代理循环以及工具如何托管。图1比较了两种编排路径及其共享的跨账户数据访问边界。
图1:并排的AgentCore实现路径
请求流程
请求遵循以下顺序:
图2显示了基于代码的Strands代理的请求路径。
图2:基于代码的Strands代理架构
图3显示了声明式AgentCore harness对应的托管路径。
图3:声明式AgentCore harness架构
选择最简单的足够模式
在选择代理实现之前,先决定工作负载是否根本需要代理。这使设计能与所需行为相称。
何时使用每种AgentCore变体
跨账户要求并不偏向某一变体。根据您的团队需要自定义和操作多少编排循环来选择。
决策在于自定义控制与托管编排之间。
先决条件
在开始之前,请确认您具备以下先决条件:
假设
示例使用以下本地配置文件别名和占位符账户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数据集的示例问题包括:
推荐实践
在部署和验证任一变体时应用以下实践:
清理资源
按照示例的清理部分获取当前命令和所需顺序。当两种变体都已部署时,首先完成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工具和可观测性解决方案方面拥有丰富经验。他位于加利福尼亚州旧金山湾区,工作之余喜欢探索新地方、听音乐和徒步旅行。
