聊聊选择，以及我的 2025 总结

老家。

酒后！

去年的所有文章有 90% 以上的内容都是 AI 写的。这篇总结就不用 AI 了。

为什么用选择这个主题呢，原因很简单，因为刷视频的时候刷到了刘震云老师的一段话：

不要后悔你曾经的所有决定，哪怕做错了，你都不要后悔，因为在当时那个条件下，你的认知就决定了，你只能做出那个选择。
你人生所有的决定都是为你自己的认知而买单。
所以不念过去，不畏将来，活在当下。
人生没有白走的路，对错都算数。 做你该做的事，你脚下的这条路，就是最好的路。

有点鸡汤，但是却真实。

想起刚毕业时的选择，有一回团建，刚好和万兴的 HR 老大在同一个车，在车上，忘记聊到了什么，现在还记得的是结婚是门当户对以及结婚是要：想好了，想清楚了，想明白了。

当时不觉得什么，这么多年过去了，这句话时常在耳边回响。

越来觉得这是一个非常深刻且富有哲理的话题，尤其是当时我这种刚毕业进入 社会的萌新、面对人生重大抉择的阶段，这句话体现认知决策的三个递进层次（当时并不觉得）。

想好了

「想好了」通常指在面对一个选择时，已经做出了最终的决定，并且愿意为这个决定承担责任。这是一个行动导向的层面。

在这个层面，我们：

  1. 停止纠结： 不再在 A 选项和 B 选项之间反复横跳。比如在婚姻中，不再犹豫“是不是还有更好的”，而是认定“就是这个人了”。
  2. 承诺： 意味着你准备好投入所有（时间、金钱、情感）。
  3. 接受现状： 承认目前的条件是做出该决定的基础。

想清楚了

「想清楚了」是理性的我。它要求我们不仅要有决心，还要对事情的前因后果、利弊得失、潜在风险有清晰的推演。这是一个逻辑导向的层面。

此时的我应该做了：

  1. 可行性分析： 能够罗列出支持这个决定的客观条件。比如，为什么说我们是“门当户对”的？是因为消费观一致？还是教育背景相似？
  2. 风险预判： 知道最坏的结果是什么。如果结婚，双方家庭会有什么矛盾？贫贱夫妻百事哀的概率有多大？如果门不当户不对，差异带来的鸿沟怎么填补？
  3. 未来规划： 知道接下来该怎么走。不仅仅是决定结婚，还想清楚了婚后住哪里、钱怎么管、孩子怎么带。

想明白了

最后一个层次，有点属于智慧的范畴。

「想明白了」意味着透过现象看到了本质，理解了自己为什么要做这个选择，以及这个选择对我们的终极意义。这是一个哲学与自我导向的层面。

在这里，我们会有：

  1. 自我认知： 知道自己到底是个什么样的人，想要什么样的人生。不是因为父母觉得好，不是因为社会觉得对，而是因为这符合我当时的追求。
  2. 接纳不完美： 深刻理解「世事无完美」。想明白了的人，不会因为婚后的一地鸡毛而崩溃，因为他早就理解婚姻的本质就是合作与妥协，而不是童话。

回到工作中，后面有一个自己的感悟，当选择工作时需要想清楚:

  • 团队是什么样的团队
  • 领导是什么样的领导
  • 业务是什么样的业务

团队是我们每天要面对的人，是我们工作的环境，它直接决定了我们的工作体验和执行效率。

就和当前面试一样，如果一个人你看第一眼觉得不舒服，那就不要聊了。

领导是职场中最重要的变量，他掌握着我们职场中的资源分配、绩效评价和升迁路径。

看眼缘和沟通风格，是事必躬亲型还是放权型？是暴躁型还是温和型？

找到和你能匹配上的，相处舒服的。

业务决定了赛道，天花板和市场价值。

以上的选择在不同的时期优先级并不一样：

  • 在刚毕业时，优先选领导或团队。
  • 随着经验的增加，优先选业务或领导
  • 最后你成熟了，可以优先选业务或团队。

可以琢磨一下为啥是这样？欢迎留言探讨。

2025 真的过去了，40 了。

这一年，真要谢谢努力的我们，为了生活起早摸黑，努力奋斗。

在烟火缭绕里谋生，在诗情画意里寻梦。

自始至终未曾虚度，也从未轻言放弃。

再苦再累也咬紧牙关撑过。

感谢这一年坚强努力的我们，希望所有的奔赴都有意义。

不谈过往，不说如果，只希望我们的 2026 越来越好!

这一年，改变，成长，完结；

下一年，希望，迭代，向前，期待。

新年，旧年，皆甜。

