企业官网建设流程全解析

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

做过 RAG 的人大概都有过这种体验：搭一个“向量库 + 相似度召回 + 拼 prompt”的流水线，demo 阶段效果惊艳，一上真实业务就露馅。用户问“我们去年Q3在华东区的退货率为什么比Q2高”，传统 RAG 会怎么做？把这句话整体 embedding，去向量库里捞 top-k 个 chunk，运气好捞到几段退货政策文档，运气不好捞到一堆无关的季度报表，然后让模型硬答。答案要么是“根据提供的资料无法确定”，要么是一本正经地胡说八道。

问题出在哪？出在把“检索”当成了一个一次性动作，而不是一个需要规划、分解、验证、迭代的认知过程。人类专家面对上面那个问题会怎么做？先拆解：需要退货率数据、需要华东区维度、需要Q2和Q3两个时间段、需要对比分析。然后逐个去找数据源，找到数据后还要核对口径是否一致，发现某个数据缺失还要换个途径再找。这一整套“想—找—看—再想—再找”的循环，才是真实的研究行为。

Agentic RAG 要解决的就是这个。它的核心主张是：让 Agent 来主导检索过程，而不是让一次向量召回决定生死。Agent 拥有规划能力（把复杂问题拆成子问题）、工具调用能力（可以查向量库、查 SQL、查网页、调 API）、反思能力（拿到结果后判断够不够、对不对、要不要再查）、以及记忆能力（把中间结论存下来供后续推理用）。

我自己的理解是，传统 RAG 是“开卷考试只准翻一页”，Agentic RAG 是“开卷考试允许你翻很多页、做笔记、交叉验证，最后交卷”。这个差别在简单事实型问答上不明显，但在深度研究（Deep Research）类任务上就是天壤之别。

那什么叫深度研究？不是“帮我查一下某公司的CEO是谁”，而是“帮我分析某行业未来三年的竞争格局和关键变量”。这类任务的特点是：信息分散在多个来源、需要多跳推理、需要时间维度的对比、需要区分事实与观点、需要对证据的可信度做判断。这正好对应了标题里的三个关键词：检索、证据核验、长程研究。下面我会把这三块拆开讲，再聊聊效率边界这个绕不开的现实问题。

2. Agentic RAG 的整体架构设计思路

2.1 为什么是“Agent 主导”而不是“流程编排”

很多人第一反应是用 LangChain 或类似框架把流程串起来：先 query 改写，再检索，再 rerank，再生成。这本质上是固定流程（pipeline），每一步都是预设好的，Agent 没有决策权。问题在于，真实问题的解决路径是不确定的——有的问题需要查3个源，有的需要查10个；有的检索一次就够，有的要迭代5轮。固定流程要么过度检索浪费成本，要么检索不足导致答案质量差。

Agentic RAG 的做法是给 Agent 一套工具和一个目标，让它自己决定下一步做什么。这里的“Agent”可以是一个 LLM 驱动的循环：观察当前状态 → 思考下一步 → 选择工具 → 执行 → 观察结果 → 继续循环，直到它认为信息足够或达到终止条件。

我实测下来，这种设计在复杂任务上的召回完整度比固定 pipeline 高出一大截，代价是 token 消耗和延迟都上去了。所以关键不是“要不要用 Agent”，而是“在什么任务上值得用 Agent”。

2.2 核心组件拆解

一个能跑的 Agentic RAG 系统，我通常会拆成这么几块：

• 规划器（Planner）：负责把用户 query 分解成子问题，或者生成一个研究计划。可以是显式的（让 LLM 输出一个步骤列表），也可以是隐式的（Agent 在循环中动态决定）。
• 检索工具集（Retrieval Tools）：向量检索、关键词检索（BM25）、SQL 查询、图数据库查询、网页搜索、API 调用。工具越多，Agent 的灵活性越高，但选择难度也越大。
• 证据核验模块（Verifier）：拿到检索结果后，判断相关性、可信度、时效性，剔除噪声和矛盾信息。
• 记忆/状态管理（Memory）：存中间结论、已查过的源、待验证的假设。没有记忆的 Agent 会重复劳动。
• 生成与引用（Generator）：最终答案必须带引用，且引用要能追溯到原始来源。

这几块不是必须全部显式实现，但缺了哪块，系统在复杂任务上就会露怯。比如没有 Verifier，Agent 会把一条微博爆料和一份官方年报同等对待；没有 Memory，它会反复查同一个东西。

2.3 一个容易踩的坑：工具太多反而变笨

