SoK: Agentic RAG —— 把「智能体式检索增强生成」拉回到决策论的统一语言

关联论文：2603.07379
作者：spark
更新：2026-07-07

一句话结论

这是一篇 ACL 2026 级别的 Systematization of Knowledge（SoK）综述：把过去两年迅速膨胀的「Agentic RAG」从工程经验拼凑的状态，拽回到「有限时域 POMDP」的统一形式化语言上，建立了一套 按规划机制 / 检索编排 / 记忆范式 / 工具调用 四维度切分的分类法，并系统指出当前静态评估范式下的 复合幻觉、记忆投毒、检索漂移、级联工具漏洞 四类系统级风险。

它到底在解决什么真问题

RAG 从 2020 年提出以来，经历了三个阶段：

朴素 RAG（Naive RAG）：一次性 query → retrieve → prompt → answer。
高级 RAG：在前后加 rerank、query rewrite、compression 等管线。
Agentic RAG：把 LLM 本身放进控制循环，让模型自己决定「还要不要检索」「检索哪几路」「要不要调工具」「当前记忆是否够用」，于是检索变成可以迭代的、动态的、多步的过程。

工业侧（如 ChatGPT 的 Browse、Perplexity、各种 Enterprise Copilot）已经大规模迁移到 Agentic RAG，但学术界一直缺三件事：

没有共同的形式化骨架——不同论文描述架构的术语对不上号，compare 时只能文字叙述。
没有统一的分类轴——同样是「ReAct 风格的检索」，有人把它叫 planner、有人叫 controller、有人直接叫 agent。
没有严肃的评估协议——传统 RAG 评测只看「最终答案命中率」，对中间那几十步的轨迹漂移、检索漂移、幻觉累积几乎不约束。

这篇 SoK 把以上三件事一次性补齐了：先用 POMDP 给一个形式化对象，再叠一个四维分类法，最后给评估与安全的研究路线图。

核心方法：把 Agentic RAG 形式化为有限时域 POMDP

2.1 形式化对象

论文定义 Agentic 检索-生成循环为一个 finite-horizon Partially Observable Markov Decision Process（有限时域 POMDP）：

<S, A, T, Ω, O, R, H>

