之前在做 AI Agent 落地时我一直被一个很实际的问题卡住专家脑子里那套判断逻辑很难完整搬到 Agent 的技能体系里。让专家写提示词写出来的东西太口语、不够结构化让开发去访谈专家又会丢失大量隐性经验。后来我梳理了一整套通过专家知识蒸馏自动生成 AI 技能的方法配合团队内部代号 COLLEAGUE.SKILL 的工程实践沉淀出了从知识采集、蒸馏转换到技能验证的完整链路。这篇文章就把这套方法完整拆开讲清楚覆盖核心概念、蒸馏流程、代码示例和坑点排查适合正在做 Agent 技能工程化、知识库转技能、或者想要让专家经验自动变成 AI 能力的小伙伴。1. 背景为什么需要自动生成 AI 技能1.1 AI 技能Skill到底是什么在 LLM Agent 的开发语境里Skill技能并不是一个玄乎的概念。它本质上是一份结构化的“能力包”包含技能的描述和触发条件执行步骤或提示词模板可调用的工具/函数定义输入输出规范参考示例Few-shot examples。对比一下普通 Prompt 和 Skill 的区别在于Prompt 是一次性的“指令文本”而 Skill 是可复用、可组合、可版本化的“能力单元”。当我们说“给 Agent 添加一个技能”并不是简单写一段提示词而是让 Agent 在遇到对应场景时能够像人一样调用一套完整的处理流程。1.2 传统技能构建的三个痛点在实际项目里构建 AI 技能通常有三种做法但都有明显的问题。第一种让领域专家直接写提示词。专家的优势是领域知识不是提示词工程。他们写出来的描述往往含糊比如说“要分析用户反馈里的情绪倾向”但不会写清楚“情绪倾向分几类、每类的判断边界是什么、遇到冲突时怎么处理”。这种技能生成后很难稳定复现专家水平。第二种让开发人员访谈专家后手工沉淀。这种方式的问题是信息损耗高。访谈过程中专家会省略大量“理所当然”的细节开发人员又不具备领域背景很难追问到关键点上。最终形成的技能往往流于表面等于把专家知识做了一个浅层抽象。第三种直接拿通用大模型生成技能。这个方式的问题是没有“专家知识源”的约束。大模型生成的技能内容可能看起来很完整但核心判断依据是模型自身的知识而不是你团队内专家真正的工作方法。换句话说生成的是“通用技能”不是“专家技能”。这三个痛点的本质都是同一个专家知识与 Agent 技能之间存在一条鸿沟缺少一个结构化的转换机制。1.3 知识蒸馏为什么适合解决这个问题知识蒸馏Knowledge Distillation这个概念最早出现在模型压缩领域核心思路是让一个小模型Student去学习大模型Teacher的输出分布从而在牺牲少量精度的情况下获得更高的推理效率。但知识蒸馏的思路并不局限在模型压缩上。只要存在“知识丰富但形态笨重”的源头和“需要轻量、结构化、可复用”的目标蒸馏思想就适用。在 COLLEAGUE.SKILL 的场景里Teacher 是专家知识源可以是专家的操作日志、决策记录、历史工单、标注数据甚至是专家与大模型的多轮交互轨迹Student 是 AI Skill一份结构化的技能定义文件包含触发条件、执行流程、约束规则和示例蒸馏的过程就是从“大量隐性的专家行为数据”中提炼出“显性的、可执行的技能逻辑”。这本质上是一种信息压缩把专家长期的、分散的、隐性的经验压缩成 Agent 可以直接加载执行的结构化技能。2. 核心概念知识蒸馏与技能生成的技术路线2.1 经典知识蒸馏的三个层次要理解 COLLEAGUE.SKILL 的可行性需要先分清知识蒸馏在不同层面上的含义。Logits 蒸馏输出蒸馏。这是 Hinton 等人提出的经典方式。Teacher 模型输出 soft labels软标签Student 模型学习这些软标签背后的概率分布。这个层面解决的是“模型压缩”问题。特征蒸馏中间层蒸馏。不仅学习输出结果还学习 Teacher 模型中间层的特征表示。这个层面解决的是“表征迁移”问题。行为蒸馏轨迹蒸馏。学习 Teacher 模型或专家在解决问题时的行为序列包括决策路径、调用工具的顺序、处理异常的方式。这个层面最适合用于 Agent 技能生成。COLLEAGUE.SKILL 强调的是第三种——行为蒸馏。专家在某个领域的经验往往不是一条条孤立的知识点而是一套“遇到什么问题 → 采集什么信息 → 做什么判断 → 产出什么结果”的行为模式。Agent 技能恰好也需要这种模式化表达。2.2 面向技能生成的知识蒸馏范式把行为蒸馏用于技能生成可以拆成四个环节第一环知识源定义。明确专家知识的载体。常见的有这么几类操作日志专家在业务系统中的每一步操作记录决策记录专家标注过的样本、写过的报告、审核意见交互轨迹专家与 AI 助手对话、纠错、修正的过程文档沉淀SOP、手册、FAQ 等显性材料。第二环蒸馏任务设计。明确蒸馏的目标形态也就是我们想让技能长成什么样。一般会同时做两个方向的抽取纵向抽取技能步骤横向抽取技能边界适用范围、不适用的场景、风险点。第三环提示词蒸馏。使用大模型作为“蒸馏器”把清洗后的专家知识源输入给大模型让大模型按预设模板输出结构化技能定义。这个过程本质上是把非结构化的专家知识翻译成结构化的技能 Schema。第四环技能验证回归。生成技能后不能直接上线需要拿历史案例做回归验证对比“专家原判断”和“技能执行结果”的差异再根据差异进行迭代。2.3 与模型微调的区别这里要特别区分一下知识蒸馏技能生成和模型微调Fine-tuning两者经常被混淆。维度模型微调技能蒸馏改变对象模型权重Agent 技能定义/提示词包成本高需要 GPU 训练低需要 LLM 调用迭代速度小时级/天级分钟级可解释性低黑盒高技能文件可审查适用场景底层能力升级上层行为定义两者并不是互斥关系。微调解决的是模型“懂不懂”的问题技能蒸馏解决的是 Agent“会不会按流程做事”的问题。在工程实践中通常先用技能蒸馏快速落地再根据效果决定是否有必要做针对性微调。3. COLLEAGUE.SKILL 的技术原理拆解3.1 整体架构COLLEAGUE.SKILL 的核心流程可以概括为一条流水线专家知识源日志/文档/轨迹 ↓ [1] 知识清洗与结构化 ↓ [2] 分段与场景聚类 ↓ [3] LLM 蒸馏器按 Skill Schema 抽取 ↓ [4] 技能定义文件生成 ↓ [5] 验证回归 → 专家确认 → 发布每个环节都有对应的输入和输出。下面拆分关键环节的技术要点。3.2 知识清洗与结构化专家知识源通常是脏数据。操作日志里可能包含噪声点击、重复操作、未完成的动作文档里可能有大量冗余表达。直接输入给大模型会导致蒸馏出的技能质量不可控。清洗阶段要做三件事去掉噪声动作比如日志中停留时间过短、无后续操作的孤立点击合并同类动作把同一分钟内连续发生的、面向同一对象的操作合并成一个步骤标注关键节点识别出“决策点”“异常分支”“终止条件”等结构化要素。清洗后的数据应该是一个个具有明确语义的“专家行为事件”而不是原始流水日志。3.3 蒸馏提示词设计蒸馏器本身不是特殊模型而是基于大模型 精心设计的提示词模板。这个模板是 COLLEAGUE.SKILL 方案中最核心的资产。蒸馏提示词需要包含以下要素角色约束说明大模型扮演“技能工程师”输入说明说明输入的是专家知识片段输出 Schema明确技能定义的字段结构抽取要求要求区分显性步骤和隐性判断依据边界约束要求输出“不适用的场景”和“已知限制”。关键技巧是不要只让大模型“总结知识”而要让它“重建决策路径”。这两者差别很大。总结知识得到的是信息清单重建决策路径得到的是可执行的技能流程。3.4 技能 Schema 设计技能定义文件是蒸馏的最终产物。一个合理的 Schema 至少包含这些字段# 技能定义文件示例结构 skill_name: 客户投诉分级处理 version: 1.0.0 description: 面向客服场景的投诉分级与升级策略 trigger: - 用户明确表达不满 - 对话中出现负面情绪词 input: - 会话记录 - 用户历史订单信息 steps: - step: 1 action: 判断投诉类型 rules: - 涉及资金安全则直接升级 - 重复投诉超过3次则升级 - step: 2 action: 分配处理优先级 rules: - 高优: 资金安全/人身安全 - 中优: 体验类问题 exceptions: - 若用户要求立即人工介入跳过分级直接转接 output: - 投诉等级 - 处理建议 - 是否触发升级 examples: - input: 你们平台乱扣钱 output: 等级: 高优; 建议: 优先核查支付记录并升级至专人处理这个 Schema 的好处是触发条件、执行步骤、规则、异常分支彼此分离既方便人审查也方便 Agent 在执行时按逻辑取用。4. 环境准备与工具链在实际落地 COLLEAGUE.SKILL 之前需要准备一套可运行的工具链。下面的版本以 2024-2025 年常见环境为例具体版本请根据你的项目实际情况调整。4.1 运行环境操作系统Windows 10/11、macOS 或 Linux 均可Python3.10 及以上版本大模型 API支持函数调用/结构化输出的 LLM 服务OpenAI 兼容接口即可向量库可选用于知识检索召回比如 Chroma 或 Milvus。4.2 项目结构建议按以下结构组织代码colleague_skill/ ├── data/ │ ├── raw/ # 原始专家知识源 │ └── cleaned/ # 清洗后的中间数据 ├── src/ │ ├── cleaner.py # 知识清洗 │ ├── distiller.py # 蒸馏器 │ ├── schema.py # 技能Schema定义 │ └── validator.py # 验证脚本 ├── skills/ # 生成的技能定义文件 └── config.yaml # 全局配置4.3 安装依赖核心依赖只需要三个openai或兼容SDK、pyyaml、pandas。pip install openai pyyaml pandas如果你的项目里用的是国产模型或自建网关只要它提供 OpenAI 兼容的/v1/chat/completions接口openai SDK 同样可以直接对接只需要修改base_url即可。5. 完整实战从专家操作记录蒸馏一个 AI 技能下面用一个具体案例来演示完整流程。场景是从一个客服专家的历史工单处理记录中蒸馏出一个“客户投诉分级处理”技能。5.1 准备原始数据先准备一份简化的专家操作记录。实际项目中这类数据通常来自 CRM 或工单系统这里用 CSV 模拟。ticket_id,time,operator,action,note T1001,09:01:02,zhang,查看用户订单,用户投诉扣款异常 T1001,09:01:15,zhang,核查支付记录,发现重复扣款 T1001,09:01:30,zhang,标记高优,涉及资金安全 T1001,09:01:40,zhang,升级转派,转给资金安全组 T1002,09:15:20,zhang,查看会话记录,用户吐槽加载慢 T1002,09:15:33,zhang,检查服务器状态,确认无异常 T1002,09:15:50,zhang,标记中优,体验类问题 T1002,09:16:05,zhang,回复用户,提供优化建议注意这份数据只是演示用。真实场景中表格字段要多得多通常还包括操作耗时、页面路径、输入参数等但核心字段类似。5.2 编写知识清洗脚本清洗脚本做的事情是把 CSV 格式的原始操作记录按照工单分组去掉无意义动作生成结构化行为序列。 文件路径: src/cleaner.py 功能: 将原始操作记录清洗为行为序列 import pandas as pd from typing import List, Dict def load_raw_data(file_path: str) - pd.DataFrame: 读取原始CSV数据 df pd.read_csv(file_path) # 按工单排序保证动作顺序正确 df df.sort_values([ticket_id, time]) return df def clean_actions(df: pd.DataFrame) - List[Dict]: 清洗逻辑: 1. 按工单ID分组 2. 过滤掉note为空且action为查看类的动作视为无效浏览 3. 将同一工单的行为序列汇总 cleaned_tickets [] for ticket_id, group in df.groupby(ticket_id): actions [] for _, row in group.iterrows(): action row[action] note row[note] # 简单规则: 只有查看动作且没有备注时跳过 if action.startswith(查看) and pd.isna(note): continue actions.append({ action: action, note: note if not pd.isna(note) else }) cleaned_tickets.append({ ticket_id: ticket_id, actions: actions }) return cleaned_tickets if __name__ __main__: df load_raw_data(data/raw/operator_logs.csv) result clean_actions(df) # 输出清洗结果预览 for ticket in result[:2]: print(f工单 {ticket[ticket_id]}:) for act in ticket[actions]: print(f - {act[action]}: {act[note]})运行后预期输出工单 T1001: - 查看用户订单: 用户投诉扣款异常 - 核查支付记录: 发现重复扣款 - 标记高优: 涉及资金安全 - 升级转派: 转给资金安全组 工单 T1002: - 查看会话记录: 用户吐槽加载慢 - 检查服务器状态: 确认无异常 - 标记中优: 体验类问题 - 回复用户: 提供优化建议5.3 编写蒸馏器脚本清洗完成后把行为序列交给大模型让它按照技能 Schema 输出结构化的技能定义。核心思路是把多组专家行为序列拼接成上下文用提示词约束大模型输出并将结果解析为 YAML。 文件路径: src/distiller.py 功能: 调用大模型将专家行为序列蒸馏为技能定义 注意: 这是一个思路示例接口参数需根据你使用的模型版本调整 import os import yaml from openai import OpenAI # 初始化客户端兼容 OpenAI 协议的服务均可 client OpenAI( api_keyos.environ.get(LLM_API_KEY, your-api-key), base_urlos.environ.get(LLM_BASE_URL, https://api.openai.com/v1), ) DISTILL_PROMPT 你是一名资深技能工程师。你的任务是从专家处理记录中蒸馏出一个结构化的 AI 技能。 输入是若干工单的专家操作序列 {tickets} 要求 1. 分析这些操作序列中的共性步骤提取出稳定的技能流程。 2. 区分显性操作和隐性判断依据。 3. 找出专家在什么条件下会走异常分支或升级路径。 4. 严格按照下面的 YAML Schema 输出不要输出额外字段。 Schema: skill_name: 技能名称 version: 版本号 description: 技能描述 trigger: - 触发条件 input: - 输入字段 steps: - step: 序号 action: 操作名称 rules: - 判断规则 exceptions: - 异常分支 output: - 输出字段 examples: - input: 示例输入 output: 示例输出 def build_tickets_text(tickets): 将行为序列拼接成文本 parts [] for ticket in tickets: parts.append(f工单 {ticket[ticket_id]}:) for act in ticket[actions]: parts.append(f - {act[action]}: {act[note]}) return \n.join(parts) def distill_skill(tickets) - dict: 调用大模型蒸馏技能 tickets_text build_tickets_text(tickets) prompt DISTILL_PROMPT.format(ticketstickets_text) response client.chat.completions.create( modelos.environ.get(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: 你只输出合法的 YAML 内容不要输出解释。}, {role: user, content: prompt}, ], temperature0.2, # 低温保证输出稳定 ) content response.choices[0].message.content # 部分模型输出可能包含markdown代码块标记需要清洗 content content.strip() if content.startswith(yaml): content content.replace(yaml, ).replace(, ).strip() return yaml.safe_load(content) if __name__ __main__: from cleaner import load_raw_data, clean_actions df load_raw_data(data/raw/operator_logs.csv) tickets clean_actions(df) skill distill_skill(tickets) # 保存技能定义 with open(skills/complaint_triage.yaml, w, encodingutf-8) as f: yaml.dump(skill, f, allow_unicodeTrue, sort_keysFalse) print(技能生成完成 - skills/complaint_triage.yaml)这里有两个细节要注意temperature设置为 0.2 而不是 0是为了在稳定输出的同时保留一点点多样性避免模型在极端情况下重复同一个结构YAML 解析前要做代码块标记清洗因为不少模型的输出会自带 yaml 围栏。5.4 生成的技能定义文件运行蒸馏脚本后生成的complaint_triage.yaml大致是这样的skill_name: 客户投诉分级处理 version: 1.0.0 description: 面向客服场景的投诉分级与升级策略适用于处理客户投诉工单 trigger: - 用户明确表达不满或投诉 - 检测到负面情绪关键词 input: - 会话记录 - 用户订单信息 - 支付记录 steps: - step: 1 action: 核查用户诉求 rules: - 优先查看用户最近订单与支付状态 - 若涉及扣款异常核查支付记录 - step: 2 action: 判断投诉类型 rules: - 资金安全类: 优先处理 - 体验类问题: 常规处理 - step: 3 action: 分配处理优先级 rules: - 高优先级: 涉及资金安全、人身安全 - 中优先级: 功能体验问题、一般咨询 exceptions: - 用户要求立即人工介入时跳过分级直接转接 - 投诉内容涉及法律风险时升级至合规部门 output: - 投诉等级 - 处理建议 - 是否触发升级 examples: - input: 用户投诉重复扣款情绪激动 output: 等级: 高优; 建议: 核查支付记录并升级至资金安全组 - input: 用户反馈页面加载缓慢 output: 等级: 中优; 建议: 检查服务状态并提供优化方案与清洗脚本输出对比可以看到大模型不仅仅复述了专家操作还补充了触发条件、异常分支和示例这些就是蒸馏出来的隐性经验。5.5 技能验证与回归技能定义生成后最重要的一步是验证。验证不能只看格式要看实际执行效果。写一个简单验证脚本用历史工单作为输入模拟技能执行结果并与专家实际处理结果对比。 文件路径: src/validator.py 功能: 用历史工单验证技能定义效果 import yaml def load_skill(path: str) - dict: with open(path, encodingutf-8) as f: return yaml.safe_load(f) def simulate_skill(skill: dict, case: dict) - str: 模拟技能执行返回处理等级 content case.get(content, ).lower() # 简易规则引擎真实项目可以用LLM 工具调用 if 扣款 in content or 资金 in content or 安全 in content: return 高优先 if 慢 in content or 卡 in content or 体验 in content: return 中优先 return 低优先 if __name__ __main__: skill load_skill(skills/complaint_triage.yaml) test_cases [ {content: 你们平台乱扣钱, expected: 高优先}, {content: 页面加载太慢了, expected: 中优先}, {content: 退款一直没到账, expected: 高优先}, ] correct 0 for case in test_cases: result simulate_skill(skill, case) is_ok result case[expected] correct int(is_ok) print(f输入: {case[content]} - 预测: {result}, 期望: {case[expected]}, {✓ if is_ok else ✗}) print(f准确率: {correct}/{len(test_cases)})验证结果说明如果准确率不达标需要通过补充专家样本、调整蒸馏提示词中的 Schema 要求、或者在技能定义中增加更细的规则来迭代。6. 常见问题与排查思路在实际使用这套流程时我整理了几个出现频率最高的问题。问题现象常见原因解决思路生成的技能步骤太笼统缺少关键判断输入样本数量不足或样本之间差异过大增加专家样本数量按场景分组建模后再蒸馏技能定义出现幻觉补充了专家并没有做过的步骤蒸馏提示词中缺少“只能基于给定输入”的约束在提示词中显式追加“禁止推断未出现的信息”同一批数据多次蒸馏结果不一致temperature 设置过高将 temperature 降到 0.2 以下并固定随机种子YAML 解析报错模型输出包含 markdown 代码块标记使用正则或字符串清洗去掉围栏后再解析技能验证准确率低清洗规则把关键动作误删了检查清洗规则中的过滤条件对“查看”类动作要区分有效查看和无效浏览API 调用超时输入的专家行为序列过长按工单批次切分蒸馏蒸馏完成后在技能层合并另外有一个容易被忽视的问题蒸馏提示词中如果包含了过多业务背景大模型反而容易“自由发挥”。真正有效的做法是让大模型在给定 Schema 的约束下“翻译”专家行为而不是“创作”专家流程。在提示词里把 Schema 字段的定义写得越清晰输出就越稳定。7. 最佳实践与工程建议7.1 知识源侧的建议专家知识源的质量直接决定技能质量这比模型选择更重要。建议在采集阶段就做好几个约束采集前先定义好技能边界这个技能解决什么问题、不解决什么问题避免把无关的专家行为混入样本样本覆盖要全面至少要覆盖正常流程、边界场景、异常分支、升级路径四类情况保留原始上下文清洗时可以过滤噪声但不要把原始数据删掉后续重新蒸馏时可能还需要。7.2 蒸馏配置侧的建议把蒸馏提示词模板独立成文件管理不要硬编码在代码里。提示词模板就是技能的“编译器”要支持版本管理Schema 中的枚举值尽量收敛比如优先级只允许“高/中/低”而不是让模型自由填空每次蒸馏都记录输入数据的指纹Hash值方便定位“哪批数据导致技能变更”批量蒸馏时建议分批进行避免上下文过长后续再通过合并策略整合技能。7.3 验证与发布侧的建议技能上线前必须经过验证建议至少做三关检查格式检查Schema 合法性、字段完整性历史回归用专家的历史处理记录做回放对比专家确认将生成技能的关键判断规则单独列出给领域专家做最终确认。发布时还要注意给技能加版本号并保存对应的蒸馏输入数据版本。一旦线上效果下降可以快速回滚到上一个版本定位是哪一批样本导致的问题。7.4 安全与合规边界如果专家知识源包含客户数据、个人信息或敏感业务数据整个蒸馏流程必须遵循最小权限原则。建议知识源采集前进行脱敏处理删除可识别个人身份的信息蒸馏过程使用独立的 API 账号和隔离环境不在本地留存原始数据副本技能定义文件在发布前做一次敏感信息扫描防止技能示例中泄露隐私涉及自动化决策比如自动给客户打标签、自动升级投诉的应用场景务必确保有明确合规授权并且技能执行链路要保留可审计日志。8. 总结与进阶学习方向这篇文章围绕 COLLEAGUE.SKILL 的核心思路完整梳理了通过专家知识蒸馏自动生成 AI 技能的流程背景痛点、知识蒸馏原理、Schema 设计、清洗脚本、蒸馏提示词、技能定义生成、验证回归以及常见坑点。整套流程的核心价值在于把原本依赖个人经验的专家能力转化为团队可复用、可审查、可迭代的 AI 技能资产。如果继续深入下面几个方向值得优先关注多技能编排当技能数量超过 50 个后如何让 Agent 在多个技能之间做选择、组合和交接技能效果自动化评估引入评估集Eval Set在每次技能迭代后自动跑分避免人工回归的低效增量蒸馏不重新蒸馏全部样本而是用新增的专家数据对已有技能做增量更新技能与微调的协同将高频技能蒸馏成专用小模型兼顾效果与推理成本。最后给一个最实际的建议不要一开始就追求“全自动蒸馏流水线”先用 20 到 50 条专家样本手工走通整套流程确认技能 Schema 合理、输出质量稳定后再逐步把采集、清洗、蒸馏、验证的步骤自动化。先把路径跑通再谈架构升级。