在Agent相关的技术讨论里“Agentic RAG”和“深度研究Deep Research”这两个词今年基本是被提及频率最高的两个方向。一方面RAG从早期的“向量检索拼接提示词”演变成了由Agent编排的复杂流水线检索不再是一次性的而是多轮、带判断、带反思的。另一方面深度研究类产品比如各种AI调研助手把“给定一个宽泛问题自动产出带参考文献的长报告”变成了可能。这篇文章是Agent论文与工业界实战总结的第二篇重点聊聊我在落地Agentic RAG和深度研究系统时遇到的核心问题检索规划怎么做、证据核验怎么落地、长程任务如何不跑偏以及效率和成本边界在哪里。内容偏工程实践也穿插一些论文观点适合正在搞Agent应用、RAG系统优化或者想自己搭深度研究工具的人参考。1. 从传统RAG到Agentic RAG为什么要“Agent化”很多团队早期做RAG走的是经典链路用户query进来embedding召回top-k文档重排后把片段拼到上下文里让大模型基于片段生成回答。这个流水线在知识库问答场景下足够用但如果问题是多跳的、需要对比多个来源、需要迭代搜索的传统RAG就暴露出明显的短板——它没有“判断”能力。1.1 传统RAG的三个硬伤第一个硬伤是召回质量直接决定答案质量而且无法补救。如果embedding阶段就没召回相关文档后面做得再好也白搭。第二个硬伤是缺乏多轮推理能力复杂问题通常需要拆解成子问题逐个搜索、验证、再汇总传统RAG做不了这个循环。第三个硬伤是证据不透明回答可能综合了多个文档但用户根本不知道哪句话来自哪个来源出了错也没法追溯。这三个问题本质上是因为RAG链路里“检索”是单向的、机械的。Agentic RAG的思路是把大模型作为调度中心让模型自己决定现在要不要检索检索什么检索结果够不够要不要换一种方式再检索一次这个转变从“一次检索定生死”变成了“多轮检索动态逼近答案”。1.2 Agentic RAG的几种范式在实际工程里Agentic RAG大概有这么几种范式可以选路由式Routing模型先判断query属于哪种类型然后决定走向量检索、走SQL查询、还是直接生成。这个适合意图分叉明显的场景比如“帮我把薪资表按部门汇总”和“介绍一下我们公司的考勤制度”就走完全不同的通道。规划式Planning模型先把复杂query拆成子问题然后逐个检索、逐个回答最后统一汇总。这个就是深度研究的雏形。反思式Reflection模型生成回答后自己审视一遍“我的答案有没有事实依据有没有矛盾”如果发现问题再触发补充检索。这个适合对准确率要求高的场景。多代理协作式Multi-Agent不同Agent分管不同职责比如Planner负责拆解问题Retriever负责搜索Verifier负责核验Critic负责挑错它们之间通过消息传递协作。选型时我的建议是能用路由式解决的不要上规划式能用规划式解决的不要上一整套Multi-Agent。复杂度每上升一层延迟、成本、出Bug的概率都跟着上升。工业界第一原则是够用就好。1.3 工业界落地时最容易被忽略的事有很多团队在Demo阶段效果不错一上生产就崩最常见的坑有三个。第一没有做检索结果的置信度判断导致模型拿低相关的片段强行作答。第二没有设计多轮检索的终止条件Agent会在“再搜一次”的循环里出不来token消耗爆炸。第三没有把“溯源”和生成解耦用户要的是答案带出处而不是答案本身。这些问题我在后面的章节会展开讲。这里先记住一个核心认知Agentic RAG不是一个模型也不是一个检索器而是一套由“决策、执行、验证”组成的闭环系统。理解了这个后面所有设计都是围绕怎么把这个闭环做得稳健、高效。2. 深度研究的检索规划从“搜一次”到“系统性调研”深度研究和普通多轮问答最大的区别在于任务的规模一个深度研究任务可能要探索几十个信息源跨多个子主题最终产出的报告甚至会有几千字。如果检索规划做得不好Agent会在信息的海洋里迷失方向。2.1 问题的分解是研究的灵魂拿到一个宽泛的研究主题比如“对比Transformer和Mamba在长文本建模上的效果”不能直接拿这句话去检索。检索系统很难对一整句复合query返回高质量的、细粒度不同的结果。正确的做法是先做问题分解一级分解把主题拆成背景、方法论、对比指标、实验结论、开源实现、业界案例等几个维度。二级分解每个维度继续下沉比如“对比指标”可以继续拆成“困惑度对比”、“吞吐量对比”、“显存占用对比”、“长距离依赖任务的benchmark对比”。数据需求映射为每个叶子子问题定义“要找什么类型的证据”是找论文、技术博客、GitHub Readme还是榜单数据。这个分解过程最早在STaR和ReAct论文里就能看到雏形后来在LangChain、LlamaIndex的文档里被工程化成了Plan-and-Solve模式。我的经验是与其让模型在运行时自由发挥拆解不如给它一套固定的分解框架用few-shot exemplar喂进去产出稳定得多。2.2 并行检索与延迟优化深度研究任务子问题数量往往很多如果串行执行假设一个子问题平均要2秒检索时间20个子问题就是40秒用户早就流失了。所以工程上必须做并行。我常用的做法是两阶段先做“粗并行”把所有一级子问题同时发出去每个子问题各自走一遍“搜索-阅读-提炼”的循环之后做“融合”把各分支产出的中间结果汇总再做一次交叉验证和查漏补缺。这个过程中需要控制的是并行度——不是越大越好因为检索接口、下游LLM的并发限制、以及汇总阶段的上下文长度限制都会制约并行上限。另外一个细节是动态规划所有子问题同时启动有些分支早早完成有些分支卡住了。最好设计一个“早停机制”对高质量来源覆盖率已经足够的分支提前结束把预算留给困难分支。工业界有不少团队把预算控制做成了参数化的比如给每个子问题分配token预算的百分比跑完一个分支就回收剩余预算。2.3 来源多样性与信息覆盖度搜索返回的结果通常存在“同质化”问题——翻来覆去都是同一批知名博客或新闻稿小众却有价值的观点反而被淹没了。做深度研究时信息覆盖度的评估指标可以这么设计来源多样性检索结果来自多少个不同域名、多少类不同载体论文、官方文档、代码库、社区讨论。角度覆盖度对于争议性话题正反两方的观点是否都出现了。比如对比框架A和B不能只搜到A的拥护者写的内容得有B的视角。信源层级优先度排序应该是学术论文/官方文档 权威机构报告 知名技术博客 个人博客 论坛讨论。要实现这些光靠通用搜索引擎不行。我在工程里加了一层“来源偏好路由”如果子问题里出现了“论文”“benchmark”等词优先走学术搜索接口如果出现了“报错”“怎么用”优先走开发者社区和官方文档。这个路由规则可以是硬编码的也可以让模型判断。工业化第一版我建议硬编码稳定可控。2.4 检索失败怎么办纠错与重试真实检索中大概率会遇到召回结果为空、搜索接口超时、或者返回的内容全是广告垃圾的情况。如果没有异常兜底Agent会拿垃圾信息硬编一篇漂亮但错误的内容。我的设计原则是“检索失败必须显式反馈给生成模块”。具体来说每一步检索返回后我会让模型打一个“检索质量分”0到1低于阈值的触发补救路径换关键词重搜、换搜索源重试、或者改用外部知识库。如果多轮补救仍然失败这个子问题会标记为“低置信度”在最终报告里明确呈现为“该部分信息未能验证”而不是让模型强行编造。这个机制看起来简单但对报告可信度的提升效果是决定性的。3. 证据核验深度研究的“事实底线”深度研究产品能不能被用户信任很大程度上取决于证据核验做得好不好。传统的RAG产品只需要“引用来源”但这远远不够。真正的证据核验要求系统能回答三个问题这个信息来源是否可靠这个信息是否支持回答中的论断多个来源之间是相互印证还是存在矛盾3.1 证据链的分级体系我在项目中把证据分为三个层级方便系统化区分一级证据直接被引用片段支持能精确到段落或图表。比如“根据论文xx第3节实验Mamba在10k长度下推理速度比Transformer快1.8倍”这就是一级证据。二级证据多个来源交叉印证同一个结论但每个来源都只是间接支持。比如三篇博客都提到了某个模型的显存占用较低但都没有给出精确数据这就是二级证据。三级证据仅有单一来源或者仅仅是大模型的内部知识。这种信息需要在报告中明确降级展示避免用户误以为是经过多方验证的事实。这个分级不是拍脑袋定的我参考了学术综述里evidence grading的标准框架结合RAG的特性做了简化。落地时让模型在生成的每个关键论断后面附加一个证据等级标签后处理阶段再根据标签决定展示样式。3.2 交叉验证与矛盾检测深度研究里最棘手的情况是不同来源给出了矛盾的结论。比如论文A说某种训练方式能提升模型精度论文B却说在更大规模实验下没有显著提升。这时候如果系统不做矛盾检测报告就会呈现两种自相矛盾的说法用户直接对产品失去信任。我的做法是在汇总阶段加一个独立的“矛盾检查器”。它把各分支提炼出的结构化事实用(spo)三元组或自然语言短句表示放在一起比对判断是否存在互斥关系。如果检测到矛盾不是强行选边站而是生成一个“争议区”把两方观点、各自支持来源、双方实验条件的差异都列出来让用户自己判断。这个模块一开始是用规则做的——关键词匹配语义相似度效果一般。后来改成让大模型专门扮演“审稿人”角色效果好了很多。但要注意成本这个模块只对“重要结论”运行不跑全量。3.3 引用的颗粒度从“给了链接”到“精确到段落”用户对引用的要求是越来越高的。最早给一个网页链接就行后来需要定位到页面里的某个章节现在最理想的状态是定位到某个段落或某张图表。实现精确段落引用核心在于“检索单元”的粒度切分。我对文档做预处理时不是简单把整篇文档切成500字的小块而是先用NLP做段落边界识别再对小段落做拼接合并。这样检索返回的片段天然对应一个完整的论述单元引用的时候可以直接说“见文档3.2节”或“见第4段”。另外引用必须伴随“生成端”的控制模型在作答时我强制要求它每个事实性句子都要标注来源ID。用结构化输出约束JSON模式或语法约束解码让它输出类似“截至2025年Q3该模型在xxx榜单上排名第一。来源: [doc_id12, section3.2]”的形式。后期再做引用验证检查这个doc_id是否真的包含该论断。这一步能过滤掉模型“幻觉参考”的问题——引用来源是真实存在的但内容完全对不上这在早期版本里大量出现。3.4 “无据可说”时的策略深度研究很难保证每个子问题都能找到完美证据。信息不足有两种情况一种是证据太少另一种是证据太散、不足以支撑强结论。在工程上我会给模型明确的指令——如果证据不足允许输出“该问题当前公开资料中缺乏直接证据”但禁止只丢这么一句话交差。正确的输出方式应该是说明尝试了哪些检索方向、找到了哪些相关但非决定性的信息、这些信息指向什么可能的结论并明确标注置信度。这样既保持诚实又不让用户觉得产品什么都不会。事实核查Factuality Check模块是这一整套机制的最后一环。报告生成完毕后再跑一次“回溯核查”对报告里的每一个关键论断反向检索一遍看是否有来源支持。这一步不怕慢因为是异步后处理不影响首屏返回。跑完之后给报告打一个整体事实可信度分0到100低分的会退回上游重新生成。有的团队觉得这个环节多此一举但实测下来它能拦截掉大约10%到15%的严重事实错误是RAG产品上信任感的基石。4. 长程研究的稳态执行与效率边界深度研究任务动辄要跑几分钟甚至更久执行过程的稳定性和资源效率是工业界落地的生死线。实验室里跑通一个脚本很容易但要支撑一个日请求量上千的在线服务完全是另一回事。4.1 超长上下文的规划与管理深度研究过程会产生大量中间结果如果全部无脑塞进上下文很快会超出上下文窗口。我踩过的坑是让Agent自由累积信息跑到第8个子任务时上下文里全是前7个子任务的原始文档模型开始“遗忘”最初的问题目标。后来我引入了“状态摘要”机制——每完成一个子任务不是把原始结果全部丢弃也不是全部保留而是压成三层原始简要信息关键数据点、来源ID、结构化摘要300字以内保留核心结论和证据等级、全局状态已完成哪些子问题、剩余哪些子问题、当前主线结论。新的子任务只需要感知“全局状态相关分支摘要”不需要重新读原始语料。这个设计大幅降低了token消耗还提升了长时间任务的一致性。4.2 步进式执行每一轮都能被观测长程Agent系统在生产环境最大的风险是“黑盒失控”——任务跑了一半你不知道它在做什么也不知道它还要跑多久。我的做法是引入步进式状态机把任务生命周期划分为几个显式阶段规划中、检索中、核验中、汇总中、复核中。每个阶段都向外暴露结构化的事件日志event log包括当前阶段、已消耗token数、已搜索关键词、已返回来源列表。这样既方便给用户展示进度条提升等待耐心也方便自己排查问题。我还设了熔断机制单次任务的检索次数上限、token消耗上限、时间上限。任何一个先触顶任务自动进入“基于已有材料汇总”的降级模式而不是无限跑下去。4.3 效率边界延迟、成本与精度的三角约束如果说长程研究是一辆车那延迟、成本、精度就是三个互相别扭的乘客。任何一方坐得更舒服了另外一方就得憋屈。我实测下来一组典型的参考数据是20个检索步的深度研究串行执行大约需要4到6分钟token消耗在200k到400k之间。通过并行检索能把延迟压到2分钟以内但并发提升的同时汇总阶段的上下文拼接会更拥挤偶尔反而降低精度。如果只追求精度不做并行和压缩成本最高可以再翻一倍。在这个三角约束下我一般建议的策略不是硬优化单一指标而是按用户类型分级。C端用户走轻量模式最多15个检索步突出效率和成本控制B端用户走深度模式允许40到60步检索产出的报告更详尽成本也更高。本质上就是在产品层面做成不同的档位而不是一套参数打天下。4.4 长程任务漂移从“跑偏”到“拉回来”长程研究最常见的失败模式不是报错而是“静默漂移”。任务开始还在研究原问题跑到中后期Agent渐渐被一些细节话题带走最终报告成了某个子主题的深度专题主问题反而没解答清楚。防止漂移除了前面说的全局状态摘要还需要有“主线对齐”的机制。我每完成3个子任务就调用一次轻量检查当前报告骨架和原始用户query还是否一致新增内容和主问题的相关性打分低不低如果漂移超标触发重规划删掉偏离的分支重新聚焦核心问题。这个重规划在必要时可以回滚到上一轮状态保证长跑任务的稳定性。5. 工业界落地实践中的评测与避坑最后分享一些评评测和落地时非常容易被忽视的东西。深度研究这类Agent系统的评测比传统RAG复杂得多因为它跑一次要几十秒钟想回归测试又费钱又费时。5.1 Agentic RAG的评测指标设计整套系统的评测单看最终报告质量是不够的因为出错的环节可能发生在检索、分解、核验或汇总任何一个模块。我把评测拆成三个层级流程质量规划的子问题覆盖率子问题和用户query的相关性、检索尝试次数是否合理、是否发生了漂移。组件质量检索模块单独评测召回率、来源多样性、核验模块单独评测矛盾检出率、引用无误率。结果质量最终报告的完整性、事实正确率、引用命中率、可读性。层级化评测的最大好处是出了问题能快速定位到环节不用猜。我这边的做法是每个评测样本存一份meta日志复盘的时候直接看子任务级的指标比如某个子任务检索质量分只有0.3那问题大概率在检索关键词设计而不是在汇总策略。5.2 人工评测与自动化评测的平衡自动化评测没法完全替代人工判断。事实正确率可以用LLM-as-a-Judge粗筛但“报告是否抓住了用户真正关心的重点”这种问题模型很难拿捏。我不太建议一开始就追求全自动化更好的方式是先跑一批人工标注的黄金测试集golden set问题类型覆盖对比型、调研型、数据查询型等用这套数据集卡基线之后每次改动都先跑一遍黄金集再结合线上指标的回归情况判断改动是否有效。5.3 常见问题速查运行、观测与成本我在排查线上问题时积累了一张问题定位的速查表很多问题一看现象就能猜个八九不离十现象可能原因排查方向报告出现大量“无信息来源”检索质量分阈值太高或检索失败未兜底检查检索日志中质量分分布、失败重试逻辑答案重复或自我矛盾上下文管理不当重复塞入同一来源文档检查状态摘要中是否有去重机制任务跑了很久但产出极短规划阶段子问题拆分过细花费大量token在无用方向上检查规划阶段子问题列表看有没有冗余引用内容与结论对不上生成端未强制结构化引用后处理引用验证缺失检查生成约束是否生效多分支结果冲突交叉验证模块未触发检查矛盾检测模块运行的触发条件这类问题如果等线上用户反馈通常已经造成了比较严重的体验问题。我的经验是日志和观测体系要前置每一步Agent决策都落一条可读日志出问题能复盘到具体步数而不是面对一个笼统的“任务失败”状态干瞪眼。5.4 Agentic RAG的架构选型建议最后聊几句架构选型的私人体会。现在LangGraph、LlamaIndex、CrewAI这些框架各有拥趸但我不建议一上来就套一个特别重的框架。工业界我见过太多团队被框架抽象坑了调试复杂、黑盒多、升级踩坑。第一版如果团队规模小、目标明确我建议用代码直接编排流程Python asyncio 原生LLM接口把每个环节显式写成函数流程清晰、好调Bug。等流程稳定了再评估要不要通过框架来承接多Agent扩展那时选择会更有依据。框架是帮人管理和扩展复杂度的不是用来给项目增加复杂度的。这个系列后面我还会继续更新重点可能会放到Agent的长期记忆设计、多Agent协作的通信协议、以及RAG系统在真实业务场景中的评测实践上。如果你也在落地类似系统欢迎多交流。