过去很多 RAG 项目在 PoC 阶段表现不错,一进生产就“体验崩盘”。
典型反馈是:
- 回答看起来专业,但不解决问题。
- 能引用文档,但不能推进流程。
- 一遇到复杂请求就回避。
这说明一个事实:传统 RAG 的上限是“知识回答系统”,而业务真正要的是“任务执行系统”。
为什么 Agentic RAG 会成为 2026 主线
RAG 的价值正在从“补充知识”转向“驱动动作”。
Agentic RAG 的核心不是多加几个插件,而是让系统具备这条闭环:
识别意图 -> 获取证据 -> 形成判断 -> 执行动作 -> 回写结果 -> 复盘评估
图表1:传统 RAG 与 Agentic RAG 的本质差异
| 维度 | 传统 RAG | Agentic RAG |
|---|---|---|
| 核心目标 | 回答正确 | 完成任务 |
| 执行能力 | 基本没有 | 有工具调用与动作链 |
| 输出形式 | 文本结论 | 结论 + 动作 + 证据 |
| 错误处理 | 回答失败 | 可回退、重试、转人工 |
| 业务嵌入度 | 中 | 高 |
图表2:生产级 Agentic RAG 架构
1 | flowchart TD |
工程拆解:四个关键模块
1. 检索层:混合检索是底线
只做向量检索,往往会漏掉关键词精确匹配场景。建议采用:
- 关键词检索(BM25 类)处理精确术语。
- 向量检索处理语义匹配。
- 重排模型做最终证据排序。
2. 规划层:把“答案”升级成“动作计划”
同一个问题,系统要先判断:
- 只是答复就够?
- 还是需要触发外部动作?
- 动作是否需要人工确认?
3. 执行层:工具契约要强约束
每个工具都要定义:
- 参数 schema。
- 幂等键。
- 重试策略。
- 超时与回滚。
4. 评估层:建立线上可观测指标
不要只看离线准确率,必须看线上:
- 完成率(Task Completion Rate)。
- 人工接管率(Escalation Rate)。
- 错误分布(检索错/规划错/执行错)。
- 单任务成本(Cost per Task)。
图表3:从 PoC 到生产的进阶路线
| 阶段 | 目标 | 退出标准 |
|---|---|---|
| P0 验证 | Top 场景可回答 | 关键问题可复现 |
| P1 可信 | 引用可追溯 | 证据命中率达标 |
| P2 可执行 | 触发业务动作 | 动作成功率可衡量 |
| P3 稳定化 | 线上可治理 | 错误率/成本稳定 |
| P4 规模化 | 多团队复用 | 模块模板化沉淀 |
代码层建议:先做结构化输出
1 | { |
结构化输出的价值在于:可审计、可测试、可回放。
常见失败模式(真实项目高频)
- 文档切片策略粗糙,导致证据缺上下文。
- 重排缺失,召回看似高但命中质量差。
- 让模型直接拼工具参数,缺 schema 校验。
- 没有失败兜底,最终用户体验断崖下跌。
落地清单:一周可推进版本
- 先定义 3 个高频任务,不贪多。
- 给每个任务写成功条件和回退策略。
- 检索链路接入重排与证据回显。
- 工具调用强制 schema 校验。
- 每周复盘错误归因,持续迭代。
结语
RAG 不会消失,但“只会回答的 RAG”会越来越难进入核心流程。未来两年,真正有壁垒的是:
- 证据可靠。
- 动作可控。
- 成本可衡量。
这三点加在一起,才是 Agentic RAG 的护城河。
参考来源
- OpenAI:New tools for building agents(2025-03-11)
https://openai.com/index/new-tools-for-building-agents/ - GitHub:RAGFlow
https://github.com/infiniflow/ragflow - 知乎:RAG 与企业检索实战讨论
https://zhuanlan.zhihu.com/p/1955668804727207627 - 知乎:从 RAG 到 KAG 的演进
https://zhuanlan.zhihu.com/p/1977739890704798545 - 哔哩哔哩:Agentic RAG 全流程实战
https://www.bilibili.com/video/BV1ZiEEzLE3X/