从RAG到Agentic RAG：构建企业知识问答系统的进阶之路

封面图为技术示意图。本文为原创教程，适合有一定RAG落地经验的工程师与架构师。

一、传统RAG在复杂问题上的局限

传统RAG的流水线通常是“用户提问 -> 向量检索 -> Top-K拼接 -> 生成答案”。在企业内部简单文档查询中，这种模式足够稳定。可一旦出现多跳推理、跨库关联、实时状态或矛盾证据，传统RAG就会变成“一本正经地看错问题”。

失败场景	传统RAG的表现	根因
同一个问题涉及“订单、供应商、财务”三个系统	只在一个静态知识库中检索	缺少任务规划与路由
上一轮谈“华东工厂”，下一轮问“他们的延误率”	无法理解指代	缺少会话状态与查询上下文
用户要“当前供应商是否在黑名单”	只能给通用政策，无法查ERP	没有工具调用能力
检索到的两份文档结论矛盾	两种观点各写一句，让用户自己猜	没有证据冲突检测与反思

二、Agentic RAG架构与原理解析

Agentic RAG不是把检索交给一个“会主动思考的大模型”这么简单。其本质是大模型从“答案生成器”变成“信息协调者”：它自己决定要去哪里查、查几次、如何把结果变成证据、以及证据不够时怎么办。在企业落地中，我更愿意把Agentic RAG理解为“有边界的自主流程”。模型可以编排动作，但不能越过权限边界；可以调用工具，但必须保留审计轨迹。

核心组件	职责
Planner	解析用户意图、消解指代、拆解多跳问题
Router	决定走知识库、业务系统API还是外部搜索
Retriever/Reranker	混合召回、重排、去重、打分
Tool Executor	执行MCP/function calling完成结构化查询
Reflector	在生成前后做证据充分性、一致性、事实性检查
Generator	基于最终证据生成带来源标记的回答

三、规划、检索、反思与工具调用流程

下面用Mermaid给出一个“简化但完整”的控制流。要注意：并不是所有问题都必须走完整循环，简单问题应当直接走捷径。

flowchart TD A[用户提问] --> B[Agent 规划] B --> C{是否需要多步拆解?} C -- 是 --> D[生成子问题清单] C -- 否 --> E[查询改写/路由] D --> E E --> F[知识库/工具检索] F --> G[重排与证据筛选] G --> H{证据是否充分?} H -- 否 --> I[反思与补充检索] I --> F H -- 是 --> J[生成候选答案] J --> K{冲突/幻觉检查} K -- 有风险 --> L[修正或请求澄清] L --> F K -- 通过 --> M[输出带引用的答案]

3.1 规划

规划的目标不是把问题“变复杂”，而是把复杂问题拆成可执行步骤。例如：“请分析华东区二季度交付延误的原因”应该先拆成：

华东区二季度有哪些交付延误工单？
延误主要集中在生产、物流还是供应商环节？
这些环节相对一季度变化是否异常？
有没有突发事件或供应商替换记录可以解释？

3.2 检索

不能只使用固定Top-K。更合理的方式是：先用混合检索召回更多候选片段，然后通过重排模型筛掉与问题无关的噪音。同时对已经使用过的证据建立“临时记忆”，避免同一个子问题反复检索。

3.3 反思

反思要回答三件事：

每个结论是否都有对应证据？
不同证据之间是否矛盾？
模型有没有把“没有证据”推断成“结论”？

如果证据不足，Agent应该继续检索；如果同一结论找不到支持依据，应该在答案里明确说“当前知识库不足以回答”，而不是猜测。

3.4 工具调用

当问题需要实时数据或结构化数据时，检索无法独立完成任务。Agent需要调用外部工具。工具调用通常遵循以下协议：

Agent产生工具名和参数；
工具网关完成身份鉴权、字段级权限校验和限流；
工具返回结构化结果或错误码；
Agent判断结果是否满足问题需求，决定继续调用还是转向检索。

四、基于MCP实现知识库与外部工具联动

MCP（Model Context Protocol）的意义，是统一“知识库、数据库、API、浏览器”等外部资源的接口协议。企业不需要为每一个大模型产品单独开发一套工具插件，只需要把系统包装成MCP Server，再交给Agent动态调用。

MCP Server	能力边界	典型工具
knowledge-base	公司内部文档/知识库，权限按租户或部门隔离	search_knowledge(query, top_k, tenant_id)
erp/business	订单、库存、供应商、财务等业务数据	query_order(code), check_supplier_status(code)
web-search	外部新闻、公告、政策等公开信息	search_web(query, time_range)
data-api	数据仓库/BI指标查询	run_bi_query(slug, params)

