Agent技能库不是越多越好：SkillBrew多目标精炼如何做减法

做Agent系统做久了，你会发现一个特别反直觉的现象：技能库这个东西，按理说越多越厉害，实际上却常常是越多越笨。去年我在维护一个偏生产向的Agent项目，技能库从最初的几十条涨到了一千多条，每次加新技能都觉得在做正确的事，但整体任务成功率却在往下掉。排查到最后才发现，问题不在模型，也不在检索器，而在那些躺在库里吃灰的冗余技能——它们像家里囤积的旧物，占地方不说，还让真正有用的东西越来越难找。

EMNLP 2026上有一篇叫SkillBrew的工作，正好戳中了我这个长期痛点。它讨论的不是怎么把技能做得更强大，而是怎么给技能库做减法——用多目标精炼的方式，在保留核心能力的同时把技能数量压下去。这个思路值得所有做Agent工程的人都看一眼，因为你迟早会撞上技能库“只增不减”的墙。

1. 技能库“只增不减”：Agent系统里最容易被忽视的慢性病

1.1 从一次安全事故说起：技能多了不一定强

我维护的那个Agent系统，核心功能是帮运营团队处理工单。团队为了提高处理率，在技能库里接入了各种能力：查订单、算优惠券、识别用户情绪、生成回执、翻译、转人工策略……每接入一个新能力，都会往技能库里加对应条目。头几个月效果确实好，工单自助解决率从31%涨到了58%，团队很高兴，于是继续堆技能。

到了第三个月，问题冒头了。同一个技能条目的描述，可能有好几个版本并存，有的写“查询订单状态”，有的写“获取最新订单物流信息”，语义高度重叠，检索器分不清该召唤哪个。更麻烦的是，几个技能之间存在互相覆盖的边界，实际调用链里经常出现“先调A再调B，而B的结果其实A已经返回过了”的冗余行为。从日志上看，每次任务平均要调3.2次工具，其中将近1次是无效调用。

这时候我想起了一句话：你没法评估你管理不了的东西。技能库膨胀之后，团队再也说不清楚每条技能到底带来多少价值。有些技能脚本里被引用，但线上一次都没被触发；有些技能看起来“好用”，实际上是靠其他技能的兜底逻辑才偶尔成功。这种状态下，任何一个管理层都会问：你们为什么不能清理一下？

1.2 为什么会膨胀：每个决策点都在鼓励“加技能”

技能库膨胀不是某一个人的问题，而是机制问题。我复盘了一下我们团队过去一年的决策流程，发现每一环都在做加法：

• 任务失败复盘时，第一反应是“是不是缺技能？”
• 新需求评审时，默认动作是“新增一个技能条目”
• 效果回测时，只统计“加了技能后的提升”，几乎没人统计“删掉一条技能后的影响”

开发者的脑子是线性的，遇到问题就想“再加一个”，却忽略了组合复杂度。一条技能本身没错，但当它与已有的三条技能形成重叠、互补、甚至冲突关系时，系统整体行为就不再是各技能能力的简单加法。

用算法的话说，技能库的问题本质是一个“集合覆盖问题”的变形：我们希望用最小的技能集合覆盖尽可能多的任务场景。而当库里同时存在冗余和遗漏时，你无法通过单纯加新技能来修复——每加一条新的，检索空间就被污染一次，而且你永远不知道旧的哪条可以退休。

1.3 膨胀带来三种隐蔽的成本

技能多了，显性成本是存储和检索变慢，这大家都知道。但真正隐蔽的是下面三种：

检索干扰成本。向量检索召回Top-K的时候，那些语义上高度相似的技能会互相挤占名额。你的“查询订单”和“查询订单详情”语义向量距离很近，结果检索器可能在Top-3里返回两条几乎一样的信息，真正需要的“查询订单异常原因”反而排在了第5位。

推理碎片化成本。Agent在做推理规划时，技能数量越多，每一步可选的分支就越多，模型决策的困惑度越高。一个含有300条技能的库和含有1500条技能的库，在同样的LLM上跑同一个任务，后者不仅更慢，任务成功率也会下降。

评估复杂度成本。这句话可能听起来偏管理，但确实是真问题：技能库超过一定规模后，你根本没法准确评测每条技能的独立贡献。一提到优化，团队只能凭感觉“谁最近改过就测谁”，评估成本随规模非线性增长。

