使用 AWS CloudFormation 构建可观测的企业级 AI 智能体检索系统

将检索增强生成（RAG）添加到基础模型通常从针对单一知识库的单个检索步骤开始。这种方式在问题变得复杂、答案跨越多个来源，或者系统需要在响应前决定查阅哪个来源时，就会遇到瓶颈。

企业级 AI 智能体检索解决了这个问题：一个 AI 智能体对问题进行推理，将其路由到正确的知识库，迭代检索，并返回带有引用的答案。但这引入了一个更难解决的运维问题。一旦 AI 智能体在循环中进行推理和检索，你就再也无法看到它做了什么，或者答案是否正确。

之前的文章《使用 Amazon Bedrock Knowledge Bases 和 AWS CloudFormation 构建端到端 RAG 解决方案》展示了如何通过自管理（向量存储）Knowledge Base 实现单次 RAG 工作流自动化。Amazon Bedrock Knowledge Bases 已从 RAG 演进到 AI 智能体检索，支持托管知识库。托管知识库的 AI 智能体检索执行多轮规划、执行检索工具，并生成带有引用的 grounded 答案。

本文迈出下一步：构建一个企业级 AI 智能体检索解决方案，其中 AI 智能体跨多个知识库进行推理和检索，并综合生成带引用的答案。该方案基于 Amazon Bedrock Managed Knowledge Base 和 Amazon Bedrock AgentCore，从一开始就内置了可观测性和评估能力。你可以通过一条 AWS CloudFormation 链一键部署全部组件。

图 1：从 Amazon S3 中的合成语料库，经过两个托管知识库、AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）和运行时 AI 智能体，到七层可观测性和评估的端到端架构，全部由 AWS CloudFormation 部署

架构图中的编号步骤对应解决方案的工作流程，具体如下：

1. 用户向托管在 Amazon Bedrock AgentCore 运行时上的 AI 智能体发送问题。运行时在每一步自动注入 OpenTelemetry span，因此 reason-and-act 循环从第一次调用起就是可观测的。

2. AI 智能体的推理模型规划任务并执行跨知识库路由：每个知识库对应一个检索工具，它选择主题与问题匹配的工具（金融或天气）。

3. 选定的工具调用通过 Amazon Bedrock AgentCore Gateway 使用 Model Context Protocol（MCP）进行代理，调用该知识库上的 AgenticRetrieveStream API。

4. AgenticRetrieveStream 完成知识库内的工作：将问题分解为子查询，从托管数据存储（从 Amazon Simple Storage Service（Amazon S3）中的语料库摄取）中迭代检索，并综合生成一个 grounded、带引用的答案，通过 Gateway 流式返回给 AI 智能体。

5. AI 智能体检查返回的上下文是否充分。如果不充分，它会在另一轮循环中再次检索，然后再组合最终答案。如果充分，则将带引用的答案返回给用户。

在此过程中，运行时向 Amazon CloudWatch 和 AWS X-Ray 发出 span、token 使用量和指标，填充七层可观测性，并同时驱动按需评估和持续评估分数。

在开始讲解之前，有必要先明确三个要点：是什么让 RAG 变得 AI 智能体化、为什么托管 Knowledge Base 是正确的基石，以及为什么可观测性和评估应该内置于设计中，而不是事后补救。

从 RAG 到企业级 AI 智能体检索

经典 RAG 执行一次检索和一次生成。企业级 AI 智能体检索在循环中引入了一个推理 AI 智能体：它决定是否检索以及检索什么，可以多次检索以优化结果，选择哪个知识库相关（语义路由），然后才组合一个带引用的 grounded 答案。这正是 Amazon Bedrock Managed Knowledge Base 现在通过其 AgenticRetrieveStream API 提供的一流能力。检索不再是单次查找，而是一个由 AI 智能体驱动的多步骤过程。这在复杂问题上能产生更好的答案。但同时也产生了一个更复杂的系统来运维，这就是为什么本文从一开始就内置了可观测性和评估。

托管知识库与自建知识库的对比

