检索增强生成在过去两年走过了一条从「加个检索」到「检索就是 Agent 的工具」的路径。大多数团队最早接触 RAG 都是从 LangChain 的RetrievalQA或者 LlamaIndex 的VectorStoreIndex开始用户提问、向量检索 Top-K、拼进 Prompt、生成回答。这个流水线简单可靠但它在生产中的表现有个隐藏前提——检索策略必须事先猜对。猜对了答案质量很高猜错了要么注入一堆无关 chunk 把正确信号淹没要么只拿到片面信息导致模型胡编。更麻烦的是一个阅读助手可能要同时处理「今天天气怎么样」和「A 方案在 Q3 的营收影响 vs B 方案在 Q4 的折旧成本差异」两种 query前者根本不需要检索就能答后者一次检索根本不够。流水线 RAG 的固有问题不在检索本身团队在优化 RAG 时通常优先调 chunk 大小、embedding 模型或 Top-K 数量。这些都是有效动作但它们解决的是「同样检索策略下如何更好」的问题而不是「不同 query 需要不同检索策略」的问题。流水线的本质是固定的无论用户问什么都走同一套分块→召回→排序→拼接流程。这个模式在一个知识库内文档结构相对统一、用户 query 复杂度差异不大的场景下完全够用。但如果你的知识库里既有简短的操作手册也有长篇技术规格文档用户既有「密码重置步骤」这种简单查找也有「对比 2024 和 2025 的 SLA 条款差异」这种需要跨文档推理的问题——固定流水线的短板就暴露了。简单 query 被塞进来大量无关 chunk不仅浪费 token还增加了模型被错误上下文误导的概率复杂 query 又因为一次检索召回的信息不够全面需要多轮追问才能补全。让 Agent 决定要不要检索、检索什么解决思路不是把检索做得更「聪明」而是把检索本身变成一个工具让 Agent 在推理过程中按需调用。这个模式在 2025 年底到 2026 年迅速成为工程主流LangGraph、LlamaIndex 和 Anthropic 的 Tool Use 都原生支持这种模式。核心变化只有一条检索不再是 Prompt 拼接的前置步骤而是 Agent 可以调用也可以不调用的一个工具。这条变化带来的工程影响比看起来大得多。当检索变成工具后Agent 可以决定不检索——如果 query 是常识性问题或者 Agent 已经在上下文中有足够信息直接回答即可节省 token 和延迟。自己构造检索 query——不再 rely 于用户原始 query 的 embedding 相似度。Agent 可以把「对比 2024 和 2025 的 SLA 差异」分解为两条精确的检索 query「2024 年 SLA 条款」「2025 年 SLA 条款」分别检索再合并。多次检索——第一次检索的结果可能暴露新的关键词或实体Agent 可以据此执行二次检索逐步收窄信息范围。选择不同检索源——一个 agent 可以同时接入向量库、搜索引擎、关系数据库甚至内部 API根据问题类型动态选择。这个能力的直接影响是RAG 系统的召回质量上限不再由 embedding 相似度决定而是由 Agent 的决策质量决定。这很反直觉但仔细想想就明白了——embedding 只能在已有 query 的词向量空间里找近邻Agent 可以改写 query、拆解 query、甚至主动决定换一个搜索策略。三种主流模式与各自的落地场景把检索做成 Agent 工具之后实践中逐渐形成了三种可复用的工程模式。模式一条件检索门Retrieval Gate这是最简单的模式也是大多数团队应该最先尝试的。Agent 拿到用户 query 后先判断自己现有的上下文是否足够回答问题。判断标准通常包括query 是否涉及时效性信息、是否需要知识库中的具体数据、Agent 是否对自己的答案有信心。实现上就是在 Agent 的 tool list 里加一个should_retrieve(query) - bool的轻量步骤这个步骤本身可以是一个小模型调用也可以是一个规则引擎。条件检索门能直接过滤掉 20-40% 的不必要检索调用具体数据看业务场景。这个模式适合用户 query 混合了常识问答和专业知识查询的系统比如企业内部帮助台。模式二动态查询构造Dynamic Query Construction在条件检索门判断「需要检索」之后让 Agent 自己构造检索用的 query而不是直接拿用户原始问题去向量搜索。这看起来多了一步推理开销但在复杂查询场景下召回率提升非常明显。实际的实现方式是把检索工具的参数定义为{query: string}Agent 在调用时自己填充这个 query。重要的是Agent 可以构造多条 query 并行检索然后把结果合并去做下一步推理。LangGraph 的实现示例大致是这样Agent 节点在判断需要检索后生成多个检索 query通过 parallel tool call 一次性发出所有检索请求所有结果返回后再进入下一个推理步骤。这个模式适合用户问题往往涉及实体、产品名、版本号等精确关键词的 RAG 系统或者需要跨文档对比的场景。模式三多步检索与信息整合Multi-Step Retrieval最复杂的模式但也是召回质量上限最高的模式。Agent 不满足于一次检索而是在每轮推理中判断是否还需要更多信息如果不够就发起新一轮检索。多步检索的关键约束不是模型能力而是成本预算。每一轮检索意味着一次向量查询加一次模型推理如果控制不当一个复杂问题可能触发 5-6 轮检索延迟和 token 消耗都会失控。生产实践中常用的约束手段包括最大检索轮次硬限制一般是 2-3 轮第二轮只检索第一轮结果中高频出现但未被回答的关键词每轮检索后评估信息完整性如果 Agent 判断「已足够回答」则提前终止这个模式适合知识库规模大、文档之间关联性强、用户问题通常是多跳推理的场景比如法律条款分析、合规审查、技术文档的综合查询。工程落地时容易踩的三个坑把检索做成 Agent 工具不是只有好处几个常见的工程问题值得提前规划。第一个坑是延迟膨胀。流水线 RAG 的延迟是可预测的一次检索 一次生成。Agentic RAG 的延迟则取决于 Agent 的决策路径。条件检索门可以过滤掉简单 query 的检索开销但复杂 query 的延迟可能比流水线模式高出 2-3 倍。如果系统对首 token 时间有要求需要引入超时兜底超过 N 秒后直接走一次快速检索并生成放弃多步优化。第二个坑是成本不可控。Agent 每多一次检索调用就多一次推理和向量查询。生产部署时必须给每个 query 设定 token 预算上限超出后强制 fallback 到单次检索模式。OpenAI 和 Anthropic 的 API 如今都支持 max_tokens 参数限制单次请求但多轮调用的总 token 消耗需要应用层自行累计和限流。第三个坑是检索结果的质量反馈缺失。流水线模式下检索结果直接进入上下文好坏都在一次生成中体现。Agent 模式下Agent 可能在第一轮拿到差结果后花一轮推理发现「不对信息不够」然后再发起第二轮。这意味着差检索不仅浪费了第一轮检索的成本还浪费了一轮模型推理。一个实用的补救是在检索工具中注入结果质量的元信息——比如返回结果的 relevance score 或检索命中的文档数——让 Agent 更早判断本次检索是否有效。静态流水线何时还是更好的选择Agentic RAG 不是万能的。如果你的场景满足以下条件固定流水线依然是更合理的工程选择用户 query 类型高度统一复杂度差异不大知识库文档结构和粒度均匀系统对 p99 延迟要求极严 500ms单次检索的召回率已经能满足 90% 的问题在这些约束下Agent 的「决策开销」是纯浪费。一个固定的检索流水线再加一个 reranker能给出足够好的结果且延迟和成本都可预测。但如果你遇到的是另一种情况——知识库内容多样、用户问题类型不可枚举、检索质量直接影响产品体验——把检索变成 Agent 的工具带来的不是锦上添花的升级而是从「猜对检索策略才能用」到「让模型自己定策略」的架构切换。这个切换的成本不低Agent 编排框架的选择、延迟预算的管理、成本的可见性但它解决的问题也是流水线模式永远无法绕过的固有限制。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。