所以当我看到SkillBrew这个标题时，我第一反应是：终于有人把“减法”当成一个正经的研究问题来做了。

2. 现有思路为什么都在“做加法”：从手工整理到自动蒸馏的困境

2.1 手工整理救不了长期系统

很多人会说，冗余就删呗，手工整理不就行了。我试过，真的很痛苦。

手工整理技能库，本质上是在做知识管理。你需要逐条阅读技能描述、查看调用日志、判断它与相邻技能的重叠关系、评估删除后的影响范围。技能少的时候没问题，几百条也能扛，但一旦上千条，人工审查的时间成本就爆炸了。我们团队当时组织过一次为期两周的“技能库减肥周”，四个人全职梳理，最后只清理了80多条，还漏掉了几个隐藏的坑——有两条技能看起来不相关，实际在某个特殊工单场景里互相依赖，删掉一条之后另一条直接失灵了。

问题在于，技能之间的依赖关系藏在调用日志里，不跑实验根本发现不了。靠肉眼读描述，只能在字面上判断“语义重复”，完全碰不到组合层面的问题。

2.2 自动蒸馏和合并的误区：模型不是“记笔记”

既然人工不行，那自动化呢？市面上常见思路是让大模型自动蒸馏技能，把多条技能浓缩成一条。听着很美，实际跑下来却容易翻车。

我踩过的坑是：把功能不同的技能合并成一条，看起来描述更简洁了，但模型在推理时反而不知道“什么时候该用这条合并技能”。原本“查询订单状态”和“退款进度查询”是两条独立技能，模型能根据用户问法精准选择。合并成一条“查询订单与退款状态”后，描述变得模棱两可，模型在需要精准调用时开始犹豫，甚至出现错误调用。

背后的原理其实很好理解：技能本质上是给模型写的“函数签名文档”，它需要尽量精准地描述输入条件和输出行为。合并操作如果只是简单拼接文本，破坏了输入的判别边界，模型就不知道该带哪个参数、该期待什么输出。这跟给大模型写工具文档一样，模糊的说明比没有说明更糟。

2.3 “只增不减”背后的激励机制

为什么学术和工程界都想做加法？“只增不减”背后其实有一套自然而然的激励机制：

• 加一条技能，效果大概率持平或变好，少数情况变差；
• 删一条技能，效果大概率持平或变差，少数情况变好；
• 没有人会因为“删得好”被表扬，但会有人因为“删错了”被追责。

在这种不对称的激励机制下，所有参与者都倾向于保守。技能库涨到一定程度，就变成了一堆“删掉有风险、留着占地方”的资产。想让系统真的敢做减法，需要一种机制来兜底：它必须在删除的同时证明“删掉之后整体效果没有变差，甚至变好了”。这是SkillBrew这类方案真正要回答的问题。

2.4 换个角度看：把删除当成头等优化目标

我这两年慢慢形成的一个认知是：技能库管理不应该被当作日常维护的“杂活”，它本身就是一个需要系统优化的目标函数。

传统的做法是把技能库当作静态知识库，只在任务失败时被动更新。而SkillBrew把这个过程倒过来了：它主动审视整个技能库，在多目标框架下寻找最优的精炼方案。这个视角的转变非常关键——你不是在“帮系统清理垃圾”，而是在“重新设计一个更优的技能子集”。

有了这个视角，技能库管理就从“经验驱动”变成了“优化驱动”，每一步删除都有据可依，而不是拍脑袋。

3. SkillBrew的多目标精炼：把“减法”做成一个可优化的目标

3.1 核心定义：什么是“技能精炼”

读SkillBrew的时候，我先关注了它对问题本身的定义。技能精炼（Skill Refinement）指的是：在已有技能库的基础上，通过合并、拆分、删减、改写等操作，产出一个规模更小但能力不降的技能子集。

关键决策点在于，它不单纯是“选出几条留下”，而是把精炼看成一个对技能库整体结构进行重组的优化问题。目标不是最小的库，而是“在维持任务表现的前提下，尽可能小而精炼”的库。

这就像做数据集的样本筛选：不是随机丢掉一部分样本，而是通过分析每一条样本对训练结果的边际贡献，保留最重要的一批。技能库同理，每条技能的价值，应该由它在一组代表性任务上的边际贡献来衡量，而不是由开发者写描述时的“感觉”决定。

3.2 精炼的多个目标：不只是“指标不掉”

我理解SkillBrew的多目标，可以从这三个维度看：

