Amazon Bedrock 推出 AgenticRetrieveStream API：多意图检索不再依赖单次查询
AWS 为 Bedrock 知识库推出 AgenticRetrieveStream API，通过模型驱动的规划循环自动分解多部分问题、迭代检索并生成答案。本文解析其工作原理、与标准 Retrieve API 的对比、定价及 API 调用示例，帮助开发者理解何时以及如何用代理式检索替代传统单次检索。
一句话看懂
AWS 为 Bedrock 知识库推出 AgenticRetrieveStream API，用模型驱动的规划循环替代单次向量检索，自动分解多意图问题并迭代检索，最终生成带引用的答案。
详细发生了什么
传统单次检索在处理多部分、比较性或探索性问题时表现不佳。例如，“对比 2020 年和 2023 年的战略变化”这类问题包含多个子意图，单一 embedding 无法准确表示，导致 top-k 结果混杂或偏向最强信号。
AWS 在 Amazon Bedrock Managed Knowledge Bases 中推出了 AgenticRetrieveStream API。它不再执行一次相似度搜索，而是运行一个由基础模型驱动的规划循环：模型将问题分解为子查询，逐一检索，判断证据是否充分，必要时迭代，最后生成带引用的答案。整个过程以有序的流式 trace 事件返回，包括 SpeculativeRetrieval（预检索）、Planning（规划）、Retrieval（检索）和 Result（结果）等步骤。
关键参数包括 maxAgentIteration（最大迭代次数，单知识库建议 3 次，多知识库 4-5 次）和 foundationModelType（可选择服务托管模型或自定义模型）。定价方面，托管模型每 1000 次调用 $4，外加每 1000 次底层 Retrieve 调用 $1；自定义模型按标准 Bedrock 模型定价加 $1/1000 次 Retrieve 调用。
中文圈视角
对于国内开发者，这个功能目前需要 AWS 账号且可能受限于区域可用性，但思路值得关注。国内云厂商如阿里云（百炼）、华为云（盘古）、百度智能云（千帆）的知识库产品目前仍以单次检索为主，面对复杂查询时往往需要用户自行编写 agent 循环来调用检索 API。
AgenticRetrieveStream 的价值在于将“规划-检索-判断-迭代”这一模式封装为原生 API，降低了多轮检索的工程复杂度。国内用户如果使用类似场景（如企业知识库问答、客服工单分析），可以关注国产平台是否跟进。目前 DeepSeek、Kimi 等模型在长上下文上有优势，但检索增强（RAG）的 agent 化能力仍是空白。
另外，定价方面 $4/1000 次调用对于高频场景成本不低，国内用户可能需要评估性价比。如果数据敏感，还需注意数据出境合规问题。
几条值得记住的细节
- AgenticRetrieveStream API 默认在检索后生成带引用的答案，设置 generateResponse=False 可只返回检索结果。
- 支持多知识库场景，每个 chunk 会标记 sourceRetriever 来源。
- 最终结果会去重，但 trace 事件保留每一步的原始检索记录。
- 预检索（SpeculativeRetrieval）不占用 maxAgentIteration 次数，用于降低首轮延迟。
- 当模型判断片段上下文不足时，可触发 FullDocumentExpansion 获取完整文档。
一句话总结
如果你正在用 Bedrock 知识库处理复杂查询，AgenticRetrieveStream 能省去手写 agent 循环的麻烦，但需要评估成本和对国内平台的适用性。