SkillsVote: Lifecycle Governance of Agent Skills from Collection, Recommendation to Evolution

原文链接：https://arxiv.org/abs/2605.18401 作者：Hongyi Liu, Haoyan Yang, Tao Jiang, Bo Tang, Feiyu Xiong, Zhiyu Li 机构：MemTensor (Shanghai) Technology 发布日期：2026-05-18

速查卡

核心 Insight

这篇论文真正有价值的地方，不是“skill 可以提升 agent”——这个大家早就知道；而是它把 skill library 的两个核心风险明确讲清楚了：

1. 任务开始前，给 agent 暴露错 skill，会造成负迁移；
2. 任务结束后，把错误经验写回 skill 库，会污染未来所有任务。

因此，skill 管理不是简单的 retrieval 问题，也不是简单的 memory 问题，而是一个全生命周期治理问题。论文把这个生命周期拆成四段：

• collection：先把开放生态里的 skill 资产收进来；
• profiling / recommendation：在任务前筛选出当前任务该暴露哪些 skill；
• attribution：任务后判断哪些成功经验真的是由 skill 带来的；
• evolution：只把有证据、可复用、责任明确的经验写回库里。

这个洞察的强点在于，它承认开放技能生态是嘈杂的：skill 可能依赖不同 OS、不同权限、不同网络环境，质量参差不齐，而且并不是越多越好。一个看似“更丰富”的技能库，如果没有曝光控制和回写控制，最后反而会拖累 agent。

为什么这个想法 work？

因为 skill 和普通 RAG 文档不一样。

• 普通文档被读错，最坏是误导一次；
• skill 被读错，可能直接把 agent 推向错误执行路径；
• 更糟的是，错误 skill 还会在后续回写中被进一步强化，形成系统性污染。

所以论文做的不是增强检索，而是在 agent 外围加了一层制度：谁能进库、谁该被看见、谁能获得功劳、谁有资格修改未来的技能库。

方法详解

整体架构

论文的整体 pipeline 可以写成：

开放技能生态
  ↓
百万级 skill corpus 收集
  ↓
requirements / quality / verifiability profiling
  ↓
从可验证 skill 合成任务并离线评估
  ↓
任务到来时做 skill recommendation
  ↓
solver agent 执行任务
  ↓
轨迹切成 subtask 并做 attribution
  ↓
只对“成功 + 可复用 + 有证据”的发现做 evolution
  ↓
更新后的 persistent skill library

关键技术组件

组件 1：百万级 skill corpus 收集

**做什么：**把开放生态中的 skill 从零散文本提升为可治理的目录级资产。

怎么做：

论文不是把 skill 当一段 description 文本，而是把每个 skill 当作目录级 package：

• 必需的 SKILL.md 定义能力与使用条件；
• 可选的 scripts/、references/、assets/ 保留代码、文档、模板等支持材料。

这很关键，因为 skill 的可执行性往往不在一句描述，而在配套脚本和引用文件里。

直觉解释：

如果把 skill 只当 embedding chunk，很多运行时约束都会丢失；如果把 skill 当目录包，agent 才能真正把它视为“可安装的经验单元”。

组件 2：requirements / quality / verifiability profiling

**做什么：**判断一个 skill 是否值得进入后续治理链路。

**怎么做：**论文给每个 skill 做三类 profile：

1. runtime requirements

   • OS 假设
   • 写权限
   • sudo 需求
   • 网络访问
   • API keys
   • CLI tools
   • MCP servers
   • 环境变量

2. quality profile

   • 是否一致
   • 是否完整
   • 是否面向具体任务

3. verifiability profile

   • 是否有低歧义成功条件
   • 是否能构造可复现实验环境
   • 是否能以合理成本构造任务实例

直觉解释：

这一步相当于给 skill 做“准入审查”。否则一个写得漂亮但根本跑不起来、或者成功条件不可验证的 skill，会污染整个系统。

组件 3：从 skill 合成可验证任务

**做什么：**把静态 skill 描述转换成可实际跑 agent 的 benchmark task。

怎么做：

对通过 verifiability profile 的 skill，系统自动合成：

• clear instruction
• reproducible environment
• executable verifier

并采用 Harbor task format 运行真实 agent-model 组合，记录：

• success rate
• cost
• execution traces
• verifier outcomes

直觉解释：

如果不把 skill 落到任务和 verifier 上，你永远不知道一个 skill 是“写得好看”还是“真的有用”。

组件 4：task-conditioned skill recommendation

**做什么：**在真正求解任务前，决定 agent 应该看哪些 skill。

怎么做：

论文不是把整个 skill 库暴露给 solver agent，而是先走一个单独 recommendation stage：

• recommendation agent 先搜索本地 skill library；
• selectively 读取候选 SKILL.md 与相关资源；
• 只输出一小组和当前任务匹配、且环境可行、彼此互补的 skill；
• 还会附一个 compact usage guide 给 solver agent。

与现有方法的区别：

很多系统只看 metadata 或 top-k chunk；SkillsVote 更强调“先搜索文件库，再按任务条件暴露 skill”。

组件 5：subtask-level attribution

**做什么：**判断一次成功到底该归功于 skill、独立探索、还是环境偶然性。

怎么做：

论文反对两种极端：

• task-level summary 太粗，无法分配功劳；
• step-level extraction 太碎，提不出可复用 procedure。

它选择中间粒度：subtask。

一个 subtask 需要满足：

• 一个独立目标；
• 一个主要评价信号；
• 最多一个关联 skill context。

然后对每个 subtask 沿三条轴压缩证据：

