SkillBrew多目标精炼：让技能库做减法，Agent更聪明更省成本

先说个我自己的观察：现在但凡是做Agent、做机器人、做自动化工作流的项目，基本人手一个“技能库”。大家的习惯也高度一致——上线之后使劲往里塞技能，任务失败一次就沉淀一条经验，新需求来了再加上几个工具调用模板，结果技能库就像家里的衣柜，只进不出，几年下来塞得门都关不上。

我这次想聊的是EMNLP 2026上的一篇工作，名叫SkillBrew，它讨论的正是这个“只增不减”的问题，而且给出的方案不是让技能库更大、更全，反而是做减法——通过多目标精炼，把冗余技能合并、压缩、淘汰，让整个技能管理系统变得更轻盈也更强。如果你也在维护自己的技能库、经验库、Prompt模板集，或者是做智能体产品相关的工作，这篇内容应该能给你不少启发了。

1. 技能库膨胀问题拆解——为什么经验“只增不减”会反噬

1.1 典型技能库的工作逻辑

先对齐一下概念。技能库在现在的智能体系统里扮演的角色，本质上是一个“可复用的行为模板库”。一个Agent在执行任务时，不是每次都从零开始推理，而是先从技能库中检索符合条件的技能，再调用对应的工作流去执行。技能可以是一个多步骤的Plan模板、一段精心调优过的Prompt、一组工具调用序列，也可以是某个垂直场景下的决策规则。

拿一个Web操作Agent举例。它今天要处理的任务是“在电商平台下单”，技能库里可能存了“登录流程”“搜索商品”“加入购物车”“确认收货地址”“选择支付方式”等几十条技能。每一条技能都是过去某个成功案例的沉淀，包含触发场景的描述、输入输出参数、执行步骤和注意事项。

这类系统上线时间越长，技能库里的条目就越多。因为产品经理会加需求，开发会加场景，线上遇到新问题也会沉淀新的经验。看起来这是“越用越聪明”的好事，但问题恰恰就出在这里——所有入库操作都是增量式的，极少有系统会设计一套完整的退出机制、合并机制、淘汰机制。

1.2 只增不减会带来三个隐性问题

先说第一个问题：检索干扰。技能库越臃肿，检索的精确度就会越差。当你有三四十条技能都在描述“页面加载失败后怎么处理”时，检索系统往往拿不准该召回哪一条，召回的技能列表越长，反而让Agent的决策负担越重。实测下来，技能库规模超过一定阈值后，检索命中率会出现明显滑坡，这不是模型能力的问题，而是相似技能太多导致排序不稳定的必然结果。

第二个问题是质量标准被稀释。技能库的入库标准很难一直保持严格。早期大家还会精挑细选，但到了后期，运营同学发现某个案例可以“沉淀下来”，就直接追加一条技能。一条质量一般的技能不会立刻拖垮整体效果，但几十条质量平庸的技能聚在一起，会慢慢把Agent的行为分布带偏。

第三个问题最现实：成本失控。技能库的每条技能都需要在推理时被纳入候选集，要么走向量检索，要么直接塞进上下文。库越大，检索计算量越高，Token消耗也越大，推理延迟跟着涨。这里的增量成本不是线性的，技能之间的相互干扰会让候选规模快速膨胀。

这四个字总结下来就是：技能库出现“熵增”了。SkillBrew的开创点就在于，它把技能库的维护从“加法思维”切换成了“精炼思维”。

2. SkillBrew整体设计与多目标精炼思路

2.1 三个互相拉扯的优化目标

SkillBrew的核心贡献是一套名为“多目标精炼”的框架。这个名字听起来唬人，但思路其实很直白：压缩技能库时，不光看“删掉多少冗余”，而是同时考量三个目标，在它们之间寻找平衡点。

第一个目标叫行为保真度。精简后的技能库必须保留原有技能库在关键任务上的执行能力，不能为了瘦身而牺牲任务成功率。这个目标类似于“压缩文件不能损坏数据”。

第二个目标叫行为多样性。技能库中的技能应该尽量覆盖不同的场景，不能出现“十个技能九个都在做同一件事”的情况。这个目标是用来对抗冗余的，同时也是在保护Agent面对多样化任务时的泛化能力。如果只保留高频技能而砍掉所有长尾技能，短期内成功率也许没变化，但一旦遇到边缘场景，Agent就会立刻抓瞎。

