实践分享：Agentic RAG 如何应对企业数据的真实混乱
🙋
我是 Luhui Dev，一个长期拆解 Agent 工程、探索 AI 教育落地的开发者。关注 Agent Harness、LLM 应用工程、AI for Math 与教育 SaaS 产品化实践。
一个工单背后的数据迷宫
假设你的公司刚上线了一套 AI 客服系统。
一位大客户发来工单：“我们上个季度在项目 Alpha 采购的服务器，保修期还有多久？能否告知当时的合同条款和对应的技术支持联系人？”
听起来是个再普通不过的问题。但你的技术负责人看到这条工单，沉默了三秒。
因为他知道，要回答这个问题，系统需要：
- 去CRM 系统里查这家客户的客户档案和项目记录
- 去ERP/合同管理系统里查项目 Alpha 的采购合同和保修条款
- 去资产管理系统里查那批服务器的入库日期和设备序列号
- 去HR 系统里查客户成功团队的当前负责人
这四个系统，分属不同的技术团队维护，使用不同的数据库，有不同的访问权限控制。
普通的 RAG 系统对这种情况束手无策。它只能回答：“抱歉，我找不到相关信息。”
这就是Agentic RAG要解决的问题。
传统 RAG：一次性的检索员
先快速回顾一下 RAG 的工作原理。
RAG（检索增强生成）的核心思路很简单：LLM 的训练知识是静态的，而企业数据是动态私有的。解决办法是在生成答案之前，先去数据库里检索相关文档片段，把它们塞进上下文，让 LLM 基于这些材料来回答。
用户问题 → [向量检索] → 召回相关文档片段 → [LLM] → 生成回答这个流程在单一知识库、问题明确的场景下效果不错。但它有两个根本性的限制：
限制一：单次检索，不迭代。检索一次，给 LLM 一次，完成。如果第一次检索没找到关键信息，整个链路就断了，LLM 只能靠猜或者说"我不知道"。
限制二：单一语料库，不路由。传统 RAG 预设知识存在一个统一的向量数据库里。现实企业里，数据分布在 CRM、ERP、Confluence、数据仓库、私有文档库……每个系统有自己的访问入口和权限边界。
用一个比喻来说：传统 RAG 是一个只能在图书馆一楼找书的图书管理员，而你需要的书可能分布在四层楼，每层楼还有不同的入馆许可。
Agentic RAG：会思考的检索部门
Agentic RAG 的核心转变是：把一次检索变成一个有规划、能迭代的检索过程。
它不再是一个被动的查询-返回流程，而是一个由多个专职 Agent 协作的工作流，每个 Agent 负责不同的职责。
让我们用前面那个客服工单的例子，拆解整个工作流是如何运转的。
第一步：编排器拆解任务
用户的问题被送到编排器（Orchestrator）。
编排器不直接去检索。它先理解问题的结构：这个问题涉及几个独立的信息需求？它们之间有没有依赖关系？需要访问哪些数据源？
对于我们的工单，编排器会拆解出：
- 子任务 A：从 CRM 查客户"项目 Alpha"的基本信息（客户 ID、项目编号）
- 子任务 B：用项目编号，从合同系统查保修条款
- 子任务 C：用项目编号，从资产管理系统查设备序列号和入库日期
- 子任务 D：从 HR 系统查当前技术支持负责人
注意：子任务 B 和 C 依赖于子任务 A 的结果（需要先拿到项目编号）。子任务 D 可以并行执行。
这个依赖关系图，就是规划器（Planner Agent）输出的执行计划。
第二步：查询改写，适配不同数据源
每个数据源的查询方式不同。CRM 可能需要关键词检索，合同系统可能需要结构化 SQL 查询，向量数据库需要语义检索。
查询改写器（Query Rewriter）负责把自然语言的子任务，翻译成每个目标数据源能理解的查询形式：
- 对 CRM 向量库：
"Alpha 项目 采购记录 {客户名}" - 对合同系统：
SELECT warranty_terms FROM contracts WHERE project_id = 'Alpha-XXX' - 对资产管理：
"Alpha项目 服务器 入库日期 序列号"
第三步：并行检索，跨越权限边界
检索扩散器（Search Fanout Agent）同时向多个数据源发起查询。
这里有个关键的工程问题：权限。
不同数据源的访问权限不同。CRM 数据可能是销售团队开放的，但 HR 数据只有管理员能访问，合同数据需要法务审批。Agentic RAG 框架需要在这一层维护"凭证池"——不同数据源对应不同的访问令牌，且检索时的权限不会超出当前用户的授权范围。
这不只是技术问题，也是合规问题：AI 不应该因为你用自然语言问了一个问题，就绕过了你本来不应该有的数据访问权限。
第四步：充足性判断——这是最关键的创新
所有检索结果汇聚后，进入充足上下文检验器（Sufficient Context Agent）。
这个环节是 Agentic RAG 区别于传统 RAG 最核心的设计：系统会主动判断当前收集到的信息是否足以回答原始问题，如果不够，明确指出缺什么，然后继续检索。
对我们的工单案例，检验器可能发现：
✅ 已找到：客户档案、项目编号、设备序列号
✅ 已找到：技术支持负责人
❌缺失：合同系统返回了文件，但保修条款在附件 PDF 里，向量检索没有命中
检验器输出的不是"信息不足"，而是精确的缺口描述：
“已获取项目编号 Alpha-2024-087，设备序列号 SN-XXX-YYY-ZZZ，入库日期 2024 年 3 月。合同主文件已检索，但保修条款位于合同附件 B，需要针对’附件 B 保修期限’重新检索合同附件库。”
这条反馈驱动第二轮检索：改写器生成更精准的查询，专门针对合同附件进行检索。
这个"检索 → 评估 → 再检索"的迭代循环，会一直持续，直到充足性检验器判断信息已经完备，或者达到最大迭代次数限制。
第五步：综合生成最终回答
所有信息齐备后，综合 Agent（Synthesis Agent）把来自四个不同系统的碎片信息，整合成一个连贯、准确、可引用来源的回答：
“项目 Alpha（编号 Alpha-2024-087）采购的 3 台服务器（序列号 SN-XXX-001 至 003），根据合同附件 B 第 4.2 条，保修期为自入库日期（2024 年 3 月 15 日）起 36 个月，即至 2027 年 3 月 14 日到期。当前技术支持负责人为李明（分机 4521，liming@company.com）。”
每一句话都有数据来源，都可追溯。
跨权限边界：比技术更难的问题
值得单独拿出来说的是权限边界的处理。
真实企业里，数据权限是一个多维度的问题：
| 维度 | 说明 | 示例 |
|---|---|---|
| 角色权限 | 不同角色能看到不同数据 | 销售能查合同摘要，但不能查原文 |
| 数据分级 | 同一数据库内有不同密级 | 员工薪资 vs 员工花名册 |
| 时间权限 | 部分数据有时效性访问限制 | 审计期间的财务数据只读 |
| 跨系统权限 | A 系统的数据不能出现在 B 系统的上下文里 | GDPR 要求数据不跨境流转 |
Agentic RAG 框架需要在每次检索调用时，都严格遵守这些权限规则，而不是在索引时统一授权。
这意味着架构上要实现**查询时权限校验，而不是把所有数据统一向量化放进一个大库这种简单粗暴的做法。
用数据库的比喻来说：传统 RAG 像是把所有表 JOIN 成一张大表再给 LLM 用；Agentic RAG 像是为每次查询动态生成带权限过滤的 SQL。
实际场景中的三个关键决策点
当你在真实工程里实现 Agentic RAG 时，有三个决策是绕不开的。
决策一：路由策略——静态配置还是 LLM 路由？
静态路由：根据查询中的关键词或元数据，提前定义规则决定去哪个数据源。速度快，可控，但应对开放式查询能力弱。
LLM 路由：让 LLM 理解查询意图后，动态决定路由到哪个数据源。灵活，但每次路由都消耗 LLM 调用，增加延迟和成本。
决策二：迭代深度——什么时候停下来？
系统可能陷入无限迭代——每轮检索都觉得还缺点什么，一直找下去。
工程上需要设置：
- 最大迭代轮数（通常 2-4 轮）
- 时间预算（超时直接用已有信息回答）
- 降级策略（超出迭代限制时，用已有信息回答并标注信息可能不完整）
决策三：延迟 vs 准确率的权衡
Agentic RAG 比传统 RAG 慢，这是无法回避的事实。多轮 LLM 调用、并行检索、充足性评估，每一步都有延迟成本。
| 方案 | 成本倍数 | 延迟倍数 | 适用场景 |
|---|---|---|---|
| 传统 RAG | 1x | 1x | 简单问答，单一知识库 |
| Adaptive RAG | 1.5-2x | 1.2-2x | 查询复杂度差异大的混合场景 |
| CRAG（纠错 RAG） | 3-5x | 2-3x | 准确率要求高、可接受秒级延迟 |
| 完整 Agentic RAG | 5-10x | 3-6x | 复杂多跳、跨库关联、异步场景 |
不是所有场景都需要完整的 Agentic RAG。
为查询进行意图分类，复杂查询走 Agentic 流程，简单查询走传统 RAG，可以把平均成本和延迟控制在合理范围内。
写在最后
我认为 Agentic RAG 的本质，就是把 RAG 中的检索变成了可执行的策略：如果一次不够，就继续找，直到够了为止。"够了"这件事本身，也是系统来判断的。
这个改变听起来简单，但它要求系统从"查询-响应"的无状态模式，转变为"目标-规划-执行-评估-迭代"的有状态工作流。
这和 Agent 系统的通用挑战是一样的：状态管理是核心难题。
如果你正在构建一个涉及多数据源的企业 AI 系统，Agentic RAG 不只是一个检索技术的升级，它要求你重新思考数据架构、权限设计和工作流编排。把这三件事想清楚了，比选择哪个框架或哪家云厂商更重要。
参考资料
Google Research,Unlocking dependable responses with Gemini Enterprise Agent Platform’s Agentic RAG, June 2026
Microsoft,Agentic Retrieval Overview – Azure AI Search, 2026-04-01 GA
Microsoft,What is a Knowledge Source? – Azure AI Search
Amazon Web Services,Knowledge Bases for Amazon Bedrock – Multiple Data Sources, April 2024
MarsDevs,Agentic RAG: The 2026 Production Guide（含各方案成本/延迟对比数据）
Google Research,Deeper Insights into Retrieval-Augmented Generation: The Role of Sufficient Context