1. 从“只增不减”说起LLM智能体技能库的膨胀困局如果你最近半年在折腾LLM智能体大概率会遇到一个很尴尬的局面智能体跑得越久技能库越臃肿但实际任务成功率并没有跟着涨反而开始往下掉。这个现象在圈子里已经不算新鲜事但真正把它当成一个核心问题去解的人并不多。EMNLP 2026上那篇关于SkillBrew的工作标题里那句“告别技能库只增不减”其实戳中了很多一线从业者的痛点——我们花了大量精力让智能体学会新技能却很少认真想过技能是不是也该做做减法。先把这个问题的背景说清楚。所谓LLM智能体的技能库本质上就是一组可复用的行为单元可能是一段提示词模板、一个工具调用序列、一段代码片段或者一个完整的子任务流程。智能体在执行任务时会根据当前状态从技能库里检索匹配的技能然后组合起来完成任务。这个思路本身没问题问题出在“入库”这件事上。绝大多数现有方案对技能入库的门槛设得很低只要某次任务成功了或者某个技能在某个场景下表现不错就把它塞进库里。久而久之技能库就像一间从来不扔东西的储藏室什么都有但真要用的时候翻半天找不到找到了还可能拿错。更麻烦的是技能之间会互相干扰。两个技能单独看都没问题但组合在一起可能产生冲突比如一个技能倾向于先调用搜索工具另一个技能默认先查本地知识库智能体在决策时就会摇摆。这种干扰在技能数量少的时候不明显一旦超过某个阈值整体表现就会断崖式下跌。我在实际项目里见过一个智能体技能库从30条涨到200条的过程中任务完成率从78%掉到了61%而团队一开始还以为是模型能力不够拼命换更大的底座模型结果毫无改善。后来把技能库精简到60条左右成功率直接回到80%以上。这件事让我意识到技能库的“减法”不是锦上添花而是决定智能体能不能长期稳定运行的关键工程问题。SkillBrew这篇工作的核心贡献就是把这个“减法”问题形式化成了一个多目标优化问题并给出了一套可落地的精炼流程。它要解决的不是“怎么让智能体学更多”而是“怎么让智能体在学的同时忘掉该忘的”。这个思路的转变很关键因为过去大家默认技能越多越好现在得承认技能库也有一个最优规模超过这个规模边际收益为负。2. SkillBrew到底在做什么多目标精炼的核心思路拆解2.1 为什么是“多目标”而不是“单目标”如果只是想让技能库变小那最简单的方法就是按使用频率排序把低频技能删掉。但这么做会出大问题。一个技能使用频率低可能是因为它确实没用也可能是因为它只在特定场景下才被触发而那个场景恰好很少出现。如果你一刀切地删掉等到那个场景真的来了智能体就抓瞎了。所以技能精炼不能只看一个指标必须同时考虑多个维度。SkillBrew把精炼目标拆成了三个技能效用、技能冗余度、技能冲突度。技能效用衡量的是这个技能对任务成功率的贡献冗余度衡量的是它和其他技能的重复程度冲突度衡量的是它和其他技能组合时产生负面干扰的概率。这三个目标之间是有张力的效用高的技能可能冗余度也高冗余度低的技能可能冲突度反而大。所以不能简单地线性加权求和而是要在帕累托前沿上找平衡点。我自己的理解是这有点像团队管理。一个团队里有的人能力强但和其他人配合不好有的人能力一般但特别擅长补位你不能只看KPI决定谁走谁留得综合考虑能力、协作、不可替代性。SkillBrew做的就是给技能库做一次“团队优化”把那些真正能打、又不惹事的技能留下来把那些占着位置但实际拖后腿的清出去。2.2 精炼流程的三个阶段SkillBrew的精炼流程大致可以分成三个阶段技能画像构建、多目标评估、精炼决策执行。技能画像构建阶段系统会为每个技能生成一个多维度的特征向量包括它的触发条件、执行代价、历史成功率、与其他技能的共现频率等。这一步的关键是特征要足够细不能只用一个“使用次数”概括。比如一个技能可能使用次数不多但每次使用都出现在高难度任务里那它的价值就不能用次数来衡量。多目标评估阶段系统会在一个验证集上跑大量任务记录每个技能在不同任务中的表现然后计算前面说的三个目标值。这里有个工程上的难点技能之间的组合爆炸。如果有200个技能理论上可能的组合是天文数字不可能全部枚举。SkillBrew采用了一种基于采样的近似方法只评估那些在实际任务轨迹中出现过的组合这样计算量就降到了可接受的范围。精炼决策执行阶段系统会根据多目标评估的结果决定哪些技能保留、哪些技能合并、哪些技能删除。合并是一个很聪明的设计两个冗余度高的技能不一定非要删掉一个可以把它们合并成一个更通用的技能。比如“查询天气”和“查询空气质量”这两个技能如果它们的执行逻辑高度相似就可以合并成“查询环境信息”减少技能数量的同时不损失功能覆盖。2.3 和传统技能管理方案的差异传统的技能管理方案不管是基于规则还是基于嵌入相似度本质上都是单目标的。基于规则的方案通常只看使用频率或最近使用时间基于嵌入相似度的方案只看技能之间的语义距离。这些方案在技能库规模小的时候够用一旦规模上去就力不从心。SkillBrew的差异在于它把技能精炼看成了一个持续的过程而不是一次性的清理。系统会定期重新评估技能库的状态因为任务分布会变技能的价值也会变。今天有用的技能下个月可能就没用了今天冗余的技能下个月可能因为新场景的出现而变得独特。这种动态视角很重要我在实际项目里就吃过亏有一次做了一次性清理结果两个月后业务方向调整删掉的技能里有一半又需要重新加回来白白浪费了之前的积累。3. 核心细节解析技能画像、评估与决策的实操要点3.1 技能画像到底要画什么技能画像是整个精炼流程的基础画得不准后面的评估和决策全是空中楼阁。根据SkillBrew的思路和我自己的实践一个技能画像至少应该包含以下几类信息触发特征这个技能在什么条件下会被激活是关键词触发、意图匹配触发还是前置技能执行完毕后的默认触发触发条件越明确后续评估越可靠。执行特征这个技能执行时需要哪些资源调用哪些工具平均耗时多少失败率多少这些数据直接关系到技能的执行代价。效果特征这个技能执行后对任务最终成功率的贡献是多少是直接完成任务还是为后续技能铺路这里要区分“直接效用”和“间接效用”。关系特征这个技能和其他技能的共现频率、组合成功率、冲突概率。关系特征是最难获取的但也是最有价值的。我在实际构建画像时会用任务轨迹日志来自动提取这些特征。每条任务轨迹记录了智能体从开始到结束的完整决策序列包括调用了哪些技能、执行结果如何、最终任务是否成功。从这些日志里可以统计出每个技能的触发频率、执行成功率、与其他技能的共现矩阵。这个过程不需要人工标注但需要日志格式足够规范否则提取出来的特征会有噪声。注意技能画像不是一次性的工作。任务分布变化、工具接口更新、甚至底层模型升级都会导致技能特征发生变化。建议至少每个月重新跑一次画像构建或者在任务成功率出现明显波动时立即触发。3.2 多目标评估的计算过程多目标评估的核心是三个指标的计算。我结合SkillBrew的描述和自己的理解把计算过程拆开讲。技能效用的计算相对直接。对于技能s它的效用可以定义为在所有使用了s的任务中任务成功率的提升幅度。具体来说可以对比“使用s的任务成功率”和“不使用s但任务类型相同的任务成功率”两者的差值就是s的边际效用。如果差值为正说明s确实有帮助如果差值为零或负说明s可能是多余的甚至有害的。技能冗余度的计算需要技能之间的相似度。SkillBrew用的是执行序列的编辑距离加上语义嵌入的余弦相似度两者加权得到一个综合相似度。如果两个技能的综合相似度超过某个阈值比如0.85就认为它们高度冗余。冗余度指标可以定义为对于技能s它与所有其他技能相似度的最大值或者平均值。最大值更能反映“有没有替代品”平均值更能反映“整体独特性”。技能冲突度的计算最复杂。两个技能单独执行都成功但组合执行时失败率显著上升这就是冲突。冲突度的计算需要统计技能对(s1, s2)的共现次数和共现成功率然后和它们各自的独立成功率做对比。如果共现成功率显著低于独立成功率的乘积就说明存在负向干扰。冲突度可以定义为对于技能s它与所有其他技能冲突概率的加权和权重可以用共现频率。这三个指标算出来之后每个技能就变成了三维空间里的一个点。精炼的目标就是在这个三维空间里找到一组技能使得整体效用最大、整体冗余度最小、整体冲突度最小。这是一个典型的多目标优化问题可以用NSGA-II之类的算法来求解帕累托前沿。3.3 精炼决策的四种操作评估完之后系统会对每个技能做出四种决策之一保留、合并、降权、删除。保留是最直接的技能效用高、冗余度低、冲突度低没有任何理由动它。合并针对的是冗余度高但效用也高的技能对把它们合并成一个更通用的技能。降权针对的是效用中等、但冲突度偏高的技能不删除但降低它在技能检索时的优先级减少它被误触发的概率。删除针对的是效用低、冗余度高、冲突度也高的技能这种技能留着就是负担。这里有个经验性的阈值设定问题。SkillBrew的论文里给了一些默认阈值但实际使用时需要根据业务场景调整。比如在容错要求极高的场景比如医疗、金融冲突度的阈值应该设得更严格宁可多删一些技能也不能让冲突技能留在库里。而在探索性较强的场景比如创意生成冗余度的阈值可以放宽因为冗余有时候意味着多样性。4. 实操过程从零搭建一套技能精炼流水线4.1 数据准备与日志规范动手之前先确认你的智能体有没有在记录任务轨迹。如果没有第一件事就是加上日志。日志至少应该包含任务ID、任务类型、时间戳、每一步调用的技能名称、技能执行结果成功/失败/超时、最终任务结果。日志格式建议用JSON Lines每行一条记录方便后续解析。我见过很多团队在这一步偷懒日志只记了“调用了什么”没记“结果如何”导致后面根本没法算效用。还有的团队日志里技能名称不统一同一个技能在不同地方叫不同名字这种问题在精炼之前必须先清洗掉。4.2 技能画像构建的代码实现下面是一个简化的技能画像构建脚本用Python写成假设日志已经整理成了JSON Lines格式。import json from collections import defaultdict, Counter def build_skill_profiles(log_path): skill_stats defaultdict(lambda: { trigger_count: 0, success_count: 0, fail_count: 0, cooccur: Counter(), task_types: Counter() }) with open(log_path, r, encodingutf-8) as f: for line in f: record json.loads(line) task_type record[task_type] task_success record[task_success] skills_in_task [step[skill] for step in record[steps]] for i, skill in enumerate(skills_in_task): stats skill_stats[skill] stats[trigger_count] 1 stats[task_types][task_type] 1 if task_success: stats[success_count] 1 else: stats[fail_count] 1 for other in skills_in_task[i1:]: stats[cooccur][other] 1 return skill_stats这个脚本跑完每个技能就有了触发次数、成功次数、失败次数、共现技能列表和任务类型分布。这些是后续计算效用、冗余度、冲突度的原始数据。4.3 多目标评估的计算脚本有了画像数据接下来算三个指标。效用直接用成功率减去基线成功率冗余度用技能共现向量的余弦相似度冲突度用共现成功率与独立成功率的偏差。import numpy as np from itertools import combinations def compute_metrics(skill_stats, baseline_success_rate): skills list(skill_stats.keys()) n len(skills) skill_to_idx {s: i for i, s in enumerate(skills)} utility {} for s in skills: stats skill_stats[s] total stats[trigger_count] if total 0: utility[s] 0.0 continue success_rate stats[success_count] / total utility[s] success_rate - baseline_success_rate cooccur_matrix np.zeros((n, n)) for s in skills: for other, count in skill_stats[s][cooccur].items(): if other in skill_to_idx: cooccur_matrix[skill_to_idx[s]][skill_to_idx[other]] count norm np.linalg.norm(cooccur_matrix, axis1, keepdimsTrue) norm[norm 0] 1 normalized cooccur_matrix / norm similarity normalized normalized.T redundancy {} for s in skills: idx skill_to_idx[s] sims similarity[idx].copy() sims[idx] 0 redundancy[s] float(np.max(sims)) if n 1 else 0.0 conflict {} for s1, s2 in combinations(skills, 2): cooccur_count skill_stats[s1][cooccur].get(s2, 0) if cooccur_count 5: continue s1_rate skill_stats[s1][success_count] / max(skill_stats[s1][trigger_count], 1) s2_rate skill_stats[s2][success_count] / max(skill_stats[s2][trigger_count], 1) expected s1_rate * s2_rate actual cooccur_count / max(skill_stats[s1][trigger_count], 1) if actual expected * 0.8: conflict[s1] conflict.get(s1, 0) (expected - actual) conflict[s2] conflict.get(s2, 0) (expected - actual) for s in skills: conflict.setdefault(s, 0.0) return utility, redundancy, conflict这段代码里有个细节值得说冲突度计算时我设了一个最小共现次数阈值5次。共现次数太少的话统计出来的冲突概率噪声太大容易误判。这个阈值可以根据你的数据量调整数据量大的话可以设高一点比如10次或20次。4.4 精炼决策的执行逻辑三个指标算出来之后就可以做决策了。下面是一个简单的决策规则实现def refine_skills(utility, redundancy, conflict, utility_threshold0.05, redundancy_threshold0.85, conflict_threshold0.1): decisions {} for s in utility: u utility[s] r redundancy[s] c conflict[s] if u utility_threshold and r redundancy_threshold and c conflict_threshold: decisions[s] keep elif u utility_threshold and r redundancy_threshold: decisions[s] merge elif u utility_threshold and c conflict_threshold: decisions[s] downweight else: decisions[s] remove return decisions这套规则不是死的你可以根据业务需求调整阈值。比如在容错要求高的场景把conflict_threshold降到0.05让更多技能进入降权或删除状态。在探索性场景把utility_threshold降到0.02保留更多可能有用的技能。4.5 精炼后的验证与回滚机制精炼做完之后不能直接上线必须先在验证集上跑一轮对比。对比的指标包括任务成功率、平均执行步数、技能库大小、技能检索耗时。如果任务成功率下降超过2个百分点或者平均执行步数上升超过10%就需要回滚或者调整阈值重新精炼。我自己的做法是保留精炼前的技能库快照一旦线上表现异常可以在5分钟内回滚。这个回滚机制看起来简单但关键时刻能救命。有一次我们精炼后上线第二天发现某个低频但关键的任务类型成功率暴跌幸好有快照回滚后问题立刻消失然后我们针对那个任务类型单独调整了阈值第二次精炼就没再出问题。5. 常见问题与排查技巧实录5.1 精炼后任务成功率反而下降怎么办这是最常见的问题通常有三个原因。第一个原因是效用计算有偏差某些低频但关键的技能被误判为低效用。排查方法是按任务类型分组看成功率变化如果某个任务类型成功率暴跌就去检查那个任务类型下被删除或降权的技能。第二个原因是冲突度计算过于敏感把一些正常的技能组合误判为冲突。排查方法是把冲突度最高的几个技能对拿出来人工看看它们的共现轨迹判断是不是真的冲突。第三个原因是精炼后技能检索的分布变了原本被高频技能压制的低频技能现在被检索到的概率变了导致智能体的行为模式发生变化。这种情况需要重新调整技能检索的排序策略。5.2 技能合并后效果不如预期合并技能听起来很美但实操中经常出问题。最常见的问题是合并后的技能触发条件变得模糊智能体不知道该在什么时候调用它。比如把“查询天气”和“查询空气质量”合并成“查询环境信息”如果触发条件只是简单地把两个原触发条件取并集智能体可能会在只需要天气的时候也去查空气质量浪费执行步数。解决办法是给合并后的技能加上更精细的触发条件或者保留两个独立的触发入口但共享执行逻辑。5.3 精炼周期应该多长这个问题没有标准答案取决于你的任务分布变化速度。如果业务场景稳定一个月精炼一次就够了。如果业务场景变化快比如每周都有新任务类型上线那可能需要每周甚至每天精炼。我的建议是先用一个月周期跑一段时间观察任务成功率的变化曲线如果曲线在精炼后两周内保持稳定说明周期可以拉长如果两周后开始下滑说明周期需要缩短。5.4 技能库规模有没有经验值根据我在几个项目里的观察技能库规模在50到150之间通常是比较健康的区间。低于50可能覆盖不了足够的场景高于150检索效率和组合成功率都会明显下降。但这个数字和任务复杂度强相关简单任务为主的智能体技能库可以小一些复杂任务为主的智能体技能库可以大一些。关键不是绝对数字而是技能库的增长曲线。如果技能库在持续增长但任务成功率不涨那就是该做减法了。问题现象可能原因排查方法解决方向精炼后成功率下降低频关键技能被误删按任务类型分组对比成功率调整效用阈值保留低频高价值技能精炼后执行步数上升技能合并导致触发模糊检查合并技能的触发条件细化触发条件或保留独立入口冲突度指标异常高共现样本不足导致噪声提高最小共现次数阈值增加日志量或调整冲突判定阈值技能库反复膨胀精炼周期过长观察成功率随时间的变化缩短精炼周期或设置自动触发条件5.5 一个容易被忽略的坑技能版本管理技能不是一成不变的同一个技能可能因为工具接口更新、提示词优化、底层模型升级而发生变化。如果你在精炼时没有考虑版本因素可能会把旧版本技能和新版本技能当成两个独立技能来处理导致冗余度计算失真。我的做法是给每个技能加上版本号精炼时只保留最新版本旧版本直接归档。如果最新版本表现不如旧版本再考虑回滚版本而不是保留两个版本。6. 多目标优化在技能精炼中的工程取舍6.1 帕累托前沿的近似求解严格来说多目标优化问题的最优解是一个帕累托前沿而不是一个单点。但在工程实践中我们通常只需要前沿上的一个或几个点。SkillBrew用的是一种基于分解的方法把多目标问题拆成多个单目标子问题每个子问题用不同的权重组合然后并行求解。这样做的好处是计算量可控而且可以得到前沿上的多个候选解方便根据业务需求选择。我在实际使用时会先跑一轮得到前沿上的5到10个候选解然后人工评估每个候选解对应的技能库在验证集上的表现选一个最符合当前业务需求的。这个过程不需要每次都做只在业务方向发生重大调整时做一次就行。6.2 计算资源的预估技能精炼的计算开销主要来自两部分画像构建和多目标评估。画像构建需要遍历所有历史日志如果日志量在百万级别单机跑一次大概需要几十分钟。多目标评估需要计算技能之间的相似度和冲突度复杂度是O(n^2)n是技能数量。如果n是200计算量完全可以接受如果n是2000就需要考虑分布式计算或者近似算法了。我的建议是如果技能库规模在500以内单机跑就够了。超过500先考虑是不是技能库本身太臃肿了也许应该先做一轮粗筛把明显没用的技能删掉再跑精细的精炼流程。6.3 和在线学习的结合SkillBrew的精炼流程是离线的但技能库的变化是在线的。新技能在不断产生旧技能在不断失效。一个自然的想法是把精炼和在线学习结合起来在线学习负责产生新技能离线精炼负责清理旧技能两者形成一个闭环。这个闭环的关键是精炼的频率要跟上技能产生的速度。如果技能产生速度是每天10条精炼周期是一个月那技能库在一个月内会膨胀300条精炼的压力就很大。这种情况下可以考虑做一个轻量级的在线过滤把明显低质量的技能直接挡在库外减轻离线精炼的负担。7. 一些实操心得和后续可以扩展的方向我在几个项目里落地技能精炼之后最大的体会是技能库的质量比数量重要得多但质量不是靠人工审核出来的是靠数据驱动的精炼流程跑出来的。人工审核技能库一天能看几十条就不错了而且主观判断容易有偏差。用SkillBrew这套多目标精炼的思路一次能处理几百条技能而且判断标准是一致的、可复现的。另一个体会是精炼不是一劳永逸的。我见过一些团队做了一次精炼效果很好然后就不管了结果三个月后技能库又膨胀回去了。精炼应该是一个常态化的流程就像代码库需要持续重构一样技能库也需要持续精炼。把精炼流程自动化设置好触发条件比如技能库超过150条自动触发或者任务成功率下降超过3%自动触发让它自己跑这样才可持续。后续可以扩展的方向我觉得有两个比较有意思。一个是把技能精炼和技能生成结合起来不是先产生再精炼而是在产生阶段就用多目标评估来筛选只让真正有价值的技能入库。另一个是把精炼粒度从技能级别细化到技能内部比如一个技能里包含多个步骤有些步骤是冗余的可以只精炼步骤而不是整个技能。这两个方向都有实际需求但工程复杂度也会更高值得后续慢慢探索。