举例：用户问“这个供应商能否继续合作？” Agent规划后可能先调用knowledge-base查询“供应商淘汰标准”，再调用erp/business查询“该供应商质量合格率与订单逾期率”，最后如果两份资料都满足条件，再结合当前合同额给出谨慎建议。每一次调用都记录在审计日志中，便于事后复盘与追责。 MCP联动需要注意：不能让Agent直接访问原始表或执行任意SQL。建议把MCP Server封装成“最小可用工具”，每个工具只暴露白名单参数和只读能力，并在写入类操作前增加人工审批。

五、评测集设计、失败分析与优化方向

Agentic RAG评测不能只看最终答案像不像。一个正确的复杂回答，必须满足“规划逻辑正确、证据链闭合、工具调用无遗漏、生成结果忠实于证据”。评测集建议包含三类问题：

多跳问答：必须合并至少两份资料才能回答；
工具依赖问题：必须查询ERP或外部API才能回答；
对抗测试：包含相似但错误的文档、互相矛盾的证据、应回答“不知道”的问题。

样例	评测点	期望结果
问题：某区域交付延误和二级供应商替换是否有关？	子问题拆解、证据链闭合	能指出相关/不相关/数据不足
问题：当前某物料库存是否满足下周排产？	工具调用、参数准确性	调用库存与排产两个工具，给出对比结论
问题：旧版规范是否仍然适用？	版本冲突识别	发现版本矛盾，要求提供生效日期

建议核心指标如下：

评测维度	指标	参考目标
任务成功率	端到端答案是否被人工或强模型判定为正确	大于等于85%
引用覆盖率	答案关键事实对应来源片段的比例	大于等于95%
过度自信率	没有证据却强行作答的问题占比	小于等于5%
工具调用正确率	工具名、参数、权限范围是否准确	大于等于90%
端到端时延	复杂问题平均耗时有界	小于等于15秒

失败分析建议从三个层面入手：第一，规划层是否把问题拆错；第二，检索层是否召回不足；第三，生成层是否没有忠实于证据。优化时也分层推进：

规划层：沉淀高难度问题few-shot，必要时微调小模型做路由；
检索层：调整切片粒度、索引字段、重排阈值；
反思层：加入“不确定就明说”的提示约束并定期抽检错误样本；
工具层：用MCP Server返回结构化错误码，如无权限、无数据、超时，而不是让大模型猜测。

平台	推荐检索词	出处说明	检索入口
B站	Agentic RAG 架构与实战	以B站UP主主页、发布时间、视频标题为准	B站检索
腾讯视频	Agentic RAG 企业落地	以腾讯视频号或机构认证账号为准	腾讯视频检索
优酷	RAG Agent 技术公开课	以优酷创作者频道为准	优酷检索
抖音	Agentic RAG 知识管理	以抖音作者主页为准	抖音检索

免责声明

本文所有流程、指标及架构建议仅为通用技术参考，不构成任何商业承诺或交付保证。文中涉及的视频、产品商标和平台名称均归各自权利人所有。生成式AI技术迭代速度快，落地前请结合你的数据规模和安全规范进行充分测试。

落地操作清单

盘点问题：从真实业务问题中选出20条最难问题，看它们是否需要多跳、工具或反思。
建立基线RAG：先保证静态知识库的单跳检索准确率不低于90%，再上Agent能力。
引入路由与规划：用强模型做Planner，用规则或小模型做简单问题拦截。
封装MCP工具：每个系统只开放少而精的工具，不要暴露任意数据库表。
实现证据追踪：每次检索和工具调用都写入trace，方便复盘。
配置反思策略：设置最大检索次数、工具调用次数和回答tokens上限，防止死循环。
建设评测集：每两周加入线上bad case，回归核心指标。
灰度发布：从只读助手模式开始，再逐步扩展到需要写操作的自动化流程。

避坑指南

坑点	现象	建议
过度设计	简单FAQ也要“规划-反思-工具”	先做问题分类，单跳问题用轻量RAG直接处理
检索没做好就上Agent	Agent反复搜索也找不到正确答案	先把切分、混合检索、重排做扎实
让模型写任意查询	工具调用绕过权限，或产生危险SQL	MCP工具封装白名单参数，写操作必须审批
反思流于形式	模型自己查自己，永远说自己没错	引入基于证据覆盖率的硬判断，不满足就拒绝作答
没有成本上限	复杂问题调用几十次模型，账单失控	设置单用户单轮调用次数和总token预算
忽略数据新鲜度	回答用旧数据并坚持正确	在工具结果上标注采集时间，过期数据明确提示