企业官网建设流程全解析

1. 从传统 RAG 到 Agentic RAG：为什么“检索一次”不够用了

做检索增强生成（RAG）的同学大概都有过这种体验：搭一个“向量库 + 相似度 Top-K + 拼进 Prompt”的流水线，跑 Demo 的时候效果惊艳，一上真实业务就露馅。用户问一个稍微绕一点的问题，比如“对比 A 方案和 B 方案在成本、交付周期上的差异，并给出适用场景”，传统 RAG 往往只召回几段语义相近的碎片，模型拿着这些碎片硬编，答案看着像那么回事，细看全是漏洞。

这就是 Agentic RAG 要解决的核心痛点。传统 RAG 的本质是一次性检索：把用户 query 编码成向量，去库里捞最相似的 K 条，然后交给模型生成。它假设“最相似的文本就是最有用的证据”，但这个假设在复杂任务里经常不成立。真实的研究型问题往往需要多跳推理、需要交叉验证、需要根据中间结果动态调整检索方向——这些都不是一次 Top-K 能搞定的。

Agentic RAG 的思路是把“检索”从一个静态步骤升级成一个由 Agent 驱动的动态过程。Agent 会自己决定：现在该不该检索、检索什么、用哪个工具检索、检索回来的东西够不够、不够的话下一步查什么。它把 RAG 从“检索-生成”的两段式管道，变成了“规划-检索-核验-再检索-综合”的闭环。

我个人的判断是，这个转变的意义不亚于当年从规则系统到机器学习的跨越。因为它改变的不是某个环节的精度，而是整个系统的问题解决范式。传统 RAG 是一个函数，输入 query 输出 answer；Agentic RAG 是一个过程，输入目标输出经过验证的结论。

1.1 传统 RAG 的三个硬伤

先把传统 RAG 的问题说透，才能理解 Agentic RAG 到底在补什么。

第一，召回与相关性脱节。向量相似度高不等于对回答有用。我做过一个专利检索的场景，用户问“某类电池材料的制备工艺”，向量库召回了一堆标题里带“电池”“材料”的综述文章，但真正关键的几篇具体工艺专利因为措辞差异没被召回。相似度衡量的是语义距离，不是证据价值。

第二，无法处理多跳问题。“A 公司的创始人是谁，他后来创办的 B 公司主打什么产品”——这种问题需要先查 A 的创始人，再拿这个人名去查 B。传统 RAG 一次性检索，要么两段都召回但拼不到一起，要么只召回其中一段。多跳推理是 Agentic RAG 最典型的用武之地。

第三，缺乏自我纠错。传统 RAG 检索完就生成，模型没有机会说“这些证据不够，我再查一次”。它只能基于给定上下文硬答，答错了也没有反馈回路。Agentic RAG 引入了核验环节，让系统能判断证据是否充分、是否矛盾，然后决定下一步动作。

1.2 Agentic RAG 的能力边界在哪里

这里要泼一盆冷水。Agentic RAG 不是银弹，它用更多的检索次数和更长的推理链换取了更高的准确率，代价是延迟和成本。我在实际项目里测过，一个需要 3-4 轮检索的研究型问题，端到端耗时是传统 RAG 的 5-8 倍，Token 消耗是 10 倍以上。

所以效率边界是 Agentic RAG 落地时必须算清楚的一笔账。不是所有问题都值得上 Agent，简单的事实查询用传统 RAG 又快又便宜。判断标准很简单：如果一个问题需要人类研究员查三次以上资料才能回答，那它才值得用 Agentic RAG。这个经验法则帮我省了很多过度设计的坑。

2. 检索环节的深水区：从向量召回走向混合与语义检索

检索是 Agentic RAG 的地基，地基不牢，后面的核验和综合全是空中楼阁。这一块我想展开讲讲，因为太多人把检索简单等同于“调个向量库 API”。

2.1 混合检索：为什么单一向量召回不够

纯向量检索有个致命弱点：它对精确匹配不敏感。用户搜一个具体的型号“XXL-JOB 日志检索”，向量检索可能召回一堆讲“任务调度日志”的泛化文章，但真正讲 XXL-JOB 这个具体框架的反而排在后面。因为向量把“XXL-JOB”这个专有名词的语义稀释了。

解决办法是混合检索（Hybrid Retrieval）：向量召回负责语义相似，关键词召回（BM25）负责精确匹配，两路结果融合排序。融合算法常用 RRF（Reciprocal Rank Fusion），它对不同召回源的分数尺度不敏感，只看得票排名，工程上很稳。

