要点
- 托管知识库（Type: MANAGED）自管摄取、存储、索引与检索——无需自运维 OpenSearch Serverless/OCU——并解锁 AgenticRetrieveStream 与 AgentCore Gateway 的 MCP 工具。
- 经典单次 RAG 在答案跨语料、路由依赖问题本身、或需要二次检索时失败；智能体在撰写带引用答案前决定是否/哪个/再查一次。
- CDK 应用的主张：四个密集交叉引用的栈；它配出的大约一半资源，是为了让你看见路径并打 faithfulness 分——而不只是返回流畅文本。
多数 RAG 系统嵌入问题、从一个索引取最近块、生成一次。这种设计以可识别方式失败：答案跨两份语料时返回流畅却半完成；正确来源取决于问题本身；二次检索无处发生。
AWS 用 CDK 走读托管 Amazon Bedrock Knowledge Base 上的企业智能体检索，称产品变化大于「托管向量」。检索变成智能体能力——多轮规划、工具驱动检索、带依据的引用——以 AgenticRetrieveStream 暴露，而不是自建编排。
[1]相对 2024 年 8 月单次 CDK 文，有三处变化：托管知识库去掉 OpenSearch Serverless 集合与 OCU 账单；Amazon Bedrock AgentCore 提供把各知识库暴露为 MCP 工具的 Gateway，以及承载推理智能体的 Runtime；可观测与评估在同一次部署里配齐——两套覆盖七层遥测的 CloudWatch 仪表盘，外加按需与持续评估。
智能体检索与 Gateway 集成仅在托管知识库上可用。客户自管 DIY 存储仍适合驻留、调参或复用约束——但拿不到这套智能体 API 面。示例跨两个知识库路由，经 Gateway 检索并返回带引用答案，由 CDK 从 construct 连线推导栈顺序。
[1]架构证据就是依赖图本身。Gateway 需要两个知识库 ID；智能体需要 Gateway URL 与 ARN；仪表盘需要 KB ID、Gateway ARN 与 agent runtime ID——七个值跨四个栈。用原始模板就要手维导出与部署脚本；在 CDK 里传入 construct 即推导边。
运维上文章很直白：单次流水线是可读的函数；在循环里检索的智能体每题走不同路径。没有埋点，你既看不见路径，也无法判断答案是否忠实。引用与 faithfulness/correctness 分数被写成负责任使用要求，不是抛光。
[1]强反对意见是：托管便利换控制权——已有 OpenSearch 机群、自定义嵌入/重排管线或严格数据面要求的团队可能正确留在 DIY，那时智能体检索根本不在菜单上。另一反驳：许多负载上 AgenticRetrieveStream 的内部规划已够用，不必上完整 AgentCore Runtime + 双知识库 CDK 大教堂。
同样薄弱的是：相对经典 RAG 的独立时延/成本、智能体过度检索频率、评估指标标定，以及多账户/多 Region 现实。这是带清晰论点的参考架构随笔，不是评测赛。
[1]对平台团队，分叉是：若需要作为服务特性的智能体多库检索，托管是闸门；若必须自运维向量库，就放弃该 API。一旦选托管，应假定一半工程预算给仪表盘、链路与评估环——否则你会交付一台无法审计的流畅生成器。
此处 CDK 的价值很具体：密集跨栈引用让脆弱的 CloudFormation 导出成为可靠性风险，而不是风格偏好。
[1]要看 AgenticRetrieveStream 是否成为 Bedrock 上企业 RAG 默认路径，以及客户是否公布这些预置评估的 faithfulness 分数。若可观测性仍可选，智能体 RAG 会重演旧 RAG 失败模式——自信答案配看不见的检索路径。若它在 CDK 里保持一等公民，「托管」将意味着可运营，而不仅是代管。
[1]