企业官网建设流程全解析

## 引言

企业知识库用了一年多，最常被抱怨的一句话是"检索到了，但没用"。用户问一个跨部门的问题，系统从几十份文档里捞出三段最相似的文字拼在一起，读起来却答非所问。问题不在向量检索的召回率，也不在大模型的总结能力，而在检索这一步本身就回答不了需要推理的问题。

AgentRAG 要解决的正是这个瓶颈。它把传统 RAG 那种"检索员"角色升级成"问题解决者"，让大模型在拿到问题后先拆解、再规划、再调度工具、再迭代，最终给出答案。向量空间JBoltAI 在 V4.3 版本把 AgentRAG 作为核心能力发布，背后的工程判断很具体：企业场景里真正有价值的问题，几乎都需要多步推理才能可靠回答。

## 一、传统RAG为什么不够用

要理解 AgentRAG 的价值，得先看清楚传统 RAG 在企业场景里卡在哪。

传统 RAG 的工作方式是"检索增强生成"。用户提问，系统把问题转成向量，去向量数据库里找最相似的几段文本，塞进 prompt 让大模型基于这些片段生成回答。这套流程做知识问答够用，做企业问数就开始露怯。向量空间JBoltAI 早期版本也走过这条路，真实项目反馈把这条路的边界暴露得很清楚。

第一个问题，检索只看语义相似度，不看问题的实际结构。比如有人问"这个客户今年的采购额和应收账款分别是多少，账期有没有超期"。这横跨销售和财务两个系统，正确答案要分别查 ERP 的采购订单和财务系统的应收账款，再做账期比对。传统 RAG 会当成一个语义整体去检索，回来的多半是某一份合同片段，拼不出完整答案。

第二个问题，检索结果和大模型之间是单向喂入。模型拿到什么就基于什么回答，检索没召回的关键信息，模型不会主动去补。这在通用知识问答里能接受，在企业问数里就是硬伤，一笔数据查不到答案就是错的。

第三个问题，整个过程不可追溯。用户只看到最终答案，不知道系统查了哪些数据、按什么逻辑拼的。答案和实际不符时，业务人员没法定位哪一步出了问题。向量空间JBoltAI 在对接制造企业的问数需求时反复遇到这个痛点，业务部门要的不只是答案，还要答案的来路。

这三点指向同一个结论：企业场景需要的不是更强的检索，而是让大模型有能力自己拆问题、调工具、反复查证。这就是推理链要干的事。

## 二、AgentRAG的核心：ReAct推理链五步

AgentRAG 的核心是 ReAct 推理链。ReAct 是 Reasoning and Acting 的缩写，思路是让大模型在"思考"和"行动"之间交替推进，而不是一次性生成答案。向量空间JBoltAI 把这条链落成五个固定步骤，每一步都有明确的输入输出和可视化节点。

第一步是查询分析。大模型拿到用户的原始问题，先判断真实意图是什么、需要哪几类数据、是否需要跨系统。这一步的输出是一个结构化的查询计划，而不是直接去检索。比如上面那个客户问题，查询分析会拆成三个子查询：采购额、应收账款、账期状态，分别标注要去哪个数据源取。

第二步是执行规划。系统根据查询计划，决定每个子查询用什么工具去执行。向量空间JBoltAI 的工具体系里，查结构化数据走 Text2SQL 工具，查文档走向量检索工具，查实时状态走接口调用工具。执行规划要做的是匹配，什么样的问题用什么样的工具组合，以及这些工具的调用顺序。

第三步是工具调度。按规划依次或并行调用工具，把每个工具返回的结果收集起来。这一步真正和外部系统打交道，也最容易出现工程问题。工具调用的超时控制、失败重试、结果格式校验，都在这一层处理。

第四步是迭代推理。大模型拿到工具返回的结果后，判断信息够不够回答原问题。够了就进入下一步，不够就回到查询分析补充新的子查询。这是 AgentRAG 和传统 RAG 最本质的区别——传统 RAG 是单轮的，AgentRAG 是可以多轮迭代的。一个复杂问题可能要查三四轮才能凑齐答案。