Amazon Bedrock 现在提供托管知识库（Type: MANAGED）：Amazon Bedrock 为你管理摄取、存储、索引和检索，包括默认使用服务托管模型的 embedding 和重排（reranking），因此无需配置、扩展或修补向量数据库。

下表展示了 Amazon Bedrock 托管知识库与客户自建知识库的区别：

为什么需要可观测性和评估

一个只"返回一个答案"的 AI 智能体系统对于生产环境是不够的。你需要了解它的行为（延迟、调用量、token 使用量）、检索和答案的质量，而且需要持续获取这些信号。本解决方案附带两个 CloudWatch 仪表板，覆盖七层遥测，加上两种形式的评估（按需和持续），全部由同一套模板配置。

II. 解决方案概述

该解决方案部署为四个原生 AWS CloudFormation 栈，每个栈的输出连接到下一个栈。

01-knowledge-bases 创建一个 Amazon Simple Storage Service（Amazon S3）存储桶、两个托管知识库（金融和天气语料库，让 AI 智能体有可路由的对象）、它们的数据源和 IAM，以及一个摄取自定义资源，负责上传文档并运行首次同步。

02-agentic-gateway 搭建一个 Amazon Bedrock AgentCore Gateway（AWS_IAM 认证、MCP），每个知识库有一个基于原生 bedrock-knowledge-bases 连接器的目标，使每个知识库暴露自己的 AgenticRetrieveStream 工具，无需 AWS Lambda 函数或额外容器。

03-agent-runtime 配置一个 Amazon Elastic Container Registry（Amazon ECR）仓库和一个 AWS CodeBuild 项目，构建一个带有 OpenTelemetry 检测的 Strands AI 智能体镜像、托管它的 Amazon Bedrock AgentCore 运行时、日志和追踪传递接线，以及在线评估配置。

04-dashboards 创建两个 Amazon CloudWatch 仪表板。

路由发生在两个层面，有必要将其区分开来。AI 智能体的推理模型执行跨知识库路由。每个知识库对应一个检索工具，加上一个系统提示让它选择与问题主题匹配的工具，它决定查阅哪个知识库。然后 AgenticRetrieveStream API 执行知识库内的工作，将问题分解为子查询、迭代检索并综合生成带引用的答案。因此 AI 智能体运行一个 reason-and-act 循环。它发起一个大语言模型（LLM）调用，决定调用哪个知识库工具，通过 Gateway 读取返回结果，在组合最终带引用的答案之前通常会再次检索。每一步都由运行时自动检测，因此七层可观测性从真实流量中填充数据。

七层，每层回答一个不同的运维问题，共同覆盖 AI 智能体端到端。第 1、4、5 层自动发出。第 3、6、7 层由驱动 notebook 作为自定义指标发布。

本解决方案中的每一个选择都源于"可运维的企业级 AI 智能体检索"这一目标。托管 Knowledge Base 是基石，因为 AI 智能体检索和 AgentCore Gateway 连接器仅在托管版上可用。它还免去了你原本需要配置、扩展和修补的向量数据库。AgentCore Gateway 将每个知识库的 AgenticRetrieveStream 暴露为 MCP 工具，因此 AI 智能体每个知识库获得一个工具，无需 Lambda 或额外容器来维护。AgentCore 运行时托管 AI 智能体并自动发出 OpenTelemetry span，这正是第 5 至 7 层无需额外接线就能实现的原因。CloudFormation 将它们绑定成一条可重复的链，因此整个系统，包括仪表板和持续评估，每次都以相同的方式启动。

III. 数据集说明

该解决方案附带两个小型合成语料库，打包在仓库的 data/ 目录下：

• 金融：一个合成的 Octank Financial 10-K（octank_financial_10K.pdf，约 198 KB）。

• 天气：一份真实的、公开可用的美国国会研究服务报告，关于龙卷风（IF12695，tornadoes_report.pdf，约 560 KB）。

这两个语料库刻意设计为截然不同，因此 AI 智能体必须将每个问题路由到正确的知识库——这就是语义路由的核心场景。我们有意使用两个独立知识库，而不是一个知识库加两个数据源。每个知识库暴露为自己的检索工具，因此 AI 智能体在它们之间做出真实的路由决策。仪表板上每个知识库的信号（索引大小、检索质量、token 使用量和评估分数，均以 KnowledgeBaseId 为键）保持清晰可分离。

