LLM Agent技能库膨胀治理：SkillBrew多目标精炼实践

不知道从什么时候开始，我做 Agent 技能库的方式变成了“只进不出”：每次任务失败，就往库里塞一条新技能；每个业务方提一个需求，就追加一套 prompt 模板。技能库从 200 条涨到 2000 条，我以为 Agent 会越来越聪明，结果检索开始飘，模型在多个技能之间反复犹豫，连原来稳定命中的场景都开始出问题。这个痛点卡了我很久，直到我刷到 EMNLP 2026 上 SkillBrew 这篇工作，才意识到问题不在于“技能太少”，而在于我从来没有对技能库做过真正的减法。

SkillBrew 的核心思路很直白：把“经验积累”从单纯的增量添加，变成一种可量化的多目标精炼。它不只是删掉不用的技能，而是对已有技能做合并、压缩、淘汰，让整个技能库在保持覆盖率的同时，降低冲突率、检索成本和维护负担。如果你也在维护 LLM Agent 的技能库、做 prompt 工程、或者被“技能越多越笨”折磨过，这篇文章会把 SkillBrew 的思路拆开讲透，并给出一套可以落地的实操流程。

1. 拥抱“只增不减”的代价：为什么技能库需要做减法

1.1 技能库膨胀的源头和陷阱

技能库这个概念听起来很专业，其实干的就是一件很朴素的事：把 Agent 做某类任务时需要用到的经验、规则、工作流沉淀成可复用的模块。在实践里，一个技能通常包含触发条件、使用说明、prompt 模板、输入输出约束，甚至还可以挂工具调用。它的价值在于让 Agent 不用每次从零开始推理，而是直接调用已经被验证过有效的“套路”。

问题出在维护方式上。大多数人跟我一样，技能库的扩张完全由“新增需求”驱动。今天客服场景反馈说“用户问退款失败需要安抚”，你加一条；明天运营场景发现“商品比价要区分自营和非自营”，你又加一条。一年下来，库里积累了几千条规则，谁也不敢删。因为每一条技能当初都是“某个时刻的救命稻草”，删掉之后万一线上又复现，后果没人担得起。

这种“只增不减”的代价不是线性的，而是指数级的。第一，向量检索的命中率会随技能数量增加而下降，因为相似技能之间的向量距离越来越近，召回 top-5 时经常带出一堆无关项；第二，模型需要在前缀里塞进大量候选技能，上下文窗口被占满，推理延迟和 token 成本一起涨；第三，技能之间的“边界模糊”会造成规则打架，同一个输入同时命中两条语义相似但约束不同的技能，Agent 就懵了。

1.2 从“更多技能”到“更好技能”

我一度觉得技能库维护就是“做加法”，做得越多，系统能力越强。SkillBrew 把这个假设直接翻了过来：技能的最终目标是让 Agent 在合适场景下用最少的认知成本做出正确决策。如果你有 100 条技能能覆盖 80% 的场景，和 1000 条技能能覆盖 82% 的场景，前者的工程价值其实更高，因为那多出来的 2% 覆盖率，往往是用 900 条低频、冗余、互相干扰的技能换来的。

这里要区分两个概念：技能数量和技能质量。SkillBrew 的多目标精炼，就是主动对技能做“合并、压缩、淘汰”，在覆盖率和简洁度之间寻找一个帕累托最优。它不是简单按使用频率砍掉冷门技能，因为冷门不代表没用，而是在多个目标下找出那些“即使删除也不影响核心收益、即使合并也不损失语义边界”的冗余项。

做减法还有一个隐藏价值：它逼着你把技能抽象化。只减不增的库里，很多技能其实是同一个底层能力的变体，比如“退款失败安抚”和“发货超时安抚”，本质都是“负向事件 + 情绪安抚”。一旦合并成“服务异常情绪安抚”，反而能提升泛化能力，让 Agent 在面对没见过的新异常时也有一点应对逻辑。

