如何构建行业 Agent 的 RAG

行业 Agent 和我们常用的「通用聊天 Agent」不是一类东西。

行业 Agent 是要能解决问题的，而查资料只是其中一步，后面还要做判断、走流程、调用系统、校验结果、留痕、可回放。

RAG 在这里的角色也变了：它不只是给模型喂上下文，而是给 Agent 提供可执行任务所需的依据、约束、参数和证据链。

今天我们聊一下行业 Agent 构建过程中的 RAG 怎么写，从目标、数据，检索以及使用 RAG 等等方面。

1. 行业 Agent 的 RAG 要服务什么能力

行业 Agent 常见的工作方式是「多步闭环」：

  1. 识别问题类型与业务对象（客户、设备、合同、工单、订单、项目、账号等）
  2. 查依据（制度、手册、知识库、历史工单、标准、接口文档）
  3. 做动作（查系统、下发指令、开通配置、生成工单、发邮件、写报告、提审批）
  4. 校验与回写（确认变更成功、回填字段、留痕、把引用/证据挂到工单）
  5. 解释（给用户说明依据、影响范围、回滚方案、下一步建议）

所以行业 Agent 的 RAG 不只是「问答检索」，而是至少要覆盖这些信息类型：

  • 规则依据：制度、条款、SOP、合规模板、变更规范
  • 操作依据：系统使用手册、接口文档、参数含义、错误码处理
  • 对象事实：来自业务系统的实时/准实时数据（用户信息、资源状态、库存、账单、设备状态）
  • 历史经验：工单处理记录、故障复盘、已知问题（KEDB）
  • 风险边界：禁用操作清单、权限范围、需要人工复核的条件

如果我们只做「文档向量库 + 生成」，Agent 走到第 3 步就会卡：它不知道该调用哪个系统、需要哪些字段、什么情况下要停下来让人确认，也不知道怎么证明自己做对了。

2. 指标

行业 Agent 场景里，最好用三类指标描述：

2.1 任务完成类指标

  • 任务成功率（最终动作成功并通过校验）
  • 平均完成时长（端到端）
  • 人工介入率（需要人确认/补充信息/兜底）
  • 回滚率（执行后需要撤销/修正）

2.2 风险类指标（红线不能过）

  • 越权率（检索/执行是否越权，目标是 0）
  • 误执行率（不该执行却执行）
  • 误答导致的错误操作（把“编出来的依据”当成执行依据）
  • 引用不可追溯率（给不出来源或来源不支持结论）

2.3 知识与检索类指标（用于驱动迭代）

  • 依据命中率（标准依据是否出现在 topK）
  • 冲突处理正确率（新旧版本/多来源冲突时是否选对）
  • 时效正确率（是否引用过期/废止内容）
  • 覆盖率（高频问题是否覆盖）

行业 Agent 的 RAG 设计，最终要对这些指标负责。否则我们会陷入「答得像那么回事，但不敢让它动系统」的状态。

3. 数据层

行业 Agent 的 RAG，数据比模型更重要。

3.1 三类数据

  1. 静态权威知识：制度、规范、手册、标准、产品文档
    目标：可追溯、版本可控、可引用
  2. 动态业务事实：来自业务系统的数据（CRM、工单、CMDB、监控、计费、IAM 等）
    目标：可校验、可审计、最好可回放（至少保留查询快照）
  3. 过程与经验：历史工单、故障复盘、处理记录、FAQ 演进
    目标：可过滤（质量参差）、可分级（权威/经验/猜测）

很多项目失败是因为把第 3 类当第 1 类用，把「经验」当「制度」。Agent 一旦据此去执行动作，风险会放大。

3.2 每个知识片段必须带的元数据