IV. 部署解决方案

部署解决方案只需一条命令，但了解该命令需要什么以及它会产生什么会很有帮助。本节涵盖前置条件、单一部署脚本，以及如何确认每个栈都已成功创建。

需要具备以下条件：一个拥有 Amazon Bedrock、Amazon Bedrock AgentCore 运行时和 Amazon Bedrock AgentCore Gateway、AWS Identity and Access Management (IAM)、Amazon CloudWatch、AWS X-Ray、Amazon ECR、AWS CodeBuild、Amazon Simple Storage Service (Amazon S3)、AWS Lambda 和 AWS CloudFormation 权限的 AWS 账户。还需要为智能体的模型启用 Amazon Bedrock 模型访问。

账户中可用的智能体模型（默认 us.anthropic.claude-haiku-4-5-20251001-v1:0）。参阅 Amazon Bedrock 中的支持的基础模型。

启用 CloudWatch Transaction Search，使 OpenTelemetry spans 落入 aws/spans，用于第 5–7 层。参阅 CloudWatch Transaction Search。

AWS Command Line Interface (AWS CLI) v2。Python 3.13，boto3>=1.43（用于 notebook）。无需本地 Docker（智能体镜像由 CodeBuild 构建）。参阅安装 AWS CLI 和 Boto3 文档。

前置步骤完成后，即可开始设置解决方案：

克隆包含解决方案文件的 GitHub 仓库：

git clone https://github.com/aws-samples/amazon-bedrock-samples.git

进入解决方案目录：

cd rag/managed-knowledge-bases/07-IaaC/managed-kb-observability-cfn/

运行 sh 脚本，它将创建部署存储桶、准备 CloudFormation 模板，并将就绪的 CloudFormation 模板和所需制品上传到部署存储桶：

./scripts/deploy.sh us-west-2 bmkb-ml21427

该脚本按顺序部署四个栈，并报告每个阶段，将输出向前传递，同时打印实时验证行，以便观察解决方案的启动过程：

图 3：部署脚本报告每个阶段，两个知识库已激活并已摄取，网关和目标就绪，启用持续评估的智能体运行时就绪，以及两个仪表板，随后打印仪表板 URL

Stack 03-agent-runtime 使用 CodeBuild 构建智能体容器，因此该阶段大约需要 8–10 分钟。

完成后，四个栈均为 CREATE_COMPLETE：

图 4：四个栈（knowledge-bases、gateway、agent、dashboards）全部达到 CREATE_COMPLETE

部署只是故事的一半。随后需要通过智能体驱动流量，以查看路由并点亮仪表板。这些分步说明位于示例的 README（"启动和测试 — 驱动流量并观察"）中，指导你完成配套 notebook。它发送按知识库区分的提示，展示每个问题如何路由到正确的知识库，并发布第 3、6 和 7 层指标。参阅 07-IaaC/managed-kb-observability-cfn/README.md。

VI. 观察：七层仪表板

两个仪表板是七层变得可见的地方。栈创建了这两个仪表板，驱动流量后它们就会被填充。

图 5：栈配置的两个仪表板，端到端智能体可观测性和按知识库的可观测性

仪表板 A，智能体可观测性（端到端）。该面板首先解释每层如何计数不同的事物。对于 N 个查询，你会看到大约 N 次智能体调用、2N 次检索、3N 次 LLM 调用和 5N 次网关 MCP 操作——智能体循环变得可见。随后展示知识库指标（L1）、网关指标和延迟（L4）、token 使用量（L6）以及无参考的第 3 层质量信号，并在每个知识库内联定义和绘图。第 3 层信号之所以无参考，是因为智能体使用 AgenticRetrieveStream，它返回综合的、带引用的答案，而不是按块分数。

图 6：仪表板 A 显示第 3 层说明器，位于两个按知识库的检索质量小部件之上，以及并排的网关延迟和 token 使用量

