企业官网建设流程全解析

你自己试试就知道了：RAG 单独用，能应付“文档里有没有”的问题，但扛不住“文档之间怎么串起来”的问题。今天这篇不绕弯子，直接讲透 RAG、AI Agent 和 Agentic RAG 到底怎么演进、怎么拆解、怎么落地。文章会有大量实操细节和踩坑记录，适合正准备做知识库问答、智能客服、文档分析这类场景的人，也适合刚把大模型跑通、想往业务纵深走一步的学习者。

严格说，RAG 不是新东西，它就是把“检索”和“生成”拼在一起。你有一条用户问题，先从知识库里捞相关片段，再把片段连同问题一起丢给大模型，让它基于材料回答。这套路最早是为了解决大模型胡编乱造的问题，因为模型不知道的事实，你给它一段参考资料，它就能照着说。但真实业务一旦跑起来，你会发现事情没那么简单：用户的问题经常是多跳的、模糊的、带隐含条件的，而你准备的检索流程是死的。检索一次、拼装一次、输出一次，中间没有任何自我修正的机会。

这就是 Agentic RAG 出现的理由。它不是换了个模型，也不是换了套向量库，而是把原来“检索流水线”变成“Agent 决策闭环”：Agent 自己决定要不要查、查什么、查几次、结果够不够、要不要换个工具再查。检索从“固定步骤”变成了“可调用的能力”，RAG 从“管道”变成了“工具”。这篇文章我会从动机讲起，拆两种主流架构，再带你把核心链路手写一遍，最后给一张常见问题的排查表。

1. 为什么 RAG 单打独斗不够用

先别急着学 Agentic RAG 的花活。你得先明白，RAG 单独用到底卡在哪。不然你连自己系统为什么答不对都说不清楚。

1.1 真实业务里 RAG 先是“真香”，再是“露馅”

我去年帮某企业内部知识库做问答机器人，第一阶段就是标准 RAG：上传几百份操作手册和技术文档，拆成小块做向量化，用户提问后做相似度检索，再拼接 Prompt 让模型生成答案。刚上线那阵子效果确实不错，常见操作类问题基本能答对。团队很开心，我也觉得这事成了。

结果测试人员随手问了句：“我们采购流程里提到如果合同金额超过五万，需要走二次审批，那二次审批的上游节点是什么？”

这个问题当场把 RAG 打回原形。因为答案的关键信息不在同一个文档块里：一个块讲采购流程，另一个块讲合同审批细则，还有一个块藏在附录的流程图说明里。标准 RAG 只做一次 Top-K 检索，拿回来的片段要么只有一部分答案，要么干脆关键词没对齐，最终模型只能含糊其辞。

这不是偶然失误，而是标准架构本身的短板。它把“检索”当成一次性的、孤立的动作，没有考虑多源信息拼接、也没考虑需要回头补充材料。

1.2 三个根因：一次检索、没有状态、不能反思

我把标准 RAG 的问题总结成三个根因，这三个根因也是理解 Agentic RAG 的钥匙。

第一，单轮检索覆盖不了多跳问题。复杂问题往往需要拆成多个子问题，每个子问题查一遍。比如刚才那个流程问题，正确的做法是先确认“合同金额超过五万要二次审批”，再反查“二次审批属于哪条流程线路”，最后还要找“该线路的上游节点定义”。这是典型的多跳检索，标准 RAG 没有“多次检索+中间推理”这种执行模型。

第二，系统是无状态的。你问完一个问题再追问“那如果换成十万呢？”，标准 RAG 是接不上的。它不记得刚才聊了什么，也不会因为你提到“换成十万”就去重新检索关于金额档位的材料。很多团队用各种办法硬塞历史记录进 Prompt，但检索仍然是针对当前问题独立跑的，缺少对上下文的动态感知。

第三，没有自我检查机制。标准 RAG 答完就结束了，不会看自己的回答是否覆盖了关键信息点，也不会因为材料不足重新检索。结果就是“缺料硬答”，用户拿到一个看似完整、实则片面的答案，如果不懂业务，根本看不出漏洞。