1. outcome evidence：结果是否由环境反馈、人工判断或无显式信号支持；
2. responsibility assignment：成功主要来自 skill 引导、独立探索还是受无关 skill 干扰；
3. reusable delta：抽取真正可复用的 procedure / precondition / workaround / recovery pattern。

为什么重要：

因为 skill evolution 不是把轨迹整段塞回去，而是把真正值得保留的“经验增量”提炼出来。

组件 6：evidence-gated controlled evolution

**做什么：**决定哪些证据有资格改写长期 skill 库。

怎么做：

论文提出三步控制：

1. Admissibility

   • 只有“成功且包含可复用探索”的 unit 才能触发更新；
   • 失败、模糊或证据弱的 unit 只能做诊断，不能直接改库。

2. Aggregation

   • 多个支持同一 procedure / precondition / workaround 的 unit 合并；
   • 避免碎片化和重复编辑。

3. Routing

   • 如果证据是对已有 skill 的合理补强，就最小化编辑原 skill；
   • 如果是边界外的新能力，就创建新 skill；
   • 若证据弱、重复或语义不对齐，就跳过更新。

训练策略

这篇工作不是训练新模型，而是训练/组织一套治理流水线。实验配置的关键信息是：

• 基座模型：Codex with GPT-5.2 或 GPT-5.4 mini
• 终端基准：Terminal-Bench 2.0，共 89 个高难终端任务
• 代码基准：SWE-Bench Pro public，共 731 个长程软件工程任务
• 离线源数据：Terminal-Bench Pro 中 48 个公开软件工程/系统管理任务
• 离线演化频率：每 4 个任务触发一次 evolution，然后将冻结后的库迁移到 Terminal-Bench 2.0 做 recommendation-only 评估

与现有方法的关键区别

实验结果

主实验

相对提升：

• GPT-5.2 离线迁移：+7.9pp
• GPT-5.4 mini 离线迁移：+5.8pp
• GPT-5.2 在线 SWE-Bench Pro：+2.6pp
• GPT-5.4 mini 在线 SWE-Bench Pro：+2.1pp

解读：

• 最大增益来自离线 evolution，这说明历史任务提炼出的 skill 库可以跨任务分布迁移；
• 在线演化也有效，但更依赖早期证据质量；
• 在 Terminal Hard 子集上，GPT-5.2 在线甚至出现回退，恰好说明“skill 不是越多越好”，暴露错误 skill 会伤模型。

消融实验（Recommendation Ablation）

关键发现：

1. recommendation 的核心价值首先不是“多提一点正收益”，而是过滤 harmful exposure；
2. 离线库已经有价值，但 recommendation 还能继续提高 gain/loss balance；
3. 论文非常诚实地展示了 heavy-tailed effect：skill 匹配对时帮很大，匹配错时伤也很大。

可扩展性与案例分析

论文给了一个很有代表性的 transfer case：

• 源任务：Apache 网站配置
• 演化出的 skill：ubuntu-apache-vhost/SKILL.md
• 迁移目标：Git server 部署任务

演化后的 agent 并不是复制原解法，而是迁移“稳定 Apache 服务 + 持久配置 + 端到端验证”这类 execution invariants；基线则做了轻量 Node server，但缺乏持久服务与最终 runtime validation。

这说明 SkillsVote 保存的是 procedure，而不是答案模板。

SOTA 对照矩阵

复现评估

复现建议：

先别试图复制百万技能库。更现实的路径是：

1. 选一个小规模内部 skill library；
2. 先做 requirements / verifiability profile；
3. 再加一个 pre-task recommendation layer；
4. 最后才尝试 subtask attribution 与 evidence-gated evolution。

批判性分析

局限性（论文承认的 + 我们发现的）

论文自述与隐含局限：

1. skill utility 对任务域、环境和 skill 库质量高度敏感；
2. 并不是所有 skill 都适合被转成 verifiable task；
3. 在线演化早期证据不足时，收益不稳定。

我们额外发现的问题：

1. 论文的核心收益来自工程治理链，而不是新理论；很多团队会低估实现成本。
2. subtask attribution 的定义虽然比 task-level/step-level 更平衡，但仍带有系统设计者主观性。
3. benchmark 主要是 terminal / software engineering；对 GUI、多模态、开放世界 task 的外推还需要新实验。

改进方向

1. 更细的环境画像： 现在 requirements profiling 已经考虑 OS、权限、网络，但还可以加入成本、时延和风险等级。
2. 跨模态 skill 治理： 未来 agent 会读图、点网页、操控 GUI，skill package 应该不只包含文本和脚本。
3. 更强的人类审批链： 对会产生真实副作用的 skill update，应该引入 reviewer gate，而不只依赖 verifier。

独立观察（论文没说但我们注意到的）

• 这篇论文和最近三大厂重新强调 SKILL.md / agent harness 的方向高度同频；
• 它说明 skill 不是“锦上添花的小技巧”，而是 agent 平台里的长期资本；
• 如果未来 agent 平台普遍采用文件化 skill，谁掌握 skill 治理能力，谁就掌握 agent 长期学习的质量上限。

对领域的影响

我认为 SkillsVote 的长期价值不在于它今天多涨了几点 benchmark，而在于它把一个容易被忽略的问题制度化了：

当 agent 从一次性问答走向长期运行时，skills 会像代码、数据和模型一样，成为必须治理的生产资产。谁只会“多塞几个 skill 给 agent”，最后会被负迁移和知识污染反噬；谁能把 skill 的准入、曝光、归因和演化做成制度，谁才更有机会把 agent 做成可持续系统。