传统 RAG 的检索是固定管道：问题进来，Top-K 召回，塞进上下文，生成答案——检索参数写死，模型被动接结果。Agentic Search 把检索升级成模型自主决策的工具调用：要不要查、怎么查、查几次、证据够不够，全部由模型在运行时决定。本文拆它的六个关键机制和一个真实开源项目里的双系统实现。
本质：ReAct 范式在检索场景的落地
工作流是一个闭环：接收问题 → 规划（判断直接回答、单次检索还是多轮拆解）→ 执行检索 → 观察评分（结果相关吗、够吗）→ 决策（够则生成，不够则改写查询或拆子问题再检索）→ 生成加可选的忠实性二次验证。它解决的核心矛盾是 Top-K 的两难：取小了漏信息，取大了塞爆上下文——每次只取少量高相关内容，靠多轮按需补全。
六个机制一张表
| 机制 | 作用 | 解决什么 |
|---|---|---|
| 查询规划/分解 | 复杂问题拆成子查询 | 答案分散在多处 |
| 工具调用 | 检索器封装成 tool 主动调用 | 从被动接变主动取 |
| 反思/评分 | 给检索结果打分：相关？充分？ | 过滤噪声、判断是否再查 |
| 查询改写 | 按已有结果优化下一轮 | 后续召回质量 |
| 停止条件 | 最大轮数/置信阈值/token 预算 | 防死循环、控成本 |
| 状态管理 | 记录已查片段与中间结论 | 防重复检索、支持多跳 |
一个开源项目的双系统实现
RAGflow 项目里 Agentic Search 其实是两套相关但独立的系统，这个区分很有教学价值：
Canvas 工具侧：AgenticSearchTool 提供三种检索模式（混合、向量、BM25），注册进工具表供 Agent 节点调用。实现要点有三处值得借鉴：按模式设置相似度权重（混合 0.3、向量 1.0、BM25 0.0）；调用底层检索时强制关闭稠密回退、排除编译结果，并通过数据集 ID 交集做知识库权限过滤——权限在检索层收口，不靠 Agent 自觉；关键词句子级裁剪压缩返回内容，控制上下文占用。
Chat 管道侧：对话的 Agentic 模式是一轮完整的 ReAct 循环，带 15 分钟超时和 50 万 token 预算，维护证据注册表跟踪"哪条证据支持哪句结论"，工具集包括语义检索、BM25 检索、关键词定位、图谱探索等。默认模板在配置文件里定义，超时和预算是硬上限——反思循环没有边界就是成本黑洞。
两套系统的工具名都不同、实现也不同，读源码时先分清是哪一侧，能省大量混淆时间。
三条关键假设与适用边界
Agentic Search 站得住依赖三个假设：模型有基本元认知（能判断自己缺什么）；底层检索器可靠（所以底层仍推荐混合检索加重排，保证单轮质量）；反思加停止条件能把额外成本压在可接受范围。适用边界同样清楚：多跳问题、证据分散、低覆盖知识库用它收益大；简单事实问答走单轮直查更便宜——短路径优先，简单问题不启动多轮，兼顾效果与成本。
一句话收束：Agentic Search 不是新的检索算法，是检索的编排与决策范式。底层可以是 BM25、向量、混合、图谱甚至文件系统，真正的差异在于"谁在决定什么时候查、怎么查、查到什么程度停"。
评论0