RAG 与 Agent 的边界：什么时候让 AI 自己决定怎么搜

团队里有人照着 LangGraph 的教程做改造，把“腾讯 2025 年营收多少“这种单跳问答也升级成了 multi-hop Agent。原来一次检索、一次生成就能答的问题，现在跑 3 轮检索、3 次生成，用户多等了好几秒——答案还是原来那个数字。

这就是本篇要聊的问题：固定管道和 Agent loop 的边界到底在哪。前面十几篇都在系统内部打转——解析、分片、检索、评估、运维——这篇是篇章四的第一篇，把镜头从系统内部抬到系统边界：同一条检索链路，哪些步骤该写死，哪些该交给模型临场决定。

一、先把两个东西摆清楚：管道和 loop

RAG 的经典架构是固定管道：用户 query → embedding → 检索 → rerank → 生成。步骤写死，每个 query 走同一条路，差别只在每步内部的参数。

Agent 的架构是一个 loop：LLM 决定下一步做什么 → 执行工具 → 观察结果 → 再决定。检索在 loop 里不再是流程的一环，而是模型手里的一件工具——调不调、调几次、调哪个，模型说了算。

所以“RAG 还是 Agent“这个问法本身有点偏。不是谁替代谁，是同一条链路上的控制权分配：哪些步骤写死，哪些步骤交给模型。写死换来可预测——延迟、成本、行为都稳定在预期内；交出去换来灵活——模型能走你事先没画出来的路径。后面所有的取舍，说到底都是这两样东西的互换。

二、判断框架：两个维度

我的判断框架就两个维度，都来自财报场景的真实 query。

维度一：query 的开放度。 对比两个极端。“腾讯 2025 年营收多少“是确定性 query：公司、年份、指标三要素齐全，检索目标明确，一次检索大概率命中，拿到数字就能答。“为什么腾讯的游戏业务毛利在 2023–2024 年下降了“是另一种：得先查毛利数据，再查游戏业务策略，再查行业背景，检索方向有好几个，而且用户没说他想从哪个角度切入——切入角度本身就要有人来定。前者写死在固定管道里绰绰有余，后者写死就难受了。

维度二：容错的成本，工程上体现为需不需要自我评估。 还是这两类 query。查营收，模型看到数字和年份对上，直接答，不需要回头看。答毛利下降的原因，生成完最好多问一句：我引用的行业背景 chunk 是 2023 年还是 2024 年的？要不要再补搜一份 2024 年的行业报告？需要这层自检的原因很直接——数字答错的代价高，模型得自己当自己的质检。第 7 篇讲口径陷阱时展开过类似的逻辑：数字类答案，错一个口径就是错一个结论，这里不重复。

两个维度都高——query 开放、答错代价大——Agentic 值得上。都低，固定管道在延迟和成本上全面占优，没有悬念。费脑子的是一高一低的中间地带，我的习惯是先卡住容错成本这一头：答错越贵，越值得为自检和重搜付延迟。

三、三种模式，从轻到重

决定要 Agentic 之后，还有“上多重“的问题。按实现代价从轻到重，三种模式。

自我反思检索（self-reflection prompting）。 检索一次 → 生成答案 → 让模型对答案做一次批判性评估：答案基于哪些 chunk？这些 chunk 覆盖了 query 的全部维度吗？有没有互相矛盾？评估不通过，改写 query 再搜一次。它最大的吸引力是便宜：只在 prompt 层加一段 assess → retry 逻辑，检索架构一行不动。

名字得交代清楚，这个模式经常被叫成“Self-RAG“，但它和论文里的 Self-RAG（Asai et al., 2023）是两个东西。论文的 Self-RAG 不是 prompt 方案：它专门训练模型生成一组 reflection token（Retrieve、ISREL、ISSUP、ISUSE），让模型在生成过程中逐段自己决定“要不要检索、检索结果相不相关、答案有没有被证据支持“——按需检索和自评都内化在模型参数里，不是外挂一段提示词。这里说的是工程上常见的 prompt 层同名模式，两者别混。

代价也明白——评估不通过时多一轮检索加生成，延迟和 token 都翻倍；但这是按次发生的，不是每次必付，多数 query 一次就过。