2. 多目标精炼的核心逻辑：把减法变成可量化决策

2.1 多目标打分的三个维度

如果“做减法”只是拍脑袋删技能，那跟直接把库清空没什么区别。SkillBrew 的关键贡献，是把减法的决策过程变成可量化的多目标评估。我理解下来，它有三个核心目标维度。

第一个维度是覆盖度。精炼后的技能库在测试集上的成功覆盖率不能明显下降，最好能通过合并带来一定的正向迁移。覆盖度不能只看“这个技能有没有被触发”，而要看到具体场景下的任务成功率。比如一个技能被删了，但它覆盖的 case 被另一个技能以更泛化的方式命中，那覆盖度就没有损失。

第二个维度是冲突度。每两个技能之间都会存在语义相似性，冲突度的计算方式是找出“输入空间重叠、输出约束矛盾”的技能对。精炼后这个值应该下降。我自己的经验里，很多冲突不是字面上的矛盾，而是两条技能给出了不同粒度的指令，比如一条说“遇到售后问题先道歉”，另一条说“遇到投诉先核实订单再道歉”，模型其实很难判断该听谁的。

第三个维度是运行成本。这里包括向量检索的 top-k 命中率、生成阶段占用的 token 量、以及人肉维护技能库所需的时间。运行成本是一个复合指标，不需要算得非常精确，但要有相对变化。我通常用“精炼前总 token 数 / 精炼后总 token 数”来衡量，再结合线上延迟毛估。

还有两个附加维度值得带上：技能的可解释性和复用频率。复用频率高的核心技能要尽量保留，即使它和某个低频技能语义相近，也应该优先压缩低频项，而不是去动高频项。可解释性则是看技能描述是否具备“人类可读、可维护”的特征，很多历史技能是当初赶工写出来的，连触发条件都写得模棱两可。

2.2 技能表示与“能合并”的判断

要让多目标精炼落地，第一步是把技能变成机器可处理的表示。SkillBrew 的做法并不复杂：先把每个技能文本用 embedding 模型转成向量，再做聚类；同时提取技能的操作意图，比如“安抚”“比价”“退款”“解释”“拒绝”等动作类别，把向量相似度和意图标签一起作为聚类特征。

聚类结果会告诉你哪些技能属于同一簇，但同一簇不代表一定可以合并。我的经验是，判断“能不能合并”要看三条硬条件：第一，两个技能的触发条件是否有显著重叠；第二，两边给出的执行步骤是否一致或有兼容关系；第三，合并之后是否还保留双方的核心边界。如果三个条件都满足，就可以做合并。如果只满足前两个，但有一条关键约束不一致，那就不要合并，而是考虑“压缩”其中一个冗余技能。

压缩和合并是两个不同动作。合并是“把多个技能编成一个新技能”，目的是减少数量；压缩是“保留技能核心逻辑，删掉描述性废话、冗余示例和重复约束”，目的是减少 token 但不减少功能。我实际测试过一条 300 token 的技能，压缩后能到 180 token，效果几乎没有变化，因为里面大量的“比如”“你可以参考”“特殊情况”其实都是 GPT 生成技能时填充的水话。

2.3 迭代式精炼流程

SkillBrew 的精炼不是“跑一次脚本然后删一批技能”这么粗暴。它更接近一个持续集成的流程：先对当前技能库做全面评估，生成多目标得分；然后筛选出冗余候选集；接着对候选集执行合并、压缩、淘汰；最后用固定评估集做回归测试，出了问题就回滚到上一个版本。

这个过程需要保留版本水位线。我通常给技能库打 Git 标签，比如skill-lib-v1.2.0，每次精炼前切一个分支，精炼后跑评估。评估通过就把分支合回主干，失败就丢弃分支。这样做减法才有安全感，因为你随时可以回到“没删之前”的状态。

