用 CDK 部署含评估与观测的检索 Agent

普通 RAG 遇到跨知识库、需要反复查证的问题，容易给出流畅却不完整的答案。AWS 这篇文章把检索交给 Agent：先判断查哪个库，再决定是否继续查，最后返回带引用的回答，并用 CDK 部署整套系统。

它值得看的地方，是把路由、检索、监控和评估放进同一套工程。但示例只有两个小语料库，没有给出与普通 RAG 的对照成绩。架构可以借鉴，效果提升还需要自己验证。

检索交给 Agent，究竟多了哪一层判断

传统 RAG 通常把问题向量化，检索一次，再生成一次答案。资料集中、问题直接时，作者也认为没有必要增加复杂度。

问题出在检索路径需要临时决定的时候。例如答案横跨两个语料库，或者第一次查完才知道还缺什么。固定流水线缺少继续查证的入口。

这套方案有两层循环。外层 Agent 运行在 Amazon Bedrock AgentCore Runtime，根据问题选择知识库，检查返回内容是否充分，必要时再次调用工具。AgentCore Gateway 把每个知识库暴露成独立的 MCP 工具，调用通过 IAM 任务角色授权，并使用 SigV4 签名。

内层由 Managed Knowledge Base 的 AgenticRetrieveStream 完成：拆解子问题、迭代检索、内部重排，再合成带来源引用的回答。

外层负责选库和补查，内层负责库内检索与回答。

作者使用金融和天气两个库，而非混合索引。这样可以在调用轨迹里直接看到 Agent 选了哪个工具，也能分别观察两个领域的质量指标。单库并非不能用，只是路由选择会更多藏在索引排序里面。

不过，示例展示的是金融问题进金融库、天气问题进天气库。原文没有展示一个复杂问题同时调用两个库的完整结果，不能把架构支持当成效果验证。

托管知识库省掉了什么，又限制了什么

文章对比了 2024 年 8 月的旧方案：当时需要部署 Amazon S3、Amazon OpenSearch Serverless 集合与索引、知识库及数据源，还要手动安排栈的部署顺序。

现在使用 Type: MANAGED，由 Amazon Bedrock 接管摄取、存储、索引和检索，默认使用服务管理的模型完成 embedding 与 reranking。这套设计无需自行配置分块、向量模型和索引，也无需为独立的 OpenSearch Serverless 配置 OCU 容量。

但省去 OCU 不等于整套系统免费。原文没有给出总成本比较。作者还指出，文中的 agentic retrieval 和 AgentCore Gateway 连接器只适用于托管知识库；如果要复用已有向量库，或者满足特定数据驻留、调优及合规要求，Customer-managed 方案仍有价值。

示例数据的规模尤其需要看清：

• 金融库只有一份约 198 KB 的 octank_financial_10K.pdf，是虚构公司 Octank 的模型生成材料，采用 CC0 许可。
• 天气库是一份真实的美国国会研究处龙卷风报告，编号 IF12695，文件 tornadoes_report.pdf 约 560 KB，属于公有领域政府作品。

摄取结果是每库成功索引 1 份文档、失败数为 0。这能证明示例流程跑通，不能证明大规模企业文档的处理能力。两个主题刻意拉开距离，也让路由任务相对容易。

替换数据时，作者要求把文件放到 data/，调整 config.py 的前缀。文件通过 BucketDeployment 上传到 S3，触发摄取的自定义资源只负责摄取，避免一个资源同时承担上传和同步两份工作。

为什么部署和监控要一起写进 CDK

这套应用有 kb、gateway、agent、dashboards 四个栈，跨栈传递 7 个值。Gateway 要知道两个知识库的 ID，Agent 要拿到 Gateway 信息，监控还要引用这些资源。

下面这段代码解决的是依赖传递与部署排序：

kb_stack = KnowledgeBasesStack(app, f"{project}-kb", env=env)

gateway_stack = AgenticGatewayStack(
    app, f"{project}-gateway", env=env,
    financial_kb=kb_stack.financial_kb,  # ← 引用会创建依赖
    weather_kb=kb_stack.weather_kb,
)

agent_stack = AgentRuntimeStack(
    app, f"{project}-agent", env=env,
    gateway=gateway_stack.gateway,
)

