2025 年就要过去了，今年算是 「 AI Agent 元年」。各种 AI Agent 层出不穷，我们能看到的做得比较好的还是编程用的 Agent。
做垂直行业 Agent 最常见的问题是「行业 Know How 没有变成系统的一部分」。
很多团队一开始就把一堆文档丢进知识库，做个 RAG，就开始卖方案。这种产品上线后很快就会遇到三类问题：
-
答得像懂，但不符合行业规则：说法对，流程错；建议对，边界条件错。 -
能聊但不能办事：无法稳定调用工具、填表、校验、留痕。 -
越迭代越乱：知识变更没人负责，指标不清，线上问题复现不了。
Know How 真正落地，不仅仅是「让模型看过资料」，还要把行业经验拆成可维护的资产，进入 Agent 的检索、对话策略、工具链、评测与治理。
下面是我对于这个事情的一些思考：
1. 行业 Know How 是什么
首先它不是什么。它不等于行业知识。
大家口头说的 Know How，落到产品和工程，至少包含五类东西：
-
概念与术语体系
行业里的实体是什么、字段是什么意思、同义词怎么对齐、缩写怎么展开。
以室内设计为例，意式低奢风格包括哪些元素，颜色，走线是怎样的，沙发应该是怎样的沙发，摆件应该是要用什么摆件等等。 -
规则与约束
哪些能做、哪些不能做；阈值、条件、合规要求、审批链。
这部分经常是 Agent 出错的根源，因为它不像百科知识那样「常识化」。或者换句话说这些在大模型的数据集中没有。 -
标准流程与例外流程
正常路径怎么走，遇到异常如何处理，什么时候需要人工介入。
垂直行业的「例外」通常比「主流程」更重要。 -
可交付的结果格式
最终输出不是一段话，而是：一张符合要求的图、一份报表、一段可执行的操作、一张表单、一条工单、一段对外话术、一次系统配置变更。
Know How 里要明确「交付物长什么样」。 -
判断标准（质量定义）
什么叫「答对/办对」，什么叫「可用/不可用」，什么叫「风险可控」。
这决定了你的评测体系怎么做，也决定能不能规模化。
很多人只停留在把 1 做好，，但 2/3/4/5 没有结构化，导致 Agent 看起来在输出，实际上没法稳定交付。
2. 行业 Know How 落地过程中的指标
把 Know How 落进 Agent 需要实现四个更实际的指标：
-
更低的错误率（尤其是规则类错误）
垂直行业里，最致命的不是“答得不够全面”，而是“违规、越权、走错流程、漏掉关键校验”。 -
更稳定的工具执行
Agent 需要把自然语言转换成结构化参数、步骤、校验，再调用系统。
Know How 决定：填哪些字段、字段怎么校验、失败如何重试、何时升级人工。 -
更可控的交付质量
有的行业输出必须“可审计、可追溯、可复核”。
Know How 需要提供引用依据、版本号、规则来源、操作日志策略。 -
更强的组织协作效率
Know How 一旦工程化，你就能把原来靠“资深同事口口相传”的经验，变成可复用资产。
这在创业团队里很关键：人员变动不会让能力断层。
3. 按四层做落地实施
我个人倾向于把落地过程拆成四层，每层都有明确产物，方便推进、验收和迭代，并且每一层可能会对应不同的工种或团队，如果团队比较大的话：
-
知识层（Knowledge）：知识库、术语体系、规则库、流程库 -
数据层（Data）：训练数据集、测试数据集、线上回流数据 -
行为层（Behavior）：提示词、对话策略、工具规范、风控策略 -
模型层（Model）：基座模型选择、RAG 策略、LoRA/微调、路由与降级
3.1 行业 Know How 的定义与知识库的搭建
既然要做行业 Know How，那么需要清晰的知道什么是行业 Know How，以及谁可以做好行业 Know How 这件事情。
典型的负责人是业务 Owner 或资深的运营专家，如果是设计相关的行业，至少是设计总监级别的人才行。
我们做这个事情的目标是让让模型/Agent 说得准、做得对，并且可维护。
其核心产物如下：
-
术语体系：术语表（中英/别名/缩写）、字段含义、口径说明 -
规则库：可枚举的判断规则、禁区、例外条件（最好结构化） -
流程库：关键业务流程（输入→判断→输出），含边界条件 -
知识源清单：哪些文档可信？更新频率？责任人是谁？（否则 RAG 永远不稳定）
这里建议做最小集合。
在做定义时，并不要直接全面畏开，小步快跑，灰度上线在这里也是一个好用的策略。
特别是小团队，可以让 业务Owner 主导，配一个「知识整理员」（运营/产品），快速迭代进行。
如果团队比较大，可以以「行业知识委员会」之类的组织形式（包括业务、法务/合规、客服/运营、产品等），每周进行，也是需要做增量逻辑 。
当做完了后，这些所有的内容都是需要验收的，大概需要有如下的一些标准，不同的行业不同，大家可以根据自己的情况延展开来：
-
覆盖 Top N 高频问题/场景（比如 50/100 个） -
每条规则/流程有：来源、责任人、更新时间 -
知识库能支撑检索：有统一 ID、可追溯引用 -
隔离策略，权限控制 -
切分粒度，过期策略
这些标准可以可直接写进项目的里程碑中。
3.2 数据集：训练数据集、测试数据集、回流数据
AI 教母李飞飞在视频里说过：数据不能说比算法重要，但至少同等重要。在垂直 Agent 场景，这句话更接近现实：用同一个基座模型，最后差距往往来自数据与评测体系。
数据一般是算法负责人或算法工程师来负责，但业务同学也需要参考其中，因为数据的好坏并不是算法同学可以解决的，以室内设计为例，一张图是否符合某个风格，算法的同学其实是不懂的，这需要业务同学的深度参与，并一起构建。
算法侧同学提供平台和数据，业务同学提供判断的能力和过程。
其核心产物如下：
-
训练/指令数据集（若需要）：问题-答案、对话、工具调用轨迹，让模型学会行业表达方式、结构化输出、工具调用格式、常见任务路径 -
测试集（强烈建议先做）：覆盖关键业务场景 + 对抗样本 + 边界条件，以可以稳定衡量上线质量 -
线上回流数据：用户输入、模型输出、工具结果、人工标注、失败原因标签，需要考虑用户隐私或者用户不允许使用其数据作为训练用等情况。这些数据可以让我们看到真实用户问题、失败案例、人工修正记录，用来驱动迭代 -
标注规范：什么算“正确/合规/有帮助/可执行”，标签定义要可复用
在小团队中，可以先做轻量的测试集，用于做版本回归；大一些的团队，可以直接先建议数据流水线：采集→脱敏→抽样→标注→入库→评测→报表。一把到位，不过也可以先人工，再脚本，再系统，再平台的逐步演化。
在做数据过程中，数据标注是一个很重要，但是又很重复的活儿。
建议在训练/测试数据中同时包含：
-
正确输出（结构化字段或执行计划） -
关键引用依据（规则/流程/定义来自哪一条知识） -
失败示例（常见错误输出长什么样） -
评判标准（哪些字段错了就算失败）
对于一个创业团队来说，很难一开始就有大量行业的高质量数据，建议把精力放在：
-
覆盖核心任务前 20% 的高频路径 -
覆盖最致命的规则错误 -
覆盖工具调用最常失败的参数组合 -
每次迭代只扩一小块范围，但把这块做“闭环”
3.3 提示词
提示词是我们和 Agent 交互的核心路径，在落地时，我们需要把 Know How 变成对话策略和执行约束。
在垂直 Agent 中，我一般只保留这些内容：
-
角色与权限边界：能做什么、不能做什么 -
任务范围：支持哪些任务，不支持哪些任务 -
关键术语与字段定义（只放必须的，其他走检索） -
输出规范：必须给结构化结果、必须给引用、必须留痕字段 -
追问策略：缺哪些字段必须追问；遇到冲突必须确认 -
风控策略：触发哪些条件必须拒绝/升级人工 -
工具调用原则：什么时候必须调用工具验证，什么时候允许只基于知识回答
不要在系统提示词里塞大量「知识正文」，那是 RAG 的工作。
垂直行业用户会追问「你凭什么这么做」。如果引用做不好，Agent 很难进入生产流程。
建议把引用设计成两层：
-
面向业务用户：引用规则标题 + 生效时间 + 一句话解释 -
面向审计/排障：引用片段 ID、版本号、检索得分、调用工具日志
这部分一旦做成标准件，后面迭代会轻松很多。
另外，需要考虑提示词的版本问题，需要像代码一样做版本管理（有变更记录、可回滚）。
并且，对于对话策略，需要能澄清问题、确认关键信息、分步执行、失败重试与兜底；对于工具，每个工具的输入输出 schema、超时、幂等、重试、权限等等都需要考虑。还有一些风控策略。
在小团队中，可以用一套主提示词 + 若干场景子提示词，先保证可控，工具尽量少但稳定。
业务复杂一些后，可以做策略路由，做一个策略系统，不同意图走不同策略/模型/工具链，并且可以引入灰度发布等逻辑以减少版本迭代时对用户的影响，以及做 A/B 策略。
3.4 在 LoRA 中如何体现这些 Know How
LoRA 适合学“表达方式与结构化习惯”，不适合塞“会变的事实与规则全文”。
以室内设计为例，LoRA 真正解决的是两件事：
-
让模型更像专业的设计师（表达方式、偏好、组合习惯、审美取向更稳定） -
让模型在特定任务上更「听话」且更一致（同样的输入，输出结构、风格强度、方案套路更可控）
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，最终要进入的是流程、合规和交付，而不是聊天。
以上。