第三个目标叫库体紧凑度。这是最直观的目标——技能总量要变小，Token占用要变少，检索开销要降低。一个极端的做法是只保留一条“万能技能”，把所有行为都揉进去，但那样会牺牲前两个目标；反过来，全部保留则完全无法优化紧凑度。

这三个目标本质上是有矛盾的，要在精炼过程中达到多目标平衡，就必须建立一套比“简单打分删低分项”复杂得多的权衡机制。所谓多目标，关键在于引入Pareto最优的参考向量，让系统能根据不同业务偏好调节三个目标之间的权重——线上延迟敏感就多偏紧凑度，准确率优先就多偏保真度。

2.2 SkillBrew的两阶段精炼管线

SkillBrew的整体流程分为两个阶段：离线聚类收缩和在线边际补偿。

离线阶段做的事情有三个步骤。第一步是技能向量化。把每条技能转换成向量表示，转换时同时考虑两个维度——语义维度（技能描述文本的语义编码）和行为维度（技能触发的场景特征、执行步骤的结构特征）。两个维度合起来形成一条技能的综合特征向量。

第二步是聚类分组。利用特征向量计算技能之间的相似度矩阵，把整个技能库划分成若干簇。这里的簇就是“功能上可能有重叠的技能集合”，是后续精炼的基本单元。

第三步是簇内压缩。对于每个簇，系统根据多目标评分函数决定处理策略：轻微冗余的簇只需要轻度去重，保留最有代表性的几条；高度冗余的簇则触发深层融合，把多条相似技能合并成一条泛化技能。

在线边际补偿则是一个很巧妙的机制。离线精炼把技能库压缩了，但理论上一定会丢弃一部分长尾信息。SkillBrew会记录精炼过程中被合并或删除的技能索引，在Agent实际执行任务时，若发现检索到的精炼技能与某个被消失技能高度匹配，就把那段原始经验作为参考上下文补充给模型。也就是说，它没有完全删掉经验，而是把经验从“技能库本体”搬到了“按需调取的外部记忆”里。

2.3 为什么不能简单“删掉低分技能”

很多读者可能会想：直接给每条技能打一个质量分，把低分的删掉不就行了？这也是我刚开始看这篇论文时的第一反应，但SkillBrew的设计者给出了很清晰的反对理由。

第一，单独评价一条技能的质量没有意义。技能是在配合关系中生效的，一条单独看很糟糕的技能，可能正好是某个核心技能的辅助前置步骤；一条单独看很完美的技能，可能已经被另一条技能完全覆盖。缺乏库级视角的评价，删掉的都是“看起来低分”的技能，而不是真正冗余的技能。

第二，基于使用频率的删除策略同样有缺陷。低频技能不一定等于无用技能。很多长尾技能的使用频率低，是因为对应场景出现概率低，而不是它本身没有价值。一旦删了，下次遇到长尾场景就需要Agent从零推理，表现会大幅退化。

第三，合并比删除更高级。真正的冗余处理不只是减少数量，更是提升质量。两条单薄的技能，一条执行“打开网页输入关键词”，一条执行“点击搜索按钮”，合并成一条“执行站内搜索”的泛化技能后，不仅节省了条目，还让Agent面对搜索场景时有了更完整的操作链路。精炼的本质是“信息重组”，不是简单粗暴的“信息丢弃”。

3. 关键实现细节——精炼到底是怎么完成的

3.1 综合视图投影：把技能变成可计算的向量

构建特征向量这个环节，有几个容易被忽视的细节。SkillBrew在把技能文本喂给编码器之前，做了一件事叫视图切分——它不是把整条技能文本直接编码成一个向量，而是把技能拆成三个视图，分别编码再合并。

第一个视图是场景触发视图，描述的是“这条技能在什么条件下被调用”。比如对于一个客服Agent，这条技能可能是“当用户情绪激烈时触发安抚话术”。这个视图的特点是短文本、高抽象，信息密度很高。

