AWS发布CDK方案：在托管版Bedrock知识库上搭建Agentic检索并内置可观测性
AWS机器学习博客介绍一套Python CDK应用，用四个栈把两个托管知识库、AgentCore Gateway与运行时Agent组装成可路由、可引用来源的检索系统，并附带两块CloudWatch仪表盘与按需、持续两类评估。
AI解读：AWS博客作者Prabhakar Chandrasekaran发布一套用AWS CDK（Python）部署的企业Agentic检索方案，让推理Agent经AgentCore Gateway在两个托管Bedrock知识库之间选择并多次检索，最后返回带引用的答案。
方案依赖Managed Knowledge Base（Type: MANAGED）：由Bedrock负责解析、分块、嵌入、索引与检索，不再需要自建OpenSearch Serverless集合，也无需按OCU付费。AgenticRetrieveStream和AgentCore Gateway集成仅在托管知识库上支持，客户自管知识库不支持这两项。
两个知识库分别装载金融与天气语料，各作为一个MCP工具暴露，目的是让Agent的路由决策在span树中可见，并让检索质量指标按知识库分开统计。金融语料为模型生成的虚构Octank 10-K样本，天气语料是真实的美国国会研究服务局报告。
整个方案由四个CDK栈组成：知识库栈、Gateway栈、Agent运行时栈和仪表盘栈，作者称七项跨栈参数由CDK构造引用自动生成依赖顺序，一条cdk deploy --all完成部署。
可观测性覆盖作者划分的七个层次，其中知识库原生指标、Gateway/MCP指标和OTEL span树自动发出，检索质量、token用量和评估分数由驱动notebook以自定义指标发布。评估分按需与持续两种，持续评估默认采样率 100%。
来源未给出该方案在真实业务数据上的效果数据；作者给出的运行预期是Agent镜像构建约 8 至 10 分钟，仪表盘在产生流量前为空。
AWS机器学习博客发布一篇教程，介绍如何用AWS CDK（Python）在托管版Amazon Bedrock Knowledge Base上部署企业级Agentic检索系统。作者Prabhakar Chandrasekaran称，整套方案以一条cdk deploy --all命令部署四个栈，Agent通过AgentCore Gateway在两个知识库之间路由并返回带引用的答案。
方案做了什么
系统的路径是：用户问题进入运行在Amazon Bedrock AgentCore Runtime上的推理Agent，Agent判断是否需要检索、选择金融或天气知识库对应的工具，经AgentCore Gateway以MCP协议调用该知识库的AgenticRetrieveStream API；该API将问题拆成子查询、迭代检索并合成带引用的答案。Agent若判断返回的上下文不足，会再次路由检索，然后才给出最终回答。
两个知识库都从Amazon S3语料经Bedrock托管摄取构建。作者解释，把两个语料拆成两个具名工具而非合并进一个索引，是为了让路由成为可观察的推理动作，并让检索质量指标按领域分别统计；合并后路由会隐入单一索引的排序，质量信号变成两个无关领域的平均值。
- 金融语料是合成的Octank Financial 10-K样本（约 198 KB，CC0授权），Octank为虚构公司，不是真实财务数据。
- 天气语料为美国国会研究服务局关于龙卷风的公开报告IF12695（约 560 KB），属美国政府作品。
- Agent默认推理模型为Claude Haiku 4.5（MODEL_ID默认us.anthropic.claude-haiku-4-5-20251001-v1:0）。
托管与自管的边界
文章以对比表说明，托管知识库支持AgenticRetrieveStream和AgentCore Gateway集成，数据存储由Bedrock自动伸缩，嵌入与重排使用内置托管模型且不额外收费；客户自管（DIY）知识库不支持上述两项能力，向量库需自行部署、伸缩和维护，嵌入与重排也需自行配置。作者称，当需要复用已有OpenSearch Serverless集合，或满足特定数据驻留、调优、合规要求时，自管仍是合适选择。
因此，这套教程描述的能力范围限于托管知识库；来源没有说明非托管知识库是否会在后续获得同等支持。
- 方案中不再创建OpenSearch Serverless集合或预留OCU容量。
- 摄取时Bedrock自动完成解析、分块、嵌入与索引；作者展示的结果是每个知识库各索引一份文档、零失败。
四个栈与可观测性
CDK应用声明四个栈：知识库栈创建S3桶、上传语料、两个托管知识库、数据源与IAM；Gateway栈创建使用AWS_IAM鉴权的MCP Gateway及每个知识库的AgenticRetrieveStream目标；Agent栈通过ECR、CodeBuild构建并部署带插桩的Strands Agent到Runtime；仪表盘栈创建agentic-observability与kb-observability两块CloudWatch仪表盘。作者称，四个栈之间共有七个值跨栈传递，代码中通过构造引用传递，依赖顺序与导出由CDK推导，取代手写导出与部署脚本。
可观测性按作者划分的七层组织：L1知识库原生指标、L2摄取、L3 Agentic检索质量、L4 Gateway/MCP指标、L5 OTEL span树、L6 token用量、L7评估分数。其中L1、L4、L5自动发出，L3、L6、L7由驱动notebook作为自定义指标发布。评估提供按需和持续两种形式，均由同一次部署创建。
- 运行时可自动用OpenTelemetry为Agent的推理与调用循环生成span，并将span、token数和指标发送至CloudWatch与AWS X-Ray。
- 仪表盘在未产生流量前为空。
- 作者称Agent镜像由CodeBuild构建（ARM64），约需 8 至 10 分钟，无需本地Docker。
部署前提
文章列出的前提包括：具备Bedrock、AgentCore（Runtime与Gateway）、IAM、CloudWatch、X-Ray、ECR、CodeBuild、S3、Lambda和CloudFormation权限的AWS账号；账号中可用的Agent模型；启用CloudWatch Transaction Search以便OTEL span进入aws/spans；Node.js 18+与CDK CLI、Python 3.13+；账号与区域完成一次cdk bootstrap。
所有可调参数集中在config.py，包括项目名前缀、区域、嵌入模型类型（MANAGED或CUSTOM）、Agent模型ID和在线评估采样率。作者称修改PROJECT_NAME可在同一账号内部署一套独立命名的副本。