你有没有数过自己Agent里的技能库是什么时候开始失控的我做过一个客服场景的Agent项目上线三个月技能库从最初的两百多条一路涨到两千多条每条都是真金白银的调用记录和线上反馈堆出来的谁也不敢删。后来更离谱的是同样是“改收货地址”这件事库里躺着五条说法各异的技能一条写在刚上线那周一条写在遭遇大促时一条写在某个用户反复投诉之后。Agent检索的时候倒也能把这五条都捞出来问题是上下文预算就那么长五条就占掉一半真正关键的信息反而被挤出去了。所以当我看到“EMNLP 2026 | SkillBrew多目标精炼”这个标题时第一反应是终于有人把“技能库只增不减”这件事当成正经研究课题了。SkillBrew这个名字起得很妙核心主张就是标题里那七个字让经验做减法。它面向的是所有靠LLM收集、沉淀、复用技能的Agent系统适合正在做大模型Agent、RAG记忆系统或者自动化工作流的人参考。不管你是研究NLP的还是在做工程落地的这篇内容都能提供一套把“技能库越堆越乱”变成“技能库越用越精”的完整思路而且比你自己拍脑袋写清理脚本要系统得多。1. 技能库“只增不减”Agent落地里最隐蔽的慢性病1.1 技能库为什么会不受控制地膨胀很多人会把技能库理解成一个“知识抽屉”用的时候往里放需要的时候往外取天然默认它应该越来越大。但真实情况恰恰相反在LLM Agent场景里技能库一旦只增不减系统性能不是变好而是以一种很难察觉的方式慢慢变差。为什么一定会膨胀因为技能的来源太多了。一个Agent在跑线上任务时每解决一个用户问题就可能沉淀出一条“经验”每处理一次异常分支就可能录一条“应急预案”开发人员每修一个Bug也会习惯性往库里塞一条新的技能。这些技能本身没有统一的产生标准只要触发条件有一点不同或者当时记录的措辞不一样就会变成完全独立的条目。我见过最典型的例子是同一个意图下因为用户表达方式不同而产生了三条技能一条针对“帮我改下地址”一条针对“我收货信息填错了”一条针对“快递要送到新公司”。对模型来说这三条语义几乎等价但技能库不会自动把它们合起来于是越积越多。这就是“只增不减”的第一层原因没有天然的合并机制。1.2 膨胀之后到底会发生什么技能库膨胀的代价不像程序崩溃那么显眼它更像是一种“慢性消耗”体现在三个地方。第一是检索相关性被稀释。技能库从几百条涨到几千条之后召回阶段的语义检索很容易把真正的关键技能排到很后面。我遇到过一次很无语的情况同样触发“处理退款”场景技能库返回的前十条里有三条是不同时期写的重复退款流程真正补充了“部分退款需要走线下审批”这条关键信息的那条技能反而被压到了第八位。技能一多模型要花更多注意力去分辨哪条才是当前真正适用的表达能力再强的模型也会被带偏。第二是上下文和成本开销双增加。每次Agent执行任务时通常会先把检索到的若干条技能文本拼进系统提示里。技能条数越多每条技能写得越完整单次调用的Token数就越大。如果你用的是商业大模型API这是纯成本如果你用的是私有化部署的开源模型这是纯显存和响应时延的压力。技能库只看数量上涨了20%但整条链路的平均耗时可能涨了40%以上因为模型还要在大量冗余技能里做潜意识的“选边站”。第三是冲突与遗忘。这是最阴险的一点。不同时期沉淀的技能方案可能是互相矛盾的。早期的一条说“收货地址修改必须等订单发货后才能操作”大促后新增的一条说“未发货订单可以直接修改地址”。两条技能同时存在于库里Agent有时候按这条执行有时候按那条执行用户视角就是“这个客服ChatBot怎么想的完全没规律”。技能库越来越大新技能并不会自动覆盖旧技能只会给系统埋下一堆行为不一致的雷。1.3 为什么“清理”解决不了问题必须靠“精炼”既然膨胀有害那直接定期清理不就行了吗我一开始也是这么想的设计过一个很朴素的清理机制按使用次数排序把半年没调用过的技能标记为“可删除”。结果上线第一天就出问题——低频技能里有好几条是专门处理极端情况的比如“话费充值后未到账且超过72小时的升级处理流程”这种技能一年触发不了几次但一旦触发就是高危场景。按使用次数一刀切等于把保命技能给删了。清理的真正难点在于它默认技能之间是彼此独立的删了A不影响B。但实际技能库里大量技能是相关的可能是同一意图的不同写法可能是一条完整流程被拆成了好几段也可能存在相互补充的陷阱和例外。这种情况下靠“保留高频、删除低频”的粗策略根本没用需要的是把一批相关技能拿在一起分析、合并、重写在保留覆盖范围的同时减少条目数量。这就是精炼和清理的本质区别清理是做减法精炼是在做减法的同时做重构。SkillBrew的多目标精炼本质上就是把“怎么减得聪明”这件事工程化和学术化。2. SkillBrew的核心思路把“多目标精炼”当成一次技能蒸馏2.1 从名字说起Brew是“煮”不是“堆”SkillBrew这个名字值得细品。Brew的原意是酿造、冲泡是把多种原料放在一起通过时间的沉淀和火候的控制最终得到一杯比原料本身更协调的成品。这和技能库的维护逻辑非常贴合堆技能是把所有经验都原封不动地放进去而精炼则是把同类的经验放在一口锅里去掉浮沫、滤掉残渣、浓缩精华最后得到的东西量更少但浓度更高。这正好对应到方法的设计哲学上从标题里的“多目标精炼”来看SkillBrew的目标函数里应该不会只有“技能数量变少”这一个指标。如果只追求数量少那把所有技能合并成一条“根据情况处理所有问题”就完事了但这种合并等于把信息量直接清零毫无价值。所以精炼动作本身必须同时满足多个目标比如保留技能的有效性、覆盖尽量多的任务场景、消除互相矛盾的表述、控制单条技能的可读性和执行效率。这些目标既有互相促进的一面也有此消彼长的关系多目标的意思就是要在这些维度之间找到一个最优平衡点。2.2 多目标精炼到底在同时优化哪几件事虽然EMNLP论文的细节要等完整版本出来才能看到但按这一类方法的基本范式SkillBrew的多目标设计大概率会落在以下几个维度上这也正是我们在工程实践中真切需要的东西。第一个目标是“保留有效性”。精炼不是把技能库变成大纲列表而是保留下那些真正能在执行阶段指导模型完成任务的细节。比如合并“修改地址”相关的多条技能时可以删掉重复的“登录-定位-修改-确认”大步骤但“备注新地址需要与收货人手机号匹配”这种触发条件和特殊校验绝不能丢。第二个目标是“维持覆盖率”。技能库里的经验覆盖了用户可能遇到的各种场景合并过程中不能把某种少数情况给合并丢了。这一点做起来比听起来难因为很多低频场景和主场景表面看起来高度相似但实际上有不同的前置条件。多目标优化在这里起作用的方式是保证输出的新技能集合仍然能覆盖原有任务集合。第三个目标是“消除冲突”。前面提到过新旧技能之间可能互相矛盾或者同一个步骤在不同的技能里给出了不同约束。精炼这个动作天然适合做一致性校对把相关技能抽样到一起逐条对比差异找出那些“同一场景、不同结论”的冲突点然后用逻辑判断或者依靠线上效果数据确定哪个才是当前应该保留的标准答案。第四个目标是“控制成本”。技能条数少了检索时被判定的候选集小了拼进上下文的Token少了对应延迟和成本都会跟着下降。这个目标往往是最容易量化的也是项目汇报时最好看的数字但千万不能把它当成唯一指标否则就会走向过度合并。2.3 与“简单删删减减”的本质差别SkillBrew这类多目标精炼和直觉层面上的“删技能”有一个非常大的差别它不是直接在原始技能文本上做减法而是先构建一个新的技能表达再用这个新表达替代原始的一批技能。可以把它理解成代码重构里的“提取公共函数”——你并没有把某段逻辑删除而是把重复实现合并成一个函数同时调整所有调用点。技能库的精炼同理它把多条相似技能的内容重新组织成一条更精炼的技能然后再让Agent的整体检索路径指向这条新技能。从实现层面看这就意味着SkillBrew要处理几个前置问题如何判断两条技能是否属于同一“意图簇”合并后保留哪些信息、舍弃哪些信息合并后的技能如何验证它确实不逊于原始版本这些问题的解法构成了方法的核心模块。后面我会拆一套可复现的参考流程即使不看论文也能照着在自己的Agent系统里做一版。3. 多目标精炼的五个实操环节一套可复现的参考流程3.1 第一步把技能统一成可比较的结构精炼的前提是技能之间能比较而大多数团队的技能库根本没法比较因为每条技能的自由度太大了。有的技能就是一句话“用户要改地址就让用户去APP操作”有的技能是一段五百字的完整对话流程有的技能里还揉进了当时的会话截图备注。这种情况下你没法做聚类也没法做合并。所以第一步要做的是给每一条技能定义一个统一的结构。我常用的结构包含四个字段触发条件、适用范围、执行步骤、例外情况。触发条件描述什么情况下应该唤起这条技能适用范围描述这条技能适用于哪些场景、哪些用户执行步骤是核心的操作流程例外情况单独列出来避免和主流程混在一起。字段不是越多越好四个已经足够覆盖大多数场景太多反而会让精炼时的LLM抓不住重点。做完结构化之后每条技能看起来就像一个小型函数有入口参数、有逻辑体、有边界条件。到这里才算有了做后续聚类和合并的基础。3.2 第二步用语义聚类找到“说同一件事”的技能簇技能结构统一之后下一步是找出那些“表面不同、实际在说同一件事”的技能把它们归到一个簇里。这一步在大多数实现里会用到Embedding加聚类算法具体做法不复杂先把每条技能的各字段拼成一段文本用Embedding模型转成向量然后计算两两之间的语义相似度最后按相似度阈值把技能分簇。分簇的阈值选择是个经验活我自己的经验是宁可让簇稍微大一点也不要让簇太碎。簇太碎的话后面合并出来的技能仍然会有很多重复簇太大则会把真正不同的场景强行捏在一起。判断两个技能是否该归为一簇有一个很实用的标准如果一名资深同事能在不看其他信息的情况下用同一套流程解决这两个技能描述的问题它们就该合并。一个容易踩的坑是直接用文本嵌入算相似度的时候执行步骤里哪怕只差一个关键步骤相似度分数也可能很高因为公共的框架性句子太多。我的做法是在算相似度时对字段加权例如“触发条件”的权重占高一些“执行步骤”的次之“例外情况”参与比较但不作为主要依据。这样能避免把两条执行路径完全不同、只是触发场景相似的技能错误合到一起。3.3 第三步簇内合并与跨簇冲突消解分好簇之后就到了整个流程的核心环节把簇内多条技能合并成一条或者少数几条。这一步可以直接交给LLM完成但提示词的设计非常关键我踩过的坑是只告诉模型“把相似的技能合并成一个”它往往会输出一个“四不像”——每条原始技能的细节都保留了30%看似全面实际上模型自己都不知道该怎么执行。一个更可靠的提示策略是给LLM一个“合并模板”要求它按固定的组织方式来生成结果。我实践下来比较好用的模板是你是一个技能库精炼引擎。下面给你一组描述同一场景的技能。请分析这些技能的异同合并成一条新的技能。要求执行步骤按动作顺序编号所有原始技能中出现的特殊前置条件和例外情况如果在新技能里没有对应覆盖必须保留相同步骤只保留最完整、最清晰的一个版本合并后总长度不能超过原始技能中长度最短的那条的一点五倍。这个“长度上限”的约束很重要它能防止模型把合并当成拼接。同时它还隐含了一层目标合并是一个求最大公约数和最小公倍数的过程只保留下真正必要的内容。跨簇冲突消解则是处理两个不同簇之间出现矛盾的情况。实践中可以先做一个全库两两扫描把“触发条件高度相似但操作步骤不一致”的技能对找出来再交给人工或者LLM判断谁更合理、要不要互相关联。这一步不能省因为冲突不清除的话合并做得再好Agent仍然会行为不一致。3.4 第四步用真实任务做验证而不是只看文本相似度很多人做完合并就觉得完事了这是最大的错误。合并出来的一条技能读起来通顺、长度也短并不代表它能在真实执行中替代原来那几条。检验精炼效果的唯一标准是拿真实任务去跑。我通常的做法是保留一份精炼前的技能库快照然后准备一个覆盖各场景的评测任务集里面混合高频场景、低频场景和有冲突的边界场景。同一个评测集分别跑旧技能库和新技能库对比任务成功率、关键动作是否缺失、Token平均消耗量这三个指标。如果新技能库在成功率上低于旧库超过两个百分点说明合并过程中丢失了关键信息需要回溯是哪一步的问题如果成功率持平甚至更高同时Token量明显下降那这次精炼就是合格的。这一步说到容易做到难因为没有团队会平白无故维护评测集。但如果你想认真推进技能库管理评测集不是可选项而是必选项。哪怕一开始只有五十条模拟任务也比完全依赖目测强一百倍。3.5 第五步版本化与灰度上线精炼会造成Agent行为的变化这种变化不一定是立刻暴露的可能是在某个低频场景里悄悄变差。所以精炼结果上线之前必须做版本化管理和灰度验证。具体做法是精炼后的技能库标记为一个新版本不直接全量替换而是先让它在小流量或者仿真环境中运行两到三天。我在项目里习惯给每个技能库版本加一个“变更说明”记录这次精炼合并了哪些技能、删除了哪些信息、解决了哪些冲突。这个变更说明对溯源非常关键。因为当Agent跑出一次异常行为时你需要在版本记录里快速定位是哪个技能被改动过。如果你的技能库没有版本概念出了问题就只能靠猜那可比不精炼还糟糕。4. 把精炼流程接进你的Agent落地层面的操作细节4.1 技能写入时就规划好“可被精简”的元数据精炼做得顺不顺利早期埋的伏笔占一半。很多团队是技能库里已经堆了几千条乱七八糟的技能之后才开始考虑精炼这时候成本已经很高了。如果你是从零搭建技能库或者还有机会调整写入流程一定要在每条技能写入时就加上元数据。元数据里最重要的两个字段是“所属意图ID”和“最近验证时间”。意图ID用来标记这条技能属于哪一类任务场景后面做聚类时可以直接用意图ID做预分组减少语义聚类的计算量最近验证时间用来判断这条技能是否已经过时给冲突消解提供时间维度上的参考。除此之外如果技能是经过真实用户问题触发生成的建议把触发次数和最后结果也记上哪怕只是草草地记一个“成功/失败”也比没有强。这些元数据不会直接提升单次任务的效果但它是整个技能生命周期管理的地基。没有元数据的技能库精炼等于盲人摸象有了元数据精炼过程才有据可依。4.2 设计精炼触发策略什么时候做多久做一次技能精炼不能太频繁也不能完全不触发。太频繁会导致Agent行为一直处于波动状态用户感知到的是“这个机器人怎么隔几天就变一个性格”完全不触发则会退回到只增不减的老路。触发策略我认为要从两个维度设计按规模触发和按质量触发。按规模触发最简单给技能库设定一个上限阈值比如五百条。每当技能条数超过阈值就自动触发一轮精炼流程。这个策略的好处是执行时机明确团队好对齐预期。按质量触发则更智能一些监控线上任务的成功率指标如果发现某个意图域成功率明显下滑并且检索日志里频繁出现高相似度技能互相抢占的情况就针对这个意图域做局部精炼。实操上我会把两种策略混合全库规模的定时精炼每两周一次局部意图域的触发式精炼随时可以进行。这样既有全局稳定节奏又能应对局部突发恶化。精炼流程本身是批量异步的不需要占用在线服务的时间放在夜间调度跑即可。4.3 用LLM自动精炼时的成本与质量平衡用LLM做技能精炼本质上是拿算力换维护人力。但如果完全不看成本精炼流程本身也可能成为一笔不小的开销。我观察到的实际成本主要来自两个环节第一步的技能向量化聚类这一环相对便宜Embedding模型批量调用即可真正贵的是第三步的合并生成因为需要给LLM输入一整簇技能还要输出一条高质量的新技能。控制成本的思路有三个。第一是尽量做局部精炼而不是全库精炼按意图ID分组处理每组技能数量有限输入输出都短Token成本很低。第二是选择合适的合并模型不需要和线上Agent用同一个级别的模型精炼任务对逻辑复杂度的要求通常低于直接服务用户的任务用中等规模的模型就够了。第三是复用精炼结果合并后的技能经过验证没有问题后可以直接缓存不需要每次精炼都把历史技能重新跑一遍。这里要顺带提醒一句如果LLM精炼输出的技能质量不稳定不要盲目换更大的模型先检查提示词里的约束条件有没有写清楚。我见过太多人把“合并技能”这件事做得像开放式写作模型当然会放飞自我。给它固定的输出结构和长度上限质量立刻就会稳下来。4.4 一个最小可落地的执行流程示例把所有环节串起来一个最小可落地的精炼任务可以这样定义输入是一个意图ID下的所有技能输出是这个意图ID下的精炼后技能集合。伪代码层面的执行流程大致如下读取该意图ID下所有技能解析为统一结构过滤掉状态为“废弃”的技能。将技能文本转为向量做簇内相似度计算按阈值把技能分成若干小组。对每个小组调用LLM按指定模板生成合并后的新技能保留例外情况。对所有新技能做冲突检测找出触发条件相似但步骤不一致的组合标记为待确认。将合并结果放到评测任务集里运行对比旧库效果记录成功率与Token消耗。如果评测通过生成新版技能库进入灰度验证如果失败回滚版本并保留失败日志。整个过程可以写成一套独立的定时任务脚本和线上服务解耦。灰度验证通过后再把新技能库发布到线上。这套流程一旦跑顺技能库的精炼就不再是一个拍脑袋的动作而是一个可以每周自动完成、结果可控的标准环节。5. 这些坑我基本都踩过常见问题与排查要点5.1 误删关键技能导致成功率暴跌我经历过的最典型事故是精炼后的技能库在一个“企业发票变更”场景上的成功率从85%掉到41%。回溯原因后发现精炼时把一条技能里的“必须上传营业执照原件照片而非复印件”这个特殊校验给删掉了因为它和主流程里的“上传相关证件”重复。但从用户的真实视角来看“相关证件”这个说法太模糊模型很容易默认复印件也行最后导致大量请求被驳回。这个坑的排查思路是精炼后如果发现某个场景的成功率明显下降不要先怀疑模型而是先对比旧版技能和新版技能在“例外情况”字段上的差异大概率是例外信息被精简了。教训是例外情况字段在精炼时必须享有最高保留优先级宁可让主流程文字更紧凑也不能牺牲例外情况。5.2 合并出来的技能“什么都讲了等于什么都没讲”这大概是使用LLM做技能合并时最常见的问题。模型把簇内的每一条技能都压缩后塞进了新技能里表面看一条技能涵盖了所有情况实际上里面充满了“如果”“或者”“同时”这类条件词模型执行的时候每条路径都不完整。后来我给提示词加了一个硬约束“合并后的技能必须能被一个没有看过原材料的新手按照步骤一步步操作完成步骤之间不得出现二选一式的分叉如果原始技能存在真正互斥的场景分支则拆成多条技能不要塞进同一段流程”。这个约束很管用因为它倒逼LLM在“保留所有信息”和“保持可执行性”之间做取舍而不会偷懒地做信息拼接。5.3 精炼频率过高Agent行为飘忽不定有一段时间我们每周都做全库精炼结果连续三周模型在线上的行为都在变客服主管反馈“用户说你们的产品换人了”。问题的根源不在精炼本身而在于精炼触发的节奏太随性每次都有新版本的技能库发布线上行为自然跟着漂移。我的调整方案是把全库精炼的周期固定为两周一版非紧急情况下不插队每个意图域的精炼节奏跟随该域的效果指标只有指标下滑时才触发并把“上一版技能库效果更好”作为触发回滚的第一优先级判断条件。稳定比永远最优更重要这是技能库管理里比算法更需要注意的地方。5.4 评价指标只盯着“库小了”却忘了任务是变好还是变坏做这类项目很容易陷入一个误区精炼之后技能数量砍半PPT画出来很好看但到底Agent有没有变好用没有人去量化。我之前犯过同样的错误在项目总结里大写特写“技能库规模减少40%”结果老板一句话问住我“那用户满意度涨了吗”后来我把精炼项目的评价指标固定为“一组三看”一看任务成功率涨跌二看单次任务平均Token消耗降幅三看用户侧可感知的异常率变化。技能库缩了多少只作为过程指标进行展示不当作项目的核心结论。做技术可以浪漫做结果必须清醒。5.5 一些可以少走弯路的个人体会在做技能库管理这件事上我越来越认同一个观点技能不是越多越好关键是每一条放进去都得清楚它“为什么存在”。SkillBrew这种多目标精炼本质上就是逼着系统去回答这个问题。哪怕你不打算完整复现论文里的算法只把“技能写入前加元数据、定期做语义聚类、合并时保护例外情况、上线前用真实任务验证”这四个习惯带到项目里效果也会远超绝大多数没有这套流程的Agent。最后分享一个小技巧精炼之后的技能库不要急着销毁旧版本。留一个“黑盒对照版”在灰度期同时保留新旧两套技能库的日志一旦新库出现异常可以立刻切回旧库然后再慢慢排查差异。这种能切回去的安全感对于推进技能库优化真的非常宝贵。结合SkillBrew的方向来看后续这个思路还能往两个地方延伸一是把精炼的目标从“技能库条目”延伸到“Agent的记忆模块”让对话历史、工作流配置也具备自动压缩与重构的能力二是把精炼的标准从“人工设定阈值”升级为“根据线上效果自动调节让系统自己决定什么时候该合并、什么时候该停手”。我个人很期待看到这类研究继续往前推进毕竟对一个真正跑在生产环境里的Agent来说懂得给经验做减法可能比堆砌更多新技能更能决定系统的上限。 
长河君 · 2026/10/28 17:10:17 · 阅读 1.2k 技能库只增不减？SkillBrew多目标精炼给经验做减法
你有没有数过自己Agent里的技能库是什么时候开始失控的我做过一个客服场景的Agent项目上线三个月技能库从最初的两百多条一路涨到两千多条每条都是真金白银的调用记录和线上反馈堆出来的谁也不敢删。后来更离谱的是同样是“改收货地址”这件事库里躺着五条说法各异的技能一条写在刚上线那周一条写在遭遇大促时一条写在某个用户反复投诉之后。Agent检索的时候倒也能把这五条都捞出来问题是上下文预算就那么长五条就占掉一半真正关键的信息反而被挤出去了。所以当我看到“EMNLP 2026 | SkillBrew多目标精炼”这个标题时第一反应是终于有人把“技能库只增不减”这件事当成正经研究课题了。SkillBrew这个名字起得很妙核心主张就是标题里那七个字让经验做减法。它面向的是所有靠LLM收集、沉淀、复用技能的Agent系统适合正在做大模型Agent、RAG记忆系统或者自动化工作流的人参考。不管你是研究NLP的还是在做工程落地的这篇内容都能提供一套把“技能库越堆越乱”变成“技能库越用越精”的完整思路而且比你自己拍脑袋写清理脚本要系统得多。1. 技能库“只增不减”Agent落地里最隐蔽的慢性病1.1 技能库为什么会不受控制地膨胀很多人会把技能库理解成一个“知识抽屉”用的时候往里放需要的时候往外取天然默认它应该越来越大。但真实情况恰恰相反在LLM Agent场景里技能库一旦只增不减系统性能不是变好而是以一种很难察觉的方式慢慢变差。为什么一定会膨胀因为技能的来源太多了。一个Agent在跑线上任务时每解决一个用户问题就可能沉淀出一条“经验”每处理一次异常分支就可能录一条“应急预案”开发人员每修一个Bug也会习惯性往库里塞一条新的技能。这些技能本身没有统一的产生标准只要触发条件有一点不同或者当时记录的措辞不一样就会变成完全独立的条目。我见过最典型的例子是同一个意图下因为用户表达方式不同而产生了三条技能一条针对“帮我改下地址”一条针对“我收货信息填错了”一条针对“快递要送到新公司”。对模型来说这三条语义几乎等价但技能库不会自动把它们合起来于是越积越多。这就是“只增不减”的第一层原因没有天然的合并机制。1.2 膨胀之后到底会发生什么技能库膨胀的代价不像程序崩溃那么显眼它更像是一种“慢性消耗”体现在三个地方。第一是检索相关性被稀释。技能库从几百条涨到几千条之后召回阶段的语义检索很容易把真正的关键技能排到很后面。我遇到过一次很无语的情况同样触发“处理退款”场景技能库返回的前十条里有三条是不同时期写的重复退款流程真正补充了“部分退款需要走线下审批”这条关键信息的那条技能反而被压到了第八位。技能一多模型要花更多注意力去分辨哪条才是当前真正适用的表达能力再强的模型也会被带偏。第二是上下文和成本开销双增加。每次Agent执行任务时通常会先把检索到的若干条技能文本拼进系统提示里。技能条数越多每条技能写得越完整单次调用的Token数就越大。如果你用的是商业大模型API这是纯成本如果你用的是私有化部署的开源模型这是纯显存和响应时延的压力。技能库只看数量上涨了20%但整条链路的平均耗时可能涨了40%以上因为模型还要在大量冗余技能里做潜意识的“选边站”。第三是冲突与遗忘。这是最阴险的一点。不同时期沉淀的技能方案可能是互相矛盾的。早期的一条说“收货地址修改必须等订单发货后才能操作”大促后新增的一条说“未发货订单可以直接修改地址”。两条技能同时存在于库里Agent有时候按这条执行有时候按那条执行用户视角就是“这个客服ChatBot怎么想的完全没规律”。技能库越来越大新技能并不会自动覆盖旧技能只会给系统埋下一堆行为不一致的雷。1.3 为什么“清理”解决不了问题必须靠“精炼”既然膨胀有害那直接定期清理不就行了吗我一开始也是这么想的设计过一个很朴素的清理机制按使用次数排序把半年没调用过的技能标记为“可删除”。结果上线第一天就出问题——低频技能里有好几条是专门处理极端情况的比如“话费充值后未到账且超过72小时的升级处理流程”这种技能一年触发不了几次但一旦触发就是高危场景。按使用次数一刀切等于把保命技能给删了。清理的真正难点在于它默认技能之间是彼此独立的删了A不影响B。但实际技能库里大量技能是相关的可能是同一意图的不同写法可能是一条完整流程被拆成了好几段也可能存在相互补充的陷阱和例外。这种情况下靠“保留高频、删除低频”的粗策略根本没用需要的是把一批相关技能拿在一起分析、合并、重写在保留覆盖范围的同时减少条目数量。这就是精炼和清理的本质区别清理是做减法精炼是在做减法的同时做重构。SkillBrew的多目标精炼本质上就是把“怎么减得聪明”这件事工程化和学术化。2. SkillBrew的核心思路把“多目标精炼”当成一次技能蒸馏2.1 从名字说起Brew是“煮”不是“堆”SkillBrew这个名字值得细品。Brew的原意是酿造、冲泡是把多种原料放在一起通过时间的沉淀和火候的控制最终得到一杯比原料本身更协调的成品。这和技能库的维护逻辑非常贴合堆技能是把所有经验都原封不动地放进去而精炼则是把同类的经验放在一口锅里去掉浮沫、滤掉残渣、浓缩精华最后得到的东西量更少但浓度更高。这正好对应到方法的设计哲学上从标题里的“多目标精炼”来看SkillBrew的目标函数里应该不会只有“技能数量变少”这一个指标。如果只追求数量少那把所有技能合并成一条“根据情况处理所有问题”就完事了但这种合并等于把信息量直接清零毫无价值。所以精炼动作本身必须同时满足多个目标比如保留技能的有效性、覆盖尽量多的任务场景、消除互相矛盾的表述、控制单条技能的可读性和执行效率。这些目标既有互相促进的一面也有此消彼长的关系多目标的意思就是要在这些维度之间找到一个最优平衡点。2.2 多目标精炼到底在同时优化哪几件事虽然EMNLP论文的细节要等完整版本出来才能看到但按这一类方法的基本范式SkillBrew的多目标设计大概率会落在以下几个维度上这也正是我们在工程实践中真切需要的东西。第一个目标是“保留有效性”。精炼不是把技能库变成大纲列表而是保留下那些真正能在执行阶段指导模型完成任务的细节。比如合并“修改地址”相关的多条技能时可以删掉重复的“登录-定位-修改-确认”大步骤但“备注新地址需要与收货人手机号匹配”这种触发条件和特殊校验绝不能丢。第二个目标是“维持覆盖率”。技能库里的经验覆盖了用户可能遇到的各种场景合并过程中不能把某种少数情况给合并丢了。这一点做起来比听起来难因为很多低频场景和主场景表面看起来高度相似但实际上有不同的前置条件。多目标优化在这里起作用的方式是保证输出的新技能集合仍然能覆盖原有任务集合。第三个目标是“消除冲突”。前面提到过新旧技能之间可能互相矛盾或者同一个步骤在不同的技能里给出了不同约束。精炼这个动作天然适合做一致性校对把相关技能抽样到一起逐条对比差异找出那些“同一场景、不同结论”的冲突点然后用逻辑判断或者依靠线上效果数据确定哪个才是当前应该保留的标准答案。第四个目标是“控制成本”。技能条数少了检索时被判定的候选集小了拼进上下文的Token少了对应延迟和成本都会跟着下降。这个目标往往是最容易量化的也是项目汇报时最好看的数字但千万不能把它当成唯一指标否则就会走向过度合并。2.3 与“简单删删减减”的本质差别SkillBrew这类多目标精炼和直觉层面上的“删技能”有一个非常大的差别它不是直接在原始技能文本上做减法而是先构建一个新的技能表达再用这个新表达替代原始的一批技能。可以把它理解成代码重构里的“提取公共函数”——你并没有把某段逻辑删除而是把重复实现合并成一个函数同时调整所有调用点。技能库的精炼同理它把多条相似技能的内容重新组织成一条更精炼的技能然后再让Agent的整体检索路径指向这条新技能。从实现层面看这就意味着SkillBrew要处理几个前置问题如何判断两条技能是否属于同一“意图簇”合并后保留哪些信息、舍弃哪些信息合并后的技能如何验证它确实不逊于原始版本这些问题的解法构成了方法的核心模块。后面我会拆一套可复现的参考流程即使不看论文也能照着在自己的Agent系统里做一版。3. 多目标精炼的五个实操环节一套可复现的参考流程3.1 第一步把技能统一成可比较的结构精炼的前提是技能之间能比较而大多数团队的技能库根本没法比较因为每条技能的自由度太大了。有的技能就是一句话“用户要改地址就让用户去APP操作”有的技能是一段五百字的完整对话流程有的技能里还揉进了当时的会话截图备注。这种情况下你没法做聚类也没法做合并。所以第一步要做的是给每一条技能定义一个统一的结构。我常用的结构包含四个字段触发条件、适用范围、执行步骤、例外情况。触发条件描述什么情况下应该唤起这条技能适用范围描述这条技能适用于哪些场景、哪些用户执行步骤是核心的操作流程例外情况单独列出来避免和主流程混在一起。字段不是越多越好四个已经足够覆盖大多数场景太多反而会让精炼时的LLM抓不住重点。做完结构化之后每条技能看起来就像一个小型函数有入口参数、有逻辑体、有边界条件。到这里才算有了做后续聚类和合并的基础。3.2 第二步用语义聚类找到“说同一件事”的技能簇技能结构统一之后下一步是找出那些“表面不同、实际在说同一件事”的技能把它们归到一个簇里。这一步在大多数实现里会用到Embedding加聚类算法具体做法不复杂先把每条技能的各字段拼成一段文本用Embedding模型转成向量然后计算两两之间的语义相似度最后按相似度阈值把技能分簇。分簇的阈值选择是个经验活我自己的经验是宁可让簇稍微大一点也不要让簇太碎。簇太碎的话后面合并出来的技能仍然会有很多重复簇太大则会把真正不同的场景强行捏在一起。判断两个技能是否该归为一簇有一个很实用的标准如果一名资深同事能在不看其他信息的情况下用同一套流程解决这两个技能描述的问题它们就该合并。一个容易踩的坑是直接用文本嵌入算相似度的时候执行步骤里哪怕只差一个关键步骤相似度分数也可能很高因为公共的框架性句子太多。我的做法是在算相似度时对字段加权例如“触发条件”的权重占高一些“执行步骤”的次之“例外情况”参与比较但不作为主要依据。这样能避免把两条执行路径完全不同、只是触发场景相似的技能错误合到一起。3.3 第三步簇内合并与跨簇冲突消解分好簇之后就到了整个流程的核心环节把簇内多条技能合并成一条或者少数几条。这一步可以直接交给LLM完成但提示词的设计非常关键我踩过的坑是只告诉模型“把相似的技能合并成一个”它往往会输出一个“四不像”——每条原始技能的细节都保留了30%看似全面实际上模型自己都不知道该怎么执行。一个更可靠的提示策略是给LLM一个“合并模板”要求它按固定的组织方式来生成结果。我实践下来比较好用的模板是你是一个技能库精炼引擎。下面给你一组描述同一场景的技能。请分析这些技能的异同合并成一条新的技能。要求执行步骤按动作顺序编号所有原始技能中出现的特殊前置条件和例外情况如果在新技能里没有对应覆盖必须保留相同步骤只保留最完整、最清晰的一个版本合并后总长度不能超过原始技能中长度最短的那条的一点五倍。这个“长度上限”的约束很重要它能防止模型把合并当成拼接。同时它还隐含了一层目标合并是一个求最大公约数和最小公倍数的过程只保留下真正必要的内容。跨簇冲突消解则是处理两个不同簇之间出现矛盾的情况。实践中可以先做一个全库两两扫描把“触发条件高度相似但操作步骤不一致”的技能对找出来再交给人工或者LLM判断谁更合理、要不要互相关联。这一步不能省因为冲突不清除的话合并做得再好Agent仍然会行为不一致。3.4 第四步用真实任务做验证而不是只看文本相似度很多人做完合并就觉得完事了这是最大的错误。合并出来的一条技能读起来通顺、长度也短并不代表它能在真实执行中替代原来那几条。检验精炼效果的唯一标准是拿真实任务去跑。我通常的做法是保留一份精炼前的技能库快照然后准备一个覆盖各场景的评测任务集里面混合高频场景、低频场景和有冲突的边界场景。同一个评测集分别跑旧技能库和新技能库对比任务成功率、关键动作是否缺失、Token平均消耗量这三个指标。如果新技能库在成功率上低于旧库超过两个百分点说明合并过程中丢失了关键信息需要回溯是哪一步的问题如果成功率持平甚至更高同时Token量明显下降那这次精炼就是合格的。这一步说到容易做到难因为没有团队会平白无故维护评测集。但如果你想认真推进技能库管理评测集不是可选项而是必选项。哪怕一开始只有五十条模拟任务也比完全依赖目测强一百倍。3.5 第五步版本化与灰度上线精炼会造成Agent行为的变化这种变化不一定是立刻暴露的可能是在某个低频场景里悄悄变差。所以精炼结果上线之前必须做版本化管理和灰度验证。具体做法是精炼后的技能库标记为一个新版本不直接全量替换而是先让它在小流量或者仿真环境中运行两到三天。我在项目里习惯给每个技能库版本加一个“变更说明”记录这次精炼合并了哪些技能、删除了哪些信息、解决了哪些冲突。这个变更说明对溯源非常关键。因为当Agent跑出一次异常行为时你需要在版本记录里快速定位是哪个技能被改动过。如果你的技能库没有版本概念出了问题就只能靠猜那可比不精炼还糟糕。4. 把精炼流程接进你的Agent落地层面的操作细节4.1 技能写入时就规划好“可被精简”的元数据精炼做得顺不顺利早期埋的伏笔占一半。很多团队是技能库里已经堆了几千条乱七八糟的技能之后才开始考虑精炼这时候成本已经很高了。如果你是从零搭建技能库或者还有机会调整写入流程一定要在每条技能写入时就加上元数据。元数据里最重要的两个字段是“所属意图ID”和“最近验证时间”。意图ID用来标记这条技能属于哪一类任务场景后面做聚类时可以直接用意图ID做预分组减少语义聚类的计算量最近验证时间用来判断这条技能是否已经过时给冲突消解提供时间维度上的参考。除此之外如果技能是经过真实用户问题触发生成的建议把触发次数和最后结果也记上哪怕只是草草地记一个“成功/失败”也比没有强。这些元数据不会直接提升单次任务的效果但它是整个技能生命周期管理的地基。没有元数据的技能库精炼等于盲人摸象有了元数据精炼过程才有据可依。4.2 设计精炼触发策略什么时候做多久做一次技能精炼不能太频繁也不能完全不触发。太频繁会导致Agent行为一直处于波动状态用户感知到的是“这个机器人怎么隔几天就变一个性格”完全不触发则会退回到只增不减的老路。触发策略我认为要从两个维度设计按规模触发和按质量触发。按规模触发最简单给技能库设定一个上限阈值比如五百条。每当技能条数超过阈值就自动触发一轮精炼流程。这个策略的好处是执行时机明确团队好对齐预期。按质量触发则更智能一些监控线上任务的成功率指标如果发现某个意图域成功率明显下滑并且检索日志里频繁出现高相似度技能互相抢占的情况就针对这个意图域做局部精炼。实操上我会把两种策略混合全库规模的定时精炼每两周一次局部意图域的触发式精炼随时可以进行。这样既有全局稳定节奏又能应对局部突发恶化。精炼流程本身是批量异步的不需要占用在线服务的时间放在夜间调度跑即可。4.3 用LLM自动精炼时的成本与质量平衡用LLM做技能精炼本质上是拿算力换维护人力。但如果完全不看成本精炼流程本身也可能成为一笔不小的开销。我观察到的实际成本主要来自两个环节第一步的技能向量化聚类这一环相对便宜Embedding模型批量调用即可真正贵的是第三步的合并生成因为需要给LLM输入一整簇技能还要输出一条高质量的新技能。控制成本的思路有三个。第一是尽量做局部精炼而不是全库精炼按意图ID分组处理每组技能数量有限输入输出都短Token成本很低。第二是选择合适的合并模型不需要和线上Agent用同一个级别的模型精炼任务对逻辑复杂度的要求通常低于直接服务用户的任务用中等规模的模型就够了。第三是复用精炼结果合并后的技能经过验证没有问题后可以直接缓存不需要每次精炼都把历史技能重新跑一遍。这里要顺带提醒一句如果LLM精炼输出的技能质量不稳定不要盲目换更大的模型先检查提示词里的约束条件有没有写清楚。我见过太多人把“合并技能”这件事做得像开放式写作模型当然会放飞自我。给它固定的输出结构和长度上限质量立刻就会稳下来。4.4 一个最小可落地的执行流程示例把所有环节串起来一个最小可落地的精炼任务可以这样定义输入是一个意图ID下的所有技能输出是这个意图ID下的精炼后技能集合。伪代码层面的执行流程大致如下读取该意图ID下所有技能解析为统一结构过滤掉状态为“废弃”的技能。将技能文本转为向量做簇内相似度计算按阈值把技能分成若干小组。对每个小组调用LLM按指定模板生成合并后的新技能保留例外情况。对所有新技能做冲突检测找出触发条件相似但步骤不一致的组合标记为待确认。将合并结果放到评测任务集里运行对比旧库效果记录成功率与Token消耗。如果评测通过生成新版技能库进入灰度验证如果失败回滚版本并保留失败日志。整个过程可以写成一套独立的定时任务脚本和线上服务解耦。灰度验证通过后再把新技能库发布到线上。这套流程一旦跑顺技能库的精炼就不再是一个拍脑袋的动作而是一个可以每周自动完成、结果可控的标准环节。5. 这些坑我基本都踩过常见问题与排查要点5.1 误删关键技能导致成功率暴跌我经历过的最典型事故是精炼后的技能库在一个“企业发票变更”场景上的成功率从85%掉到41%。回溯原因后发现精炼时把一条技能里的“必须上传营业执照原件照片而非复印件”这个特殊校验给删掉了因为它和主流程里的“上传相关证件”重复。但从用户的真实视角来看“相关证件”这个说法太模糊模型很容易默认复印件也行最后导致大量请求被驳回。这个坑的排查思路是精炼后如果发现某个场景的成功率明显下降不要先怀疑模型而是先对比旧版技能和新版技能在“例外情况”字段上的差异大概率是例外信息被精简了。教训是例外情况字段在精炼时必须享有最高保留优先级宁可让主流程文字更紧凑也不能牺牲例外情况。5.2 合并出来的技能“什么都讲了等于什么都没讲”这大概是使用LLM做技能合并时最常见的问题。模型把簇内的每一条技能都压缩后塞进了新技能里表面看一条技能涵盖了所有情况实际上里面充满了“如果”“或者”“同时”这类条件词模型执行的时候每条路径都不完整。后来我给提示词加了一个硬约束“合并后的技能必须能被一个没有看过原材料的新手按照步骤一步步操作完成步骤之间不得出现二选一式的分叉如果原始技能存在真正互斥的场景分支则拆成多条技能不要塞进同一段流程”。这个约束很管用因为它倒逼LLM在“保留所有信息”和“保持可执行性”之间做取舍而不会偷懒地做信息拼接。5.3 精炼频率过高Agent行为飘忽不定有一段时间我们每周都做全库精炼结果连续三周模型在线上的行为都在变客服主管反馈“用户说你们的产品换人了”。问题的根源不在精炼本身而在于精炼触发的节奏太随性每次都有新版本的技能库发布线上行为自然跟着漂移。我的调整方案是把全库精炼的周期固定为两周一版非紧急情况下不插队每个意图域的精炼节奏跟随该域的效果指标只有指标下滑时才触发并把“上一版技能库效果更好”作为触发回滚的第一优先级判断条件。稳定比永远最优更重要这是技能库管理里比算法更需要注意的地方。5.4 评价指标只盯着“库小了”却忘了任务是变好还是变坏做这类项目很容易陷入一个误区精炼之后技能数量砍半PPT画出来很好看但到底Agent有没有变好用没有人去量化。我之前犯过同样的错误在项目总结里大写特写“技能库规模减少40%”结果老板一句话问住我“那用户满意度涨了吗”后来我把精炼项目的评价指标固定为“一组三看”一看任务成功率涨跌二看单次任务平均Token消耗降幅三看用户侧可感知的异常率变化。技能库缩了多少只作为过程指标进行展示不当作项目的核心结论。做技术可以浪漫做结果必须清醒。5.5 一些可以少走弯路的个人体会在做技能库管理这件事上我越来越认同一个观点技能不是越多越好关键是每一条放进去都得清楚它“为什么存在”。SkillBrew这种多目标精炼本质上就是逼着系统去回答这个问题。哪怕你不打算完整复现论文里的算法只把“技能写入前加元数据、定期做语义聚类、合并时保护例外情况、上线前用真实任务验证”这四个习惯带到项目里效果也会远超绝大多数没有这套流程的Agent。最后分享一个小技巧精炼之后的技能库不要急着销毁旧版本。留一个“黑盒对照版”在灰度期同时保留新旧两套技能库的日志一旦新库出现异常可以立刻切回旧库然后再慢慢排查差异。这种能切回去的安全感对于推进技能库优化真的非常宝贵。结合SkillBrew的方向来看后续这个思路还能往两个地方延伸一是把精炼的目标从“技能库条目”延伸到“Agent的记忆模块”让对话历史、工作流配置也具备自动压缩与重构的能力二是把精炼的标准从“人工设定阈值”升级为“根据线上效果自动调节让系统自己决定什么时候该合并、什么时候该停手”。我个人很期待看到这类研究继续往前推进毕竟对一个真正跑在生产环境里的Agent来说懂得给经验做减法可能比堆砌更多新技能更能决定系统的上限。