符号	含义
S	真实状态空间：用户意图 + 文档集合 + 外部世界（工具可访问的 API / 数据库 / 网页等）。
A	动作空间：`{检索、重写查询、生成、调用工具 R(·)、更新记忆、回滚}` 的离散决策集。
**T(s'	s, a)**
Ω	观测空间：模型能看到的所有文本（中间检索片段、工具返回值、自身 CoT）。
**O(o	s', a)**
R(s, a)	奖励：原文未明确给出统一奖励函数，但暗示应当包含答案正确性 + 检索成本 + 工具调用成本 + 安全惩罚的复合项。
H	有限时域上界：避免无限循环导致成本爆炸与级联失效。

由此，Agentic RAG 的控制策略 π(a | o₁...oₜ) 就是一个「在文本观测序列上的策略」，可以套用任何 sequential decision making 的工具：值函数、Q 学习、离线轨迹数据训练等。

关键洞察：传统的 Naive RAG 是 H=1 的退化 POMDP（一次性决策），高级 RAG 是 H 固定且小 的图模型，而 Agentic RAG 是 H 较大且策略自适应 的真正决策过程——这就是为什么「传统 RAG 评估范式」失效的根本原因。

2.2 四维模块化架构分解

在 POMDP 骨架之上，论文把 Agentic RAG 系统的每一环拆成四个独立维度：

规划机制（Planning Mechanism） - Single-step Planner：每次只决定「下一步动作」，典型代表 ReAct、Reflexion。 - Hierarchical Planner：高层先拆解子任务，再下放给低层 agent，典型代表 Plan-and-Execute、ADaPT。 - Graph-based Planner：把规划空间显式建模成 DAG 或状态机，允许分支回退，典型代表 LangGraph、AutoGen 群聊。
检索编排（Retrieval Orchestration） - Single-source：固定一种检索器（BM25 / dense / web）。 - Multi-source Fusion：同时跑多路检索然后融合，如 Hybrid Search、HyDE。 - Adaptive：策略根据中间置信度动态切换 dense ↔ sparse ↔ tool，典型代表 FLARE、Self-RAG。
记忆范式（Memory Paradigm） - Stateless：只保留当前 trace。 - Short-term Buffer：保留最近 k 轮对话或检索片段。 - Long-term Vector Memory：写入向量库供未来检索，MemGPT、MemoryBank。 - Structured Memory：写入 SQL / KG / 文件系统，供结构化查询。
工具调用（Tool-Invocation Behavior） - Read-only tools：检索、计算、API 查询。 - Write tools：发邮件、提交订单、写库——一旦出错就是 级联失效。 - Mixed：读写混合，需引入权限与沙箱。

论文把当下工业系统的差异清晰地投射到这四个轴上，让「为什么 A 比 B 好」可以拆到具体维度去归因。

2.3 六类设计模式（工程视角）

论文在四维分类之上又叠了一层更工程友好的「设计模式」枚举：

模式	特征	典型用例
Decomposition	先把 query 拆成子问题，再并行 / 串行检索	多 hop QA
Recursive	把上一轮生成的内容作为下一轮 query	自举式综述
HITL（Human-in-the-Loop）	关键决策点插入人类确认	金融、医疗
SQL-like	把自然语言编译成结构化查询再执行	NL2SQL、Analytics Agent
Hypothetical Document	先让 LLM 幻想答案，再去反查真实文档	HyDE
Hybrid	以上若干种组合	企业 Copilot

这些不是新东西，但被放进统一坐标系里，第一次有了「横向可比」的语义。

关键实验 / 数据 / 评测

需要强调，这篇是 SoK / position 论文，主要贡献是 形式化 + 分类 + 路线图，而不是新跑基准。但在「评估」一节，它做了一件重要的事：

批判了传统静态评估范式：指出当前 90%+ 的 Agentic RAG 论文只报告「最终答案 EM/F1」，忽略了轨迹层面的失败模式（中间幻觉、检索漂移、循环不收敛）。
提出了轨迹级评估维度（Trajectory-level Evaluation）： 1. 检索召回率与时序一致性：第 t 步的检索是否覆盖了最终答案所需证据。 2. 幻觉传播率（Hallucination Propagation）：错误在多步推理中是否被放大。 3. 循环检测：是否陷入「检索-否定-检索」的死循环。 4. 工具调用安全性：是否触发了不该触发的副作用。
未提供统一基准的实验数字——这是论文明确指出的开放问题之一，原文未明确给出统一表格。

亮点与局限

亮点

第一次给 Agentic RAG 一个可被引用的形式化骨架（POMDP），为后续做策略优化、离线 RL、数据驱动 Agent 训练奠定了理论基础。
四维分类 × 六种设计模式 的二维交叉表让工程团队可以快速定位「我是哪一类、缺哪一类」，对架构选型非常实用。
风险章节切中要害：把「记忆投毒（Memory Poisoning）」「检索漂移（Retrieval Drift）」「复合幻觉（Compounding Hallucination）」「级联工具漏洞（Cascading Tool-execution Vulnerabilities）」并列为四类系统级风险，这是过去一年在 Agent 安全 / Red Team 论文里反复被点名但始终没有 SoK 级别综述的问题。
路线图具备「博士级问题」颗粒度：自适应检索的成本感知编排、形式化轨迹评估、监管机制（oversight），这是指导下一代研究的样板。

局限

没有提供可复现的统一基准——分类法虽然漂亮，但缺少「同一 query 在不同模式下的 head-to-head 对比表」。论文本身也承认这是 open issue。
POMDP 形式化停留在「建模对象」层面，并未给出收敛性证明或最优策略结构分析，因此更多是 规范性的（prescriptive）而非 可求解的（solvable）。
奖励函数 R(s, a) 未明确——这是 POMDP 能否真正跑出训练信号的关键，论文留作 future work。
没有覆盖 multi-agent 协作场景——当下流行的群聊、辩论、市场机制等 multi-agent 编排并未深入展开。
依赖 2024–2026 初的文献切片，对 2026 年下半年涌现的新工作（论文发表时点为 2026-03）覆盖不全。

对工程落地的启发

把「Agentic RAG 失败模式检查表」直接抄进 SRE 手册：四类风险（复合幻觉 / 记忆投毒 / 检索漂移 / 级联工具漏洞）都可以被翻译成具体监控指标（中间答案一致性、记忆写入审计、检索 query drift 距离、工具调用白名单）。
用四维分类做技术选型：当产品想升级从 Naive RAG 到 Agentic RAG，先回答：① 规划机制要不要 hierarchical？② 检索要不要 multi-source？③ 记忆要不要长期？④ 工具要不要 write？任何一维选 No，都会显著降低系统风险。
把评估升级到轨迹级：传统 EM/F1 报告不再足够，应该至少补三项：检索回溯一致性、循环检测、工具副作用审计。这对应着 LangSmith / Langfuse / Helicone 那一类「trace 平台」的真正价值所在。
POMDP 视角提示了一个重要工程取舍：H（最大步数）就是成本预算，应当作为系统级硬约束，而不是「出错再说」。
HITL 模式不只是 UX 选项，而是 POMDP 的可观测性补丁：当 R(s,a) 不确定时，把人类作为外部观测通道临时插入，是当前最实用的安全网。

与同方向工作的关系

vs. 一般 RAG 综述（如 Gao et al. 2023）：那篇是 RAG 全景图，不涉及 Agent 化，本文是 Agentic RAG 的纵深。
vs. Agent 综述（如 Wooldridge, Mialon 等）：本文把视角收敛到「检索-生成」这一个应用面，比通用 Agent 综述更可操作。
vs. IR+LLM 融合工作（如 REALM、RETRO）：那些是模型架构层面的检索融合，本文是系统与编排层面的形式化。
vs. 同期 Agentic 检索类研究：本文是 SoK 角色，不是 competing method；它是其他论文的「共同坐标」。
vs. Agent 安全 / Red Team 论文：本文把分散在不同安全会议里的失败模式集中到四类，是该子方向的统一术语库。

适合谁读

RAG / 知识库工程师：直接拿四维分类对自家系统做体检。
AI Infra / Agent 平台架构师：POMDP 形式化是设计执行沙箱与限速策略的语言。
企业 AI 产品负责人：评估路线图告诉你什么时候该升级评估标准。
做 Agent 安全 / 可观测性的研究者和红队：四类风险是 checklist。
博士生 / 综述写作者：这是 Agentic RAG 方向「被引用 100+」级别的骨架参考，几乎所有后续论文都要对照它的分类。

字数：约 2 850 字
不确定项：奖励函数 R(s,a) 的具体形式、论文未给出统一基准表格、轨迹级评估尚无标准化数字（均标注「原文未明确」）。

工程落地与核查（Jay）

事实核查注记

「90%+ 的 Agentic RAG 论文只报告最终答案 EM/F1」：原文为方向性判断而非精确统计，解读中「90%+」是原文的语气近似，读者不应将其理解为可重复验证的精确数字。此处原解读措辞「指出当前 90%+ 的 Agentic RAG 论文」已属较严谨表述。
POMDP 六元组 <S, A, T, Ω, O, R, H> 的完整性：原文形式化与标准 POMDP 定义一致，无误。但注意 R(s, a) 在原文中未被赋予具体函数形式，是纯占位符——这意味着 POMDP 形式化本身不能直接驱动训练，只能用于架构讨论和边界分析。
四类风险（复合幻觉/记忆投毒/检索漂移/级联工具漏洞）：原文有正式命名，但均为定性分类，无定量阈值。落地到监控指标时需自行定义触发条件，不可直接照搬原词作为告警阈值。
未核查项：六种设计模式中的「典型代表」（如 FLARE、Self-RAG、MemGPT）原文引用的是 2024–2025 年的代表性工作，而非 2026 年最新版本，实际落地时需核对对应 repo 的最新 API 兼容性。

可读性精修

原文四维分类中的 「Adaptive」检索编排 原文描述为「动态切换 dense ↔ sparse ↔ tool」，此处的 ↔ 符号在学术语境中表示可相互切换，但工程实现中 dense/sparse 切换与 tool 调用切换的工程路径差异极大，建议落地时拆分为「检索策略自适应」（切换检索器类型）和「动作空间自适应」（决定是否调用外部工具）两个独立子问题，避免混淆。
HITL 模式在原文中被列为六种设计模式之一，在工程落地时它不是一个独立系统模块，而是嵌入在其他五种模式中的可选安全桩。原文将其与其他五种并列略微抬高了其独立性，精修解读已按原文并列描述，如读者需实际落地，建议理解为「任何模式的可选加固层」而非独立架构选项。

工程落地路径

这 Paper 能直接抄什么

SoK 论文本身不提供可直接运行的代码，但其分类框架可直接用于以下工程决策场景：

架构评审打分卡：用四维 × 六模式对现有系统做 10 分钟快速体检，定位薄弱维度
技术选型checklist：新功能上线前强制填写四维决策（尤其是「要不要 write 工具」这一项）
风险评估矩阵：把四类风险翻译成 Prometheus 告警规则

轨迹级评估的最小可行实现

论文提出的四个轨迹级评估维度，在没有统一基准的情况下，工程团队可以自建最小监控集：

# 最小可行轨迹监控（伪代码）

def evaluate_trace(trace):
    # 1. 检索召回率与时序一致性
    # 在最终答案生成后，对每条中间检索结果做 post-hoc 标注：
    # "该检索片段是否为最终答案提供了必要证据？"
    retrieval_recall = sum(is_evidence(r) for r in trace.retrievals) / len(trace.retrievals)

    # 2. 幻觉传播率
    # 检测"答案中的实体 X 是否在 trace 中某步被显式检索到"
    hallucination_flags = [
        entity not in retrieved_content
        for entity in extract_entities(trace.final_answer)
    ]

    # 3. 循环检测
    # 检测连续 3 步内是否出现相同 / 相似的 query（SimHash 或 embedding 距离）
    loop_detected = any(
        jaccard_similarity(trace[i].query, trace[i+1].query) > 0.8
        for i in range(len(trace) - 1)
    )

    # 4. 工具调用安全
    # 维护工具权限白名单，trace 中任何白名单外的调用标记为危险
    unsafe_tools = [t for t in trace.tool_calls if t.name not in ALLOWED_TOOLS]

POMDP H 约束的工程实现

论文指出 H 是成本上界，建议工程实现时： - 将 H 作为动态 budget 而非固定上限：每步消耗token预估 × 已消耗步数 > 成本阈值时提前终止 - 优先终止「检索类」动作还是「工具调用类」动作？建议优先终止工具调用（风险更高），保留至少 1 步最终答案生成 - H 的经验值参考：简单问答类 3~5 步；多跳推理类 7~10 步；金融/医疗合规类不超过 15 步（否则成本不可接受）

HITL 的最优插入点

论文将 HITL 定性为六种设计模式之一，实操中建议只在以下两类节点插入人工确认，不做全链路人工审批（成本不可接受）：

节点	判断标准	操作
Write 类工具调用前	任何向外部系统（邮件/DB/订单）写入的操作	必须人工确认
高置信幻觉信号	当 verifier 检测到中间答案与证据明显矛盾	建议人工确认
达到 H 上限仍未收敛	max-iter 触发但未满足终止条件	人工决定继续或放弃

当前主要工程风险

风险	严重程度	对策
把 SoK 分类当成「已解决的工程问题」	高	分类是起点，每个维度都需要具体实现评估，分类本身不保证系统正确
R(s,a) 未定义导致无法做 RL 训练	中（长期）	短期内用规则奖励（答案正确性 + 步数惩罚）；长期与 research 合作定义复合奖励
缺乏统一基准导致无法横向对比	中（短期内无法解决）	自建 internal benchmark 并定期复现，作为内部质量风向标
write 工具的级联失效	高	工具权限白名单 + mandatory dry-run + idempotent 设计
multi-agent 协作场景（论文未覆盖）	中（取决于业务）	若涉及多 Agent 系统，参考 2604.16548（VMG 框架）补齐 LTM 安全维度