## 引言企业知识库用了一年多最常被抱怨的一句话是检索到了但没用。用户问一个跨部门的问题系统从几十份文档里捞出三段最相似的文字拼在一起读起来却答非所问。问题不在向量检索的召回率也不在大模型的总结能力而在检索这一步本身就回答不了需要推理的问题。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 平台能做到多深的关键尺子。