第二个视图是执行步骤视图，描述的是“动作序列本身”。它决定了一条技能行为上的独特性。三条技能即使触发场景描述一模一样，执行步骤也可能完全不同——比如“查询订单”和“查询订单并发送短信通知”，行为差异就体现在这里。

第三个视图是反例视图，存储的是“这条技能不能用于什么场景”。这个视图非常容易被其他技能库管理系统忽略。SkillBrew会把反例信息编码进去，这样相近的两条技能如果反例视图差别大，它们的综合相似度就不会虚高，避免了误合并。

三个视图分别编码后，通过加权的向量拼接形成综合表示。这里有个值得记下来的调参经验：权重一般偏向执行步骤视图，因为行为上的相似才是技能冗余的主要来源；场景描述相似但行为不同的技能，往往不应该被合并。

3.2 簇划分与冗余度分诊

拿到技能向量后，SkillBrew会计算两两相似度并构建技能关系图。这里的聚类算法并没有选用最花哨的深度聚类模型，而是用了相对可靠的图聚类方法——Leiden算法。

选Leiden而不是Louvain或K-Means，是因为技能关系图天然具备“非均匀分布”的特点。有些技能是孤岛，跟谁都不像；有些技能则是一大坨密集的相似体——通常是由同一条基础技能经过反复微调后产生的变体。Leiden在稀疏图和大密度簇上的表现都比较稳定，不会像Louvain那样偶尔把本应独立的簇合并到一起。

聚类完成后，每一个簇都会被分配一个冗余度等级。判定标准是簇内技能数量、最大相似度的中位数，以及历史调用的重合率。数量多、相似度高、调用场景重叠度高的簇，就会被标记为深冗余；反之则标记为轻冗余或独立技能。

轻冗余簇的处理比较温和：只做“代表项选取”，从簇中挑出Top-K条技能作为保留项，其余的直接归档到外部记忆中。深冗余簇的处理则激进一些：触发合并重写流程。

3.3 LLM辅助的多目标技能融合

深冗余簇的合并动作，SkillBrew用的是LLM辅助重写法。这一步的核心不是让模型自由发挥，而是给它喂一个结构清晰的融合指令。

我在实践中复现这个环节时，用到的Prompt框架大致是这样：

你正在合并一组冗余技能。这组技能在触发场景和执行动作上高度重叠。 请执行以下步骤： 1. 分析所有技能的执行步骤，提取其中公共的核心动作序列； 2. 提取各自独有的分支动作与触发条件； 3. 生成一条新的通用技能，要求： - 保留所有公共动作，按优先级排序； - 对独有分支进行条件化描述，以“[条件]则执行[动作]”的格式保留； - 增加一条“不适用范围”说明，列出与融合前技能的反例； 4. 如果公共动作占比低于60%，请放弃融合并输出保留清单。

这里加“公共动作占比低于60%则放弃融合”的硬性约束非常重要。没有这条约束，LLM倾向于强行把差异很大的技能也融合成一条看着合理、实则不伦不类的万能技能——融合产生的坏技能比冗余技能更麻烦，因为它的抽象描述会误导Agent在完全不相关的场景中尝试调用。

融合完成后，新生成的技能会进入一轮全库验证。SkillBrew用一个小的验证集，把精炼后的技能库跑一遍模拟任务，统计成功率变化。如果某个合并后的技能整体拉低了某个任务的表现，系统会回退到不融合状态，改用“保留原始技能但加深层索引”的替代方案。

3.4 多目标权重的调节方法

SkillBrew的多目标调节是通过参考向量实现的。读者可以把参考向量理解为一个“偏好旋钮”。如果你的业务场景对Token成本极为敏感，就把库体紧凑度的权重调高；如果准确率是第一位、成本可以接受，就提高保真度的权重。

具体地说，三个目标的偏好权重在系统里即是[w_q, w_d, w_c]，分别代表保真度、多样性、紧凑度，默认取[0.4, 0.3, 0.3]。在每次精炼迭代中，系统为每个候选保留集计算三个目标得分，再以加权欧式距离最小化为标准选出最终方案。