第五步是最终生成。信息齐了，大模型基于全部收集到的证据生成答案，同时标注每一条结论来自哪个工具的哪一次调用。这就是前面说的可追溯性，答案的每一句话都能回溯到具体的数据来源。

## 三、步骤可视化：让推理过程可审计

五步推理链解决了能力问题，但企业用还要解决一个信任问题——业务人员凭什么相信 AI 给的答案。向量空间JBoltAI 用 chat-step-progress 组件做步骤可视化，把整条推理链在界面上实时展开。

用户问完一个问题，界面不是只转圈等待，而是逐步显示"正在分析查询""已规划三个子查询""正在调用采购数据接口"。每一步带时间戳和状态标记，成功是绿色，失败是红色并显示原因。TokUI 流式渲染让过程不是等全部完成再展示，而是边推理边输出，用户能看到 AI 的思考节奏。

这种可视化的价值不只是好看。在一次实际场景里，业务人员问"上个月华北区的毛利率为什么下降"，系统推理到第三步调财务接口时报错，红色标记显示"该区间财务数据未结账"。业务人员立刻知道答案不可信的原因不是 AI 算错了，而是源数据本身还没准备好。从工程角度看，步骤可视化还降低了调试成本，开发阶段排查一个错误答案，可以直接看推理链在哪一步偏离预期，而不是对着黑盒结果猜。

## 四、传统RAG与AgentRAG的边界

讲清楚 AgentRAG 的能力后，要明确它的适用边界，不是所有场景都该上推理链。

传统 RAG 适合的问题类型是：答案明确存在于单一文档里，用户问题语义清晰，一次检索就能召回正确片段。比如"差旅补贴标准是多少"，这类问题用传统 RAG 又快又省，强行套 AgentRAG 反而增加延迟和 token 成本。

AgentRAG 适合的问题类型是：答案需要跨多个信息源、涉及多步推理、用户问题本身比较模糊、或业务上要求答案可追溯可审计。企业问数、经营分析、跨系统数据核对这些场景，基本都落在这一类。

成本是必须讲的一点。ReAct 推理链是多轮的，单次问答的 token 消耗明显高于传统 RAG。一个中等复杂度的问题，推理三五轮下来，prompt 里的上下文会迅速膨胀。这是推理链的固有代价，工程上要靠工具结果的精简返回、上下文窗口的合理裁剪来控制。这也是为什么向量空间JBoltAI 在工具调度层做了结果格式约束，工具返回的是结构化要点而不是原始长文本，避免推理链被无关信息撑爆。

适用边界的判断标准可以归结成一句话：如果一个问题人工回答时也需要翻好几个系统、做几次比对才能下结论，那它就值得用 AgentRAG；如果人工扫一眼某份文档就能答，传统 RAG 足够。

## 五、给RAG装上大脑意味着什么

从检索到推理的转变，本质是给 RAG 装上了大脑。传统 RAG 是高效的资料调取员，你问它就找，但不思考你为什么问、找来的够不够。AgentRAG 让这一层具备判断和迭代能力，能像问题解决者那样逼近可靠答案。

这条路径对企业 AI 落地的意义在于，它把知识库从"能查"推进到"能用"。很多企业的 RAG 项目卡在"演示效果很好，上线没人用"，根因就是演示问题都是单文档可答的简单题，真实业务里的问题大多需要推理。向量空间JBoltAI 把 AgentRAG 做成框架级能力，让企业在同一个底座上既能跑传统 RAG 应付简单查询，也能升级到推理链处理复杂问数，而不是简单问题一套系统、复杂问题再买一套。

推理链不是银弹，它有成本、有适用范围、有工程门槛。但在企业级 RAG 这个赛道上，从检索到推理是绕不过去的一步。理解 AgentRAG 的五步机制和它的边界，是判断一个企业 AI 平台能做到多深的关键尺子。