我一开始给 Agent 配了七八个检索工具，结果发现它在工具选择上频繁出错，经常用网页搜索去查本该查数据库的结构化数据。后来砍到三个核心工具（向量库、SQL、网页搜索），并在工具描述里写清楚“什么场景用哪个”，准确率立刻上来了。

提示：工具的数量和 Agent 的决策准确率不是正相关。工具描述的质量比数量重要得多，每个工具都要写清楚适用场景、输入格式、返回内容的样子。

3. 检索环节的深水区：从意图识别到多路召回

3.1 意图识别决定了检索的天花板

检索效果差，八成是意图没识别对。用户说“帮我看看那个新政策对我们有啥影响”，这里的“那个新政策”指什么？“我们”是谁？影响是指业务影响还是合规影响？如果 Agent 不先把这些歧义消解掉，后面检索再精准也是白搭。

我的做法是在 Agent 循环的第一步强制做意图澄清：让 LLM 输出一个结构化的意图表示，包含实体、时间范围、任务类型（事实查询/对比分析/趋势预测）、约束条件。如果关键信息缺失，Agent 可以选择向用户反问，或者基于上下文做合理假设并标注出来。

这一步看起来简单，但它直接决定了后续 query 改写的质量。意图识别错了，query 改写就是南辕北辙。

3.2 多路召回与融合排序

单一向量检索的问题在于，它对精确匹配和结构化查询很弱。用户问“合同编号 HT-2024-0871 的付款条款是什么”，向量检索可能召回一堆讲付款条款的通用文档，却漏掉那份具体合同。这时候需要关键词检索（BM25）来兜底。

我通常用三路召回：

三路结果出来后，用 RRF（Reciprocal Rank Fusion）或交叉编码器做融合排序。RRF 的好处是不需要训练，对分数尺度不敏感，工程上很省事。交叉编码器精度更高但慢，适合对质量要求极高的场景。

3.3 Query 改写的几个实用套路

Agent 在检索前对 query 做改写，能显著提升命中率。我常用的几种：

• HyDE（假设文档嵌入）：让 LLM 先“编”一段可能包含答案的假文档，用这段假文档去检索。原理是假文档的语义分布更接近真实答案文档，比原始短 query 的召回效果好。实测在开放域问答上提升明显，但在需要精确匹配的场景要慎用。
• 子问题分解：把“A 和 B 哪个更适合我们”拆成“A 的优缺点”“B 的优缺点”“我们的需求是什么”三个子查询分别检索。
• 多视角改写：同一个问题用不同措辞生成3-5个 query 并行检索，取并集。适合术语不统一的领域。

注意：Query 改写不是越多越好。每多一轮改写就多一次 LLM 调用，成本和延迟都上去了。我的经验是，简单事实查询不做改写，复杂分析类查询做1-2轮改写就够了。

3.4 关于“RAG 知识库能不能存图片”这件事

热词里有人问这个，我顺带说下。传统 RAG 知识库主要存文本 chunk，图片要么被 OCR 成文本，要么被忽略。但现在多模态 embedding 已经比较成熟了，可以把图片和文本映射到同一向量空间，实现图文混合检索。工程上的做法是：图片单独走一个多模态编码器生成向量，文本走文本编码器，检索时两路都查，结果融合。如果只是想让图片“可被检索”，最省事的还是 OCR + 图片描述生成，把图片转成文本再入库。

4. 证据核验：让 Agent 学会“不轻信”

4.1 为什么证据核验是 Agentic RAG 的分水岭

传统 RAG 的一个致命问题是它不知道自己不知道。检索回来的内容不管对不对，都会被当成事实喂给 LLM。如果检索结果里混入了过时信息、错误信息、甚至恶意注入的内容，LLM 会照单全收。

Agentic RAG 必须有一个核验环节，对每条证据做可信度评估。这个环节做得好不好，直接决定了系统在深度研究任务上能不能用。

4.2 核验的三个维度

我通常从三个维度评估一条证据：

• 来源可信度：官方文档 > 权威媒体 > 个人博客 > 匿名论坛。这个可以预先给数据源打标签，Agent 检索时带上来源元数据。
• 时效性：很多领域的信息有保质期。金融数据可能按天算，技术文档可能按版本算。Agent 需要判断证据的时间是否在有效范围内。
• 一致性：多条证据之间是否矛盾。如果两条证据说法冲突，Agent 不能随便选一条，而要标记出来，要么继续找第三条来仲裁，要么在最终答案里呈现分歧。