迭代式精炼还有个容易忽略的细节：评估集需要定期补充新 case。如果你的评估集永远是老 case，精炼很可能会过拟合到评估集上，删掉一些“评估集里没覆盖但线上偶尔有用”的技能。我建议每个版本从线上日志里抽样 10% 的新对话，由规则或人工标注后加进评估集，保持评估集跟真实分布同步。

3. 实操过程：从技能库快照到多目标精炼落地

3.1 第一步：规范化技能库与生成技能卡片

在做任何精炼之前，我先把技能库重构成结构化条目。原始技能可能是一堆散落的 markdown 文件、prompt 片段或工具描述，统一格式化后才有办法批量处理。我用的格式大致长这样：

id: sk-1024 name: 处理发货超时安抚 category: 售后安抚 trigger: - 用户表达不满 - 订单状态为发货超时 - 用户询问补偿方案 instructions: - 先确认订单号 - 核实超时原因 - 致歉并说明预计时长 constraints: - 不承诺具体补偿金额 - 不承认承运商责任 frequency: 0.12 success_rate: 0.86 conflict_ids: [sk-1041, sk-1099] token_size: 312

字段里的frequency和success_rate是从线上日志里统计出来的，conflict_ids是上一轮评估标出的冲突技能对。这些元信息是后面多目标打分的原料，如果没有，精炼就完全靠人工读文本，效率和稳定性都很差。

如果是从零开始建技能库，我建议先用一段时间的 Agent 日志做候选挖掘。把日志按任务聚类，提取成功的调用链，把“用户目标 + Agent 行为 + 结果”转成候选技能，再用规则和人工双重筛选。这个过程不需要一次做到完美，只要做到“每个候选技能都有对应的线上真实 case”即可，因为后面精炼时会反复用这些 case 做验证。

3.2 第二步：多目标评分与候选筛选

有了结构化技能卡片后，就可以写一个评分脚本。下面是简化版的多目标评分逻辑，只保留最核心的覆盖度、冲突度和成本三个维度。

def score_skill(skill, eval_set, conflict_map, cost_weight=0.2): coverage = estimate_coverage(skill, eval_set) # 0~1，命中且成功概率 conflict = 1 - len(conflict_map.get(skill["id"], [])) / max_conflict # 惩罚冲突 cost = 1 / max(skill["token_size"], 1) # token 越小越好 total = 0.5 * coverage + 0.3 * conflict + cost_weight * cost return total

筛选时的具体参数，我会用“候选比例”和“功能重叠阈值”两层控制。比如聚类后某个簇里有 20 条技能，如果两两相似度中位数超过 0.82，我会把该簇标为“高冗余候选簇”；在这个簇里，只有被触发频率低于 0.05 且成功率低于均值 10% 的技能才会进入淘汰名单。

举个实际数字。我上一个项目里技能库有 2143 条，聚类后得到 126 个功能簇，其中 38 个簇的相似度中位数超过 0.8。在这些簇里筛出了 412 条低分技能，合并后生成 83 条新技能，压缩掉 156 条冗余文本，最终精炼目标是缩减到约 1428 条。这个过程不是一次做完，而是分了五轮，每轮只处理 60~80 条候选，避免一次改动太大无法定位问题。

3.3 第三步：精炼动作与人工确认

自动评分只解决“哪些技能值得处理”，真正执行合并和淘汰时，我建议保留人工确认环节。SkillBrew 本身没有规定必须全自动，它的价值在于把候选集缩小到一个人类可以逐条审查的程度。让一个人把 2000 条技能全部读一遍不现实，但让人看 60 条合并建议是可行的。

合并动作有一个重要的实操技巧：不要只做文本拼接。直接把两条技能的 prompt 模板拼在一起，得到的是一个又臭又长的新技能，token 没省多少，语义边界反而糊了。我尝试过的有效做法是：先让 LLM 基于两条技能各自的核心逻辑生成一个抽象版本，再由人工删掉其中“过于具体”的例子和“重复的约束”，最后人工确认抽象版本是否覆盖了两边的主要 case。