多步推理检索（Multi-hop）。 Agent 把复杂 query 拆成子问题逐步搜。“腾讯游戏毛利为什么下降“会被拆成：先搜游戏业务收入结构，拿到结果后再搜 2023–2024 年游戏行业政策变化，最后比较两个时期的毛利数据、找出下降原因。每一步可能用不同的工具——第一步查向量库，第二步上 Web，第三步翻内部报告——由 Agent 决定。这是能力上限最高的一种，代价是延迟随步数累加，而且每一步都是一次出错机会：链条越长，歪的概率越大。

路由型。 系统里摆着多个检索后端——向量库、SQL、知识图谱、Web 搜索——Agent 按 query 动态选择走哪个。“腾讯和茅台毛利率对比“这种问题，会被路由到两个向量库（港股库和 A 股库）各查一轮，再调 SQL 把两家公司历史毛利率的时间序列拉出来。放到财报系统里，它的真实形态通常是一个分析代理层：负责拆问题，先查结构化指标，再查叙述性章节，最后汇总并附上引用。代价是三种里最重的：后端每多一个，路由出错的面就多一块，调试时你还得同时摸清每个后端的脾气。

四、什么时候不要上 Agent

比“怎么用“更重要的是“什么时候别用“。Agentic RAG 有四项隐含成本，教程里一般不写。

• 延迟。 多轮检索加多轮生成，等待时间翻倍起步。固定管道是 1 次检索 1 次生成，Agentic 跑到 3 次检索加 3 次生成不稀奇。
• 成本。 每轮 loop 都是 token。3 轮下来，量级上就是 ×3。
• 不稳定性。 loop 可能卡在“搜了 → 不满意 → 重搜 → 还是不满意“的循环里，把 token budget 耗光。固定管道没有“不满意“这个状态，永远不会这样。
• 引入错误。 每一步检索都可能带进新噪音。某一步里一个关键数据被错误 chunk 替换掉，后面整条推理链就歪了——而且歪得很有条理，最难发现。

“3 轮”“×3“都是量级估计，不是实测数字，实际轮数看 query 和模型。但方向不会变：轮数上去，四项成本一起上去。

我自己的落地规则有两条。先声明，“3 秒“和“80%“都是经验阈值，不是测量结论，在财报问答场景里够用，换场景要重新校准。

第一，用户在等答案，还是离线跑分析？用户在等——经验上意味着总延迟要压到 3 秒以内——就别上多步 Agent，多一轮都是拿体验冒险。反过来，离线跑研报、跑批量分析，屏幕前没人等，多跑几轮无所谓。“比较 50 家半导体公司的资本开支和库存变化，再结合管理层措辞解释原因”，这种题本来就不是人在聊天框里等的活，拆成多步让 Agent 慢慢跑，才是正道。

第二，query 里 80% 以上能靠 metadata 过滤直接搞定吗？能，就不需要 Agent。这条其实是篇章二的老结论：公司、年份、报告期这类强约束，本来就该走 metadata 预过滤，第 6 篇到第 8 篇反复讲的就是这件事。能写死的约束甩给 Agent 临场发挥，是最不划算的一种灵活性。

两条里有一条指向“别上“，就先不上。

五、边界在融合，但工程决策看约束

得承认，Agentic RAG 是真实趋势，不是泡沫。大厂产品里“模型自己去搜“的形态越来越多，但拆开看，实质仍然是 retrieval + rerank + grounding，只是产品层不再让用户感知到“RAG“。被淘汰的不是 RAG，是机械 top-k 拼接式的低配 RAG；模型越强，越需要更智能的检索编排。演进这条线这里不展开，留给第 20 篇。

趋势归趋势，工程决策看约束。我的经验判断：多数财报问答场景，把 metadata 设计好、chunk 设计好、固定管道调好，已经能覆盖 90% 上下的需求；剩下的 10%——复杂多跳、对比分析、探索性研究——才是 Agentic 的用武之地。这个 90/10 是财报问答场景的经验比例，不是定律。客服闲聊、开放研究类场景，比例会明显不同，别直接搬。

回到开头那个反例。把“搜 2025 年营收“做成 multi-hop Agent，问题不在工具——LangGraph 本身没毛病——在于这笔买卖做反了：拿确定性的约束去换用不上的灵活性，延迟和成本翻倍，换回来一个和原来一样的答案。

所以本篇的结论收到这里：要不要 Agentic，看 query 的开放度和容错的成本，不看热度。

另一个同样热门的升级方向是 GraphRAG。我的结论比本篇更直接：大多数财报场景先别上。建图、更新、查询、适用面，四笔账算完再说话——下一篇《Graph RAG 的边界：我为什么不建议你先上它》专门算这笔账。