一句话讲清楚👉🏻 微软提出的 AgenticRAG 给企业知识库上的 RAG 套了一层轻量级 Agent harness ，让推理模型可以反复 search 、 find 、 open 、 summarize ，在真实长文档检索、企业问答和金融文档问答上显著逼近“拿到正确证据后再回答”的上限。
企业知识库里的 RAG ，最容易翻车的地方通常落在第一把检索。
用户问一句“这个条款在什么情况下适用”“某家公司利润率变化主要来自哪里”“排障步骤里前置条件是什么”，检索系统要先从几千篇、几万篇甚至更大的内部文档里切出候选片段。传统流水线会把这些候选内容一次性交给模型，模型再基于这一小包上下文回答。
问题在于，企业问题往往不是一句关键词能打穿的。
同一个答案可能散在产品手册、支持文档、财报 PDF 、合规条款、历史邮件导出的知识页里；一个关键数字可能要先找到章节，再跳到表格，再回头读定义；一次检索返回的 snippet 看起来相关，完整文档里却可能是反例或过期说明。于是整个系统把很大的压力压在检索栈上：第一把检索必须足够准，排序必须足够好，切片必须刚好覆盖证据。
微软这篇 AgenticRAG 的思路很工程化：不要强迫搜索栈一次性做完所有判断。搜索栈负责广撒网、给高召回候选；推理模型负责后续的精读、跳转、补证据、合并线索。
论文来自 Microsoft Corporation ，目标场景也很明确：企业知识库、长文档、复杂问题、可追溯证据。它没有训练新模型，没有重建知识图谱，也没有要求把企业文档搬去重新做一套专用索引；它选择在已有企业搜索基础设施之上加一层轻量 Agent harness 。
核心变化：从“一次检索”变成“带工具的阅读过程”
传统 RAG 像是让模型只看搜索引擎第一页截图，然后立刻写答案。 AgenticRAG 更像一个会查资料的人：先搜索候选文档，发现不够就进文档里找关键词，再打开完整窗口读上下文，证据太多时先做摘要，最后带着引用回答。
论文把这套 harness 拆成四个工具：
这张图里的关键不在“Agent”这个名字，关键在闭环。模型每轮都看到当前对话、已有工具结果和引用标识，然后自己决定下一步动作：继续 search ，还是对某个文档 find ，还是 open 深读，还是已经足够回答。
论文设置的默认最大迭代次数是 15 。达到上限后，系统会强制模型基于已有信息完成回答；如果上下文使用量达到 128K token 阈值附近，系统会触发 summarize ，把重要证据压缩留下来，删除无关工具结果。这样做的目的很实在：让模型能在长文档任务里持续检索，又不被上下文撑爆。
为什么企业 RAG 尤其需要这种设计
公开网页搜索里，很多问题本来就可以靠一两个高质量页面回答。企业知识库要麻烦得多。
第一，企业文档长。 FinanceBench 里的金融文档平均约 143 页、约 11.7 万 token ； BRIGHT 长文档设置里， Stack Overflow split 的平均文档长度超过 4 万 token 。把这些内容预切成 chunk 后，结构信息会被打散，标题、表格、上下文边界也容易丢。
第二，企业问题常常是 situational query 。用户不会问“定义是什么”这种教科书问题，而会带着场景问：“如果 A 条件成立但 B 未完成，该流程怎么走？”这类问题需要跨段落、跨文档、跨术语对齐。
第三，企业系统需要证据链。回答要能指向文档、章节、引用，不能只给一个看似合理的自然语言结论。 AgenticRAG 里的 reference ID 、 line-numbered preview 、 candidate reference retention ，都是围绕“回答可追溯”设计的。
论文里有一句很值得工程团队记住：这套方法把搜索栈的责任从“最终精排”调整为“高召回候选发现”。最终精读和判断交给推理模型完成。
这对已有企业搜索系统很友好。企业内部往往已经有成熟搜索栈，负责权限、索引、文件类型、元数据、延迟和可用性。 AgenticRAG 不要求推倒重来，它把现有搜索包装成一个工具，再补上文档内搜索和窗口化阅读。
四个工具怎么协作
search ：先扩大候选面
search 工具对接已有企业搜索后端。在默认配置下，模型一次工具调用里最多可以给出 5 个 query reformulations 。比如用户问金融文档中的某个利润率变化，模型可能同时搜索指标名、同义表达、公司名加季度、相关报表字段等。
每条查询最多返回 10 个结果。系统会合并、去重，并给每个结果分配全局唯一 reference ID ，格式类似 turnmsearchn 。这个 ID 会在后续 find 和 open 中继续使用，避免模型只靠模糊标题引用文档。
多查询搜索的作用主要是效率。论文消融显示，去掉 multi-query search 后， Recall@1 没有崩，但平均工具调用从 4.79 上升到 6.79 。也就是说，多查询让模型少绕路，用更少回合找到差不多质量的证据。
find ：知道要找什么时，直接进文档定位
find 解决的是“候选文档很长，但我已经知道关键词”的问题。
比如模型在 search 结果里看到某份财报很可能包含答案，它可以在这份文档内部找 revenue 、 operating margin 、 capital expenditure 这类 pattern 。论文里的 find 是大小写不敏感的 substring matching ，也可以启用 semantic find 。每个 pattern 最多返回 2 个匹配片段，返回内容会做去重并截断在约 11K token 以内。
它不是为了替代全文阅读，而是用来把阅读位置缩小到关键区域。对企业 PDF 、手册、支持文档来说，这个动作非常像人类先 Cmd+F 再阅读上下文。
open ：从片段走向上下文
open 工具负责读取完整文档窗口。默认每次返回 1800 行，也会告诉模型当前查看的是哪一段，比如“Viewing lines [0–1799] of 3000 lines”。模型可以根据标题、表格、上一轮 find 的位置，继续从某个行号附近打开。
这个设计处理了一个常见痛点： RAG chunk 可能只给出局部片段，但答案判断往往依赖片段前后的定义、例外、表格脚注、单位说明。 open 让模型从“命中一段文字”进入“阅读一段文档”。
summarize ：长链路里的压缩阀
当模型反复 search 、 find 、 open ，工具结果很快会堆满上下文。 AgenticRAG 在对话达到 90% token budget 时发出内部警告，到阈值时强制 summarize 。
summarize 工具不是普通摘要，它会让模型记录当前推理状态，并指定需要保留的 reference ID 。系统随后扫描工具消息，删除未被保留引用关联的内容。这样一来，模型不会因为压缩而丢掉关键证据来源，也不需要从头开始检索。
我的判断是， summarize 在这篇论文里的意义比消融分数看起来更偏“生产安全阀”。 BRIGHT 上去掉 summarize 影响不大，因为任务通常在上下文撑爆前结束；但在真实企业问答里，一次会话可能有多轮追问，用户还会不断引用前文，这个机制会决定系统能不能稳定跑久。
实验一： BRIGHT 长文档检索
BRIGHT 是一个面向 reasoning-intensive retrieval 的 benchmark 。论文选用 long-context setting ：文档是完整网页，而不是预切片段。任务是给定复杂问题，找出相关完整文档。
数据覆盖 8 个领域： Biology 、 Earth Science 、 Economics 、 Psychology 、 Robotics 、 Stack Overflow 、 Sustainable Living 、 Pony 。总计 861 个 query 、 5650 篇文档，平均文档长度约 16280 token 。 Stack Overflow split 的文档尤其长，平均超过 40700 token 。
核心指标是 Recall@1 ，也就是系统排第一的文档是否命中 gold document 。
AgenticRAG with Claude Sonnet 4.5 达到 49.6% 平均 Recall@1 ，比最强 embedding baseline Qwen 的 27.8% 高 21.8 个百分点； GPT-5-mini 达到 43.5%，也高出 15.7 个百分点。
提升最明显的领域包括 Economics 、 Earth Science 、 Robotics 、 Psychology 。论文解释得很直白：在大语料、长文档、相关文档稀疏的场景里，一次性检索很难把候选排准；模型通过多轮工具调用可以先粗筛，再深入打开少量高价值文档。
这里值得注意的是 Pony split 。 Pony 的平均 gold docs 是 6.9 ，而 BRIGHT 整体平均只有 1.9 。 AgenticRAG 在这个 split 上仍然吃力， Claude 只有 7.1 ， GPT-5-mini 只有 4.8 。原因很合理：当前 harness 更擅长从大量候选中钻到少数关键证据，对“要广泛覆盖多份相关文档”的任务没有专门优化。
这给产品落地一个提醒： AgenticRAG 适合深挖证据，不一定天然适合“把所有相关资料全召回”。后者可能需要不同的轨迹策略，比如先判断问题是否 broad evidence need ，再切换成更宽的覆盖模式。
实验二： WixQA 企业支持问答
WixQA 更接近企业客服和支持文档场景。问题通常是 procedural query ，需要多步推理和多文章依赖。论文使用两个子集： Expert Written 和 Simulated ，每个都是 200 个 query 。知识库规模是 6221 篇领域帮助文章。
在 Expert Written split 上， AgenticRAG with GPT-5-mini 的 factuality 达到 0.96 。对比基线： E5 retrieval 是 0.85 ， BM25 是 0.83 。相对最强基线提升约 13%。
这个结果的意义不在于“换了一个更强模型”，因为图中可以看到，同样的生成模型配不同检索方式， agentic retrieval 普遍更稳。对支持问答来说，模型必须先找到正确流程、前置条件、限制说明，再组织成回答。一次检索命中错误文章或少一个依赖步骤，最终答案就可能不完整。
Simulated split 上差距更大。论文附录给出的结果是， AgenticRAG 达到 0.94 factuality ，而 E5+GPT-4o 与 BM25+GPT-4o 都是 0.77 。这类问题往往更需要拆解，单条语义检索容易把最相关的一篇文档找出来，却漏掉完成答案所需的第二篇或第三篇。
实验三： FinanceBench 金融长文档问答
FinanceBench 是更硬的长文档任务。问题来自公开公司 filings ，包括 10-K 、 10-Q 、 8-K 和 earnings reports 。论文使用 150 个问题、 84 份 ground documents ；每份文档平均约 143 页、约 116715 token 。
最扎眼的是 92.00%。这个成绩距离 oracle evidence 的 94.00% 只差 2 个百分点。 oracle 的意思是：直接把正确证据页给模型，跳过检索过程。 AgenticRAG 几乎逼近这个上限，说明瓶颈从“找不到证据”大幅转向“模型拿到证据后能不能推理”。
这在金融文档里很难得。财报问题常见两类：一类是找到某个 line item 或 ratio ，另一类是解释 margin 变化、资本开支、收入结构。前者考验定位，后者考验读上下文和计算关系。传统 RAG 的 24.24% 很像真实工程里的尴尬状态：模型语言能力够强，但证据没给对。
对企业内部财务、法务、审计、供应链文档来说，这个结果很有参考价值。很多公司已经有搜索系统和权限体系，真正缺的是让模型在已有系统上“会读文档”的 harness 。
成本：质量提升不是免费的
AgenticRAG 的代价主要是 token 和延迟。
论文统计了 end-to-end token cost ，包括系统提示词、工具调用参数、工具结果、 thinking tokens 和最终回答。在 BRIGHT 上， AgenticRAG 平均每个 query 消耗 52.3K token ； Single-shot Search 是 20.4K ，成本约 2.6 倍。
但质量收益更大： Claude Sonnet 4.5 with AgenticRAG 的 Recall@1 是 49.6%， Single-shot Search 只有 8.41%，约 5.9 倍提升。
FinanceBench 更贵。 AgenticRAG 平均每个 query 消耗 114.8K token ， Single-shot 是 14.7K ，成本约 7.8 倍。这也符合直觉：金融 PDF 长、问题需要深读，模型要打开更多上下文。
所以 AgenticRAG 不该无脑替代所有 RAG 。论文的 pre-production 经验里也提到一个 switcher ：复杂、多意图查询走 agentic harness ；简单问题走传统 RAG ，降低成本和延迟。
我的建议也一样：企业落地时先做路由。
消融实验：到底是谁在起作用
论文的消融结果显示，最大贡献来自“从 single-shot search 切换到 agentic tool use”。 Single-shot Search 平均 Recall@1 只有 8.41%；完整 AgenticRAG with Claude Sonnet 4.5 达到 49.59%， with GPT-5-mini 达到 43.49%。
多查询搜索主要提升效率。去掉 Multi-query Search 后， GPT-5-mini 平均 Recall@1 是 44.84%，看起来还略高一点，但平均工具调用从 4.79 增到 6.79 ， search 从 3.39 增到 4.38 ， open 从 1.22 增到 2.16 。也就是说，质量接近，但绕得更久。
去掉 summarize 对 BRIGHT 影响很小， 43.34% vs 43.49%。这里更准确的理解是： summarize 对 BRIGHT 这类单轮检索任务帮助有限，因为多数样本还没有把上下文压到极限。
去掉 semantic find 反而提升到 46.34%。论文解释是， lexical find fallback 对大多数文档内搜索已经够用，去掉 semantic find 可能降低延迟，让系统在同等预算里做更多 search/open 。这一点很实用：别一上来就把所有工具都做成最复杂版本。企业系统里，可靠、快、可解释的关键词定位，经常比更花哨的语义定位更值钱。
模型行为差异： Claude 深挖， GPT-5-mini 广搜
论文还比较了模型使用工具的模式。
Claude Sonnet 4.5 更偏 exploitation ： search 调用更少， open 更多， semantic find 更多。它倾向于选中候选后往深处读。
GPT-5-mini 更偏 exploration ： search 调用更多，倾向于改写查询、扩大候选面，而不是在单篇文档里反复 find 。
二者没有绝对高下，差异来自问题类型。 BRIGHT 里大多数 query 的 gold document 很少，深挖高质量候选更有优势；如果任务是找全多份证据，广搜策略可能反而需要被加强。
产品上可以把这种差异变成策略：
预生产经验：四个细节很工程
论文最后给了几条 pre-production deployment 经验，我觉得比 benchmark 还值得看。
第一，搜索结果要暴露元数据。 标题、文件名、文件类型、可用 metadata ，会帮助模型区分语义相近的 snippet ，减少重复搜索。企业文档里同名、版本、草稿、归档文件很多， metadata 是重要信号。
第二，文档预览要有行号。 line-numbered preview 让模型可以锚定位置，下一次 open 直接跳到附近，而不是每次从头读。
第三， summarize 后要保留 candidate reference 。 如果摘要只保留自然语言结论，不保留引用 ID ，模型后续就没法继续打开原文。保留 reference ID 相当于保存书签。
第四，要有复杂查询路由器。 简单查询进传统 RAG ，复杂多意图查询进 AgenticRAG 。这个 hybrid approach 才能平衡体验、成本和模型可用性。
这些细节不像论文主结果那么吸睛，但会真正影响上线质量。 AgenticRAG 的价值除了“模型会调用工具”，还在于工具调用被约束在企业系统可控的接口里：权限、引用、上下文预算、最大迭代、失败兜底都有明确边界。
和 GraphRAG 、 Self-RAG 的区别
近两年 RAG 改进路线很多： GraphRAG 强调先建知识图谱， RAPTOR 强调层级摘要树， Self-RAG 和 Corrective RAG 强调自评估与回退， PlanRAG 和 Search-o1 强调规划与搜索结合。
AgenticRAG 的位置更朴素：它是 inference-time harness 。企业文档已经在搜索后端里，模型只需要通过工具去查、找、读、总结。
这种路线牺牲了一些离线结构化收益，但换来几个工程优势：
如果企业文档高度结构化、关系非常稳定， GraphRAG 可能更适合；如果文档变化快、权限复杂、已有搜索系统很强， AgenticRAG 这类轻量 harness 会更容易落地。
我的几个落地判断
1. AgenticRAG 最适合作为高价值查询通道。 它不应该承担所有问答。 FAQ 、短事实、单文档简单问答，用传统 RAG 更便宜。多文档、长文档、强引用需求，再交给 AgenticRAG 。
2. 工具返回格式比工具数量更关键。 reference ID 、行号、文件 metadata 、窗口范围、引用保留，这些字段决定模型能不能稳定规划下一步。很多失败不是模型不会推理，而是工具结果没有给它“可继续行动”的把手。
3. 成本控制要内建在轨迹里。 最大迭代次数、每次 open 行数、 find 返回片段数、 search query 数、 summarize 阈值，都应该成为可调参数。不同业务线可以有不同预算。
4. 评测不能只看最终答案。 还要看证据命中率、工具调用轨迹、无效 open 比例、重复 search 比例、引用是否真的支撑答案。否则系统可能“答对了”，但证据路径不可复现。
5. 简单关键词工具仍然有生命力。 论文里 semantic find 的消融结果很有意思：复杂语义工具不一定总带来收益。企业系统不要低估 lexical search 、文件名、章节标题、行号这些老派工具。
局限也很清楚
AgenticRAG 的第一类局限是成本。它靠多轮工具调用换质量， FinanceBench 上 7.8 倍 token 成本不是小数。生产系统必须做 query routing 、预算控制和超时兜底。
第二类局限是 broad evidence retrieval 。 Pony split 说明，当一个问题需要找很多份相关文档时，当前 harness 的深挖策略不够理想。未来可能需要 coverage-aware planning ，先判断需要覆盖多少证据，再决定 search/open 比例。
第三类局限是工具和搜索后端强相关。论文里的结果建立在可用的企业搜索、文档窗口读取、 reference 追踪之上。如果后端索引质量差、文档解析乱、权限元数据缺失， Agent harness 也很难凭空补救。
第四类局限是评测场景还不等同于完整企业上线。真实系统有多轮对话、用户打断、文档权限变化、旧版本污染、敏感信息过滤、延迟 SLA 。论文已经给出 pre-production 信号，但大规模部署还需要更多观测。
这篇论文最值得带走的点
AgenticRAG 没有把企业 RAG 神秘化。它承认已有搜索栈很重要，也承认推理模型现在更会用工具。于是把两者分工重新摆了一下：搜索负责召回，模型负责逐步取证。
对做企业知识库的人来说，这比“换一个 embedding 模型”更有启发。很多 RAG 系统卡住， embedding 能力只是原因之一，更大的结构性问题是：系统强迫检索在第一步就做完所有困难决策。 AgenticRAG 给了另一种结构：允许模型像人一样，一边查，一边读，一边修正搜索目标。
如果未来企业知识库 Copilot 要稳定处理复杂问题，大概率会走这种混合路线：简单问题快速回答，复杂问题进入可追踪、可预算、可中断的 agentic retrieval 流程。
论文里 49.6% BRIGHT Recall@1 、 0.96 WixQA factuality 、 92% FinanceBench correctness 这些数字很亮眼，但我更看重另一个信号：在 FinanceBench 里，它已经接近 oracle evidence 上限。也就是说，只要工具链把证据找对，现有推理模型已经足够接近可用。
下一步真正要拼的，是谁能把“找对证据”这件事做得稳定、可控、便宜。