DashboardsStack(
    app, f"{project}-dashboards", env=env,
    financial_kb=kb_stack.financial_kb,
    weather_kb=kb_stack.weather_kb,
    gateway=gateway_stack.gateway,
    agent_runtime=agent_stack.agent_runtime,
)

重点看 financial_kb=kb_stack.financial_kb：传递资源引用时，CDK 会推导依赖边，不必再写脚本手动串联输出。执行 cdk deploy --all，即可按依赖部署四个栈。

前提并不少：Node.js 18+、Python 3.13+，通过 npm install -g aws-cdk 安装 CLI，执行 pip install -r requirements.txt，并为账户和区域运行一次 cdk bootstrap。默认推理模型是 us.anthropic.claude-haiku-4-5-20251001-v1:0。容器由 CodeBuild 使用 ARM64 构建，无需本地 Docker，Agent 栈这一阶段约需 8–10 分钟。

默认项目名为 bmkb-obs-cdk，由 PROJECT_NAME 控制；Notebook 也读取同一配置。账户和区域使用 CDK_DEFAULT_ACCOUNT、CDK_DEFAULT_REGION，原文另要求检查 config.py 的 ACCOUNT_REGION，默认 us-west-2，并确认相关服务在目标区域可用。

长任务则使用 CDK Provider 分开启动与轮询，避免让一次 Lambda 调用持续等待：

cr.Provider(
    self, "IngestSyncProvider",
    on_event_handler=on_event,        # StartIngestionJob，返回任务 ID
    is_complete_handler=is_complete,  # GetIngestionJob，报告 IsComplete
    query_interval=Duration.seconds(30),
    total_timeout=Duration.minutes(30),
)

这里要看两个时间参数：每 30 秒查询一次，总预算 30 分钟，绕开单次 Lambda 最长 15 分钟带来的等待限制。

部署还包括两个 CloudWatch 仪表盘，覆盖七层信号：L1 知识库原生指标、L2 摄取、L3 检索质量、L4 Gateway/MCP、L5 OTEL 调用树、L6 token 用量、L7 评估分数，配合 AWS X-Ray 查看调用过程。

部署了仪表盘，不代表已经获得全部质量信号。

原文明确说，L1、L4、L5 自动产生，L3、L6、L7 由驱动 Notebook 发布自定义指标。使用前还要开启 CloudWatch Transaction Search，让跨度数据进入 aws/spans；Notebook 位于 notebooks/01-drive-and-observe.ipynb，需先运行 pip install -r requirements-notebook.txt。

仪表盘用 Metric、GraphWidget、Row 和 TextWidget 编写。代价是 dashboards_stack.py 达到约 400 行；作者认为收益是部分配置错误能在约 1 秒的 cdk synth 阶段暴露，而不是上线后才看到坏图表。

我的判断

我认同它把可观测性放进设计起点。Agent 每次可能走不同路径，只看最终文本，很难判断错在选库、检索还是生成。把知识库拆成独立工具，也让这些问题更容易定位。

但质量论证还不够。作者声称复杂问题回答更好，却没有提供相对单次 RAG 的准确率、延迟和成本对照。两个小文档上的成功演示，支持的是方案可运行。

L3 指标也需要谨慎解释。原文称它无需标准答案、无需额外评判模型，从实际检索与引用中计算，范围为 0–1；但所给内容没有展开计算公式。引用了材料，不等于引用支持结论，更不等于材料本身正确。

文章还宣称支持按需与持续两种评估，涉及忠实度和正确性，但输入在仪表盘代码处截断，没有展示完整机制与结果。这部分只能视为方案描述。

对于资料集中、一次检索就够的应用，普通 RAG 仍是合理起点。已经依赖 AWS、确实需要多库选择和反复查证的团队，才更容易获得这套架构的收益。

能拿来做什么

• 给现有 AI 问答整理一组失败问题，标出哪些需要跨库、哪些需要第二次检索，再决定是否引入 Agent 循环。
• 如果 Node 服务已经调用多个检索接口，可以借鉴独立工具的设计，记录选库、调用次数、耗时和引用来源，先让错误能够定位。
• 复用示例时，换入真实业务文档，并用同一组问题比较普通 RAG 与 Agent 方案的答案完整度、延迟和成本。
• 在前端展示引用时，让用户能够查看对应来源片段；评估分数则留作排查依据，不要直接包装成答案正确率。