行为保持目标。精炼后的技能库在基准任务集上的成功率，应该不低于原技能库。这是最基本的底线——你不能为了砍数量而牺牲核心表现。这里的核心设计点是“代表性任务集”怎么选：要覆盖高频场景、异常场景和边界场景，否则你只是在自己假设的“均衡”里自嗨。

冗余消除目标。技能子集内部的语义冗余度要尽量低。我偏向于把它理解为“两两技能的功能重叠度”，可以用预测行为的相似度来估算，而非只读描述文本。两条技能在同一个任务上都能触发，且产生几乎相同的效果，那其中一条就是冗余的。

复杂度降低目标。技能数量、调用链平均长度、检索耗时，这些工程指标也要纳入目标函数。毕竟你精炼技能库，最终是想让系统更快、更省、更稳。技能数量少一个，推理时可供选择的分支就少一些，踩错分支的概率也会下降。

这三个目标放在一起，本质上是一个带约束的多目标优化问题：在保真度约束下，最小化冗余和复杂度。这就比单一“删到多少条合适”的粗放问题精细得多。

3.3 求解思路：候选生成、评估、选择三步走

虽然我看不到SkillBrew的训练/求解代码，但从方法命名和经验判断，它的流程应该可以拆成三步。这也是任何想复现这个思路的人都该先搭好的框架：

第一步，候选生成。基于现有技能库，生成一批可能的精炼动作。包括：把哪几条技能合并成一条、把哪条技能拆成两条更精准的技能、删除哪些完全被覆盖的技能、改写哪些描述以扩大/缩窄适用边界。这一步可以把大模型当生成器用，但需要设计好候选的动作空间，不能让它瞎提。

第二步，批量评估。对每一条候选精炼动作，在代表性任务集上做效果评估。难点在于评估成本，直接跑Agent系统非常贵。可以先用规则和模型预测做粗筛，只把一小部分高质量候选拿出来做真实评测。

第三步，组合选择。在通过评估的候选中，选择一组组合起来能达成“多目标最优”的精炼动作。这就是一个集合选择优化问题，SkillBrew的“多目标”机制应该落在这里——它需要输出一组候选，而不是一条一条独立决定。

这套流程最聪明的地方是：每一个动作都经过了“会改变什么”的验证，而不是写代码的人拍脑袋决定。你删掉一条技能，是因为有评估证据证明它在代表性任务上没有被依赖，而不是因为“感觉没人用它”。

3.4 单目标删除和多目标精炼的对比

为了让自己和团队理解这种思路的价值，我列了一个对比：

这个对比在我脑子里最大的启发是：单目标删除是在“事后补救”，多目标精炼是在“事前重构”。前者是被动的，后者是主动的。

4. 从论文设计到工程实践：真正考验人的三个细节

4.1 基准选择：别只跟“随机删除”比

我读论文有一个习惯，先看它拿什么做对比。如果一篇方法只跟最简单的baseline比，那它大概率没有解决真实问题。SkillBrew这类工作，有意义的对比至少要包括：

• 随机删除同样数量的技能；
• 基于调用频率的低频删除；
• 基于语义聚类的冗余合并；
• 不做任何操作的原始技能库。

只有在这个维度上做对比，你才知道“多目标精炼”到底比“无脑删低频”强在哪。如果两者的任务成功率差不多，那为什么要费劲做多目标？

我建议所有从这篇文章里取经的团队，都自己动手跑一遍这个对比矩阵。很多时候你不实际删一遍，根本不知道自己的技能库冗余度有多高。

4.2 评估粒度：任务级、轨迹级、还是技能级

另一个我特别关注的细节是评估粒度。技能库精炼之后，应该在哪个层面看效果？

• 任务级：整个任务的成功率变化，这是最重要的结果指标。
• 轨迹级：平均工具调用次数、调用链长度、重试次数，这能看到效率变化。
• 技能级：每条技能的独立触发次数、边际贡献，这能看到精炼决策是否合理。

我认为这三层都要测。任务级保证方向正确，轨迹级证明有工程收益，技能级帮你定位问题。我们的系统里，如果技能库瘦身之后任务成功率保持不变，但平均调用链从3.2降到2.1，这个收益就足够划算了。

4.3 消融实验要回答的三个问题

做工程复现的时候，消融实验的思路也可以迁移过来。任何多目标方案都应该回答：

