将 Amazon Bedrock AgentCore 连接到跨账户知识库
将 Amazon Bedrock AgentCore 连接至跨账户知识库
许多组织使用 Amazon Bedrock AgentCore 来部署智能体（Agent）。这是一个支持大规模构建、连接和优化智能体的平台，可与任意框架或模型配合使用。这些智能体可能需要访问位于其他 AWS 账户中的受管知识库。这种跨账户隔离有助于明确划分工作负载边界，但也会带来集成方面的挑战。
本文将介绍，如何让一个账户中的 AgentCore 智能体，在不复制源数据的情况下，从另一个账户中由 Amazon Redshift Serverless 支撑的知识库（基于 Amazon Bedrock Knowledge Bases 的全托管检索增强生成能力）生成答案。文章涵盖两种正式可用的 Amazon Bedrock AgentCore 编排模型的架构、安全边界、请求流程及选型标准。文末附带的 GitHub 示例提供了两种方案的部署步骤和实现细节：
- 基于代码的 Strands 智能体，运行在 AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）上。
- 声明式的 AgentCore harness（Amazon Bedrock AgentCore 的一项能力）。
挑战所在
使用 Amazon Bedrock 构建 AI 智能体的组织，通常会将结构化数据存放在 Amazon Redshift Serverless 中。这些数据仓库可能与 AI 智能体位于不同的 AWS 账户中。
Amazon Bedrock Knowledge Bases 的资源策略支持 Retrieve 和 GetDocumentContent 跨账户操作，但不支持 RetrieveAndGenerate 这一操作。由于本方案需要借助 RetrieveAndGenerate 返回生成的答案，工具在调用该 API 之前，会在知识库所在账户中承担一个权限范围严格限定的 AWS Identity and Access Management（IAM）角色。
这对拥有多账户架构的企业来说是个挑战，因为他们通常希望：
- 基于 Amazon Redshift Serverless 中的结构化数据生成自然语言答案。
- 在智能体工作负载和数据工作负载之间保持账户边界。
- 避免将受管源数据复制到智能体账户中。
- 通过专用的跨账户 IAM 角色授予最小权限访问。
解决方案概览
本方案以两种方式实现跨账户查询模式。
方案一：把 Strands agent 部署到 AgentCore 运行时上。方案二：使用声明式的 AgentCore 封装框架（harness）。两种实现共用同一条数据访问边界。
由模型控制的工具通过 AWS Security Token Service（AWS STS）代入知识库访问角色，调用 RetrieveAndGenerate，然后把生成的答案和引用来源返回给编排层。两种方案的区别在于：agent 循环由谁主导，以及工具托管在哪里。图 1 并排对比了这两条编排路径，以及它们共用的跨账户数据访问边界。
图 1：两种 AgentCore 实现路径对比
请求流程
请求按以下顺序流转：
- 用户通过 Streamlit UI 或 AgentCore API 提交自然语言问题。
- Amazon Nova Pro 决定调用 query_knowledge_base 工具。
- 方案一中，工具运行在本地 Model Context Protocol（MCP）子进程中，该子进程随 AgentCore 运行时一起打包。
- 方案二中，AgentCore 封装框架通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）调用 AWS Lambda 工具。
- 工具通过 AWS STS 代入知识库账户中的 bedrock_kb_access_role 角色。
- 被代入该角色的会话使用 Claude Haiku 4.5 调用 RetrieveAndGenerate。
- 知识库把问题转换为针对 Amazon Redshift Serverless 的结构化查询。
- 生成的答案沿所选编排路径返回给用户。
图 2 展示了基于代码的 Strands agent 的请求路径。
图 2：基于代码的 Strands agent 架构
图 3 展示了声明式 AgentCore 封装框架对应的托管路径。
图 3：声明式 AgentCore 封装框架架构
选择最简单且够用的模式
在挑选 agent 实现之前，先判断工作负载到底需不需要 agent，这样设计才能与需求相匹配。
如果应用只需要检索内容，先评估一下能否用知识库资源策略直接做跨账户原生 Retrieve。如果每个请求都固定只需要生成一个答案，先确认工作负载确实用不到工具选择、多步推理或对话状态
如果不行，则代入 Knowledge Base 账户角色，直接从应用程序或 AWS Lambda 函数调用 RetrieveAndGenerate。当模型需要在更广泛的对话或使用工具的工作流中决定何时或如何查询知识库时，才使用代理（agent）。
何时使用每种 AgentCore 变体
跨账户要求并不偏向某一种变体。请根据你的团队需要定制和操作编排循环的程度来选择。
| 决策领域 | 基于代码的 Strands 代理 | 声明式 AgentCore Harness |
|---|---|---|
| 最佳适用 | 需要定制编排、钩子、中间件、重试行为、检测或直接控制工具和流式的团队。 | 用例适合托管式循环，且偏好配置优先生命周期的团队。 |
| 代理循环 | 你的 Python 代码使用 Strands Agents SDK 运行循环。 | AgentCore 根据 Harness 定义运行循环。 |
| 工具路径 | AgentCore 运行时 → 本地 MCP 子进程 → Knowledge Base。 | AgentCore Harness → AgentCore Gateway → AWS Lambda → Knowledge Base。 |
| 跨账户主体 | AgentCore 运行时执行角色。 | AgentCore Gateway 背后的 AWS Lambda 执行角色。 |
| 你需要维护的内容 | agent.py、依赖项、MCP 服务器、工具逻辑和运行时配置。 |
AgentCore Harness 配置、系统提示、AWS Lambda 工具、IAM 和应用行为。 |
| 调用 API | InvokeAgentRuntime。 |
InvokeHarness。 |
抉择在于：定制控制 vs. 托管编排。
前提条件
开始之前，请确认你已具备以下前提条件：
- 两个 AWS 账户：一个 agent 账户和一个 agent-kb 账户。
- AWS 命令行界面 (AWS CLI) v2.24.22 或更高版本，并配置有这两个账户的凭证。
- Python 3.10 或更高版本，以及 jq。
- 一个连接到 Amazon Redshift Serverless 的结构化 Amazon Bedrock 知识库。
- 美国西部（俄勒冈）地区的模型访问权限：agent 账户中的
us.amazon.nova-pro-v1:0，以及 agent-kb 账户中的us.anthropic.claude-haiku-4-5-20251001-v1:0。 - 如需按区域查看模型可用性，请参阅 Amazon Bedrock 中的《AWS 区域支持的模型》。
- 对于 Harness 变体，除了基于代码的变体所使用的 Python
bedrock-agentcoreCLI 之外，还需要安装当前的@aws/agentcoreNode.js CLI。
假设条件
示例中使用以下本地 profile 别名和占位账户 ID：
| Profile | 示例账户 | 用途 |
|---|---|---|
| agent | 111122223333 | 托管 AgentCore 资源 |
| agent-kb | 999999999999 | 托管知识库和 Redshift Serverless |
示例使用美国西部（俄勒冈）区域（us-west-2）。Profile 名是本地别名，请替换为你实际配置的 profile 名，并查询账户 ID，而不是硬编码。
AGENT_PROFILE=agent
将 Amazon Bedrock AgentCore 连接到跨账户知识库
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 记忆（memory）——这是 Amazon Bedrock AgentCore 提供的一项能力。之后，根据需要选用「运行 Agent」来体验基于代码的 Strands 变体，或通过「变体 2：声明式 Harness」走托管式 Agent 循环。示例还附带一个 Streamlit 端到端客户端，支持 Local、AgentCore 和 Harness 三种界面模式。
验证方法
对比不同变体时，请保持相同的问题、知识库 ID、模型、检索数量和全新会话。提示词约定（prompt contract）会要求两个 Agent 将用户问题原样传给工具，但 RetrieveAndGenerate 仍属于生成式能力。对于需要明细行的问题，请明确指定行数、日期范围和排序方式，因为不受限的生成式 SQL 可能超出结果处理上限。验证业务事实时，应以工具的直接响应和底层结构化数据为准。
在 Streamlit 客户端中，先选择调用模式，再对比结果。使用 AgentCore 或 Harness 模式时，请确认对应已部署资源的 Amazon Resource Name（ARN）已填充。每次独立的事实对比，都建议开启新会话。
图 4：在 Streamlit 侧边栏选择 Local、AgentCore 或 Harness
图 5 展示了 Harness 模式下一次成功的受限查询。
图 5：Harness 模式，显示已部署的 ARN 和一次成功的受限查询
TPC-H 数据集的示例问题包括：
- 沙特阿拉伯排名前 5 的客户有哪些？
- 按供货量计算，美国排名靠前的零部件供应商是谁？
- 1998 年各地区总收入是多少？
- 哪些产品在折扣后创造了最高收入？
- 列出 1997 年 10 月 1 日至 12 月 31 日期间标记为 1-URGENT 的 100 笔最高金额订单。
推荐实践
部署和验证任一变体时，建议遵循以下做法：
- 每次独立的事实对比都使用全新的会话 ID。
- 记录确切的工具查询、知识库 ID、模型 ID 和检索结果数量。
定义派生业务指标时，使用经过审批的精选 SQL 和字段说明。给行级查询设定明确的返回行数上限、日期范围和排序方式，避免 SQL 结果集过大。跨账户角色的权限范围要尽量缩小，只覆盖所需的 Knowledge Base 和模型资源。在长期运行的运行时和保持预热的 AWS Lambda 环境中，使用可刷新的 STS 凭证。针对两种方案，分别测试系统提示词、工具描述、IAM 权限配置和应用行为。
启用 Amazon Bedrock Guardrails，对用户提问和生成的回答进行内容审核，识别有害内容、违规话题和敏感信息。需要指出的是，Guardrails 是对最小权限访问、源数据治理、基于引用的验证以及重要决策人工复核的补充，不能替代这些机制。
清理资源
按照示例中的清理章节，按顺序执行清理命令。如果两种方案都已部署，先完成 AgentCore harness（托管方案）的清理，将其 AWS Lambda 执行角色的信任授权从共享的 Knowledge Base 访问角色中移除；然后再删除基于代码的 Strands 运行环境和共享 IAM 资源。这些脚本不会删除项目管理的 AgentCore 记忆存储、Knowledge Base 或 Redshift Serverless 资源。如果不再需要，请单独删除。
总结
本文介绍了 AgentCore 智能体如何跨 AWS 账户边界，从结构化 Amazon Bedrock 知识库中返回生成的答案。两种实现都在数据账户中使用最小权限角色，架构上的区别在于：智能体循环由谁控制，工具如何托管。
如果原生 Retrieve 或直接调用 RetrieveAndGenerate 就能满足工作负载需求，建议优先采用这两种方式。当需要模型控制工具或会话式编排时，可以选择基于代码的 Strands 方案，以便自定义循环行为并获得直接控制力。如果 AgentCore harness 的托管循环恰好适配你的场景，且团队更倾向于配置优先的运营模式，则可以选用它。两种方案都有效，均已正式可用。
可以从 Amazon Bedrock AgentCore 文档开始上手，里面附有代码示例。
关于作者
Kunal Ghosh：AWS 技术专家。
About the Authors
Arghya Banerjee
Arghya 是 AWS 旧金山湾区的一位高级解决方案架构师，专注于帮助客户采用和使用 AWS 云。他的工作重点包括大数据、数据湖、流式和批处理分析服务，以及生成式 AI。他热衷于在 AWS 上构建高效、有效的解决方案，尤其在生成式 AI、分析、数据科学和机器学习领域。工作之余，他喜欢阅读、游泳、骑行、看电影和探索美食。
Indranil Banerjee
Indranil 是 AWS 旧金山湾区的一位高级解决方案架构师，专注于帮助高科技和半导体行业的客户利用 AWS 云解决复杂的业务问题。他的兴趣领域包括现代化改造、迁移、分析平台和生成式 AI。
Yoginder Sethi
Yoginder 是 AWS 战略客户解决方案架构团队的高级解决方案架构师。他在设计、构建和管理大规模云架构、DevOps 工具以及可观测性解决方案方面拥有丰富的经验。Yoginder 常驻加州旧金山湾区，业余时间喜欢探索新地方、听音乐和徒步。