‍我是 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 保修期限’重新检索合同附件库。”这条反馈驱动第二轮检索改写器生成更精准的查询专门针对合同附件进行检索。这个检索 → 评估 → 再检索的迭代循环会一直持续直到充足性检验器判断信息已经完备或者达到最大迭代次数限制。第五步综合生成最终回答所有信息齐备后综合 AgentSynthesis Agent把来自四个不同系统的碎片信息整合成一个连贯、准确、可引用来源的回答“项目 Alpha编号 Alpha-2024-087采购的 3 台服务器序列号 SN-XXX-001 至 003根据合同附件 B 第 4.2 条保修期为自入库日期2024 年 3 月 15 日起 36 个月即至 2027 年 3 月 14 日到期。当前技术支持负责人为李明分机 4521limingcompany.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 调用、并行检索、充足性评估每一步都有延迟成本。方案成本倍数延迟倍数适用场景传统 RAG1x1x简单问答单一知识库Adaptive RAG1.5-2x1.2-2x查询复杂度差异大的混合场景CRAG纠错 RAG3-5x2-3x准确率要求高、可接受秒级延迟完整 Agentic RAG5-10x3-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 2026Microsoft,Agentic Retrieval Overview – Azure AI Search, 2026-04-01 GAMicrosoft,What is a Knowledge Source? – Azure AI SearchAmazon Web Services,Knowledge Bases for Amazon Bedrock – Multiple Data Sources, April 2024MarsDevs,Agentic RAG: The 2026 Production Guide含各方案成本/延迟对比数据Google Research,Deeper Insights into Retrieval-Augmented Generation: The Role of Sufficient Context