仪表板 B，按知识库（BMKB）可观测性。决定支出的运营信号，按知识库细分：索引大小（来自 Amazon S3 源字节）、检索量、智能体工具调用、会话 token 使用量，以及按模型的生成 token 使用量，每个都有内联说明。

图 7：按知识库可观测性仪表板已填充索引大小、检索调用、智能体工具调用、token 使用量和按模型的生成量

VII. 评估：按需和持续

质量有两种衡量方式，两者均由栈配置。

按需评估。驱动 notebook 调用 AgentCore Evaluate（LLM 即裁判）来对每个会话的 spans 进行内置评估器（正确性、忠实度、工具选择准确性）评分，并将分数发布到 CloudWatch，在那里它们显示为仪表板 A 上的第 7 层。

图 8：仪表板 A 上的第 7 层，按知识库的按需评估分数（正确性），第 5 层 OpenTelemetry span 表携带 gen_ai.usage token

持续（在线）评估。Stack 03-agent-runtime 还配置了 AWS::BedrockAgentCore::OnlineEvaluationConfig，对实时会话进行采样并自动评分。结果显示在控制台 CloudWatch、GenAI Observability、Bedrock AgentCore、Evaluations 下，无需运行 notebook。配置视图列出了评估器及其各自的评分结果数量：

图 9：bmkb_ml21427_online_eval 配置使用四个内置评估器（工具选择准确性、忠实度、正确性、响应相关性）对实时会话进行评分，零错误

深入查看可以看到这些评估器的平均分数和按 trace 细分的详情：

图 10：来自同一配置的持续分数，忠实度 0.95、正确性 0.9、响应相关性 1.0 和工具选择准确性 1.0，并附有按 span 的评估详情

⚠️ 采样和成本。该解决方案将 SamplingPercentage 设置为 100 完全是为了博客实验，因此每个会话都会被评分，结果立即可见。这不是生产环境建议。在线评估对每个采样的会话调用 LLM 即裁判，因此成本随采样率和流量规模而增加。对于实际部署，选择适合你质量监控需求和预算的采样百分比，并在启用之前根据组织自身的策略和成本治理要求对齐配置。该比率是 templates/03-agent-runtime.yaml 中的单个属性（OnlineEvaluationConfig.Rule.SamplingConfig.SamplingPercentage）。

何时使用哪种评估。按需评估适合开发和预发布检查。当你想按需获取质量读数时，你可以有针对性地对选定的一组会话运行它，并且只在运行时付费。持续（在线）评估适合生产监控。它对实时流量进行采样并自动评分，因此质量回归会在无人启动作业的情况下浮出水面，但成本随采样率增加。常见模式是在迭代期间依赖按需评估，然后在智能体开始服务真实用户后以适中的采样百分比启用持续评估。

使用一条命令按相反顺序删除所有内容：

./scripts/cleanup.sh us-west-2 bmkb-ml21427

图 11：清理脚本按相反依赖顺序删除四个栈

我们基于托管 Amazon Bedrock Knowledge Base 和 AgentCore 构建了一个完整的智能体检索解决方案（多知识库语义路由、推理智能体、七层可观测性，以及按需和持续评估），并使用单一 AWS CloudFormation 链部署了所有内容。使用托管知识库完全消除了向量存储基础设施，并添加了智能体检索和 AgentCore Gateway 连接器，这是客户管理的知识库所不具备的。

这种模式适用于正确答案存在于多个地方、系统需要选择去哪里查找的工作负载。例子包括：在产品文档知识库和计费知识库之间路由的支持助手、跨越独立监管和科学语料库的研究助手，或者将 HR、IT 和财务内容隔离在独立知识库中以实现访问和成本分离的内部帮助台。在每个案例中，AI 智能体跨知识库路由，上下文工程在一个知识库内完成多步骤工作，七层结构则展示其运行状况和成本。

从这里开始，你可以将数据源指向你自己的语料库，将 AI 智能体放置在虚拟私有云（VPC）中，根据你的预算和政策调整在线评估采样率，或向路由器添加更多知识库。模板、驱动 notebook 和自包含工具都在附带的代码仓库中。