你有没有数过，自己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来说，懂得给经验做减法，可能比堆砌更多新技能更能决定系统的上限。