我实测下来，混合检索在专有名词密集的场景（专利、代码、产品文档）比纯向量召回提升明显，召回率能涨 15-25 个百分点。代价是要维护两套索引，但这点成本相比效果提升完全值得。

2.2 语义检索的进阶玩法：查询改写与多查询

用户的问题往往不是最优的检索 query。口语化的提问、省略的指代、模糊的表述，都会让检索效果打折。Agentic RAG 里，Agent 可以在检索前先做查询改写：把“那个电池的工艺咋做的”改写成“锂电池正极材料制备工艺流程”，再拿去检索。

更进一步是多查询检索：让模型针对一个问题生成 3-5 个不同角度的子查询，分别检索后合并结果。这招对覆盖长尾证据特别有效。比如研究“某技术的效率边界”，可以拆成“该技术性能指标”“该技术瓶颈”“该技术对比方案”三个子查询，召回的证据面就宽多了。

注意：多查询会成倍增加检索开销，建议限制在 3-5 个，并且对子查询做去重，否则容易召回大量重复内容浪费上下文窗口。

2.3 检索粒度：段落、句子还是整篇

检索粒度是个容易被忽视但影响巨大的参数。整篇文档召回，上下文完整但噪声大；句子级召回，精准但容易丢上下文；段落级是折中，也是我目前最推荐的默认粒度。

在专利检索这类场景，我甚至会用层级检索：先召回相关专利，再在专利内部定位到具体段落。这样既保证了文档级的相关性，又提供了段落级的精准证据。实现上就是两阶段检索，第一阶段粗排文档，第二阶段细排段落。

3. 证据核验：让 Agent 学会说“我不确定”

检索回来一堆文档，直接丢给模型生成，这是传统 RAG 的做法。Agentic RAG 多了一步：核验。这一步是区分“看起来对”和“确实对”的关键。

3.1 证据充分性判断

Agent 需要判断：当前召回的证据，够不够回答这个问题？这个判断可以交给模型做，给它一个 prompt：“基于以下证据，能否完整回答用户问题？如果不够，还缺什么信息？”模型会输出一个判断和缺口描述，Agent 据此决定是否继续检索。

我踩过的坑是：模型倾向于说“够了”，哪怕证据其实不充分。解决办法是强制模型列出证据与问题各要点的对应关系，哪个要点没有证据支撑就标出来。这种结构化输出比让模型直接判断“够不够”可靠得多。

3.2 交叉验证与矛盾检测

研究型任务里，不同来源的证据经常互相矛盾。Agentic RAG 的价值在于它能发现并处理矛盾，而不是随机选一个信。

做法是让 Agent 对关键结论做交叉验证：同一个事实，至少要有两个独立来源支撑才采信。如果来源冲突，就标注出来，要么继续检索找第三方证据，要么在最终答案里明确说明存在分歧。这个机制在深度研究场景里特别重要，因为研究报告的可信度就建立在证据的可靠性上。

3.3 引用溯源：每个结论都要有出处

Agentic RAG 生成的答案，每个关键结论都应该能追溯到具体证据。这不仅是可信度问题，也是可审计性问题。实现上，让模型在生成时标注引用编号，然后做一次引用校验：检查每个引用编号对应的证据是否真的支持该结论。

我见过太多系统引用是“装饰性”的，随便挂几个来源，实际内容对不上。真正的引用溯源需要校验环节，虽然增加成本，但在专业场景（法律、医疗、专利）是刚需。

4. 长程研究：当 Agent 需要连续工作几十分钟

长程研究是 Agentic RAG 最硬核的场景。用户给一个开放目标，比如“调研某技术路线的产业化现状”，Agent 需要自主规划、连续检索、逐步深入，最后产出一份结构化报告。这个过程可能持续几十轮交互，对系统的规划能力和状态管理是巨大考验。

4.1 任务分解与规划

长程研究的第一步是把大目标拆成可执行的子任务。Agent 需要生成一个研究计划：先查什么、再查什么、每个子任务的目标是什么。这个计划不是一成不变的，Agent 要根据中间结果动态调整。

我的经验是，计划要分层：顶层是研究大纲（3-5 个核心问题），中层是每个问题的检索策略，底层是具体查询。分层的好处是，当某个子任务卡住时，Agent 可以在中层调整策略，而不必推翻整个计划。

4.2 状态管理与上下文压缩

