一句话结论
亚马逊云科技（AWS）推出代理检索功能，允许通过 LangChain 自动分解复杂查询，显著提升多意图检索覆盖率。
关键要点
- 代理检索采用规划循环机制，将复杂问题拆解为子查询，证据不足时自动触发再次搜索，区别于单次混合搜索。
- 该功能依赖 Boto3 1.43.32 或更高版本，部署区域限定为 us-east-1，且需配置特定的 IAM 权限策略。
- 检索结果不包含类型化分数字段，传统基于分数的排序逻辑失效，需通过事件键分支处理流式返回数据。
- 支持在单次请求中注册最多 5 个知识库，基于自然语言描述进行路由，但单次调用成本与延迟高于标准检索。
- 设置 generateResponse 为 False 可仅获取检索片段，避免额外模型推理费用；设为 True 则返回接地答案与引用。
背景与事实
亚马逊云科技近期在 Amazon Bedrock（亚马逊基础模型服务）托管知识库中推出了代理检索（Agentic Retrieval）功能。该功能通过 LangChain 的 langchain-aws 包实现，核心机制是将用户输入的复杂问题分解为多个子查询。系统在执行检索后，会评估证据是否充足；若证据不足，规划循环将自动触发再次搜索，直至满足条件或达到迭代上限。相比之下，标准检索（Retrieve API）仅执行单次混合搜索并返回评分块，而代理检索（AgenticRetrieveStream API）运行的是流式规划循环，并返回跟踪事件。在基础设施层面，知识库配置以 Amazon S3 作为数据源，由 Bedrock 负责文档的分块、嵌入、存储和检索。由于该功能此前不存在，环境要求明确指定部署区域为 us-east-1，且 Boto3 版本需不低于 1.43.32。
在使用 LangChain 集成时，代理检索并非传统的检索器类，而是由 langchain-aws 包通过独立函数 agentic_retrieve 暴露的功能。这是因为 API 本身是流式且不同步的，无法通过检索器标志开启。对于仅需要检索行为的场景，开发者应将 generateResponse 设置为 False，以避免触发额外的基础模型推理成本。若需同时获取接地答案与引用，需将 generateResponse 设为 True，此选项仅限托管知识库使用。内部流程包含规划、检索及充分性评估三个阶段，助手通常会隐藏计划详情。若需观察分解过程，需调用 bedrock-agent-runtime 客户端的 agentic_retrieve_stream 方法，因为助手会丢弃部分跟踪事件，且未暴露 maxAgentIteration 或自定义规划器模型的接口。
身份认证与权限管理涉及两个层面的角色。服务角色需具备 s3:ListBucket 和 s3:GetObject 权限，并通过条件键限制 aws:ResourceAccount、aws:SourceAccount 和 aws:SourceArn。调用者身份需具备 bedrock:AgenticRetrieveStream、bedrock:InvokeModelWithResponseStream、bedrock:Retrieve 等权限。特别需要注意的是，bedrock:GetDocumentContent 权限在代理检索的 FullDocumentExpansion（全文扩展）步骤中被调用，若缺失该权限，查询将在中途失败。此外，管理知识库还需 bedrock:CreateKnowledgeBase、GetKnowledgeBase 等权限；若使用护栏（Guardrails），则需额外添加 bedrock:GetGuardrail 和 bedrock:ApplyGuardrail 权限。成本结构包括文档存储、摄取、检索调用及基础模型推理费用。
影响分析
对于中文开发者与从业者而言，这项功能改变了处理复杂知识检索的技术范式。过去，面对多意图或探索性问题，开发者需自行构建多路召回与重排序逻辑，或在客户端实现简单的多次检索循环。现在，亚马逊将这一逻辑下沉至服务端，通过代理机制自动处理子查询分解与证据充分性判断。这意味着开发者可以将精力从复杂的检索编排逻辑中解放出来，转而专注于领域特定提示词与业务逻辑。然而，这也带来了新的复杂性：由于结果不包含类型化分数字段，原有的基于分数截断和排序的代码必须重写。开发者需适应流式事件驱动的处理模式，根据事件键（如 Planning、Retrieval、FullDocumentExpansion）分支处理数据，而非期待统一的终端返回对象。此外，成本控制的难度增加，因为代理检索的单次调用成本更高且延迟更大。因此，企业需建立基于查询形状的流量路由机制，使用分类器将大多数简单流量导向低成本的标准检索路径，仅将复杂的长尾流量导向代理检索路径。
适用边界
代理检索适用于多部分、比较或探索性的复杂问题，支持在单次请求中注册最多 5 个知识库。然而，该结论在以下场景不成立：对于短小、范围明确的问题，标准检索器（Retrieve API）在延迟、成本和可控性上均优于代理检索。此外，若开发者需要精细控制生成过程或使用自定义提示词，通常需关闭服务端的 generate_response 功能，此时代理检索的“答案生成”价值部分抵消。代理检索也不适用于需要自托管向量库的场景，因为该功能深度绑定于 Amazon Bedrock 托管知识库架构。若需支持 MASK 模式的护栏，应使用 Retrieve API，因为代理检索目前仅支持 BLOCK 模式。
孤本观察
代理检索将复杂检索的算力成本与逻辑复杂性外包给云服务，换取了开发便捷性，但牺牲了结果排序的可解释性与成本控制粒度。这是云计算“黑盒化”趋势在检索领域的典型体现。