行业 Agent 需要的不只是「能搜到」，还要「能用来做动作」。建议每个 chunk 至少包含：

  • doc_id / chunk_id
  • source（系统/库）
  • source_url（可点击或可定位）
  • title_path（标题链）
  • doc_type（制度/手册/接口文档/复盘/工单等）
  • version、status（草稿/已发布/已废止）
  • effective_from / effective_to（能给就给）
  • owner（维护人/团队）
  • updated_at
  • 适用范围标签：产品线/地区/客户/机型/环境（生产/测试）
  • 权限标签：RBAC/ABAC 所需字段
  • 可执行性标签（建议加）：
    • 是否可作为执行依据（例如制度/已发布 SOP 才能）
    • 是否需要人工复核（高风险操作）
    • 是否仅供参考（复盘/经验）

这些标签对 Agent 比较关键：它能决定「能不能做、要不要停、怎么解释」。

3.3 文档解析与切分

行业 Agent 的 RAG 的切分策略，优先级一般是：

  1. 按结构切：章/节/条款/接口字段说明/错误码条目
  2. 把“前置条件/限制/例外”跟规则放一起
  3. 表格与字段定义要保表头（字段含义脱离表头就没法用）
  4. 把可执行步骤单独成块（SOP、Runbook、变更步骤）

注意：不要把「定义」「适用范围」「例外条款」切碎。Agent 执行动作时，最需要的就是边界条件和限制。

4. 索引与检索

行业 Agent 和常规的 Agent 不同，其更依赖于「过滤 + 排序 + 证据链」

4.1 使用混合检索

行业 Agent 的查询里会出现大量「硬信息」：

  • 条款号、标准号、型号、错误码、参数名、接口路径、工单号、配置项名

纯向量在这些场景不稳。工程上更常用的是：

  • 关键词/BM25：抓编号、术语、字段名、错误码
  • 向量召回：抓语义相近、同义表达
  • 融合 + 重排：把候选集排序成「最能支持动作/结论」的那几段

4.2 检索要先过滤，再找相似

行业 Agent 的过滤通常是强约束，如下：

  • 权限过滤（用户/角色/租户/数据域）
  • 状态过滤（废止、草稿默认不进）
  • 生效时间过滤（尤其制度、计费、合规）
  • 适用范围过滤（产品/地区/环境）
  • 数据域隔离（内部/客户侧/合作方）

如果我们把这些留到生成阶段「让模型自己注意」，效果不可控，风险也不可控。

4.3 Agent 专用检索

不止检索答案，还要检索工具与参数

行业 Agent 经常需要两类额外检索：

  1. 工具检索（Tool RAG）
    从「工具说明库/接口文档/SOP」里检索：该用哪个工具、需要哪些参数、有哪些限制、失败怎么处理。
  2. 参数与字段检索（Schema RAG）
    从「数据字典/字段说明/枚举值」里检索：字段含义、可选值、校验规则、示例格式。

这两类检索的结果不一定直接展示给用户，但会决定 Agent 能不能把动作做对。

5. 固化 Agent 使用 RAG 的逻辑

行业 Agent 的 RAG 关键是要「把 RAG 插进决策点」

行业 Agent 常见的内部循环大致是：

  • Plan（决定下一步做什么）
  • Act（调用工具/检索/执行）
  • Observe（拿到结果）
  • Decide（是否继续、是否需要人确认、是否结束）
  • Explain（对外输出）

RAG 的插入点建议固定成三处：

5.1 决策前

用 RAG 找「规则边界」

在 Agent 做出关键决策前，先检索：

  • 是否允许执行（权限、合规、风险等级）
  • 前置条件是什么（必须具备哪些信息、哪些系统状态）
  • 需要的审批/确认是什么（是否必须人工确认）

这一步的输出的是「约束」，不是「答案」。它会影响下一步是继续、暂停还是转人工。

5.2 执行前

用 RAG 找「操作步骤与参数」

执行某个动作前，检索：

  • SOP / Runbook / 接口文档
  • 必填参数、参数来源
  • 校验方式（执行后如何确认成功）
  • 回滚方式（失败/异常如何撤销）

这一步的输出是「可执行步骤」，不是「解释性段落」。

5.3 执行后

用 RAG 做「结果判定与错误处理」

拿到工具返回值后，检索：

  • 错误码含义与处理建议
  • 常见失败原因
  • 是否需要升级/转人工
  • 是否需要二次校验（比如跨系统一致性）