这三个问题叠加起来，标准 RAG 在真实业务里的定位就变得很尴尬：它能做“单点知识问答”，但做不了“需要串联信息的场景”。而串起信息、拆解问题、反复确认，恰好是 Agent 的看家本领。

2. Agent 把“检索”升级成“能力”

API 调用谁都会，但让模型“会思考先查什么、再查什么”，这才是 Agent 带来的质变。

2.1 Agent 的四个基本能力

先说清楚 AI Agent 是什么。一个合格的 Agent 至少具备四样能力：规划、记忆、工具调用、反思。

规划能力是指把复杂任务拆成子步骤。比如用户问“对比 A 和 B 两份合同的违约责任差异”，Agent 要先规划：提取 A 合同相关条款、提取 B 合同相关条款、逐条对比、输出差异列表。每个子步骤都可以对应一次工具调用。

记忆能力分为短期和长期。短期记忆就是当前对话的上下文，长期记忆是跨会话保存的用户偏好或历史决策。RAG 本身可以扮演长期记忆的外部存储，Agent 则决定什么时候把相关记忆拉回来。

工具调用是 Agent 接触外部世界的窗口。对 Agentic RAG 来说，最重要的工具就是“检索知识库”，但还可以有：查数据库、调业务 API、执行代码、读网页。工具越多，系统能处理的任务类型越广。

反思能力是最容易被忽略的。它是指 Agent 在执行完一轮操作后停下来检查：当前信息够不够？答案有没有矛盾？需不需要换个关键词再查一次？反思机制是 Agent 比管道灵活的关键原因。

2.2 检索从流水线节点变成 Agent 的决策工具

在标准 RAG 里，检索是固定顺序里的一环：Embedding → 召回 → 重排 → 生成。在 Agentic RAG 里，检索只是 Agent 众多工具中的一个动作，什么时候查、查几次、用什么语句查，全都由 Agent 根据输入动态决定。

这里有个很重要的区别：标准 RAG 的“检索 query”就是用户问题原样，或者做一轮浅层改写。Agentic RAG 的检索 query 则是 Agent 规划出来的子问题。比如用户问“我预算两万能买你们的可移动工作站吗”，标准 RAG 会直接用这句话去查，结果匹配到一堆无关手册；而 Agentic RAG 会先拆出子查询：“预算两万元”、“可移动工作站型号”、“价格表”，甚至转去查产品数据库，而不是只查文档库。

另一层区别在于“检索后动作”。标准 RAG 拿到结果就拼 Prompt。Agentic RAG 拿到结果后会判断：这些片段足以回答吗？如果不够，就修改关键词重新检索；如果够，还要检查是否有矛盾信息需要找证据对比。整个过程形成一个检索-反思-再检索的循环，而不是一次到底的直线。

有了这层理解，再去看 Agentic RAG 的工程架构，思路会顺很多。

3. Agentic RAG 的两种工程架构

市面上的 Agentic RAG 方案五花八门，但抽掉营销词汇，底层就两种模式：编排式和路由式。你把这两种吃透，再看任何框架都能一眼看穿它属于哪种。

3.1 编排式：一个中央大脑调度所有工具

编排式是最直觉的设计：一个中央 Agent 作为大脑，它自己负责理解问题、拆解步骤、调用各个工具，并决定下一步动作。所有工具都挂在这个 Agent 下面，工具之间不直接沟通，全部通过中央 Agent 中转。

我用一个最简状态机来描述这个过程：

• 接收用户问题
• 规划子任务列表
• 按顺序执行子任务，每个子任务可能触发一次 RAG 检索
• 每次拿到检索结果后，Agent 判断信息是否充足
• 信息不足则重新规划查询
• 信息充足则组织最终答案

这个模式的优点是灵活度高，Agent 可以在中途切换策略，比如用户突然补充了一个条件，Agent 能立刻调整检索方向。适合资料种类杂、问题形态不固定的场景。

缺点是延迟和成本高。每多一次推理，就多一笔模型费用和时间开销，而且中央 Agent 一旦在复杂路径里迷失，可能反复尝试做无用功，甚至绕圈子。

