1. 技能库膨胀这件事到底卡在哪儿了做LLM智能体的同行应该都有个共同感受智能体跑得越久技能库就越臃肿。一开始可能只有十几个基础技能跑上几周之后技能库里躺着几百条技能条目其中大量是重复的、过时的、甚至互相矛盾的。这个问题在业界有个很形象的说法叫“技能库只增不减”跟仓库只进货不清理是一个道理。我最早踩到这个坑是在做一个客服场景的智能体项目。当时设计思路很朴素智能体每解决一个新问题就把解决方案抽象成一条技能存进去下次遇到类似问题直接调用。前两周效果确实好命中率肉眼可见地涨。但到了第四周问题开始暴露了——技能检索的准确率反而下降了。原因很简单技能库里有太多“长得像”的技能检索模块分不清该用哪条有时候调出来的技能还是早期版本跟后来更新的业务规则完全对不上。这就是技能库膨胀的典型症状技能数量线性增长但技能质量非线性衰减。检索噪声变大、技能冲突增多、维护成本飙升最终拖垮整个智能体的决策效率。EMNLP 2026上有一篇关于SkillBrew的工作核心思路就是给技能库做“减法”。它不是简单地删技能而是通过多目标精炼的方式让技能库在保持覆盖能力的前提下把冗余、冲突、低质量的技能合并或淘汰掉。这个方向我觉得非常务实因为现在大部分智能体框架都在卷“怎么加技能”很少有人认真研究“怎么减技能”。这篇文章我想从工程落地的角度把SkillBrew这套思路拆开讲清楚。包括它解决的核心问题、多目标精炼的具体机制、实际部署时的参数选择、以及我在类似场景中踩过的坑。如果你正在做智能体开发尤其是涉及长期运行、技能持续积累的场景这些内容应该能帮你少走不少弯路。2. 技能库为什么不能只做加法2.1 技能膨胀的三个隐性成本很多人觉得技能库大了是好事说明智能体“学得多”。但实际跑过长期项目的人都知道技能库膨胀会带来三个很隐蔽但很致命的成本。第一个是检索精度衰减。技能检索本质上是一个语义匹配问题当库里有大量语义相近的技能时匹配模块的区分度会急剧下降。我做过一个测试同一个查询在50条技能的库里Top-1命中率能到92%但放到500条技能的库里Top-1命中率掉到了67%。多出来的技能并没有带来更好的覆盖反而把原本清晰的匹配信号淹没了。第二个是技能冲突与版本漂移。智能体在不同时间学到的技能可能互相矛盾。比如早期学到的“退货政策”技能是基于旧规则后来业务规则变了新技能存进去了但旧技能没删。检索时如果命中旧技能智能体就会给出错误回答。这种问题在人工维护的规则库里很少见但在自动积累的技能库里非常普遍。第三个是维护与调试成本。当技能库膨胀到一定程度你根本不知道里面哪些技能还有用、哪些已经失效。每次排查问题都要在几百条技能里翻找调试效率极低。更麻烦的是你不敢随便删技能因为不确定删了之后会不会影响某些边缘场景的覆盖。2.2 传统做减法的思路为什么不够用既然只增不减有问题那定期清理行不行行但传统清理思路有几个明显短板。最简单粗暴的是按时间淘汰比如只保留最近30天用过的技能。这个策略的问题在于有些低频但关键的技能会被误删。比如一个处理“发票抬头修改”的技能可能一个月才用一次但一旦遇到就必须有。按时间淘汰会把它干掉。稍微好一点的是按使用频率淘汰保留高频技能删除低频技能。这比按时间好但依然有问题高频技能里可能有很多是重复的低频技能里可能藏着不可替代的长尾能力。单纯按频率一刀切会把“冗余的高频”和“珍贵的低频”一起处理掉。还有一种是按相似度合并把语义相近的技能合并成一条。这个思路方向是对的但实现起来很难相似度阈值怎么定合并后的技能怎么保证不丢失原有能力合并后的技能描述怎么写才能让检索模块准确匹配这些问题不解决合并出来的技能反而更糟糕。SkillBrew的价值就在于它把“做减法”这件事从单一维度升级成了多目标优化。不是简单地按某个指标删技能而是同时考虑覆盖度、冗余度、冲突度和使用效果找到一个整体最优的精炼方案。2.3 多目标精炼的核心思想SkillBrew的多目标精炼本质上是在解一个约束优化问题。目标函数不是单一的“技能数量最少”或“使用频率最高”而是一个组合目标在保证技能库覆盖能力不下降的前提下最小化冗余度和冲突度。这里的关键洞察是技能库的质量不能用技能数量来衡量而应该用技能集合的“信息效率”来衡量。所谓信息效率就是每条技能平均能覆盖多少有效场景、产生多少正确决策。一个100条技能但信息效率高的库远胜过一个500条技能但信息效率低的库。多目标精炼的具体做法我理解下来大概是这样的先把技能库里的技能做聚类把语义相近的技能归到一组然后在每组内部做冲突检测和冗余评估最后根据评估结果决定是保留、合并还是淘汰。整个过程不是一次性的而是可以周期性执行让技能库始终保持在一个健康的规模。这个思路跟传统的数据去重有点像但复杂度高得多。因为技能不是简单的文本条目它包含触发条件、执行逻辑、适用场景等多个维度判断两条技能是否“重复”需要综合考虑这些维度。3. SkillBrew的多目标精炼机制拆解3.1 技能表示与相似度计算要做精炼第一步得让技能变得“可比较”。SkillBrew对每条技能做了一个结构化表示我理解至少包含这几个维度技能描述自然语言、触发条件什么情况下该用这条技能、执行动作具体做什么、适用场景标签、历史使用记录。有了结构化表示之后相似度计算就可以分维度进行。不是简单地把技能描述拿去做embedding然后算余弦相似度而是分别计算触发条件相似度、执行动作相似度、场景标签重叠度然后加权求和。这个设计很关键。我见过太多项目直接用文本embedding算相似度结果把“触发条件相似但执行动作完全不同”的技能误判为重复。比如“用户询问退货政策”和“用户询问换货政策”文本上很像但执行动作完全不同不能合并。SkillBrew的分维度计算能避免这类误判。实际操作中相似度阈值的设定需要根据业务场景调整。我的经验是触发条件相似度权重可以设高一些比如0.4执行动作相似度权重设0.35场景标签重叠度设0.25。阈值方面综合相似度超过0.85才考虑合并超过0.95才考虑淘汰。这个阈值不是拍脑袋定的而是通过在一批标注数据上做实验调出来的。3.2 冲突检测不只是“像”还要看“对不对”相似度只能告诉你两条技能“长得像”但不能告诉你它们“对不对”。冲突检测解决的是后一个问题。SkillBrew的冲突检测主要看两种情况。一种是逻辑冲突两条技能在相同触发条件下给出不同的执行动作。比如一条技能说“用户要求退款时直接同意”另一条说“用户要求退款时先转人工审核”。这两条技能如果同时存在智能体就会精神分裂。另一种是效果冲突两条技能都能处理同一类问题但历史数据显示一条的成功率明显高于另一条。这种情况下低效技能应该被淘汰或合并到高效技能里。冲突检测的难点在于很多冲突不是显式的而是隐式的。比如两条技能的触发条件描述不同但实际覆盖的场景有重叠。这就需要结合历史使用记录来做分析如果两条技能经常在同一个对话中被先后触发说明它们可能在处理同一类问题需要进一步检查是否存在冲突。我在实际项目中遇到过一种特别隐蔽的冲突两条技能单独看都没问题但组合使用时会产生矛盾。比如一条技能负责“收集用户信息”另一条负责“根据信息做推荐”如果信息收集技能更新了字段但推荐技能还在用旧字段就会出问题。这种跨技能的冲突SkillBrew通过技能依赖图来检测思路很值得借鉴。3.3 多目标优化的权衡策略精炼技能库时有几个目标天然是矛盾的。覆盖度要求保留更多技能冗余度要求删除更多技能冲突度要求合并或淘汰冲突技能使用效果要求保留高效技能。这几个目标不可能同时最优必须做权衡。SkillBrew的权衡策略我理解是分层的。第一层是硬约束冲突技能必须处理这是底线。第二层是软约束在冲突处理完之后再在覆盖度和冗余度之间找平衡。具体做法是设定一个覆盖度下限比如“精炼后技能库对历史查询的覆盖度不得低于95%”在这个约束下最小化冗余度。这个分层策略很实用。因为冲突问题是必须解决的没有商量余地而覆盖度和冗余度的权衡可以根据业务需求灵活调整。比如客服场景可能更看重覆盖度宁可保留一些冗余也不能漏掉长尾问题而内部工具场景可能更看重简洁性可以接受稍微低一点的覆盖度。参数选择上我建议覆盖度下限设在90%到95%之间。低于90%会明显感觉到智能体“变笨了”高于95%则精炼效果不明显。这个参数需要根据实际业务的历史查询分布来调没有万能值。3.4 精炼周期的设定技能库精炼不是一劳永逸的事需要周期性执行。但周期设多长是个需要仔细考虑的问题。设太短比如每天精炼一次计算开销大而且技能库变化不大精炼效果不明显。设太长比如每月一次技能库可能已经膨胀到影响性能了才处理期间智能体的表现会持续下降。我的经验是按技能增长速率来定精炼周期。如果技能库每周新增超过10%那每周精炼一次比较合适如果新增速率低于5%可以两周或一个月精炼一次。另外在业务规则发生重大变化时应该触发一次额外精炼因为规则变化往往会导致大量技能冲突。SkillBrew支持增量精炼和全量精炼两种模式。增量精炼只处理新增技能和受影响的旧技能计算开销小适合高频执行全量精炼处理整个技能库开销大但更彻底适合低频执行。实际部署时可以组合使用每周做增量精炼每月做一次全量精炼。4. 落地实操从零搭建技能精炼流程4.1 技能库的初始化与结构化如果你现在手里已经有一个膨胀的技能库第一步不是直接跑精炼算法而是先把技能结构化。很多项目的技能库就是一堆文本条目没有触发条件、执行动作这些字段这种情况下精炼算法没法工作。结构化的过程可以半自动化。先用LLM对每条技能做信息抽取把触发条件、执行动作、适用场景这些字段抽出来。然后人工抽检一批修正抽取错误。这个过程比较费时但值得做因为结构化质量直接决定后续精炼的效果。我建议至少抽检20%的技能确保抽取准确率在90%以上。如果准确率不够要么调整抽取prompt要么换更强的模型来做抽取。不要跳过这一步否则后面精炼出来的结果会一团糟。结构化完成之后给每条技能打上唯一ID建立技能之间的依赖关系图。依赖关系可以从历史对话记录里挖掘如果技能A经常在技能B之前被触发说明A可能依赖B的输出。这个依赖图在后续冲突检测时会用到。4.2 相似度计算与聚类实操结构化完成后就可以做相似度计算和聚类了。具体步骤我整理成了一张表方便对照操作。步骤操作内容关键参数注意事项1对技能描述做embedding建议用领域微调过的模型通用embedding在专业领域效果差2计算触发条件相似度权重0.4触发条件是区分技能的关键3计算执行动作相似度权重0.35动作不同则绝不能合并4计算场景标签重叠度权重0.25用Jaccard相似度即可5加权求和得到综合相似度阈值0.85阈值需在验证集上调6基于相似度做层次聚类距离阈值0.15聚类数不宜过多聚类完成之后每个簇代表一组语义相近的技能。接下来要在簇内部做冲突检测和冗余评估。这里有个经验簇的大小要控制。如果一个簇里超过10条技能说明聚类粒度过粗需要调小距离阈值重新聚类。簇太大意味着内部差异大强行合并会丢失信息。4.3 冲突检测与处理的代码框架冲突检测这部分我写了一个简化版的代码框架展示核心逻辑。实际部署时需要根据业务场景补充更多规则。def detect_conflicts(skill_a, skill_b, history_records): 检测两条技能之间是否存在冲突 返回冲突类型和冲突程度 conflicts [] # 逻辑冲突触发条件相似但执行动作不同 trigger_sim compute_similarity( skill_a.trigger, skill_b.trigger ) action_sim compute_similarity( skill_a.action, skill_b.action ) if trigger_sim 0.85 and action_sim 0.5: conflicts.append({ type: logic_conflict, severity: trigger_sim - action_sim }) # 效果冲突处理同类问题时成功率差异大 success_a get_success_rate(skill_a, history_records) success_b get_success_rate(skill_b, history_records) if abs(success_a - success_b) 0.3: conflicts.append({ type: effect_conflict, severity: abs(success_a - success_b), better_skill: skill_a.id if success_a success_b else skill_b.id }) # 依赖冲突技能依赖的字段或接口不一致 if has_dependency_conflict(skill_a, skill_b): conflicts.append({ type: dependency_conflict, severity: 1.0 }) return conflicts这个框架的核心思路是不同类型的冲突用不同的检测逻辑最后汇总冲突程度。冲突程度超过阈值的技能对进入人工审核或自动处理流程。自动处理策略我建议分三档低冲突severity 0.3只记录不处理中冲突0.3 severity 0.7自动合并合并后保留两条技能的并集能力高冲突severity 0.7自动淘汰低效技能但需要记录淘汰日志以便回溯。4.4 精炼效果评估与迭代精炼做完之后必须评估效果。不能只看技能数量减少了多少那没有意义。关键指标是精炼前后智能体在验证集上的表现变化。我通常用这几个指标来评估检索Top-1准确率精炼后应该持平或上升如果下降说明精炼过度了任务完成率精炼后应该持平或上升下降说明删掉了关键技能平均响应延迟精炼后应该下降因为技能库变小了检索更快技能冲突率精炼后应该显著下降这是精炼的核心目标如果精炼后任务完成率下降超过2%说明精炼策略太激进了需要调高覆盖度下限或调低相似度阈值。如果技能冲突率没有明显下降说明冲突检测逻辑不够灵敏需要补充检测规则。迭代节奏上我建议前三次精炼都做人工审核确认自动处理的结果合理之后再逐步放开自动化程度。完全自动化的精炼在业务稳定期可以用但在业务快速变化期风险较大。5. 踩坑记录与常见问题排查5.1 过度合并导致长尾能力丢失这是我踩过最大的坑。早期做技能精炼时为了追求技能库的简洁性把相似度阈值设得比较低0.75结果把很多“看起来像但实际不同”的技能合并了。合并后的技能描述变得很笼统检索时反而匹配不准。具体案例把“查询订单状态”和“查询物流进度”合并成了“查询订单相关信息”。合并后用户问“我的包裹到哪了”检索模块匹配到这条笼统技能但执行时不知道该查订单状态还是物流进度最后返回了一个模糊的回答。教训是相似度阈值宁高勿低。0.85是底线重要业务场景建议设到0.9以上。合并带来的收益远小于误合并带来的损失。5.2 冲突检测的假阳性问题冲突检测有个常见问题是假阳性两条技能被判定为冲突但实际上它们只是在不同场景下使用并不矛盾。比如“用户要求退款时直接同意”和“用户要求退款时先转人工审核”如果只看执行动作确实冲突。但如果看触发条件前者可能适用于“VIP用户且金额小于100元”后者适用于“普通用户或金额大于100元”。这种情况下两条技能并不冲突只是适用条件不同。解决假阳性的关键是在冲突检测时充分考虑触发条件的差异。如果两条技能的触发条件有明显不同的约束即使执行动作不同也不应判定为冲突。我在代码框架里加了触发条件差异检查假阳性率从30%降到了8%左右。5.3 精炼后的技能描述质量问题合并技能时新技能的描述怎么写是个容易被忽视的问题。如果只是简单拼接两条技能的描述检索效果会很差。好的做法是用LLM根据两条技能的触发条件、执行动作、适用场景生成一条新的、更抽象但更准确的描述。生成后要人工审核确保描述既覆盖了原有能力又不会过于笼统。我试过几种prompt策略效果比较好的是“先总结共同点再列出差异点最后生成一条兼顾两者的描述”。直接让LLM合并描述容易丢失关键细节。5.4 常见问题速查表问题现象可能原因排查方向解决方案精炼后任务完成率下降过度合并或误删检查被合并/删除的技能调高相似度阈值恢复关键技能技能冲突率没下降冲突检测规则不足分析剩余冲突类型补充检测规则尤其是依赖冲突精炼耗时过长全量精炼频率太高检查精炼日志改为增量精炼为主全量精炼降频合并后检索不准新描述过于笼统检查合并后技能描述用LLM重新生成描述并人工审核精炼结果不稳定相似度计算受embedding波动影响对比多次精炼结果固定embedding模型版本增加结果平滑5.5 几个实操小技巧第一个技巧精炼前先备份。技能库精炼是不可逆操作虽然可以回滚但回滚成本高。我习惯在每次精炼前把技能库完整导出存成带时间戳的版本。万一精炼出问题直接回滚到上一个版本。第二个技巧用A/B测试验证精炼效果。不要一次性全量精炼先拿10%的流量做A/B测试对比精炼前后智能体的表现。确认没问题再全量推开。这个做法虽然麻烦但能避免大规模翻车。第三个技巧关注技能库的“熵”。我定义了一个简单指标技能库中不同技能的平均相似度。这个值越高说明冗余越严重。定期监控这个指标比等到问题爆发再处理要主动得多。6. 技能精炼之后还能做什么技能库精炼解决的是“存量”问题但智能体的技能管理还有“增量”问题。精炼之后怎么防止技能库再次膨胀我目前的思路是在技能入库环节加一道“准入检查”。新技能入库前先跟现有技能做相似度和冲突检测。如果跟现有技能高度相似就不入库而是更新现有技能如果存在冲突就触发人工审核。这样能从源头控制技能库的质量。另一个方向是技能分层管理。把技能库分成核心层和扩展层。核心层是经过精炼的高质量技能检索时优先匹配扩展层是低频或待验证的技能检索时作为补充。这样即使扩展层有些冗余也不会影响核心检索的准确性。SkillBrew这篇工作给我的最大启发是智能体的能力增长不应该只靠“堆技能”而应该靠“提质量”。一个精炼过的、信息效率高的技能库比一个庞大但混乱的技能库更有价值。这个思路在LLM智能体越来越普及的当下值得每个做智能体开发的人认真对待。我在实际项目里把技能精炼周期设为两周一次配合入库准入检查技能库规模稳定在150条左右检索Top-1准确率维持在90%以上。相比精炼前500多条技能、准确率不到70%的状态提升非常明显。如果你也在被技能库膨胀困扰不妨试试这套多目标精炼的思路先从结构化技能库开始一步步来效果会比你预期的好。