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，最终要进入的是流程、合规和交付，而不是聊天。

以上。