用 AWS CDK 在托管 Amazon Bedrock 知识库上构建智能体检索

普通 RAG 的典型流程是：把问题向量化，从单一索引取回最相近的片段，交给模型生成答案，一次检索对应一次生成。对很多问题这已经够用，但遇到三类情况会失效：答案横跨两个语料库时只能取回一半信息，答案看似流畅却不完整；正确来源取决于问题本身时，单一索引没有选择机制；看到首个结果后需要再查一次语料时，流程里没有第二次检索的位置。

Amazon Bedrock 的托管知识库（Type: MANAGED）把摄取、存储、索引和检索都交给服务管理，默认使用服务托管模型完成嵌入与重排，因此不再需要自行创建、扩展 OpenSearch Serverless 集合与索引，也不必按 OpenSearch Compute Units（OCUs）付费。智能体检索只在托管知识库上提供。

AgenticRetrieveStream API 把多轮规划、检索执行和带引用的答案作为服务能力直接提供，而不是让用户在原始向量检索之上自建编排层。Amazon Bedrock AgentCore 承担智能体部分：Gateway 把每个知识库暴露为 Model Context Protocol（MCP）工具，Runtime 承载推理智能体，AgenticRetrieveStream 在内部完成重排并返回综合后的引用答案。

这套方案以单个 Python AWS CDK 应用交付：智能体在两个知识库之间路由，经 Gateway 检索，返回有依据、带引用的答案，部署顺序由 CDK 推导，一条命令即可完成。与 2024 年那篇基于 CDK 的单次检索方案相比，向量存储不再需要自建，检索变为智能体式，应用所预置的资源中约有一半用于记录智能体的行为。

可观测性与评估

单次流水线可以靠读代码理解，而在循环中推理并检索的智能体对每个问题走的路径都不同，默认情况下既看不到路径，也无法判断答案质量。方案因此预置两个 Amazon CloudWatch 仪表盘，覆盖七层遥测，并在同一次部署中提供按需评估与持续评估两种形式。

编辑部观察

这套方案的价值在于把“智能体检索”和“可观测性”放在同一个部署单元里。对准备从单次 RAG 迁移的团队，值得先确认三点：业务问题是否真的需要跨知识库路由或二次检索；托管知识库的默认嵌入与重排模型是否满足现有评测基线；七层遥测中哪些指标会进入日常告警。原文未给出延迟、成本或准确率的具体数字，迁移前应自行在自有语料上做对比测试。