Agentic RAG：Agent 如何用工具迭代检索

传统 RAG 的模式是"问题 → 一次检索 → 拼答案"，检索质量决定了答案上限。但现实问题是：用户问题经常含混（“那个考核制度”、“关于迟到那条规定”），一次检索根本不知道该搜什么。

Agentic RAG 的核心变化：把"检索"从一次调用变成 Agent 的决策循环——模型自己决定搜什么、搜几次、要不要换关键词、要不要看多个来源再综合。

一、传统 RAG 的四个死穴

问题不明确时，第一次检索就是错的：“那个考核制度”——哪个考核？检索出来的全是噪音
复杂问题需要多步：“去年 Q3 的晋升条件”——先找"晋升制度"，再找"2025 Q3 生效的版本"
找不到就放弃：首次检索为空，直接回答"没有找到"，实际知识库里可能有（换个词就能搜到）
证据不充分就回答：检索到一条模糊片段，LLM 就敢给结论

二、Agentic RAG：检索变成循环

关键区别：Agent 有"评估 → 再检索"的循环能力，而不是一次定生死。

三、工具集设计（这是 Agentic RAG 的灵魂）

工具	作用	何时用
`search(query)`	语义+关键词混合检索 Top5	初始探索
`search_more(terms)`	换词重搜（BM25 强化）	首次结果差
`get_doc(doc_id)`	取完整文档（不切分版）	片段不够，要看全文
`list_sections(topic)`	列出知识库目录/章节	定位大范围
`check_facts(claims)`	校验答案是否有来源支撑	综合前自查

设计要点：

工具要少而清晰（5 个内），LLM 才能正确选
每个工具描述写"何时用"：search_more 的 description 写"当首次搜索结果不理想时，用不同关键词重试"——这就是教 LLM 决策
检索结果带元数据（来源、日期、置信度），Agent 才能评估证据强弱

四、Agent 循环的约束（防失控）

Agent 自由循环的代价是失控风险：无限搜、绕圈子、token 烧光。必须加约束：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 系统提示中的循环规则（节选）
{
  "max_iterations": 5,
  "per_round_tools": 3,
  "answer_rules": [
    "证据不足时必须说明'知识库中没有明确依据'",
    "每次结论必须带引用来源",
    "第5轮强制输出最终答案"
  ]
}

五、评测结果：值不值

指标	传统 RAG	Agentic RAG
答案准确率	55%	78%
未找到率（知识库明明有）	18%	4%
平均延迟	1.2s	3.8s
平均 token 消耗	900	2600

结论：

值：准确率 +23%，“找不到"大幅减少——知识问答类场景收益巨大
代价：延迟 3 倍、成本 3 倍——不适合低延迟场景（实时客服、聊天）
适用：高价值、可等待、错误代价大的场景（HR 政策咨询、法律/制度问答、专家助手）

六、生产级落地要点

分两层：快速 RAG（1 次检索）兜底 + Agentic RAG 在快速层"不确定"时才触发——延迟和成本可控
评估前置：跑评测集对比两种模式，数据说话
缓存：常见问题的 Agent 检索轨迹可缓存，二次命中秒回
可观测：Agent 每一步的"思考+工具+结果"记日志——出了错能复盘是哪一步检索错了

总结

Agentic RAG 不是"换了个 Prompt”，是把检索从函数变成了决策：

Agent 决定"搜什么、搜几次、换不换词"，检索质量上限大幅提高
工具集要少而清晰，描述里写清楚"何时用"
循环必须加约束（迭代上限、评分门、引用硬约束）
用"快速层 + Agent 层"分层，平衡质量与成本

传统 RAG 是查字典，Agentic RAG 是让 Agent 当研究员——查字典快但浅，研究员慢但准。选哪个，看你产品的用户愿意等多久。

Agentic RAG：Agent 如何用工具迭代检索#

一、传统 RAG 的四个死穴#

二、Agentic RAG：检索变成循环#

三、工具集设计（这是 Agentic RAG 的灵魂）#

四、Agent 循环的约束（防失控）#

五、评测结果：值不值#

六、生产级落地要点#

总结#

📚 相关阅读