行业 Agent 和我们常用的「通用聊天 Agent」不是一类东西。
行业 Agent 是要能解决问题的，而查资料只是其中一步，后面还要做判断、走流程、调用系统、校验结果、留痕、可回放。
RAG 在这里的角色也变了：它不只是给模型喂上下文，而是给 Agent 提供可执行任务所需的依据、约束、参数和证据链。
今天我们聊一下行业 Agent 构建过程中的 RAG 怎么写，从目标、数据，检索以及使用 RAG 等等方面。
1. 行业 Agent 的 RAG 要服务什么能力
行业 Agent 常见的工作方式是「多步闭环」：
- 识别问题类型与业务对象（客户、设备、合同、工单、订单、项目、账号等）
- 查依据（制度、手册、知识库、历史工单、标准、接口文档）
- 做动作（查系统、下发指令、开通配置、生成工单、发邮件、写报告、提审批）
- 校验与回写（确认变更成功、回填字段、留痕、把引用/证据挂到工单）
- 解释（给用户说明依据、影响范围、回滚方案、下一步建议）
所以行业 Agent 的 RAG 不只是「问答检索」，而是至少要覆盖这些信息类型：
- 规则依据：制度、条款、SOP、合规模板、变更规范
- 操作依据：系统使用手册、接口文档、参数含义、错误码处理
- 对象事实：来自业务系统的实时/准实时数据（用户信息、资源状态、库存、账单、设备状态）
- 历史经验：工单处理记录、故障复盘、已知问题（KEDB）
- 风险边界：禁用操作清单、权限范围、需要人工复核的条件
如果我们只做「文档向量库 + 生成」，Agent 走到第 3 步就会卡：它不知道该调用哪个系统、需要哪些字段、什么情况下要停下来让人确认，也不知道怎么证明自己做对了。
2. 指标
行业 Agent 场景里，最好用三类指标描述：
2.1 任务完成类指标
- 任务成功率（最终动作成功并通过校验）
- 平均完成时长（端到端）
- 人工介入率（需要人确认/补充信息/兜底）
- 回滚率（执行后需要撤销/修正）
2.2 风险类指标（红线不能过）
- 越权率（检索/执行是否越权，目标是 0）
- 误执行率（不该执行却执行）
- 误答导致的错误操作（把“编出来的依据”当成执行依据）
- 引用不可追溯率（给不出来源或来源不支持结论）
2.3 知识与检索类指标（用于驱动迭代）
- 依据命中率（标准依据是否出现在 topK）
- 冲突处理正确率（新旧版本/多来源冲突时是否选对）
- 时效正确率（是否引用过期/废止内容）
- 覆盖率（高频问题是否覆盖）
行业 Agent 的 RAG 设计，最终要对这些指标负责。否则我们会陷入「答得像那么回事，但不敢让它动系统」的状态。
3. 数据层
行业 Agent 的 RAG，数据比模型更重要。
3.1 三类数据
- 静态权威知识：制度、规范、手册、标准、产品文档
目标：可追溯、版本可控、可引用 - 动态业务事实：来自业务系统的数据（CRM、工单、CMDB、监控、计费、IAM 等）
目标：可校验、可审计、最好可回放（至少保留查询快照） - 过程与经验：历史工单、故障复盘、处理记录、FAQ 演进
目标：可过滤（质量参差）、可分级（权威/经验/猜测）
很多项目失败是因为把第 3 类当第 1 类用，把「经验」当「制度」。Agent 一旦据此去执行动作，风险会放大。
3.2 每个知识片段必须带的元数据
行业 Agent 需要的不只是「能搜到」，还要「能用来做动作」。建议每个 chunk 至少包含：
doc_id / chunk_idsource（系统/库）source_url（可点击或可定位）title_path（标题链）doc_type（制度/手册/接口文档/复盘/工单等）version、status（草稿/已发布/已废止）effective_from / effective_to（能给就给）owner（维护人/团队）updated_at- 适用范围标签：产品线/地区/客户/机型/环境（生产/测试）
- 权限标签：RBAC/ABAC 所需字段
- 可执行性标签（建议加）：
- 是否可作为执行依据（例如制度/已发布 SOP 才能）
- 是否需要人工复核（高风险操作）
- 是否仅供参考（复盘/经验）
这些标签对 Agent 比较关键：它能决定「能不能做、要不要停、怎么解释」。
3.3 文档解析与切分
行业 Agent 的 RAG 的切分策略，优先级一般是：
- 按结构切：章/节/条款/接口字段说明/错误码条目
- 把“前置条件/限制/例外”跟规则放一起
- 表格与字段定义要保表头（字段含义脱离表头就没法用）
- 把可执行步骤单独成块（SOP、Runbook、变更步骤）
注意：不要把「定义」「适用范围」「例外条款」切碎。Agent 执行动作时，最需要的就是边界条件和限制。
4. 索引与检索
行业 Agent 和常规的 Agent 不同，其更依赖于「过滤 + 排序 + 证据链」
4.1 使用混合检索
行业 Agent 的查询里会出现大量「硬信息」：
- 条款号、标准号、型号、错误码、参数名、接口路径、工单号、配置项名
纯向量在这些场景不稳。工程上更常用的是：
- 关键词/BM25：抓编号、术语、字段名、错误码
- 向量召回：抓语义相近、同义表达
- 融合 + 重排：把候选集排序成「最能支持动作/结论」的那几段
4.2 检索要先过滤，再找相似
行业 Agent 的过滤通常是强约束，如下：
- 权限过滤（用户/角色/租户/数据域）
- 状态过滤（废止、草稿默认不进）
- 生效时间过滤（尤其制度、计费、合规）
- 适用范围过滤（产品/地区/环境）
- 数据域隔离（内部/客户侧/合作方）
如果我们把这些留到生成阶段「让模型自己注意」，效果不可控，风险也不可控。
4.3 Agent 专用检索
不止检索答案，还要检索工具与参数
行业 Agent 经常需要两类额外检索：
- 工具检索（Tool RAG）
从「工具说明库/接口文档/SOP」里检索：该用哪个工具、需要哪些参数、有哪些限制、失败怎么处理。 - 参数与字段检索（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 的输出建议拆成三层，分别服务不同目标：
- 用户层：结论/进展、需要用户补充什么、下一步怎么走
- 证据层：引用依据（链接、页码、版本、生效日期）
- 执行层（留痕层）：本次调用了什么工具、参数摘要、返回结果摘要、校验结果、回滚点
用户不一定要看到执行层细节，但系统必须存储这些内容。只有出了问题能回放，才敢放权。
同时，行业 Agent 的生成要有硬规则：
- 没有命中权威依据：不输出肯定结论
- 有冲突：必须把冲突来源、版本、生效时间写清楚
- 涉及高风险动作：必须停下来请求确认（并把依据与影响范围给出来）
- 引用必须来自检索上下文：不允许来虚的，「凭印象补一句」
7. 权限、审计、隔离
**行业 Agent 的 RAG 必须「检索前隔离」。
行业 Agent 一旦能调用系统，风险比问答高一个量级。权限要分两层：
7.1 知识权限
能不能看的问题
- 文档/知识片段按 ABAC/RBAC 做过滤
- 按租户隔离（多客户必做）
- 按数据域隔离（内部策略、客户信息、合作方信息）
7.2 行为权限
能不能做的问题
- 工具级权限：这个角色能调用哪些工具
- 动作级权限：同一工具下哪些操作允许（例如只读查询 vs 修改/下发）
- 参数级权限：同一动作下哪些资源范围允许（例如仅能操作自己负责的项目/客户）
很多团队只做了「知识权限」，没做「行为权限」。
这会导致不放心，即使 Agent 能查到 SOP，也能学会「怎么做」，但你又不敢让它真的做。
7.3 审计要能回答四个问题
- 为什么这么做（依据是什么）
- 做了什么（调用了哪些工具、关键参数是什么）
- 得到了什么（返回结果与校验结果）
- 谁批准的（如果需要人工确认）
没有这四个问题的答案，行业 Agent 很难通过安全审查，也很难在出事后定位责任与修复点。
8. 灰度上线策略
先控制风险，再谈覆盖率
行业 Agent 的上线节奏建议按权限逐步放开：
- 只读 Agent：只检索、只解释、只给建议，不执行任何写操作
- 半自动 Agent：可以生成“执行计划/工单草稿/变更单草稿”，必须人工确认后执行
- 受限自动 Agent：只允许低风险、可回滚、可校验的动作自动执行（例如查询、对账、生成报表、创建工单、补全字段）
- 高风险动作：默认保留人工确认，除非你能做到严格的权限、校验、回滚、审计，并且有明确的责任边界
上线必须准备三套兜底：
- 超时与降级：检索失败/重排失败/模型失败时怎么退化
- 失败回滚：执行失败怎么撤销，撤销失败怎么升级
- 人工接管：在关键节点能一键转人工，并把证据与执行轨迹带过去
9. 常见坑
- 把「经验工单」当「标准答案」：Agent 会把偶发处理当成通用规则。必须分级与降权。
- 只做知识库，不做数据字典与工具库：Agent 会不知道参数怎么填、字段是什么意思、错误码怎么解。
- 只做检索，不做执行前校验与执行后校验：敢执行的前提是可校验、可回滚。
- 权限只管文档，不管工具：最容易在这里翻车。
- 没有回放评测：你不知道一次小改动会不会让 Agent 在某个分支上开始乱走。
- 把「多轮对话」当「任务编排」：行业 Agent 的关键是状态机与决策点，不是聊得多。
最后，行业 Agent 的 RAG 如果要构建，不仅仅是算法的事情，需要更多的业务专家，业务 Owner 来直接参与，他们才是最懂行业的人。需要他们来定义「什么算答对/答错」、哪些文档权威、版本如何取舍、哪些内容不能答。
以上。