北京
企业在用 Amazon Bedrock AgentCore 构建 AI 代理时，常遇到一个现实问题：代理跑在一个 AWS 账号里，而受管控的结构化数据（比如 Amazon Redshift Serverless 里的数据）却存放在另一个账号中。这种跨账号隔离有助于划清工作负载边界，但也让代理无法直接调用知识库生成答案。
近日发布的技术方案展示了如何在不复制源数据的前提下，让 AgentCore 代理跨账号访问 Amazon Bedrock Knowledge Bases（Amazon Bedrock 托管的检索增强生成能力），并基于 Redshift Serverless 中的数据生成自然语言回答。方案同时覆盖了架构设计、安全边界、请求流程，以及两种已正式可用的 AgentCore 编排模型的选择标准。
核心挑战：API 权限缺口
问题的根源在于权限模型。Amazon Bedrock Knowledge Bases 的资源策略支持跨账号调用 Retrieve 和 GetDocumentContent 操作，但偏偏不支持 RetrieveAndGenerate——而后者恰恰是返回生成答案所必需的接口。
为了绕开这个限制，方案中的工具在调用 API 之前，会先通过 AWS 安全令牌服务（STS）临时扮演一个知识库所属账号中权限范围极窄的 IAM 角色。这样一来，企业既能获得 RetrieveAndGenerate 返回的答案，又不必把受治理的源数据复制到代理所在账号。
这套设计主要面向有多账号架构的企业，核心诉求包括：对 Redshift Serverless 中的结构化数据生成自然语言答案；在代理工作负载和数据工作负载之间保持账号边界；避免将受管控源数据复制进代理账号；通过专用跨账号 IAM 角色实现最小权限授权。
两种实现路径，同一数据边界
方案提供了两种跨账号查询模式的实现方式，二者共享完全相同的数据访问边界：模型控制的工具通过 STS 扮演知识库访问角色，调用 RetrieveAndGenerate，再把生成的答案和引用来源返回给编排层。区别只在于代理循环由谁掌控、工具部署在哪里。
- 变体一：将 Strands 代理部署到 AgentCore 运行时（Amazon Bedrock AgentCore 的一项能力），工具在本地模式运行。
- 变体二：使用声明式 AgentCore harness（同样是 AgentCore 的能力），编排逻辑由 harness 接管。
请求流程：从提问到答案
整个调用链路清晰直接。用户通过 Streamlit 界面或 AgentCore API 提交自然语言问题；Amazon Nova Pro 模型判断需要调用 query_knowledge_base 工具；在变体一中，该工具在本地模式运行，完成跨账号数据访问并返回结果。
配套的 GitHub 示例代码提供了两种变体的详细部署步骤和实现细节，方便企业根据自身架构偏好选择合适路径。对于已经在多账号环境中运行 AgentCore 代理、又希望直接利用 Redshift 中结构化数据的团队来说，这套方案补上了跨账号检索生成的关键一环。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