3.2 路由式：按问题类型分发到不同执行管道

路由式则强调分工。系统入口是一个路由器（Router），先判断用户问题属于哪一类，再把请求分发给不同的子处理单元。比如：

• 简单事实类问题 → 走单次 RAG 管道
• 多文档对比类问题 → 走文档比对管道
• 数值计算类问题 → 走代码执行管道
• 需要多轮追问 → 走深度检索管道

每个子管道是半独立的。有的管道内部还是普通的 RAG 流程，有的管道可能内置一个小型 Agent 循环。路由器本身可以是一个轻量级分类模型，也可以是一个带 few-shot 的大模型判断。

路由式的最大优势是稳定、可观测。每次请求走哪条路径是可预期的，不会出现中央 Agent 失控的情况。缺点是对初期设计能力要求高，你必须提前把业务问题摸清，设计好路由规则，如果遇到路器分错类的场景，系统会直接答非所问。

3.3 哪种更适合刚起步的项目

我个人的判断标准很简单：如果你的知识库规模和业务口径还在快速变化期，优先做编排式；如果你的业务问题类型已经非常明确，且有大量可枚举的场景，路由式会让你好维护得多。

大部分团队会从编排式起步，跑稳定后再把高频路径固化成路由分支，做成“路由为主、编排兜底”的混合结构。这也是我比较推荐的长线演进路径：先用编排式跑通逻辑，再逐步用规则或轻量分类器替代高频路径，降低单次成本。

4. 落地时最容易被忽略的四个细节

架构选完之后，真正的坑才刚刚开始。我在这里把四个影响成败的细节提前讲清楚，避免你到调优阶段再返工。

4.1 检索质量是地基，别指望 Agent 力挽狂澜

Agentic RAG 再聪明，检索如果烂，Agent 拿到一堆垃圾材料再怎么反思也白搭。让我反复强调一个判断标准：先用标准 RAG 把单轮检索的准确率做到八成以上，再考虑上 Agent 编排。

影响检索质量的因素，按优先级排：文档拆分方式 > 向量模型质量 > 混合检索策略 > 重排模型。很多人一上来就折腾向量模型，其实拆分方式才是大头。

比如某公司把年度安全报告拆成固定 500 字块，结果“安全培训参与率”这句话被硬生生从表格上下文里切开，后续无论模型多好都召不回正确数字。后来改成“按标题层级+表格结构”的语义切分，只改这一项，召回准确率就提高了十几个点。

你需要建立自己的召回评估集：拿五十个真实业务问题，人工标注期望答案出处，每次改检索配置都跑一遍这五十个问题，记录召回命中率。没有这个校准过程，后面所有上线决策都是在凭感觉。

4.2 上下文窗口再大，也不能无限塞材料

大模型的上下文越来越长，但把大量检索片段全塞进 Prompt 依然是最愚蠢的做法，没有之一。

原因有两个。第一是模型注意力会被无关内容稀释，中段信息利用率尤其低；第二是成本控制不住，几轮 Agent 循环下来，每轮塞三千 tokens，积累的量非常惊人。

一个可用的策略是：把召回片段交给一个轻量级的“上下文筛选器”，给每个片段打分——与问题相关程度、信息量与已有答案的重复度。只保留最相关的三到五段，每段裁剪到 300 字以内，再拼进最终 Prompt。整个筛选过程其实可以用少量模型调用甚至规则完成，没必要全部交给主 Agent 思考。

上下文管理还有一个容易被忽视的层面：多轮对话中的记忆。Agent 经过几轮工具调用后，对话历史的工具执行记录占的 token 远超用户消息本身。你要定期压缩旧轮次的执行细节，保留结论而丢掉冗长的中间日志，否则上下文会像滚雪球一样膨胀，最终把模型窗口撑爆。

4.3 工具不是越多越好，调用边界必须清晰

Agentic RAG 的“工具”一旦加多了，模型的选择负担和错误率会同步上升。工具说明写得模糊、参数定义不清，Agent 就很可能会拿“查库存”的工具去回答“合同条款”问题。