这一步的输出是「下一步动作建议 + 证据」。

6. 生成与输出

行业 Agent 的输出要分层，不要把所有东西都写给用户

行业 Agent 的输出建议拆成三层，分别服务不同目标：

  1. 用户层：结论/进展、需要用户补充什么、下一步怎么走
  2. 证据层：引用依据（链接、页码、版本、生效日期）
  3. 执行层（留痕层）：本次调用了什么工具、参数摘要、返回结果摘要、校验结果、回滚点

用户不一定要看到执行层细节，但系统必须存储这些内容。只有出了问题能回放，才敢放权。

同时，行业 Agent 的生成要有硬规则：

  • 没有命中权威依据：不输出肯定结论
  • 有冲突：必须把冲突来源、版本、生效时间写清楚
  • 涉及高风险动作：必须停下来请求确认（并把依据与影响范围给出来）
  • 引用必须来自检索上下文：不允许来虚的，「凭印象补一句」

7. 权限、审计、隔离

**行业 Agent 的 RAG 必须「检索前隔离」。

行业 Agent 一旦能调用系统，风险比问答高一个量级。权限要分两层：

7.1 知识权限

能不能看的问题

  • 文档/知识片段按 ABAC/RBAC 做过滤
  • 按租户隔离（多客户必做）
  • 按数据域隔离（内部策略、客户信息、合作方信息）

7.2 行为权限

能不能做的问题

  • 工具级权限：这个角色能调用哪些工具
  • 动作级权限：同一工具下哪些操作允许（例如只读查询 vs 修改/下发）
  • 参数级权限：同一动作下哪些资源范围允许（例如仅能操作自己负责的项目/客户）

很多团队只做了「知识权限」，没做「行为权限」。

这会导致不放心，即使 Agent 能查到 SOP，也能学会「怎么做」，但你又不敢让它真的做。

7.3 审计要能回答四个问题

  • 为什么这么做（依据是什么）
  • 做了什么（调用了哪些工具、关键参数是什么）
  • 得到了什么（返回结果与校验结果）
  • 谁批准的（如果需要人工确认）

没有这四个问题的答案，行业 Agent 很难通过安全审查，也很难在出事后定位责任与修复点。

8. 灰度上线策略

先控制风险，再谈覆盖率

行业 Agent 的上线节奏建议按权限逐步放开：

  1. 只读 Agent：只检索、只解释、只给建议，不执行任何写操作
  2. 半自动 Agent：可以生成“执行计划/工单草稿/变更单草稿”，必须人工确认后执行
  3. 受限自动 Agent：只允许低风险、可回滚、可校验的动作自动执行（例如查询、对账、生成报表、创建工单、补全字段）
  4. 高风险动作：默认保留人工确认，除非你能做到严格的权限、校验、回滚、审计，并且有明确的责任边界

上线必须准备三套兜底：

  • 超时与降级：检索失败/重排失败/模型失败时怎么退化
  • 失败回滚：执行失败怎么撤销，撤销失败怎么升级
  • 人工接管：在关键节点能一键转人工，并把证据与执行轨迹带过去

9. 常见坑

  1. 把「经验工单」当「标准答案」：Agent 会把偶发处理当成通用规则。必须分级与降权。
  2. 只做知识库，不做数据字典与工具库：Agent 会不知道参数怎么填、字段是什么意思、错误码怎么解。
  3. 只做检索，不做执行前校验与执行后校验：敢执行的前提是可校验、可回滚。
  4. 权限只管文档，不管工具：最容易在这里翻车。
  5. 没有回放评测：你不知道一次小改动会不会让 Agent 在某个分支上开始乱走。
  6. 把「多轮对话」当「任务编排」：行业 Agent 的关键是状态机与决策点，不是聊得多。

最后，行业 Agent 的 RAG 如果要构建，不仅仅是算法的事情，需要更多的业务专家，业务 Owner 来直接参与，他们才是最懂行业的人。需要他们来定义「什么算答对/答错」、哪些文档权威、版本如何取舍、哪些内容不能答。

以上。