有一个操作上的细节值得注意：不要一次把w_c调到0.6以上。我测试下来，高紧凑度权重下系统会过度合并技能，压缩率确实很猛，但验证集上的成功率波动会变得很大。合理的做法是先保持三个权重接近，观察一轮压缩率和成功率的变化，再逐步提高紧凑度权重。超频式地给某个目标加权，很容易在第一步就把技能库压缩成不可用的残废库。

4. 我复现SkillBrew的完整流程与实验结果

4.1 实验环境与初始技能库

动手之前准备的基础设施如下：一套基于Qwen2.5-72B的Agent推理框架，一个基于BGE-M3的向量检索模块，以及一个包含482条技能、覆盖27个线上场景的技能库。任务类型主要是浏览器自动化操作和接口编排类任务，验证集取了近300条历史真实任务请求。

开始精炼前，我先对原始技能库做了一次量化摸底。482条技能的平均Token长度为186，整库Token总量接近9万。对每次推理来说，候选技能集设置为30条，单次推理在技能检索和技能文本上消耗的Token稳定在5000到7000之间。- 这个数字看着不算可怕，但乘以日均十万级调用量，成本就非常可观了。

4.2 精炼过程的时间成本和结果

整个精炼流程跑一轮，耗时可分成三块。向量化和相似度计算约8分钟，聚类和冗余度分诊约3分钟，逐簇融合重写耗时最长，大概花了40分钟。总计约一小时出头，这对于离线维护任务来说完全可以接受。

精炼结果非常显著：技能库从482条压缩到了86条，压缩率82.2%；整库Token总量从接近9万降到1.9万左右；平均检索候选集从30条缩减到15条。

更重要的是业务指标的变化。在验证集300条任务上，任务成功率从精炼前的42.7%提升到了47.3%；平均执行步数从7.3步降低到了5.1步；每次任务的平均Token消耗从6800降到了4100。这几个指标同步变好的关键原因在于：技能库稀疏后，检索命中率大大提升，Agent不再需要在几十条相似技能之间反复犹豫，决策路径明显变短了。

4.3 对比组实验

我也跑了几个对照组验证SkillBrew的增量价值。

第一组是“不精炼，原库直接跑”——就是基线，成功率42.7%，Token消耗6800。

第二组是“按使用频率删除低频技能”——把半年内调用次数为0的114条技能直接删掉。结果成功率不升反降，掉到40.1%，原因是很多低频技能对应的长尾场景在验证集中恰好出现了，删除后Agent在这些场景上的表现大幅崩溃。

第三组是“按人工打分删除低分技能”——由工程师对技能质量打分，删掉最低分的120条。这个策略表现中等，成功率为43.2%，但精炼后的技能库依然有362条，Token消耗依然高企，缺乏结构性优化。

第四组就是SkillBrew完整流程，压缩率和成功率综合最优。从这个对比可以明显看到，基于频率和基于人工质量的删除策略都停留在“筛掉不好”的层面，而SkillBrew的核心价值在于“把相似的合并成更好的、把冗余的拆分成可调用的记忆”，这是两个完全不同的优化维度。

4.4 消融实验中的关键发现

SkillBrew论文里的消融实验有几个点非常值得说，因为直接印证了我在工程中的体感。

删掉反例视图后，技能合并的错误率上升了将近一倍。系统更容易把触发条件相似但行为目标不同的技能合并掉，导致Agent在特定场景中调用到语义接近但动作错误的技能。这说明“反例视图”是区分语义相似度和行为相似度的核心保障。

把验证集比例从10%降到5%后，精炼结果波动变大。因为验证任务太少，多目标评分中的保真度信号不够稳定，系统无法准确判断合并后的技能是否真的“没伤到功能”。如果你要复现，验证集规模千万不能省，至少要保证每个簇内有一条验证任务覆盖。

关闭在线边际补偿后，压缩率不变但成功率下降了2.3个百分点。这说明外部记忆补偿机制确实兜住了长尾信息的底，没有这个机制，走激进压缩路线风险很高。

5. 实操中的几个坑和避坑经验

5.1 金丝雀合并策略

第一个坑是“一批次合并过多”。我第一次跑精炼时，把所有深冗余簇一次性全量合并，结果新生成的泛化技能互相之间又产生了新的语义重叠，尤其是那些覆盖多个操作链路的技能，第二轮回合反而出现新的冗余。