对于删除动作，我的原则是“先归档，不删除”。被淘汰的技能不是丢进回收站，而是移入一个archive/目录，保留完整元数据和历史评估记录。这样即使三个月后某个场景突然复活，还能快速找回旧技能，不用重写。

4. 常见问题与排查技巧实录

做技能库精炼最怕的不是“效果没提升”，而是“改动之后出了问题但你不知道是哪里出的问题”。我把实际操作中遇到的典型坑整理成了一张表，方便你按症状排查。

第一个问题最值得展开。有一次我把“退款失败安抚”和“退款延迟安抚”合并成“退款异常安抚”，直觉上很合理，但合并后“退款失败”场景的覆盖率从 0.79 掉到 0.61。原因是我在抽象新技能时，把“失败”这个词理解得太宽，导致技能在引导用户重新支付时给出了一些不适合“延迟但会到账”场景的建议。人类很容易在抽象时丢失精确性，机器更难把握这种微妙边界。后来我在合并模板里加了强制步骤：生成抽象版本后，逐条对照两个原始技能的约束项，只要有一项不一致，就把这一项显式写进新技能的constraints里。

第二个问题也很常见。很多人以为冲突率会随着技能数量减少而自动下降，实际上如果合并得不好，一条新技能可能同时继承了双方的触发条件，反而跟第三条技能发生新的冲突。我现在的做法是每轮精炼后重新计算全局冲突图，而不是只看被合并的那几对技能；冲突图的构建成本不高，但能避免“按下葫芦浮起瓢”。

关于评估集过拟合，我想额外强调一点：技能库精炼最大的风险不是删除错误，而是评估集失真。如果你的测试集是三个月前固定的，那么任何一次精炼都可能过度适配这个测试集。我现在每个版本自动抽取最近 7 天的线上日志，进行去隐私处理后人工抽样 500 条，覆盖新增场景，保证“评估集永远比线上慢半拍而不是慢半年”。

5. 一些实操心得和后续扩展

我自己的经验是，精炼节奏比精炼幅度更重要。不要想着一次把技能库从 2000 条砍到 500 条，那是大扫除，不是精炼。SkillBrew 理念里真正可复制的是“持续小步做减法”的思路，每轮只删 5%~15% 的冗余项，跑完一轮评估，稳定后再继续下一轮。这样做的好处是每次改动的因果链都相对清晰，出了性能波动能很快定位到具体某一批技能改动；如果一次性大砍，问题混在一起，根本没法排查。

在跑技能库精炼之前，一定要先建立版本水位线和回滚机制。我见过不少团队连 Git 都没给技能库建仓，直接用线上配置文件覆盖，一次精炼错了就要从历史备份里翻文本。技能库本质上跟代码一样，是应该被严格版本管理的资产。我的习惯是每次精炼前生成一个快照，并把评估报告一起入库，这样就算回滚，也能知道上个版本为什么是那个样子。

后续扩展我觉得有两个方向很有意思。一个是把精炼做成运行时的钩子：当 Agent 在线上重复遇到“同一条技能被高频触发但失败率上升”时，自动给这条技能打上“待精炼”标记，积累到一定数量后进入下一轮精炼。另一个方向是把个人经验里的 hard case 直接转成技能库的“反向约束”，让技能库不仅能做加法减法，还能对冲突情况做显式禁止，相当于把容易出错的边界直接写死。

最后分享一个小技巧：在做多目标精炼的评分阶段，不要把“模型效果”当作唯一目标，可以把“人类维护这种技能库的负担”也当成一个隐性指标。我在实际操作中的体会是，精简后的技能库不仅线上效果更稳，日常维护也轻松得多，因为你在阅读 1500 条技能时比阅读 3000 条技能时，更容易发现那些真正值得修改的细节。这个收益没法写到论文里，但对我来说，才是 SkillBrew 这套思路最实在的价值。