SkillsVote：从收集、推荐到演化的智能体技能生命周期治理 SkillsVote: Lifecycle Governance of Agent Skills from Collection, Recommendation to Evolution
为百万级 Agent Skill 生态构建一个采集-推荐-归因-演化的闭环治理框架，抑制噪声与误归因对技能库的污染。
前置知识
Agent Skills（智能体技能）
由 Anthropic 等社区推广的一种结构化可复用经验单元，以目录形式打包 SKILL.md（程序化指引）、scripts/（可执行脚本）、references/（参考文档）和 assets/（模板资源），并标注依赖边界与适用条件。比整段轨迹更紧凑，又比纯自然语言摘要保留更多可执行上下文。
本文核心治理对象就是这些 Skill 包；读者需要理解一个 Skill 既是文本指引也是目录级的可执行工件，才能跟上推荐和演化机制的讨论。
Long-horizon LLM Agent（长程智能体）
能在多轮决策中持续调用工具、操作外部环境（终端、文件系统、API）并依据反馈调整行为的 LLM 系统，例如在 SWE-Bench 修复真实代码仓库、Terminal-Bench 操作容器化命令行任务。任务跨度通常为数十到数百步。
SkillsVote 假设的任务流就来自这种长程 agent——只有在多步执行后才会有需要归因和蒸馏的完整轨迹。
Credit Assignment / 信用归因
在多步决策序列中判断最终成功或失败应该归功于哪一步、哪个工具调用、哪段指引的问题。粒度过粗（整个轨迹）则监督信号稀疏，粒度过细（单步）又难以聚合出可复用经验。
本文插入的 subtask 级归因正是为了解决这个粒度鸿沟，是论文方法部分的核心创新。
Harbor 评测框架
本文使用的开源 agent 评测框架，统一管理任务容器启动、agent 配置、trial 执行、verifier 运行与日志归档，并通过 trial-end hook 暴露给外部系统。
SkillsVote 把推荐、归因、演化三个阶段都挂到 Harbor 的 trial 生命周期上，理解这一点能看懂工程实现细节。
研究动机
长程 LLM agent 每天产生海量执行轨迹，但原始轨迹是糟糕的复用底料——它们冗长、噪声大、与本地环境强耦合，常常把稳健策略与偶发状态混在一起。当我们把这些轨迹封装成 Agent Skills（SKILL.md + scripts + references + assets 的目录工件）后，问题并没有消失，反而被放大到生态尺度：在 GitHub 上公开的 Skill 集市（如 SkillsMP、skills.sh）已经达到百万级，作者数量爆炸后内容高度冗余、质量参差、安全风险攀升，论文第 1 节明确引用了 130+ 高赞的讨论来佐证这一点。更大的 Skill 库虽然覆盖更广，却同时拉大了检索空间；先前 SkillsBench、SkillCraft 等基准已经证明，弱相关或写得很差的 Skill 会反向拖累 agent 表现。换言之，技能生态想要真正可用，关键不再是「如何写一个 Skill」，而是「如何治理一个持续膨胀的 Skill 库」——收集、治理、剖析、推荐、评估、演化必须被视作耦合过程，否则会出现两类典型失败：执行前被无关 Skill 干扰注意力，执行后被弱证据污染 Skill 库。
本文的目标是SkillsVote 提出了一个覆盖 collection、recommendation、attribution、evolution 四个阶段的 Skill 全生命周期治理框架，目标是在百万级开放 Skill 语料上同时实现三件事：1）执行前通过任务条件化的 agentic 检索，把少量相关、低冗余的 Skill 注入 solver 的上下文，而不是直接把整库暴露；2）执行后把轨迹分解为「subtask」这一中间粒度，把成功或失败归因到 skill-guided execution、agent exploration、environment、result signal 四类责任主体；3）只让带证据、可复用、来源清晰的发现进入 Skill 库更新，避免无差别写入污染库。
与已有工作不同的是，已有方法在三个层面各做一段：SkillRouter 用 0.6B 嵌入+重排模型做全库检索，但只解决「选哪个」不解决「库怎么变」；ReasoningBank、skill-creator 把整条轨迹蒸馏成高层策略或一条新 Skill，缺少归因层，于是常把环境带来的伪成功误归给 Skill；离线 Skill 演化系统（Voyager、ExpeL 等）多依赖轨迹级成功信号，监督稀疏且难以做信用分配。本文的关键切入角度是把「Skill 治理」当作一个跨四个阶段的可审计闭环，特别是把 subtask 级的归因层作为连接推荐与演化的中间枢纽——推荐决定暴露什么，归因决定什么证据可信，演化因此可以保守、局部、最小化地改写库。
核心方法
SkillsVote 把 Skill 视作生命周期工件，分四个阶段串联。预处理阶段从 GitHub 抓取 1,681,615 个 SKILL.md 包，先用 Anthropic 官方 quick_validate 脚本做格式校验，再按 SKILL.md 内容哈希去重，然后调用 Claude Code（仅授予 Grep/Glob/Read/StructuredOutput 工具）为每个 Skill 生成运行期画像（OS、写权限、依赖 MCP/CLI/环境变量）、质量画像（一致性、完整性、面向任务性）和可验证性画像（成功可验证、环境可控、任务可构造），最终留下约 187K 高质量 Skill，并基于「verifiability=true 且三维度皆 true」自动合成 Harbor 格式任务。运行时阶段分为三步：第一步是 pre-task recommendation，solver 启动前由一个独立 agent 用文件系统原生工具（Grep/Glob/Read）在候选库中搜索、阅读候选 SKILL.md，输出至多 top_k 个 Skill 名称加一段压缩使用指南；第二步是 in-task execution，solver 在注入的 Skill 上下文与 compressed guide 引导下完成原始任务；第三步是 post-task attribution + controlled evolution，Harbor trial-end hook 触发后，attribution agent 通过 Codex resume 恢复原会话上下文，把整条轨迹拆成若干 subtask，每个 subtask 标记 judge 类型（environment/human/unknown）、attribution 类型（含 success_skill_used_with_extra_exploration、fail_*、uncertain_* 等十余类）、skill_linked 与具体 skill_refs 行号；attribution 后的 subtask 通过 admissibility（必须成功且 exploration 非空）、aggregation（同 Skill 的多条证据合并为一个 edit 请求）、routing（决定是 edit 现有 Skill 还是 create 新 Skill 或 skip）三道闸门，最终只让带证据、可复用、来源清晰的发现进入 Skill 库。
核心创新是把「subtask」作为可演化的基本单元，夹在完整轨迹（粒度太粗、监督稀疏）和单步工具调用（粒度太细、无法聚合为可复用经验）之间。一个 subtask 必须满足「单一独立目标 + 单一主要评估信号 + 至多一个相关 Skill 上下文」，并沿 outcome evidence、responsibility assignment、reusable delta 三条轴压缩为可演化的最小证据单元。这让系统能够精准区分「成功是因为 Skill 真的帮上了忙」「成功是 agent 自己摸索出来的」「失败是 Skill 自身有 bug」「失败是环境问题」四种责任，并据此决定该不该改库、改哪个 Skill。这一粒度的插入与基于归因的三道闸门控制（admissibility / aggregation / routing）共同构成本文与已有 self-evolution 系统的本质区别：ReasoningBank 直接蒸馏整条轨迹，skill-creator 用单一 prompt 让 agent 把完成后的轨迹转成 Skill，两者都没有归因层，因此会写入来自环境或评估信号的伪证据。
方法步骤详情
方法完整执行流程如下：(1) Corpus 收集与剖析——从 GitHub 抓取 1.68M SKILL.md，依次经过格式校验（保留 794,617，约 47.2%）、内容哈希去重（保留 291,092）、质量与可验证性画像（保留 187,292 高质量子集）；剖析 prompt 三段：Task 1 环境分析（os/write_scope/privilege/externality/envs/bins/mcps + 3-5 句 justification）、Task 2 质量评估（consistency/completeness/orientation 三布尔）、Task 3 可验证性评估（success_verifiability / environment_controllability / task_constructability 三布尔）；输出 SkillEnvironmentRubric + SkillQualityRubric + SkillVerifiabilityRubric + 类别（DataAndAI/Development/Testing/DevOps/AgentMeta/ProfessionalDomainKnowledge/NaturalScienceKnowledge/Tools 多标签）。(2) 任务合成——对通过 verifiability 的 Skill，由 Claude Code 生成 Harbor 格式的 task instruction + Dockerfile + verifier，给真实 agent 执行并记录成功率、成本、轨迹。(3) 推荐——solver 启动前启动一次独立 Codex 0.125.0 进程，cwd 设为只读候选 Skill 根，禁用 web search / built-in skills / plugins / writes，使用专门的 system prompt（见附录 G.2），用 Grep/Glob/Read 做文件系统原生搜索，输出严格符合 schema 的 JSON：skill_names (list[str]) 与 optimized_context (str)；输出验证失败或重试 3 次仍无有效输出时回退为注入所有候选 Skill。(4) 执行——Solver agent 在注入 Skill 与 compressed guide 之后按正常 Codex 流程跑任务，全过程 JSON logging。(5) 归因——trial-end hook 触发后，attribution 阶段通过 Codex resume 恢复原 session（保留原生上下文与加密的 chain-of-thought），追加 user prompt 包含当前可见 Skill、当前工作路径与 verifier 反馈（online 模式只给任务级 test counts，offline oracle 模式额外给 solution / verifier tests / verifier stdout 的路径，但仍禁止把 gold answer、私有常量、canary 字符串蒸馏进 reusable exploration），输出 subtasks 列表，每个 subtask 含 goal/summary/exploration/judge(environment/human/unknown)/attribution（十余类枚举）/skill_linked/skill_refs(file_path+start_line+end_line+capability+used_for)。(6) 演化——subtask 先经 admissibility 过滤（exploration 非空 且 attribution ∈ {success_viewed_skill_but_not_used, success_no_skill_seen, success_skill_used_with_extra_exploration}），然后按 attribution 聚合：success_skill_used_with_extra_exploration 且 skill_linked 非空 → 按 skill 名分组形成 edit 请求，每个 edit 对应一个老 Skill；其余成功的无关联 Skill 的探索 → 形成 create 请求；编辑前自动用 batch timestamp 备份老 Skill 到运行库。create 用 create prompt，edit 用 edit prompt，两者均使用 StructuredOutput 输出 action_type (error_fix / knowledge_addition / prerequisite_addition / create_skill / skip) + rationale + summary + skill_dir_path。
技术新颖性
技术新颖性体现在三处。第一，subtask 中间粒度的形式化定义与自动化构造是首创：以往 trajectory-level 监督太粗、step-level 监督太碎，本文以「单目标 + 单评估信号 + 至多一个 Skill 上下文」作为切分边界，并允许 subtask 跨多个原始 step，这把 credit assignment 从启发式规则提升为可审计 schema。第二，把 attribution 升级为演化准入控制而非事后分析：admissibility/aggregation/routing 三道闸门形式化为可控策略，agent 在演化阶段只能拿到通过闸门的 subtask，因此无法把环境伪成功写入 Skill 库，这种保守设计在 self-evolution 类系统中并不常见。第三，把文件系统原生工具（Grep/Glob/Read）作为 Skill 检索的通用接口，区别于 SkillRouter 的双塔嵌入+重排（0.6B）、DCI 的语料交互、RAG 的 top-k chunk；GPT-5.5 xhigh 仅靠文件系统原生操作就在 79,141 Skill 库上拿到 FC@10 62.7，比 SkillRouter 46.7 高出 16 个百分点，且单查询平均 API 成本仅 0.158 美元、不随库规模线性增长。
实验结果
Table 1（Terminal-Bench 2.0，89 题）显示，在三个模型档（GPT-5.2 medium / GPT-5.4 mini medium / GPT-5.5 xhigh）下，SkillsVote 的在线演化设置平均准确率分别为 53.7 / 52.8 / 80.7，相对无 Skill 基线提升 +2.6 / +1.1 / +0.9 个百分点，并在六组（benchmark × backbone）配置中全部是最优或并列最优的在线方法。离线 TB-Pro 库迁移到 Terminal-Bench 2.0 表现最强，分别提升 +7.8 / +5.8 / +1.4 pp；而离线 Curated 库（10K 高质量 GitHub Skill）对 GPT-5.5 甚至掉点 -1.7 pp，提示历史轨迹衍生的 Skill 比通用开源 Skill 在该基准上迁移性更好。Table 2（SWE-Bench Pro public，731 题，覆盖 11 个开源仓库）显示，SkillsVote 在线 avg@1 Resolve Rate 为 50.3 / 49.5 / 59.6，相对无 Skill 基线提升 +2.7 / +2.6 / +1.2 pp。GPT-5.4 mini 上的 ReasoningBank (+2.1) 和 skill-creator (+2.3) 也有可观提升，但在 GPT-5.5 上都掉到 -2.5 / -2.6 pp，说明它们对强模型反而产生负迁移；离线 Curated 库只在 GPT-5.4 mini 上得到 +1.5，在 GPT-5.2 / GPT-5.5 上分别 -3.4 / -2.3，再次证实通用开源 Skill 库在大型仓库上的迁移性不稳定。Table 3 把 Skill 路由问题隔离出来比较，在 SkillRouter 公开的 79,141 Skill 难题集上 GPT-5.5 xhigh 拿 Hit@1 70.7 / R@10 74.2 / FC@10 62.7，单查询成本 0.158 美元，相对 SkillRouter（双塔嵌入+重排基线）的 65.3 / 67.2 / 46.7，FC@10 提升 16 个百分点；图 4 显示 SkillsVote 的 FC@10 在 1k–79,141 全程稳定高于 SkillRouter，且成本几乎不随库规模变化，GPT-5.4 mini 在 50k 与全库上掉到 52.0 / 34.7，提示小模型在大且易混的库上仍依赖底座能力。图 5 显示推荐机制对负迁移的控制：直接暴露 online 库时任务级平均 Δ 贡献为 +3.3 / -6.7（损失大于收益），引入推荐后转为 +6.0 / -6.0（持平），离线库上由 +11.3 / -3.3 改善为 +15.3 / -2.0，这说明「库怎么变」和「暴露什么给当前任务」是互补环节。图 6 表明离线演化跨 checkpoint 把 Terminal-Bench Pro 的轨迹逐步沉淀为可迁移到 Terminal-Bench 2.0 Hard 的 Skill 库，库大小在第 3→12 步从 ~10 增加到 ~45，且 created + edited 双通道都在持续工作；与此同时 Terminal-Bench Pro 自身表现非单调，说明库效用与源任务表现可以解耦。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Terminal-Bench 2.0（89 题，4 Easy / 55 Medium / 30 Hard） | avg@5 Accuracy | GPT-5.2 medium 53.7 (+2.6)；GPT-5.4 mini medium 52.8 (+1.1)；GPT-5.5 xhigh 80.7 (+0.9)；离线 TB-Pro 迁移：58.9 / 57.5 / 81.2 (+7.8 / +5.8 / +1.4)；离线 Curated：54.8 / 55.7 / 78.1 (+3.7 / +4.0 / -1.7) | 无 Skill 基线 51.1 / 51.7 / 79.8；ReasoningBank 52.1 / 50.6 / 77.7；skill-creator 53.7 / 47.6 / 78.8 | 相对无 Skill 基线 GPT-5.2 提升 +2.6 pp、GPT-5.4 mini 提升 +1.1 pp、GPT-5.5 提升 +0.9 pp；强模型上在线方法出现明显分化（GPT-5.5 下 ReasoningBank / skill-creator 分别 -2.1 / -1.0 pp，而 SkillsVote 仍 +0.9 pp）；离线 TB-Pro 是最强迁移设置，对 GPT-5.2 累计提升 +7.8 pp。 |
| SWE-Bench Pro public（731 题，覆盖 11 个 GPL 仓库，含 ansible/openlibrary/qutebrowser/flipt/teleport/vuls/navidrome/webclient/element-web/NodeBB/tutanota） | avg@1 Resolve Rate | SkillsVote 在线：50.3 / 49.5 / 59.6 (+2.7 / +2.6 / +1.2)；离线 Curated：44.2 (-3.4) / 48.4 (+1.5) / 56.1 (-2.3) | 无 Skill 基线 47.6 / 46.9 / 58.4；ReasoningBank 47.7 / 49.0 / 55.9；skill-creator 48.6 / 49.2 / 55.8 | SkillsVote 在三个模型档全部优于无 Skill 基线和两种在线基线；离线 Curated 库在 GPT-5.2 / GPT-5.5 上出现 -3.4 / -2.3 pp 退化，揭示通用开源 Skill 库在大型真实仓库上易产生负迁移。tutanota 仓库（20 题）在所有模型档均为 0%，可能与体量过小或任务分布有关。 |
| SkillRouter 公开路由基准（75 查询，79,141 Skill 含 780 LLM 生成 distractors） | Hit@1 / R@10 / FC@10 / 单查询成本（美元） | GPT-5.5 xhigh 70.7 / 74.2 / 62.7 / 0.158；GPT-5.4 xhigh 65.3 / 66.1 / 54.7 / 0.090；GPT-5.4 mini xhigh 52.0 / 48.0 / 34.7 / 0.076 | SkillRouter（0.6B 嵌入+重排）65.3 / 67.2 / 46.7 / - | GPT-5.5 下 FC@10 提升 +16 pp、Hit@1 提升 +5.4 pp；GPT-5.4 下 FC@10 提升 +8 pp；GPT-5.4 mini 在 1k-10k 区间仍领先 SkillRouter（89.3 / 78.7 / 81.3 / 74.7 的 Hit@1 vs 84.0 / 81.3 / 77.3 / 76.0），但 50k 与全库掉到 60.0 / 52.0，提示能力下限决定大库路由上限。 |
局限与改进
作者在第 4 节诚实地指出几条限制。第一，平均提升幅度「温和」是 skill 重尾分布的直接后果——Table 1/2 显示 max 单点提升可达 +10 量级（如 TB-Pro→TB2.0 Hard GPT-5.4 mini +13.3 pp），但分布偏斜使得总体平均被低改善任务拉低。第二，推荐机制虽然把负迁移从 -6.7 降到 -6.0（持平），仍存在 -6 pp 量级的尾部损失，并未完全消除；图 5 显示在 Hard split 上均值收益与损失仍是大致对称。第三，离线 Curated 库（10K 开源 Skill）对强模型在两个 benchmark 上都出现负迁移，作者解释为通用 Skill 噪声被强模型更敏感地捕捉。第四，GPT-5.4 mini 在 50k+ 库上路由性能显著下滑，提示推荐质量高度依赖底座模型能力，跨能力档的鲁棒性不足。从我自己的观察看，文中所有评估均基于 Codex CLI 0.125.0 + OpenAI GPT-5.x 系列，没有跨厂商模型（Claude、Gemini、国产模型）的迁移证据；attribution 阶段的 Codex resume 依赖商业模型的会话恢复能力，对开源模型不一定适用；TB-Pro → TB-2.0 的迁移只跑了一个 historical pass，离线演化的「饱和点」尚未探明；推荐阶段用文件系统原生工具这一选择在 1k 库上平均成本 $0.143、全库 $0.158，几无增长，但论文未披露 wall-clock 时延，强弱模型之间单查询耗时差异也可能成为瓶颈。
独立分析的弱点
独立分析有四点可改进之处。第一，subtask 的「单目标 + 单评估信号 + 至多一个 Skill 上下文」三边界由 LLM 判断，没有可量化的边界一致性指标，建议引入两次独立抽取 + inter-annotator agreement（或对同一轨迹用不同温度采样计算 subtask 边界稳定性）。第二，归因虽然区分了 success_skill_used_with_extra_exploration 等四类成功，但「成功」仍依赖 verifier pass/fail 或 task-level test counts，缺少数值化贡献度（如 skill-guided action 在最终 reward 中的实际边际），改进方向是给每个 subtask 加一个 0-1 的「skill 利用强度」连续评分，让 editable 阈值可调。第三，推荐阶段 top_k 固定，附录 C.1 没有报告对 top_k 的消敏度，建议补充 top_k ∈ {3, 5, 10, 20} 的扫描，以验证「少而准」是收益主因。第四，演化只在成功且 reusable exploration 的 subtask 上触发，但 reusable 的判定完全依赖 LLM 自由文本，存在把任务特定常量误判为通用经验的风险，改进方向是显式增加「环境特定常量黑名单」（如端口号 9090、路径 /srv/www）让 reusable 抽取可拒绝。
未来方向
作者在第 5 节暗示的方向包括：把 Skill 治理推向跨厂商多模型、把 Skill 库作为可审计工件集成进 agent harness、把 online + offline 两条路径拼成持续学习的「治理操作系统」。基于本文结果还可以延伸几个方向：1）把百万级库进一步按 task 分布做谱分解，引入任务族级别的「Skill bundle」推荐而非单 Skill 推荐；2）subtask 粒度归因可推广到 RL 训练中的过程奖励建模，把 Skill 更新与策略更新耦合；3）归因层的 attribution reason 可作为 Skill 的「使用案例」自动反哺 SKILL.md 的 description 字段，形成 Skill 自描述的反馈循环；4）跨基准迁移目前只做了 Terminal-Bench Pro → Terminal-Bench 2.0，未来可以测更多跨域迁移（如 SWE-Bench → Terminal-Bench），衡量 Skill 是否真的具备环境无关的可执行性；5）当前推荐阶段完全依赖 GPT-5.x，可考虑蒸馏一个 7B 级别的 Skill Router 替代高成本模型，并设计端云混合的本地 fallback。
复现评估
复现评估整体偏正面。代码与数据已开源：官网 skills.vote，GitHub MemTensor/skills-vote。Skill 语料源自 GitHub 公开 SKILL.md，作者承诺开放高质子集（约 187K）。所有实验统一基于 Harbor 评测框架 + Codex CLI 0.125.0 + 三组 (model, effort) 配置（GPT-5.2 medium / GPT-5.4 mini medium / GPT-5.5 xhigh），附录 C 详细记录了 Docker 镜像预构建、retry 策略（最多 3 次，仅对环境性失败）、超时（4× 默认）、closed-network 评测设置。Terminal-Bench 2.0 报告 avg@5（5 次独立运行），SWE-Bench Pro 报告 avg@1（单次），均符合对应 leaderboard 协议。复现难点在于：a）依赖 OpenAI GPT-5.x 系列商用模型，无开源等价替代，论文也未提供 Claude/Gemini 上的迁移数据；b）attribution 用 Codex resume 恢复加密 chain-of-thought，开源模型不一定支持同等机制；c）百万级 Skill 库的剖析基于 Claude Code 调用 Claude Agent SDK（仅 Grep/Glob/Read/StructuredOutput 工具），这意味着复现需具备 Claude API 访问权限；d）GPT-5.5 在 Terminal-Bench 2.0 上有 4 题被 OpenAI cyber-risk review 屏蔽，论文显式排除这 4 题以保证比较公平——复现者需注意对齐筛选集合；e）TB-Pro → Terminal-Bench 2.0 离线演化只跑了一次 pass，checkpoint 间的方差未披露，建议复现时跑 ≥3 次取平均。总体而言，工程实现细节非常充分，主要门槛是 API 与算力成本。
论文图表
