很多团队第一次做 Deep Research，会把它理解成“检索次数更多的 RAG”。
于是系统不管收到什么问题，都先拆计划、反复搜索、打开网页、整理报告。用户只是问一句“这个产品支持哪些文件格式”，也要等 Agent 跑完一整轮研究。
流程看起来很智能，实际却把一个本来一次检索就能回答的问题，做得更慢、更贵、更不稳定。
反过来，如果用户问的是“请比较三种技术方案在小团队、低运维和数据合规约束下的适用性，并给出能够核查的依据”，只查一次再生成也不够。一次检索可能只拿到某个厂商的宣传页，模型会把不同时期、不同部署方式和不同口径的数据混在一起。
所以这道面试题会越过概念背诵，直接考一个项目判断：
什么问题用普通 RAG 就够，什么问题需要 Agentic RAG，什么问题才值得进入完整的 Deep Research？系统怎样自动分流，又怎样证明分流是对的？
先划清三条路线
普通 RAG 的典型链路是：用户提问，系统检索一批相关片段，把片段交给模型生成答案。
它适合“答案已经存在于某一处资料中”的问题。例如安装方法、字段含义、某条规则的适用条件。工程重点是解析、召回、重排、证据门槛和引用，而不是让模型自主做长期规划。
Agentic RAG 把检索从固定步骤变成 Agent 可以反复调用的工具。模型看到第一次结果不够，可以改写查询，再查一次或打开某个候选来源。它适合一次检索经常不够，但任务仍以“回答当前问题”为主的场景。
Deep Research 的目标不再是一段即时回答，而是一轮完整研究。系统要先明确任务边界，拆开多个子问题，选择工具，反复查找和阅读，识别证据缺口，处理来源之间的冲突，最后交付带出处的结构化报告。
三者构成一条能力和成本逐步增加的光谱，并非互相替代的产品。越往后，系统的自由度越高，可能解决的问题越复杂；与此同时，步骤更多、错误面更大、任务时间更长，验证也更难。
选型要找的是能够满足任务的最低复杂度，“最先进”并不是有效判断标准。
判断一：答案能否从一处证据直接得到？
第一道分流问题最朴素：正确答案是否主要位于一段可检索资料中？
如果是，优先普通 RAG。
例如用户问“系统怎样创建知识库”，目标答案就在产品文档的一节里。系统需要找到正确片段、过滤无关内容、保留来源并回答。此时引入研究规划不会创造更多事实，只会增加调用。
但“一处证据”不等于“只返回一个 Chunk”。有时一项规定跨两个相邻段落，检索端仍可以扩展上下文。判断的重点是任务是否需要主动探索新的来源，而不是检索结果数量是不是一。
普通 RAG 也不等于能力弱。对企业内部政策、说明书和制度问答，它往往更可控：知识范围明确，权限容易处理，延迟和成本更容易预测，测试集也更容易构建。
面试时如果只说“简单问题用 RAG，复杂问题用 Deep Research”，面试官通常会继续问：“复杂到底怎么定义？”
这时要把“复杂”拆成能观察的任务特征。
判断二：是否需要根据中间结果继续行动？
有些问题的答案仍然很具体，但第一次检索无法预先确定下一步查什么。
例如用户问“某个开源组件是否适合当前环境”。第一次搜索拿到版本说明后，系统才发现还要确认操作系统要求；查完系统要求，又发现某个依赖版本存在限制。下一步动作依赖上一步观察，这就出现了 Agent 循环。
如果这种循环通常只有少量步骤，最后仍然交付一个直接答案，可以考虑 Agentic RAG。
它与普通 RAG 的区别不在于有没有向量库，而在于检索是否由固定流水线执行。普通 RAG 预先规定“检索一次再生成”；Agentic RAG 允许模型根据当前证据决定是否再查、改查什么、要不要调用另一个工具。
它与 Deep Research 的区别则在交付目标。Agentic RAG 主要想把当前答案补准；Deep Research 要覆盖一个完整研究任务，包括多个对象、多个维度、证据冲突和最终报告。
判断三：是否必须跨对象、跨来源和跨步骤综合？
完整 Deep Research 通常同时出现几类信号。
第一，问题包含多个研究对象，需要比较多个方案、公司、政策或技术路线，单查一个产品事实无法完成交付。
第二，问题包含多个评价维度。用户不仅问性能，还关心成本、运维、合规、生态和适用边界。
第三，关键结论无法由单一来源支持。系统需要查官方文档、论文、公开报告或其他独立来源，并说明哪些是事实、哪些是推断。
第四，中间结果会改变后续方向。某个候选不满足硬约束，就不必继续深挖；某个关键数据缺失，Agent 要换关键词或寻找替代来源。
第五，交付物是结构化报告，而不是一段短回答。报告要有执行摘要、分项比较、证据引用、信息缺口和建议边界。
这些信号越集中，越有理由进入 Deep Research。只有“问题很长”并不是充分条件。用户可能把一个单点问题写得很长，也可能只用一句话提出一个需要多天调研的开放任务。
不要只看字数，要看任务契约
一个可执行的路由器，至少要从问题里提取五类信息。
一是交付类型：用户要事实答案、解释、比较表，还是完整研究报告。
二是对象数量：问题涉及一个对象还是多个对象，是否要求逐一查证。
三是证据要求：是否要求最新资料、多源验证、论文或官方出处。
四是推理结构：是否需要比较、条件判断、多跳关联或数值计算。
五是风险与预算：结论是否影响重要决策，用户愿意等待多久，允许调用多少工具。
这些字段组合起来，才比一个模糊的“复杂度分数”更容易解释。路由结果也要能返回理由，例如“涉及三个候选和五个比较维度，需要多源引用，因此进入研究链路”。理由不仅方便调试，也能让用户知道为什么这次任务需要更久。
路由器判断的是任务需要什么能力，而不是问题看起来有多难。
一个稳妥的分级路由流程
第一步，先做硬规则判断。
如果用户明确要求“生成带引用的研究报告”“比较多个候选并给出取舍”，可以直接标记为研究候选。相反，如果问题是明确的文档定位或操作步骤，可以优先进入普通 RAG。
第二步，再做轻量语义判断。
规则覆盖不了的问题，可以让一个成本较低的分类器或模型输出结构化字段：对象数、维度数、证据需求、预期交付和推荐路线。这里不需要生成答案，只做分诊。
第三步，执行前设置预算。
即使进入 Deep Research，也要有最大工具调用、最长任务时间、允许的来源类型和报告长度。预算不是最终停止条件，但它是避免任务失控的硬边界。
第四步，执行中允许升级和降级。
普通 RAG 如果证据不足，可以升级到补充检索；研究任务如果很快找到唯一权威答案，也不必为了凑步骤继续搜索。因此路由应被设计成可调整的执行策略，而非一次性标签。
第五步，记录路由和实际轨迹。
系统要知道最初选择了哪条路线、为什么选择、实际调用了多少次工具、最后是否完成。没有这些记录，就无法发现路由器把简单问题送进昂贵链路，或把真正复杂的问题错误压成一次检索。
为什么“一个模型全包”不够稳？
最简单的实现，是把所有问题交给同一个大模型，让它自己决定搜几次。
这能跑通 Demo，但生产上有三个问题。
第一，行为不容易预测。同样的问题换一种说法，模型可能选择不同步数，延迟和成本波动很大。
第二，模型可能偏爱行动。训练数据里如果搜索轨迹太多，它会在常识题上也调用 Search，看起来勤奋，实际浪费资源。
第三，模型可能过早收尾。它看到一份看似相关的资料就生成结论，没有意识到用户要求的是多方案比较。
因此，路由层和执行层要分开观察。路由层决定任务走哪一级能力；执行层在该级能力内部决定下一步行动。两者都可以用模型，但目标、输入和评估方式不同。
三类最常见的误路由
误路由一：所有问题都进入 Deep Research
症状是工具调用数很高、简单问答也要等待、报告里出现大量对用户无用的背景。
根因通常出在产品没有定义研究入口，不应简单归咎于模型能力。团队把“能多步搜索”当成卖点，却忘了用户真正要的是快速拿到可信结果。
修复方式是补充简单事实题、单文档定位题和无需搜索题，把“选择更短链路”也当成正确行为。
误路由二：所有问题先走普通 RAG，失败才升级
这种做法看似省钱，却可能让用户先收到一次低质量回答，再等待第二次研究。更严重的是，第一次答案已经锚定了后续方向，升级后的 Agent 可能沿着错误前提继续查。
对明确要求多对象比较、最新证据和完整报告的请求，应在执行前识别，不必先制造一次失败。
误路由三：把“资料多”当成“需要研究”
一个知识库可能有十万份文档，但用户问的事实仍然只在一段文本里。资料规模大是检索系统的问题，不自动意味着要用 Deep Research。
反过来，哪怕只有几个网页，只要需要跨来源比较、处理矛盾和形成判断，也可能是研究任务。
路由评测集应该怎么建？
路由是否准确，不能靠看几个演示问题。
首先建立三类样本。
普通 RAG 样本包括单点事实、操作说明、规则定位和明确的无答案问题。
Agentic RAG 样本包括需要补充查询、打开正文、做一次计算或根据初次结果换关键词的问题。
Deep Research 样本包括多候选比较、多源验证、开放分析、信息冲突和结构化报告任务。
然后加入边界样本。边界样本最有价值：一条很长的单点问题、一条很短的开放研究请求、明确要求“最新”但只涉及一个事实的问题、看似比较但实际上已有官方对照表的问题。
标注时不要只给路线，还要写理由和最低所需动作。否则标注者之间很容易凭感觉争论“难不难”。
同一次路由要同时检查任务质量、等待时间、工具调用和完成情况。
路由验证不能只算准确率
第一类指标是路由正确性：模型选择的路线是否与人工标注一致，尤其关注把复杂任务压到简单链路的漏判。
第二类指标是最终质量：路由正确不代表任务完成。普通 RAG 是否找到直接证据，Deep Research 是否覆盖关键维度并提供可核查来源。
第三类指标是执行成本：工具调用数、模型调用数、总 Token 和任务时间。这里不预设“越少越好”，而是看是否存在无效步骤。
第四类指标是稳定性：相同意图换一种说法，是否仍进入相近路线；工具失败后是否无边界升级。
第五类指标是用户契约：系统是否提前说明预计交付和等待方式。一个需要较长时间的任务，如果界面仍假装即时问答，体验同样不合格。
最终要按问题类别看混淆矩阵，而不是只看一个总分。把普通 RAG 错送进 Deep Research，主要损失是成本和延迟；把真正的研究任务错送进普通 RAG，主要损失是答案完整性和可信度。两类错误的代价不同，不能简单等权。
路由还要连接真实的产品交互
后端选对路线，前端没有表达清楚，用户依然会觉得系统失控。
普通 RAG 可以保持即时问答形态，直接展示答案和证据。Agentic RAG 可以提示“正在补充核对一个来源”，让用户知道为什么比普通回答多等一步。Deep Research 则更像一个异步任务，需要先确认研究范围，再展示当前阶段、已覆盖内容和仍待核验项。
用户也应该能够改变路线。如果他只想快速确认一个事实，可以缩小交付范围；如果他看到初步答案后希望做完整比较，可以升级为研究任务。路线切换时要继承已经获得的证据，不能把前一条链路的工作全部丢掉。
产品层还要处理取消和部分结果。用户取消 Deep Research 时，系统应停止新工具调用，保存已经核验的材料，并说明哪些内容尚未完成。不能因为没有生成最终长报告，就让前面的研究全部不可见。
这反过来要求路由输出不只有一个分类标签，还要包含预期交付、可用工具、预算边界和任务状态。只有这样，前端才能把“为什么需要研究、现在进行到哪里、用户还能做什么”讲清楚。
路由错误怎样进入下一轮迭代？
线上反馈不能只记“用户点了不满意”。要把问题拆回路由和执行两个阶段。
如果一条简单事实题进入研究链路，但最终答案正确，问题主要在路由成本。应把这类 Query 加入轻量链路的困难样本。
如果任务进入正确路线，却因为工具空结果失败，问题在执行和容错，不应拿它训练路由器。
如果普通 RAG 找到一段相关资料却无法覆盖用户要求的比较维度，说明任务在入口被低估，应补充“多对象、多维度、完整报告”等特征。
如果人工也无法判断路线，先修任务定义和标注说明。把模糊标注直接喂给模型，只会让路由行为看起来随机。
路由之后，还要有“退出机制”
进入 Deep Research 不代表必须跑满预算。
如果研究过程中发现问题存在唯一、明确、权威的直接答案，系统可以提前收口，并说明为什么不再扩展。
如果搜索多轮仍缺少关键资料，系统也应该输出已确认结论、未确认部分和信息缺口，而不是继续消耗预算或把推断写成事实。
如果用户要求的任务超出工具能力，例如需要访问未授权的私有系统或执行高风险操作，路由器应在入口拒绝或转人工，不能假装 Agent 可以完成。
所以路由不是单纯的性能优化。它同时规定了能力边界、风险边界和交付边界。
面试官继续追问，怎么接？
追问一：为什么不直接让最强模型自己判断要搜几次？
模型可以参与判断，但仍要输出结构化路由结果和理由，并受预算、权限和允许工具约束。否则行为难以复现，简单任务也可能被过度执行。
追问二：问题里带“最新”，就一定要走 Deep Research 吗？
不一定。“某版本最新发布日期”可能一次搜索官方页面就能确认；“最近一年多个方案的进展与差异”才需要跨来源综合。时效要求只是一个信号，还要看对象数和交付类型。
追问三：路由错了怎么办？
保留升级和降级通道。简单链路证据不足时可以升级；研究链路很快获得充分证据时可以提前收口。关键是记录触发原因，事后能回放并加入路由评测集。
追问四：怎样控制 Deep Research 的成本？
第一层就是分级路由，只让真正需要研究的问题进入昂贵链路。进入后再通过最大预算、提前终止、工具缓存和模型分工控制成本。不能只回答“加缓存”。
追问五：怎样防止用户故意把普通问题包装成复杂报告？
尊重用户的交付要求，但系统仍可以先识别事实范围。如果结论简单，可以用较短链路完成后再按要求组织格式，而不是为了报告篇幅制造无意义搜索。
一分钟讲清三档研究路由
我会把普通 RAG、Agentic RAG 和 Deep Research 看成一条能力与成本逐级增加的光谱，而不是三个谁替代谁的方案。答案能从一处资料直接定位的问题走普通 RAG；需要根据初次结果补一两次搜索或打开正文的问题走 Agentic RAG；只有涉及多个对象、多个评价维度、多源交叉验证、动态调整和结构化报告的问题，才进入完整 Deep Research。
工程上我会先抽取任务契约，包括交付类型、对象数量、证据要求、推理结构和预算，再由规则加轻量模型输出路线与理由。执行过程中允许升级、降级和提前收口，同时记录初始路由、工具轨迹和最终完成情况。
验证时不能只算路由准确率。我会准备普通事实题、补充检索题、完整研究题和一批边界题，分别看最终质量、总耗时、工具调用、无法完成率和路线稳定性。尤其要区分两种错误：把简单问题送进研究链路会浪费成本，把研究任务压成一次检索则会损害结论完整性和可信度。最终要用最低够用的复杂度交付可靠结果，而非让所有问题都显得“很智能”。
你的分流系统真的落地了吗
回答前先对照实现与 Trace，分清已有执行链路、可解释的路由规则和仍停留在设计阶段的部分。
- 你的系统是否真的存在三条不同执行链路，还是只有一条 Prompt？
- 路由依据来自规则、模型还是人工选择？能否输出可解释理由？
- 是否有普通题、研究题和边界题组成的路由评测集？
- 你能拿出真实的工具调用和任务时间记录吗？没有就不要承诺降本比例。
- 哪些能力已经实现，哪些只是架构设计？面试时要明确区分。
这道题的专业度，最后落在一句话上：知道什么时候不该用 Deep Research。