长程研究最大的技术挑战是上下文爆炸。几十轮检索下来，累积的证据可能几十万字，远超模型上下文窗口。必须做上下文压缩：把已消化的证据总结成要点，只保留原始证据的引用，需要时再回查。

我常用的策略是滚动摘要：每完成一个子任务，就把该任务的证据和结论压缩成一段摘要，原始证据存到外部存储。后续推理基于摘要进行，需要细节时再按引用回查。这样上下文始终保持在可控范围。

4.3 效率边界：什么时候该停

长程研究必须有终止条件，否则 Agent 会无限检索下去。终止条件可以是：证据充分性达标、达到最大轮次、边际收益递减（新一轮检索没有带来新信息）。

边际收益递减是最实用的终止信号。我让 Agent 每轮检索后评估“本轮新增信息量”，如果连续两轮新增信息低于阈值，就停止检索进入综合阶段。这个机制能有效避免 Agent 在信息饱和后继续空转。

5. 效率边界与工程取舍：Agentic RAG 的成本账

前面讲了这么多能力，最后必须回到工程现实：Agentic RAG 很贵。贵在延迟、贵在 Token、贵在系统复杂度。这一章专门算这笔账。

5.1 延迟与成本的量化分析

我做过一组对比测试，同一个问题集，传统 RAG 平均延迟 1.2 秒，Agentic RAG 平均 8.5 秒；Token 消耗传统 RAG 约 2K，Agentic RAG 约 25K。这个差距在规模化后会非常可观。

所以落地时必须做分级路由：简单问题走传统 RAG，复杂问题才走 Agentic RAG。路由判断可以用一个轻量分类器，或者让模型先判断问题复杂度。这个设计能省下大量成本。

5.2 缓存与复用策略

Agentic RAG 的检索结果有很强的复用性。同一个子查询在不同研究任务里可能重复出现，缓存检索结果能显著降本。我一般会做两级缓存：查询级缓存（相同 query 直接返回）和证据级缓存（相同文档片段不重复处理）。

5.3 模型选型：不是越大越好

Agentic RAG 里不同环节对模型能力要求不同。规划、核验这类需要强推理的环节用大模型，查询改写、摘要压缩这类相对简单的环节可以用小模型。混合选型能在保证效果的同时把成本压下来。我实测过，把摘要压缩换成小模型，整体成本降了 30%，效果几乎无损。

6. 常见问题与排查技巧实录

这一章是我踩坑踩出来的经验，都是文档里不会写的。

问题一：Agent 陷入检索死循环。表现是反复检索相似内容，不推进。原因通常是证据充分性判断失效，Agent 总觉得“还差一点”。解决办法是设置硬性轮次上限，并且每轮强制要求 Agent 说明“本轮检索与上轮的差异”，没有差异就强制终止。

问题二：引用编号错乱。长上下文里模型经常把引用编号搞混。解决办法是每轮检索后重新编号，并且在 prompt 里明确当前可用的引用范围。别指望模型记住几十轮前的编号。

问题三：核验环节过于严格导致无法收敛。有些场景证据本身就是有限的，Agent 一直找不到“充分”证据。这时候要允许 Agent 在证据不足时输出“基于现有证据的初步结论”，并标注不确定性，而不是死等完美证据。

问题四：多查询召回大量重复。子查询角度没拉开，召回内容高度重叠。解决办法是在生成子查询时强制要求角度互斥，并且对召回结果做去重。

7. 我在实际项目中的几点体会

做 Agentic RAG 这一年多，最大的体会是：别一上来就追求全自动。我最早做的版本想让 Agent 完全自主，结果各种失控。后来改成“人在关键节点确认”的半自动模式，稳定性大幅提升。比如研究计划生成后让用户确认一下，检索方向跑偏时让用户纠偏，这些人工介入点反而让系统更可用。

另一个体会是评估体系要先建。Agentic RAG 的链路长，出问题很难定位。我后来建了一套分环节的评估：检索召回率、核验准确率、引用正确率、最终答案质量，每个环节单独测。这样出问题能快速定位到具体环节，而不是笼统地说“效果不好”。

最后分享一个实用技巧：给 Agent 加一个“反思”步骤。在生成最终答案前，让 Agent 自己审一遍：结论有没有证据支撑、有没有遗漏重要信息、有没有逻辑跳跃。这个自审步骤成本不高，但能拦下不少低级错误。我实测下来，加了反思步骤后，答案的事实性错误率降了差不多四成。