写得很虚，没有什么数据和具体的逻辑，就这样吧。

以上。

行业 Agent 实战总结：行业 Know How 如何在 AI Agent 中落地

2025 年就要过去了，今年算是 「 AI Agent 元年」。各种 AI Agent 层出不穷，我们能看到的做得比较好的还是编程用的 Agent。

做垂直行业 Agent 最常见的问题是「行业 Know How 没有变成系统的一部分」。

很多团队一开始就把一堆文档丢进知识库，做个 RAG，就开始卖方案。这种产品上线后很快就会遇到三类问题：

  • 答得像懂，但不符合行业规则：说法对，流程错；建议对，边界条件错。
  • 能聊但不能办事：无法稳定调用工具、填表、校验、留痕。
  • 越迭代越乱：知识变更没人负责，指标不清，线上问题复现不了。

Know How 真正落地，不仅仅是「让模型看过资料」，还要把行业经验拆成可维护的资产，进入 Agent 的检索、对话策略、工具链、评测与治理。

下面是我对于这个事情的一些思考：

1. 行业 Know How 是什么

首先它不是什么。它不等于行业知识。

大家口头说的 Know How，落到产品和工程，至少包含五类东西：

  1. 概念与术语体系
    行业里的实体是什么、字段是什么意思、同义词怎么对齐、缩写怎么展开。
    以室内设计为例，意式低奢风格包括哪些元素，颜色，走线是怎样的，沙发应该是怎样的沙发，摆件应该是要用什么摆件等等。

  2. 规则与约束
    哪些能做、哪些不能做；阈值、条件、合规要求、审批链。
    这部分经常是 Agent 出错的根源，因为它不像百科知识那样「常识化」。或者换句话说这些在大模型的数据集中没有。

  3. 标准流程与例外流程
    正常路径怎么走，遇到异常如何处理，什么时候需要人工介入。
    垂直行业的「例外」通常比「主流程」更重要。

  4. 可交付的结果格式
    最终输出不是一段话，而是：一张符合要求的图、一份报表、一段可执行的操作、一张表单、一条工单、一段对外话术、一次系统配置变更。
    Know How 里要明确「交付物长什么样」。

  5. 判断标准（质量定义）
    什么叫「答对/办对」，什么叫「可用/不可用」，什么叫「风险可控」。
    这决定了你的评测体系怎么做，也决定能不能规模化。

很多人只停留在把 1 做好，，但 2/3/4/5 没有结构化，导致 Agent 看起来在输出，实际上没法稳定交付。

2. 行业 Know How 落地过程中的指标

把 Know How 落进 Agent 需要实现四个更实际的指标：

  1. 更低的错误率（尤其是规则类错误）
    垂直行业里，最致命的不是“答得不够全面”，而是“违规、越权、走错流程、漏掉关键校验”。

  2. 更稳定的工具执行
    Agent 需要把自然语言转换成结构化参数、步骤、校验，再调用系统。
    Know How 决定：填哪些字段、字段怎么校验、失败如何重试、何时升级人工。

  3. 更可控的交付质量
    有的行业输出必须“可审计、可追溯、可复核”。
    Know How 需要提供引用依据、版本号、规则来源、操作日志策略。

  4. 更强的组织协作效率
    Know How 一旦工程化，你就能把原来靠“资深同事口口相传”的经验，变成可复用资产。
    这在创业团队里很关键：人员变动不会让能力断层。

3. 按四层做落地实施

我个人倾向于把落地过程拆成四层，每层都有明确产物，方便推进、验收和迭代，并且每一层可能会对应不同的工种或团队，如果团队比较大的话：

  1. 知识层（Knowledge）：知识库、术语体系、规则库、流程库
  2. 数据层（Data）：训练数据集、测试数据集、线上回流数据
  3. 行为层（Behavior）：提示词、对话策略、工具规范、风控策略
  4. 模型层（Model）：基座模型选择、RAG 策略、LoRA/微调、路由与降级

3.1 行业 Know How 的定义与知识库的搭建

既然要做行业 Know How，那么需要清晰的知道什么是行业 Know How，以及谁可以做好行业 Know How 这件事情。

典型的负责人是业务 Owner 或资深的运营专家，如果是设计相关的行业，至少是设计总监级别的人才行。

我们做这个事情的目标是让让模型/Agent 说得准、做得对，并且可维护。

其核心产物如下：

  1. 术语体系：术语表（中英/别名/缩写）、字段含义、口径说明
  2. 规则库：可枚举的判断规则、禁区、例外条件（最好结构化）
  3. 流程库：关键业务流程（输入→判断→输出），含边界条件
  4. 知识源清单：哪些文档可信？更新频率？责任人是谁？（否则 RAG 永远不稳定）