• 去掉“保真度约束”会怎样？——大概率数量更少、效果掉得更狠，说明保真度约束是底线；
• 去掉“冗余消除目标”会怎样？——数量降下来了但重叠依然存在，检索效果提升有限；
• 去掉“复杂度目标”会怎样？——可能选出来的技能子集依然有很长的调用链。

我当时就是因为想明白了这三个问题，才真正理解多目标不是“把三个指标放在一起求平均”，而是“三个维度互相制衡”。每个目标都是在给另两个目标设边界。

4.4 关于泛化性的冷思考

最后泼一盆冷水。技能精炼这种方案，在垂直领域Agent系统里效果可能很好，因为任务场景稳定、数据集可控。但如果你的Agent面临的是开放世界任务（每天都有新类型的请求），技能库精简后泛化能力会不会变差？这是没有标准答案的。

我的看法是，任何精炼方案都必须配套“新增技能时的准入机制”，否则刚精炼完，过两周又膨胀回去了。SkillBrew的思路最好用在一个闭环里：定期精炼 + 新技能准入评估 + 冗余监控，三者缺一不可。光做一次减法，治标不治本。

5. 从SkillBrew到我们自己的Agent工程：四个可以直接落地的启发

5.1 给技能库加一个“定期精炼”机制

我现在强烈建议所有维护Agent系统的人，把技能库精炼当成CI流程的一部分。不是技能多了才清理，而是每个迭代周期结束之后就做一次自动化的冗余分析。

具体怎么做呢？把线上日志导出来，统计每条技能的触发率、成功率、独立贡献。对触发率低于阈值的技能，直接进入待审查列表。对这个列表里的技能，用大模型生成“移除/合并/改写”的候选建议，然后拿到一个固定的回归测试集上批量验证。通过验证就执行，没通过就保留有缘再优化。

这其实就把论文里的多目标精炼思想，落成了一个可重复的工程流程。好处是，你不必等技能库膨胀到不可收拾才开始处理。

5.2 用“代价—收益”视角重看每一条技能

我学会了用一个二维坐标来衡量技能：横轴是维护代价（描述越模糊、依赖越隐蔽、改动影响面越大，代价越高），纵轴是任务收益（触发频次 × 成功率加权）。高收益低代价的技能是核心资产，高收益高代价的技能要重点优化描述，低收益低代价的可以保留，低收益高代价的优先清理。

这个视角最直接的影响是，团队开会讨论“要不要新增技能”时，不再只问“能不能实现”，还会问“新增之后，我们打算让哪条旧技能退休”。如果答不上来，这个人就在制造技能库膨胀的根源。

5.3 量化精炼收益：算算你省下的钱

工程团队推动任何重构，都需要拿数字说话。我给自己定的计算方式是：

• 每次Agent任务调用技能的平均Token消耗差 × 每日任务量 × 365 = 年省Token费用；
• 平均响应时间的下降带来的客户满意度提升（以拦截的投诉量估算）；
• 技能库规模下降后，单人审查技能的耗时下降幅度。

这套算法不一定严谨，但很有说服力。我上回给团队算了一笔账：技能库从1200条压到450条之后，平均每个工单少调用0.7次无效技能，按当时API价格换算，一年能省出几台开发机的钱。再加上体验提升，这个优化项目的性价比高过大多数“新增技能”项目。

5.4 别把精炼做成一刀切，保留“人工兜底”通道

最后是我吃了亏才学到的经验：哪怕自动化精炼流程再成熟，也必须保留人工审查通道。有些技能的触发频次很低，但在关键场景里一次都不能掉链子。比如“紧急订单取消”这种低频高危技能，单看频次可能被当作冗余清掉，但它恰恰是不能出错的底线能力。

所以我后来在流程里加了一个规则：某些被标记为“关键路径”的技能，无论如何都不参与自动精炼候选。这类技能只有在人工确认其功能被新技能完全覆盖之后，才允许手动移除。这条规则看起来保守，但它保证了整个精炼系统的安全性。

SkillBrew这种“做减法”的思路，本质上是在迫使你思考每个技能存在的理由。技能库管理不是一个“越多越好”的堆积游戏，而是一场不断追问“它凭什么留在里面”的长期治理。我在实际项目里最大的体会是：敢于做减法，比善于做加法更需要方法论支持。多目标精炼提供了这套方法论——它让删除从“冒险”变成了“优化”，这才是Agent系统长期进化的正确姿势。