4.3 用“自一致性”做交叉验证

一个很实用的技巧是自一致性检查：让 Agent 对同一个子问题用不同的检索路径查两次，如果两次结果一致，可信度就高；如果不一致，就触发深入调查。这本质上是用冗余来换可靠性。

我试过在一个合同分析任务里用这个策略，Agent 第一次从向量库查到一条条款，第二次从关键词检索查到同一条但上下文不同，两次拼起来才发现完整意思。如果只查一次，很可能就漏了关键限定条件。

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

最终答案里的每一句话，都应该能追溯到具体的证据片段。工程上的做法是让 LLM 在生成时输出结构化引用，比如[1]对应某文档的某段落。然后有一个后处理步骤验证引用是否真实存在、是否支持该结论。

这一步在演示时经常被省略，但在生产环境里是刚需。没有引用溯源的 Agentic RAG，本质上还是一个更贵的黑盒。

5. 长程研究：多跳推理与迭代检索的工程实现

5.1 什么是长程研究任务

长程研究（Long-horizon Research）指的是那些需要多轮检索、多跳推理、跨多个信息源才能完成的任务。比如“分析某公司过去三年的战略变化及其对市场份额的影响”，这需要：找到三年的年报、提取战略相关段落、找到市场份额数据、做时间序列对比、分析因果关系。任何一步的信息缺失都会导致最终结论不完整。

这类任务对 Agent 的要求是：能记住已经查过什么、还缺什么、下一步该查什么。这需要一个显式的状态管理机制。

5.2 用“研究计划 + 待办列表”管理长程任务

我的做法是让 Agent 在开始研究前先生成一个研究计划，包含若干个子任务，每个子任务有状态（待办/进行中/已完成/受阻）。Agent 每轮循环时先看当前待办列表，选择优先级最高的子任务执行，完成后更新状态。

这个机制的好处是：

• 防止 Agent 跑偏或重复劳动
• 任务受阻时可以跳过，先做其他子任务，最后再回来
• 整个研究过程可追溯、可中断、可恢复

实现上可以用一个简单的 JSON 结构存状态，每轮循环把状态序列化后放进 prompt。状态不要太大，只保留关键信息，否则 prompt 会爆炸。

5.3 多跳推理的链式检索

多跳推理的典型模式是：第一跳找到实体 A，第二跳用 A 的属性去查 B，第三跳用 B 的信息回答原问题。比如“某公司CEO的母校在哪个城市”，需要先查CEO是谁，再查他的母校，再查母校所在城市。

Agent 实现多跳的关键是把上一跳的结果作为下一跳的查询条件。这听起来简单，但工程上要注意：上一跳的结果可能有多个候选，Agent 需要判断用哪个；如果上一跳没找到，要有回退策略。

我踩过的一个坑是：Agent 在第一跳拿到一个模糊结果后，直接把它当成确定事实往下查，导致后面全错。后来加了一个“置信度检查”，只有置信度高于阈值的结果才能作为下一跳的输入，否则先做澄清检索。

5.4 迭代终止条件的设计

Agent 不能无限循环下去。终止条件通常有这几个：

• 所有子任务都已完成
• 达到最大迭代轮数（比如15轮）
• 连续N轮没有新增有效信息
• Token 预算耗尽

这几个条件要组合使用。只设最大轮数会导致该停的时候不停，只设“信息足够”会导致 Agent 永远觉得不够。我的经验是：最大轮数设为预期轮数的1.5倍，同时监控“新增有效信息”的速率，速率降到阈值以下就提前终止。

6. 效率边界：Agentic RAG 的成本与延迟现实

6.1 成本到底高在哪

Agentic RAG 比传统 RAG 贵，贵在三个地方：

• LLM 调用次数：传统 RAG 一次生成，Agentic RAG 可能十几次甚至几十次调用（规划、改写、核验、生成各一次）。
• 检索次数：多路召回、迭代检索，检索次数是传统 RAG 的数倍。
• 上下文长度：Agent 的 prompt 里要带历史状态、工具描述、证据片段，token 消耗大。

我实测过一个中等复杂度的研究任务，传统 RAG 大概消耗 5k token，Agentic RAG 消耗了 80k token，差了16倍。这个成本差异在 demo 阶段无所谓，在生产环境就是真金白银。

6.2 什么时候不值得用 Agentic RAG

不是所有任务都值得上 Agent。以下几类任务用传统 RAG 甚至直接 LLM 回答就够了：