我的习惯是：每加一个工具，就问自己三个问题。第一，这个工具的业务边界是否清晰？第二，它的入参能否用自然语言明确表达？第三，如果 Agent 调用错了，代价有多大？工具描述里一定要写明适用场景、典型 query 例子、不适用场景。把工具当成给你新同事看的接口文档，写清楚才能减少用错。

同时要设计超时和失败兜底。Agent 循环里最常见的失控场景是：某个检索工具持续无返回，Agent 却反复等待重试，白白耗掉大量时间。你需要给每个工具设置明确的超时时间和失败错误信息，让 Agent 收到错误后能及时切换策略，而不是原地打转。

4.4 效果评估必须贯穿全程

Agentic RAG 引入多轮循环后，评估难度比标准 RAG 高不少。不能只看最终答案就完事，至少要评估三件事：检索召回命中情况、中间决策是否合理、最终答案是否正确。

如果你没有评估集，后期一改配置就出 regression，你完全无感知。我建议哪怕先准备二十条代表性测试问题，也要跑通“输入-中间-输出”的全链路日志记录。每条 Agent 执行轨迹都存成结构化日志：用了哪些工具、每轮检索用到的 query、返回了多少条结果、最后哪几段进了上下文。有了这些日志，排查问题才不是大海捞针。

5. 从零搭建可落地的 Agentic RAG 系统

理论知识说够了，接下来进入写代码阶段。我会从模块划分、核心链路、关键参数三个层面，走一遍最简可运行的 Agentic RAG 系统。

5.1 总体设计与模块划分

完整系统至少包含六个模块：

• 文档处理层：负责文本解析、清洗、切分、向量化
• 检索服务层：提供向量检索、关键词检索、混合检索 API
• Agent 引擎层：负责规划、调度、反思
• 工具注册层：把检索服务以及业务 API 包装成 Agent 可调用的工具
• 记忆管理层：维护短期对话历史和长期用户信息
• 观测与日志层：记录每次调用的输入输出和轨迹

我这次示例重点放在 Agent 引擎层和工具注册层，因为这两层是 Agentic RAG 区别于标准 RAG 的核心。

5.2 核心链路的手写实现

假设我们已经把文档向量化并建好索引，检索函数封装为search_knowledge_base(query, top_k)。接下来定义一个最简单的 Agent 执行循环，配合工具调用。以下代码是核心骨架，去掉框架封装，逻辑清晰可见：

import json from typing import List, Dict class MockLLM: """模拟大模型接口，实际使用时可替换为真实模型调用""" def chat(self, messages: List[Dict[str, str]], tools: List[Dict]) -> str: # 这里填入真实大模型 API。返回 JSON 字符串。 pass def search_knowledge_base(query: str, top_k: int = 5) -> List[Dict]: """向量检索 + 关键词检索 + 简单融合，具体实现略""" pass # 定义给 Agent 的工具列表 TOOLS = [ { "name": "search_knowledge_base", "description": "在内部知识库中检索相关内容，适合查询操作手册、合同条款、产品规格等问题。入参为检索关键词。", "parameters": ["query", "top_k"], } ] def convert_tool_schema(tools: List[Dict]) -> List[Dict]: """把上面的工具说明转换成模型能识别的 function calling schema""" converted = [] for tool in tools: converted.append({ "type": "function", "function": { "name": tool["name"], "description": tool["description"], "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "检索关键词"}, "top_k": {"type": "integer", "description": "返回条数"} }, "required": ["query", "top_k"] } } }) return converted def run_agentic_rag(user_question: str, max_iterations: int = 5) -> str: llm = MockLLM() messages = [{"role": "user", "content": user_question}] visited_queries = set() for step in range(max_iterations): # 让模型决定下一步动作，可能返回文本答案，也可能返回工具调用请求 response = llm.chat( messages=messages, tools=convert_tool_schema(TOOLS) ) # 如果模型没有要求调用工具，说明它认为可以直接回答了 if "tool_calls" not in response or not response["tool_calls"]: return response["content"] # 解析工具调用请求 for call in response["tool_calls"]: func_name = call["function"]["name"] args = json.loads(call["function"]["arguments"]) query = args.get("query") top_k = args.get("top_k", 5) # 简单的防重复检索：同样 query 不重复查 if query in visited_queries: # 强制要求模型换个角度再查 messages.append({ "role": "assistant", "content": f"查询 '{query}' 已执行过且结果不足，请换个关键词继续检索。" }) continue visited_queries.add(query) docs = search_knowledge_base(query, top_k) # 把检索结果作为工具执行结果返回给模型 messages.append({ "role": "assistant", "content": None, "tool_calls": [ { "type": "function", "id": f"call_{step}_{call}", "function": { "name": func_name, "arguments": json.dumps(args) } } ] }) messages.append({ "role": "tool", "tool_call_id": f"call_{step}_{call}", "content": json.dumps(docs, ensure_ascii=False) }) # 超出最大轮数后强制生成答案 final_prompt = f"请基于以下对话记录总结回答用户问题：{user_question}" return llm.chat([{"role": "user", "content": final_prompt}])

