AWS 介绍 Bedrock AgentCore 跨账户知识库两种编排方案

Amazon Web Services 在其机器学习博客中发布了一篇架构指南，详细介绍如何让部署在一个 AWS 账户中的 Amazon Bedrock AgentCore 智能体访问托管在另一账户中的 Amazon Bedrock 知识库（基于 Amazon Redshift Serverless），并避免跨账户拷贝源数据。该方案面向在多账户架构下需要保持智能体与数据工作负载边界清晰的企业用户。

背景与挑战

许多组织在 Amazon Bedrock 上构建 AI 智能体，同时把结构化数据保存在 Amazon Redshift Serverless 中。这些数据仓库往往与智能体所在账户分离。Bedrock 知识库的资源策略虽然开放了 Retrieve 与 GetDocumentContent 这两类跨账户操作权限，但并未包含直接返回生成式答案的 RetrieveAndGenerate。要在跨账户场景下拿到「检索 + 生成」的完整结果，工具需要先在知识库账户中扮演一个权限收窄的 IAM 角色，再调用该 API。

这一约束带来的核心问题是：企业既想对 Redshift Serverless 中的结构化数据生成自然语言答案，又要维持智能体账户与数据账户之间的隔离，并通过专门的跨账户 IAM 角色授予最小权限。

解决方案概览

AWS 提供了两种已正式可用（GA）的编排实现方式，二者共享同一条数据访问路径——由模型控制的工具通过 AWS STS 扮演知识库访问角色，调用 RetrieveAndGenerate，再把生成的答案与引用回传给编排层。区别主要在于「谁来掌控智能体循环」以及「工具如何托管」：

• 变体一：基于代码的 Strands 智能体，部署在 AgentCore Runtime 上。
• 变体二：声明式的 AgentCore Harness，走 AgentCore Gateway 调用 AWS Lambda 工具。

请求流程

整个请求的流转步骤如下：

• 用户通过 Streamlit UI 或 AgentCore API 提交自然语言问题。
• Amazon Nova Pro 决定调用 query_knowledge_base 工具。
• 在变体一中，工具运行在与 AgentCore Runtime 打包在一起的本地 MCP 子进程中；在变体二中，AgentCore Harness 通过 AgentCore Gateway 调用 AWS Lambda。
• 工具通过 AWS STS 扮演知识库账户中的 bedrock_kb_access_role。
• 扮演后的会话以 Claude Haiku 4.5 调用 RetrieveAndGenerate，知识库把问题翻译为针对 Redshift Serverless 的结构化查询。
• 生成的答案经编排路径返回给用户。

选型建议

在选择智能体实现之前，应先判断业务是否真的需要智能体——这有助于让设计与所需行为相匹配：

• 若应用只需检索内容，可直接评估带资源策略的原生跨账户 Retrieve。
• 若每个请求都确定性地需要一个生成式答案，且不需要工具选择、多步推理或会话状态，可让应用或 Lambda 函数直接扮演知识库账户角色并调用 RetrieveAndGenerate。
• 只有当模型需要在更广泛的对话或工具调用工作流中决定「何时、如何」查询知识库时，才应使用智能体。

在两个 AgentCore 变体之间，跨账户需求本身并不偏向其中一方，主要按团队对编排循环的自定义与运维需求取舍：

• 代码版 Strands 智能体：适合需要自定义编排、钩子、中间件、重试、埋点或对工具与流式输出有直接控制权的团队，调用接口为 InvokeAgentRuntime。
• 声明式 AgentCore Harness：适合用例契合托管循环、偏好配置优先生命周期的团队，调用接口为 InvokeHarness。

简单来说，前者强调自定义控制，后者强调托管编排。

前提条件

按博客说明，部署前需准备两个 AWS 账户（智能体账户与知识库账户），并完成相应的 IAM 角色、知识库资源策略以及 Redshift Serverless 配置。具体的部署步骤、IAM 策略模板与示例代码可通过博客附带的 GitHub 仓库获取。