• 简单事实查询（“某产品的保修期是多久”）
• 单跳检索能解决的问答
• 对延迟极度敏感的场景（比如实时客服）
• 预算极其有限的场景

判断标准很简单：如果一个问题人类专家查一次资料就能回答，就不需要 Agentic RAG。只有当问题需要“查多次、想多轮、交叉验证”时，Agent 的价值才体现出来。

6.3 降本增效的几个实操手段

• 模型分级：规划、核验这类“思考”环节用强模型，改写、摘要这类“执行”环节用便宜的小模型。我通常用大模型做 Planner 和 Verifier，小模型做 Query Rewriter 和 Summarizer。
• 缓存：相同或相似的子查询结果缓存起来，避免重复检索。语义缓存（用 embedding 判断 query 相似度）比精确匹配缓存命中率高很多。
• 并行化：多个独立的子任务并行执行，而不是串行。比如三路召回可以同时发起，不用等一路完成再发下一路。
• 提前终止：设计好终止条件，该停就停。我见过太多 Agent 在信息已经足够的情况下还在反复检索，纯粹是浪费。
• 证据压缩：检索回来的长文档先做摘要或抽取关键句，再喂给 LLM，而不是把整篇文档塞进去。

6.4 延迟优化的取舍

Agentic RAG 的延迟通常在几十秒到几分钟，这对交互式应用是致命的。优化手段包括：流式输出中间结果（让用户看到 Agent 在干什么）、异步执行非关键路径、预取可能用到的数据。

但有些延迟是省不掉的——多轮推理本身就需要时间。我的建议是：对延迟敏感的场景，把 Agentic RAG 做成异步任务，用户提交问题后先收到“正在研究”的反馈，完成后推送结果。这比让用户盯着转圈圈体验好得多。

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

7.1 Agent 反复查同一个东西怎么办

这是最常见的问题，根因通常是记忆机制没做好。Agent 不记得自己查过什么，或者记得但没在决策时参考。解决办法：在每轮 prompt 里显式列出“已查询过的 query 和结果摘要”，并加一条规则“不要重复已查询过的内容”。如果还不行，就在工具层面做去重，相同 query 直接返回缓存结果并提示 Agent“此查询已完成”。

7.2 检索结果相关性差怎么排查

按这个顺序排查：

1. 意图识别对不对？把 Agent 输出的意图表示打出来看。
2. Query 改写有没有跑偏？对比原始 query 和改写后的 query。
3. Embedding 模型适不适合这个领域？通用模型在专业领域可能表现很差。
4. Chunk 策略合不合理？chunk 太大噪声多，太小语义不完整。
5. 召回数量够不够？top-k 设太小会漏，设太大噪声多。

7.3 证据矛盾时 Agent 怎么处理

理想情况下 Agent 应该识别矛盾并呈现分歧，但实际中它经常随便选一个。解决办法是在 Verifier 里加一个矛盾检测步骤：把多条证据两两对比，如果发现冲突，标记出来并要求 Agent 要么找仲裁证据，要么在答案里说明分歧。这个逻辑要写进 prompt，不能指望 Agent 自发做到。

7.4 长程任务中途失败怎么恢复

把 Agent 的状态（研究计划、已完成子任务、中间结论）持久化到外部存储，每轮循环后保存。失败后可以从上次状态恢复，不用从头再来。这个在工程上很重要，尤其是任务跑几分钟的时候。

8. 我个人的一些实践体会

Agentic RAG 这个概念现在很热，但我想说的是，它不是银弹。我见过不少团队一上来就搞全自动 Agent，结果效果还不如精心调优的传统 RAG。Agent 的价值在于处理不确定性，如果你的任务本身很确定，用 Agent 就是杀鸡用牛刀。

另一个体会是，证据核验这块的投入回报比最高。很多人把精力花在检索优化上，但检索再准，如果核验环节缺失，最终答案还是可能被一条错误证据带偏。我现在的做法是，Verifier 的 prompt 写得比 Generator 还仔细，宁可多花点 token 在这里。

最后说个工程上的小技巧：Agent 的 prompt 里一定要有负面示例。告诉它“不要做什么”比“要做什么”更有效。比如“不要在没有引用的情况下下结论”“不要在证据不足时强行回答”“不要重复已完成的查询”。这几条加进去，Agent 的行为会规矩很多。

这个方向还在快速演进，多模态检索、图结构 RAG、自适应检索策略都是值得关注的点。但不管技术怎么变，核心逻辑不变：让系统像人一样做研究——有计划、会验证、能迭代、知边界。