这段代码把 Agentic RAG 的核心循环体现得很清楚：用户问题进、Agent 决定调用工具、工具执行并返回结果、结果回填对话、模型再判断。你可以在此基础上加记忆、加反思、加多工具调度。

需要注意几处工程细节：

tool_calls的id必须与后续tool消息里的tool_call_id对应，否则模型在下一轮会迷失上下文。不同的模型服务商对这个 id 的格式要求不同，有些允许自定义，有些要求严格格式，你要对齐官方规范。

检索返回结果不要直接塞原文，最好在返回前做一次清洗：抽取出文档名、片段内容、页码，拼成结构化文本。这样模型能明确知道每段材料来自哪里，回答时也会更有依据。

5.3 关键参数设置与调优经验

Agent 循环里的核心参数有这么几个，我按重要性排序：

max_iterations，最大循环步数。标准答案是「够用就小」。设成 3 和设成 10 的区别不只是次数，而是模型行为都会改变：设得太大，模型会倾向多试几次工具调用；设得太小，模型会因为「没有余量」直接放弃检索开始硬答。我的经验是 4 到 6 之间最稳，跑一段时间再根据日志调整。

top_k的取值取决于你的切分粒度。如果切分块较大，top_k 取 3 到 4 就够；如果切分块比较碎，要取 8 到 10 才能覆盖信息点。配合上下文筛选器使用，可以稍微取大一点，给筛选环节更多候选材料。

temperature在 Agent 流程中建议比普通问答调低一些，0.2 到 0.3 左右。温度太高会让 Agent 在工具选择上飘，同样的输入可能这次查 A 工具、下次查 B 工具，导致行为不可控。

还有个容易被忽视的参数是timeout，尤其是当你接外部 API 工具时。建议每个工具独立设置超时时间，比如知识库内部检索 3 秒，外部 HTTP 接口 5 到 8 秒。Agent 收到超时错误后，要能继续执行而不是卡死。

5.4 最小可行版本怎么上线

第一次上线不需要追求全功能。把范围压小，先把一条核心链路跑通：

选一个你最有把握的知识库场景，比如「产品手册问答」，而不是一个把合同、代码、操作手册全塞进来的混合库。把工具数量控制在两个以内，一个检索文档库，一个可选的业务查询接口。先验证效果，再逐步增加查询场景和工具种类。

上线前一定要做一轮「用户问题模拟」。找研发以外的人来问问题，不要只让团队内部自测。因为内部人已经有预期，问的问题都自带答案倾向，测不出召回缺口。外包测试或真实用户提前体验，效果远好于内部自嗨。

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

这里整理一份速查表，都是我在实际项目里反复遇到的高频问题，比看理论管用得多。

第一个问题的排查路径要展开说下。你在日志里会看到类似现象：用户问「退货时限是多久」，检索 query 却是「退货时限」，top_k=3，返回的前三段分别是「退货流程」「退货地址」「运输说明」，完全没有提到「时限」的文档块。这时候你不该怪 Agent，而是怪检索模块没有把这句用户表述映射到正确的知识块。你需要给检索服务加一个 query 改写层，或者做关键词扩展，把「退货时限」扩展成「退货时效 / 退货期限 / 多少天内可退货」，召回立刻变好。