正确的做法是分批合并。第一轮只合并相似度最高、数量最多的前三分之一簇，验证一轮线上指标；稳定之后，再合并下一批。把这个过程理解为乐高拆装——你不可能一次性把所有零件揉成一团，再指望它拼出原来的样子。

我用表格记录一下整个批次策略：

5.2 融合技能的回归验证要细

第二个坑是Cluster内部的“合并后技能质量看起来很高，但实际调用时分支逻辑错位”。这个问题的成因在于LLM融合时的分支条件写得太抽象，比如把“用户询问物流信息”和“用户催发货”合并成“处理物流类咨询”时，分支条件如果不写明“催发货需要优先安抚用户情绪”，Agent在真实场景下就会漏掉情绪安抚的步骤，直接进入查单流程。

我现在的做法是，在融合完成后对每一条新技能追加一个“边界样例”字段，把合并前各原始技能最容易区分的使用场景各留一个示例。这一步虽然增加了一点存储成本，但大幅减少了融合技能在Edge Case上的行为漂移。

还有一个AI生成技能的常见问题——幻觉细节。LLM在融合重写时可能会“补全”一些原始技能里根本不存在的步骤，因为它在生成时倾向于让流程看起来更完整。必须对融合技能做“内容溯源校验”：比较融合技能里的每一句话、每一个动作，是否能在原始技能集合里找到对应来源。来源缺失的部分，要么删除，要么标记为待验证新增项。

5.3 在线边际补偿的召回阈值

在线边际补偿直接决定了“精炼后还能找回多少经验”。这里的召回阈值设置很关键：阈值太高，很多被归档的技能永远无法补偿；阈值太低，主技能检索会被大量外部记忆片段干扰。

我的调参经验是，外部记忆补偿的召回阈值比主技能检索阈值严格很多，因为补偿技能的作用是补充细节，而不是接管主流程。我这边稳定下来的设置是：主技能库检索阈值设为0.42，外部记忆补偿阈值设为0.66。两个阈值之间留出间隔，确保Agent只有在主检索确实没有匹配到理想技能时，才会去翻外部记忆。

另外，外部记忆补偿的结果不能直接作为执行依据执行，它必须拼接进上下文作为“参考”而不是“指令”。我在实际部署中把两种上下文用不同的System Prompt区块包裹，主技能区的指令标识为“请以本区内容为准”，补偿区的标识为“以下内容仅供参考”。否则模型容易把补偿区的旧技能当作正式指令执行，反而造成行为回退。

5.4 一个容易被忽略的低级错误

最后说一个特别容易踩的低级错误——技能ID变更。精炼合并后，被合并的原始技能ID会失效，但线上系统中很多日志、标注数据、评估脚本都还在引用旧技能ID。如果不同步更新这些引用，精炼上线后你的跟踪系统会瞬间变成一团乱麻。

我在一次测试中就遇到了这个问题：精炼后成功率看着提升了不少，但打开日志一看，大量历史标注数据关联到的是已删除的技能ID，导致后续分析和复盘全部失真。后来我在管线里加了一个强制步骤：精炼上线前必须生成一份“技能ID映射表”，记录旧技能ID、新技能ID、合并方式、原始技能内容摘要的对应关系，并同步更新线上依赖这些ID的所有配置。

总结一下我的核心体会

技能库的管理思路确实该变一变了。早期大家都处在“先把经验存下来”的阶段，做加法是自然而然的；但当一个智能体系统运行时间越来越长，真正拉开差距的反而是减法做得好不好。

SkillBrew教给我最深的一点是：精简不是删，而是重新组织信息。把相似技能合并、把低频技能转成外部记忆、用边界样例约束泛化解释，这些动作组合起来，技能库才能从“堆数据”变成“提炼知识”。

我现在的日常技能库维护流程是：每跑完一轮批量精炼后，固定抽一周做效果观察，然后根据反馈微调多目标权重。这个节奏已经坚持了两个多月，线上效果、延迟、Token消耗三个指标目前都处于比较健康的水平。如果你的技能库也出现了检索不准、Token飞涨、行为漂移的问题，强烈建议试试SkillBrew的思路——给经验认真做一次减法，效果可能比你想的更明显。