这里建议做最小集合。

在做定义时，并不要直接全面畏开，小步快跑，灰度上线在这里也是一个好用的策略。

特别是小团队，可以让 业务Owner 主导，配一个「知识整理员」（运营/产品），快速迭代进行。

如果团队比较大，可以以「行业知识委员会」之类的组织形式（包括业务、法务/合规、客服/运营、产品等），每周进行，也是需要做增量逻辑 。

当做完了后，这些所有的内容都是需要验收的，大概需要有如下的一些标准，不同的行业不同，大家可以根据自己的情况延展开来：

  • 覆盖 Top N 高频问题/场景（比如 50/100 个）
  • 每条规则/流程有：来源、责任人、更新时间
  • 知识库能支撑检索：有统一 ID、可追溯引用
  • 隔离策略，权限控制
  • 切分粒度，过期策略

这些标准可以可直接写进项目的里程碑中。

3.2 数据集：训练数据集、测试数据集、回流数据

AI 教母李飞飞在视频里说过：数据不能说比算法重要，但至少同等重要。在垂直 Agent 场景，这句话更接近现实：用同一个基座模型，最后差距往往来自数据与评测体系。

数据一般是算法负责人或算法工程师来负责，但业务同学也需要参考其中，因为数据的好坏并不是算法同学可以解决的，以室内设计为例，一张图是否符合某个风格，算法的同学其实是不懂的，这需要业务同学的深度参与，并一起构建。

算法侧同学提供平台和数据，业务同学提供判断的能力和过程。

其核心产物如下：

  1. 训练/指令数据集（若需要）：问题-答案、对话、工具调用轨迹，让模型学会行业表达方式、结构化输出、工具调用格式、常见任务路径
  2. 测试集（强烈建议先做）：覆盖关键业务场景 + 对抗样本 + 边界条件，以可以稳定衡量上线质量
  3. 线上回流数据：用户输入、模型输出、工具结果、人工标注、失败原因标签，需要考虑用户隐私或者用户不允许使用其数据作为训练用等情况。这些数据可以让我们看到真实用户问题、失败案例、人工修正记录，用来驱动迭代
  4. 标注规范：什么算“正确/合规/有帮助/可执行”，标签定义要可复用

在小团队中，可以先做轻量的测试集，用于做版本回归；大一些的团队，可以直接先建议数据流水线：采集→脱敏→抽样→标注→入库→评测→报表。一把到位，不过也可以先人工，再脚本，再系统，再平台的逐步演化。

在做数据过程中，数据标注是一个很重要，但是又很重复的活儿。

建议在训练/测试数据中同时包含：

  • 正确输出（结构化字段或执行计划）
  • 关键引用依据（规则/流程/定义来自哪一条知识）
  • 失败示例（常见错误输出长什么样）
  • 评判标准（哪些字段错了就算失败）

对于一个创业团队来说，很难一开始就有大量行业的高质量数据，建议把精力放在：

  • 覆盖核心任务前 20% 的高频路径
  • 覆盖最致命的规则错误
  • 覆盖工具调用最常失败的参数组合
  • 每次迭代只扩一小块范围，但把这块做“闭环”

3.3 提示词

提示词是我们和 Agent 交互的核心路径，在落地时，我们需要把 Know How 变成对话策略和执行约束。

在垂直 Agent 中，我一般只保留这些内容：

  • 角色与权限边界：能做什么、不能做什么
  • 任务范围：支持哪些任务，不支持哪些任务
  • 关键术语与字段定义（只放必须的，其他走检索）
  • 输出规范：必须给结构化结果、必须给引用、必须留痕字段
  • 追问策略：缺哪些字段必须追问；遇到冲突必须确认
  • 风控策略：触发哪些条件必须拒绝/升级人工
  • 工具调用原则：什么时候必须调用工具验证，什么时候允许只基于知识回答

不要在系统提示词里塞大量「知识正文」，那是 RAG 的工作。

垂直行业用户会追问「你凭什么这么做」。如果引用做不好，Agent 很难进入生产流程。

建议把引用设计成两层：

  • 面向业务用户：引用规则标题 + 生效时间 + 一句话解释
  • 面向审计/排障：引用片段 ID、版本号、检索得分、调用工具日志

这部分一旦做成标准件，后面迭代会轻松很多。

另外，需要考虑提示词的版本问题，需要像代码一样做版本管理（有变更记录、可回滚）。

并且，对于对话策略，需要能澄清问题、确认关键信息、分步执行、失败重试与兜底；对于工具，每个工具的输入输出 schema、超时、幂等、重试、权限等等都需要考虑。还有一些风控策略。