第二个问题尤其隐蔽。Agent 第一次查「服务器配置要求」没查全，第二次还是用很相似的说法再查一遍，系统白白空转。加了visited_queries还不够，因为模型如果把 query 稍微换个写法，去重就失效了。稳妥的做法是记录语义指纹，对两个 query 做一次向量相似度计算，相似度超过 0.9 就视为重复，然后强制模型换角度拆解问题，比如提示「从故障原因维度检索」。

第三个问题最常见的场景是接了外部系统 API。某项目接了内部工单系统，结果对方接口高峰期响应要 15 秒，Agent 每轮都傻等，一次问答下来十几分钟。后来把超时设为 5 秒，超时就返回「工单系统暂不可用」，Agent 会主动告诉用户当前无法查询，并推荐改用知识库里的说明文档。

第四个问题是数据量大的项目里几乎必现的。我用过一个方案效果不错：工具返回内容先经过一个「压缩函数」，它把检索到的长文本块里与 query 最相关的句子提取出来，拼成 300 字以内的摘要。这个函数可以用简单的关键词命中加位置加权来做，不一定需要再调模型。

第五个问题在路由式架构里更常见。用户问「怎么申请报销」，路由把请求发给了「行政制度」管道，但报销可能在「财务制度」管道里。解决思路是给路由器的少量样本里把这种相近场景写清楚，或者在两个子管道里同时挂同一个知识库的子集，反正底层检索都是同一套索引，路由错误时靠入口的兜底重试也能修正。

7. 工具选型与团队协作建议

Agentic RAG 不是一个人埋头就能干好的事，它需要模型、检索、工程三个角色协同。这里给一点我踩过坑之后的选型依据。

模型层面，不要只盯着大参数模型。控制延迟和成本的关键，是在不同环节用不同规模的模型：路由判断用小模型，最终答案生成用大模型，中间检索结果压缩用轻量模型。我见过很多团队一律用最贵的大模型，成本翻了好几倍，效果提升却很有限。

检索层面，向量模型要跟你的领域文本做测试。通用向量模型在通用语料上表现不错，但一遇到你单位内部的缩写、系统代号、表格化表述，匹配度就会断崖式下跌。如果你有预算，在领域数据上微调一个向量模型，投入产出比相当高。没预算的话，至少加一层关键词检索兜底，做简单的分数融合，能救回来一半以上召回损失。

工程层面，日志系统越早上越好。Agent 的执行轨迹和普通请求日志不一样，它是一条多步骤、有分支的树状结构。建议直接存成 JSON 或者专门的事件流，每次工具调用记录一组输入输出，方便后面重放和调试。我见过太多项目上线两个月后才发现某个工具调用错了几千次，就是因为追踪日志没做好。

团队协作上，一定要有一个人专门维护「评估集」。这不是写测试用例那么简单，评估集要包含问题、期望答案、期望检索命中片段、可接受的多轮路径。每次模型版本升级、工具参数变化、文档库更新，都要跑一遍全量回归。否则你不知道哪次调整把原来的正确行为改坏了。

8. 写在最后的经验分享

说句大实话，Agentic RAG 不是银弹。它不是把 RAG 换成 Agent 就万事大吉，而是把问题从「检索准不准」升级成了「决策对不对、循环稳不稳」。这两种问题的调试难度不在一个量级。

我自己的经验是：如果一个小白用户能靠浏览文档解决问题，那用标准 RAG 就够了，完全不需要上 Agent。只有当你的场景里出现「需要多步推理、需要跨文档串联、需要边查边修正」的需求时，Agentic RAG 的价值才真正体现出来。

很多人一上来就搞一个带四个工具、十轮循环的重型系统，结果上线后模型行为乱成一团，运营和研发互相甩锅。与其这样，不如从最小闭环开始：一个工具、一轮规划、一次反思，跑稳一个场景，再复制到下一个场景。稳扎稳打比炫技重要得多。就按这条思路做，你会省下很多不必要的痛苦。