在小团队中，可以用一套主提示词 + 若干场景子提示词，先保证可控，工具尽量少但稳定。

业务复杂一些后，可以做策略路由，做一个策略系统，不同意图走不同策略/模型/工具链，并且可以引入灰度发布等逻辑以减少版本迭代时对用户的影响，以及做 A/B 策略。

3.4 在 LoRA 中如何体现这些 Know How

LoRA 适合学“表达方式与结构化习惯”，不适合塞“会变的事实与规则全文”。

以室内设计为例，LoRA 真正解决的是两件事：

  1. 让模型更像专业的设计师（表达方式、偏好、组合习惯、审美取向更稳定）
  2. 让模型在特定任务上更「听话」且更一致（同样的输入，输出结构、风格强度、方案套路更可控）

LoRA 是把隐性经验固化

设计的很多 know-how 不是“能查到的一条条规则”，而是：

  • 这个风格到底应该选哪些材质更对味
  • 什么比例的木色/灰度/金属更像“中古”
  • 软装怎么搭不显廉价
  • 同一个户型在预算约束下，先动哪里收益最大
  • 同样叫“奶油风”，专业设计师认可的“奶油风”边界在哪里

这些东西虽然也可以写成原则，但很难写成完整可枚举的规则库。这类「难以规则化但能被大量样例体现」的东西，才是 LoRA 更擅长的。

以风格为例，风格可以拆成两部分：

A. 可描述、可枚举的部分（更像知识）
比如：

  • 风格定义与边界：什么是侘寂、什么不是
  • 常用元素清单：材料、色系、线条、灯型、家具轮廓
  • 禁忌与冲突：哪些组合容易翻车
  • 预算/空间约束下的硬规则：动线、安全、尺度、收纳基本原则

这部分适合放在 知识层（术语/规则/流程）+ RAG：因为它会更新、可追溯、要引用来源，改起来也方便。

B. 难以枚举、靠“整体观感”判断的部分（更像模型能力）
比如：

  • “像不像某个风格”的整体一致性
  • 元素比例、轻重、层次、留白的拿捏
  • “高级/廉价”“松弛/用力过猛”这种审美判断
  • 团队偏好的方案套路（同户型常用的解决方式）

这部分更适合用 LoRA：用高质量样例把“认可的风格分布”压到模型里，让它输出更稳定。

在以 LoRA 落地的过程中， 风格一致性更稳，输出更贴近可交付物，方案「更会落地」

3.5 那大模型呢？

Know How 在大模型中如何体现？企业不炼模型，怎么选、选完能做什么？

大多数企业不可能自己训练大模型，现实做法是：选一个合适的基座 + 做好工程层的增强。

大模型的选择需要在成本、稳定性、延迟之间达到可用平衡，并可持续可迭代。 这里的迭代不仅仅是大模型本身的迭代，还可能是切换到其它的大模型。

在当前的 AI 场景，没有所谓的客户忠诚可言，哪个好用用哪个，而且切换成本不高（API + 提示词场景）。

创业小团队需要以 RAG + 行为策略，把 80% 问题做稳，暂缓微调；把钱花在评测与回流上。 只有这些成熟一些后，可以再考虑上 LoRA/微调，收益才可控。

对于大模型，我们会关心这些维度：

  • 工具调用能力：函数调用是否稳定、参数是否可控
  • 长上下文与检索融合：能不能在引用材料下保持一致
  • 结构化输出稳定性：格式错一次，生产系统就要兜底
  • 安全与合规：越权回答、敏感信息处理、拒答策略
  • 成本与延迟：是否能在预算内跑到规模
  • 部署形态：公有云/私有化/混合；日志与数据是否可控

我们不会只选一个模型就定终身。哪个好用用哪个，并且在工程层面实现「模型路由」：不同任务用不同模型，失败自动降级。

4. 聊下组织

在整个落地的过程中，组织是对落地结果的非常重要的保障，需要事事有人跟，件件有人负责，一般的分工如下：

  • 业务负责人：定义任务边界与验收标准，批准规则变更
  • 行业专家：产出规则/例外/口径，参与标注与复核
  • 产品/运营：维护任务地图、模板、知识版本，推动回流闭环
  • 算法/工程：RAG、工具链、评测、监控、部署与回滚

5. 小结

Know How 落地的目标不是「更像专家」，而是「更像系统」

垂直行业的 AI Agent，最终要进入的是流程、合规和交付，而不是聊天。

以上。

如何构建行业 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 来直接参与，他们才是最懂行业的人。需要他们来定义「什么算答对/答错」、哪些文档权威、版本如何取舍、哪些内容不能答。

以上。