Paper Notes

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

作者Hongyi Liu, Haoyan Yang, Tao Jiang, Bo Tang, Feiyu Xiong, Zhiyu Li
机构MemTensor (Shanghai) Technology
发表arXiv preprint · 2026
参考论文: arxiv.orgGitHub

24分钟阅读

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

Paper: arXiv:2605.18401 Code: MemTensor/skills-vote Code reference: main @ 86fd7391 (2026-05-19)

1. Motivation (研究动机)

当前方法的问题

长程 LLM Agent 的执行轨迹包含大量可复用经验：命令、工具调用、环境反馈、失败恢复、依赖安装、验证方式等。但论文指出，raw trajectories 不是一个可治理的长期记忆载体：它们很长、噪声大、绑定具体环境，且会把真正稳健的操作策略与偶然状态、一次性常量、重复试错混在一起。直接把轨迹塞回上下文会带来两类风险：一是检索到的无关经验干扰当前任务；二是把弱证据或错误归因的经验写入技能库，污染未来上下文。

Agent Skills 比普通摘要更适合作为经验 schema，因为一个 skill 可以同时包含程序化 guidance、脚本、模板、references、依赖边界和适用条件；但开放技能生态已经接近 marketplace scale，SKILL.md 的名称、描述、热度或安装量并不能说明它是否能在目标环境运行、是否有完整资源、是否有明确 success condition、是否可被 verifier 检查。SkillsMP / skills.sh 这类生态解决了“收集与发现”，没有解决“运行前如何选择”和“运行后如何安全更新”。

论文要解决的具体问题

SkillsVote 要解决的是 Agent Skill 的全生命周期治理：从开放技能库收集、技能画像 profiling、任务前 recommendation，到任务后 attribution 和 evidence-gated evolution。它不是训练一个新模型，而是在 frozen agent 外部构造一个可搜索、可审计、可演化的 skill library，让技能在进入上下文和写回库之前都经过控制。

为什么值得研究

如果这个问题解决，Agent 可以把每次长程工具任务产生的操作证据转化为长期可复用技能，而不是一次性日志；更重要的是，这个过程不需要更新模型参数。论文在 Terminal-Bench 2.0 和 SWE-Bench Pro 上展示：受控的外部技能库能给 frozen Codex/GPT backbone 带来可测收益，同时 recommendation 可以减少负迁移，evolution 可以积累跨任务 transferable procedures。

换句话说，这篇论文关注的是 Agent 系统里的“经验供应链”：经验从哪里来、什么时候进入上下文、如何判断它真的帮助了任务、以及什么证据足以修改共享技能库。这个问题比单次任务求解更系统，因为 skill 一旦写入库就会影响后续许多任务；错误 skill 或过度泛化的 skill 不是一次失败，而是会持续增加未来任务的搜索成本和误导风险。

论文选择 Terminal-Bench / SWE-Bench Pro 作为验证场景也符合这个动机：这些任务的“经验”通常表现为可执行操作链，而不是一个可背诵的事实。比如服务配置、依赖安装、端口验证、repo-specific debugging 都需要在后续任务中被有条件地复用。

2. Idea (核心思想)

SkillsVote 的核心 insight 是：skill library 不应被当作静态检索库，而应被当作有生命周期的经验系统。运行前，技能要“投票进入”solver context；运行后，执行证据也要“投票进入”skill library。两次投票分别控制 exposure 和 preservation。

具体创新是把生命周期拆成四个受控阶段：收集 million-scale SKILL.md corpus 并做 execution-readiness profiling；用 agentic library search 选择少量 task-conditioned skills；把执行轨迹压缩为 subtask-level attribution units；只允许成功、可复用、归因清楚的 evidence 触发 edit/create/skip 类型的技能演化。

与只做 semantic top-k skill retrieval 的方法相比，SkillsVote 让 recommender 像 agent 一样在文件系统技能库中搜索和读取候选 skill；与直接从成功轨迹提炼经验的方法相比，它引入 subtask-level attribution 和 conservative routing，避免把整条 trajectory 或单个 tool call 直接变成持久技能。

更细地说，SkillsVote 把“检索”和“学习”都改写成带约束的治理问题。检索侧，它不问“哪些文本片段语义最像当前任务”，而问“哪些完整 skill package 在当前环境下可用、互补、低冗余，并且值得暴露给 solver”；学习侧，它不问“这条成功轨迹能总结出什么”，而问“哪一个 subtask 的成功有明确 evidence，是否归因到已有 skill，新增知识是否跨任务可复用，以及应该 edit 旧 skill 还是 create 新 skill”。

因此它与传统 RAG/SkillRouter 的差异不只在检索器形式，而在更新边界：SkillRouter 主要决定 runtime 该读什么，SkillsVote 还决定哪些执行证据可以改变 persistent skill artifacts；与 Reflexion/经验池式方法相比，它不是把自然语言反思直接加入记忆，而是要求 evidence、attribution、reusable delta 和 action type 同时成立。

“Vote”这个名字可以理解为双向筛选机制：skill 在任务前通过 recommendation 竞争上下文席位；execution evidence 在任务后通过 attribution 和 reusable-exploration gate 竞争写入库的资格。

3. Method (方法)

3.1 整体框架：技能进入上下文前后都要被治理

Figure 2 解读：图中闭环分为 pre-task recommendation、in-task execution evidence、post-task attribution 和 controlled library evolution。左侧的 profiled skill library 在任务开始前被搜索，只有少量相关技能和压缩 usage guide 进入 solver context；任务结束后，轨迹和结果信号被拆成 skill-linked subtasks，再决定哪些探索能编辑旧 skill 或创建新 skill。这个设计的关键不是“多存经验”，而是控制经验何时被暴露、何时被保留。

直觉上，SkillsVote 把技能库看成一个外部、可版本化的 operational memory。推荐阶段解决“当前任务应该读哪些技能，避免上下文噪声”；归因阶段解决“成功到底来自 skill、agent 自己探索、环境偶然性还是 verifier 信号”；演化阶段解决“哪些发现足够稳定，可以成为未来任务的 persistent procedure”。因此它特别适合 Tool-Use Agent：这类任务的价值往往不在最终文本答案，而在环境操作、依赖边界、验证路径和故障恢复流程。

3.2 Open-source skill corpus 与 profiling

SkillsVote 从 GitHub 上的 SKILL.md 文件构建 million-scale open-source Agent Skill corpus。论文强调它不是把 skill 当作一个文本 chunk，而是把整个目录当作 package：必需的 SKILL.md 描述能力和使用条件，scripts/、references/、assets/ 保存可执行代码、支撑文档和模板。

Profiling 有三条主线：

  • Runtime requirement profile：估计 OS 假设、写权限、sudo、网络、API key、CLI tools、MCP servers、环境变量等运行条件。
  • Quality profile：判断 skill 是否是稳定执行单元，关注 consistency、completeness、task orientation。
  • Verifiability profile：判断是否有低歧义 success condition、可复现实验环境、可用合理成本构造 task instance。

通过 verifiability profile 的 skill 会被合成为 Harbor task：每个 task 包含明确 instruction、可复现 environment 和 executable verifier。系统再用真实 agent-model combination 运行这些任务，记录 success rate、cost、execution trace 和 verifier outcome。论文也明确限制：preference-driven、open-world 或 hardware-intensive skills 不会被强行转成 benchmark task，只保留为 profiled corpus item。

推荐阶段不是让 solver 直接解决任务，而是让单独的 recommender agent 搜索本地 skill library、选择性读取候选 SKILL.md 和相关资源，输出少量 exposed skills 与短 usage guide。它区别于 metadata-only routing 或 fixed top-k retrieval：推荐器可以用文件系统工具迭代搜索、打开候选、比较环境适配性和技能互补性。

Released code 中，src/skills_vote/recommend/model.py 将输出 schema 固定为 skill_names: list[str] 与 optimized_context: str；src/skills_vote/recommend/codex.py 的 step_recommend 会生成 recommendation.schema.json、构造 system/user prompt、以 skills_dir 为工作目录调用 Codex CLI，并用 RecommendOutput.model_validate_json(...) 校验结构化输出。这个 recommendation record 也成为后续 attribution 的锚点：任务结束后可以检查被暴露的 skill 是否真的被读取、是否贡献了可复用探索。

async def recommend_skills(agent, task_instruction, recommend_config, env):
    skills_dir = recommend_config.skills_dir
    recommendation_dir = agent.logs_dir.parent / "recommendation"
    schema_path = recommendation_dir / "recommendation.schema.json"
    schema_path.write_text(RecommendOutput.model_json_schema())
 
    prompt = build_prompt_template(
        recommend_config.prompt_path,
        instruction=task_instruction,
        skills_dir=str(skills_dir),
        default_top_k=recommend_config.default_top_k,
    )
    raw_json = await run_codex_cli(
        cwd=skills_dir,
        prompt=prompt,
        output_schema=schema_path,
        output_path=recommendation_dir / "recommendation.json",
    )
    output = RecommendOutput.model_validate_json(raw_json)
    return output.skill_names, output.optimized_context

3.4 Subtask-level attribution：介于整条任务和单步工具调用之间

Figure 3 解读：左侧 task-level summary 太粗，只知道整题成功或失败，无法判断哪段操作贡献了可复用经验；右侧 step-level extraction 太碎，一个命令通常不足以成为 skill；中间的 SkillsVote 方案把轨迹切成 subtask，每个 subtask 有独立目标、主要 evaluation signal 和最多一个关联 skill context，从而既能做 credit assignment，又能保留过程知识。

论文把 subtask 定义为支持 library evolution 的最小语义完整单元：它有一个 standalone objective、一个 primary evaluation signal、最多一个 associated skill context。轨迹只在三类边界变化时切分：目标变化、主评估信号变化、关联 skill context 变化，而不是每个 tool call 都切一次。

每个 subtask 的 attribution 压缩成三组字段：

  • Outcome evidence：环境反馈、人类偏好、无明确信号，防止 verifier-backed outcome、主观目标和 unsupported claim 被同等对待。
  • Responsibility assignment：成功可能来自 skill-guided execution、independent exploration、看到无关 skill 后的探索；失败或不确定 subtask 只做诊断证据，不直接授权演化。
  • Reusable delta：只抽取确实影响执行的 skill knowledge 与可复用发现，如缺失步骤、precondition、recovery pattern；丢弃普通 trial-and-error、任务特定常量和重复操作。

可把 released code 的 gating 形式化为： 这里 是 subtask。若 的 attribution 不在三类成功探索集合内，或没有 exploration 字段，代码不会生成 evolution request。

代码中的成功归因枚举与演化动作可以直接读成下表：

Code enumMeaning in noteDefault route
success_viewed_skill_but_not_usedAgent 看过 skill，但成功路径主要不是它塑造的create request
success_no_skill_seenAgent 没看 skill，靠独立探索完成 subtaskcreate request
success_skill_used_with_extra_explorationAgent 依赖了 skill，但通过额外探索补足成功路径edit linked skill if skill_linked exists; otherwise create
fail_skill_issue / fail_agent_limit / fail_client_env / fail_external_env / fail_unknown_env失败归因skip
uncertain_human_judge_required / uncertain_environment_judge_inconclusive / uncertain_no_judge证据不足或需要人类判断skip

Released code 的 feedback schema 位于 src/skills_vote/feedback/model.py：Judge 只能是 environment、human、unknown；Attribution 包含三类成功、四类失败和三类不确定。step_feedback 位于 src/skills_vote/feedback/codex.py，它收集 verifier test-case counts、可用 skills、可选 ground truth、Codex session 文件，再输出 feedback.json。

def attribute_execution(result, trial_dir, config):
    feedback_dir = trial_dir / "feedback"
    ground_truth = prepare_ground_truth_dir(result, trial_dir, feedback_dir) \
        if config.feedback_include_ground_truth else None
 
    total, passed, failed = extract_test_case_counts(
        result,
        trial_dir,
        config.feedback_verifier_summary_extractors,
    )
    prompt = build_prompt_template(
        config.feedback_prompt_path,
        cwd=str(feedback_dir),
        available_skills=format_available_skills(config.agent_skills_dir),
        ground_truth_context=format_ground_truth_context(ground_truth),
        num_total_test_cases=total,
        num_passed_test_cases=passed,
        num_failed_test_cases=failed,
    )
    feedback = run_codex_with_schema(prompt, FeedbackOutputPayload)
    return FeedbackPayload(subtasks=attach_paths_and_skill_refs(feedback.subtasks))

3.5 Evidence-based controlled skill evolution

Figure 4 解读：图中展示了从 raw trajectory 到 structured subtasks，再到 edit/create/skip 的路由。只有 successful subtasks 且满足 attribution 与 reusable-exploration gate 时，才会触发技能编辑或新建；外部环境失败、证据不足或不可复用探索会被 skip。示例中 next-js 技能因为 CORS/proxy 发现被最小编辑，visual-style 属于无旧 skill 的独立探索而创建新 skill，Vercel 外部环境/API 问题则不写入技能库。

演化阶段有三步：

  1. Admissibility：只有 successful 且包含 reusable exploration 的 unit 可以触发演化；failed、uncertain、weakly supported evidence 只保留诊断价值。
  2. Aggregation：支持同一个 reusable procedure、precondition、workaround 或 correction 的 units 会先合并，避免重复或碎片化编辑。
  3. Routing：如果证据扩展了真正影响执行的旧 skill，则做最小 justified edit：error_fix、knowledge_addition 或 prerequisite_addition；如果证据是旧 skill 边界外的独立能力，则 create_skill；如果证据弱、重复或语义不匹配，则 skip。

Released code 中，src/skills_vote/evolve/model.py 的 feedback_to_evolve_requests 实现了论文中的路由：success_skill_used_with_extra_exploration 且 skill_linked 非空会按 linked skill 聚合为 edit request；其他成功探索进入 create request；失败和不确定 attribution 不产生 request。src/skills_vote/evolve/codex.py 的 step_evolve 为每个 request 建运行目录和 schema，调用 Codex 生成 EvolveOutput，然后把 edit 结果复制回 working_skills_dir，把 create_skill 结果复制成新 skill 目录。

def build_evolve_requests(feedback_payload):
    edit_subtasks = defaultdict(list)
    create_subtasks = []
 
    for subtask in feedback_payload.subtasks:
        if subtask.exploration is None:
            continue
        if subtask.attribution not in EVOLVABLE_ATTRIBUTIONS:
            continue
        if subtask.skill_linked and subtask.attribution in EVOLVE_EDIT_ATTRIBUTIONS:
            edit_subtasks[subtask.skill_linked].append(subtask)
        else:
            create_subtasks.append(subtask)
 
    requests = []
    if create_subtasks:
        requests.append(EvolveRequest(
            request_dir_name="create_request",
            subtasks=create_subtasks,
        ))
    for skill_name, subtasks in edit_subtasks.items():
        requests.append(EvolveRequest(
            request_dir_name=f"edit_{skill_name}",
            target_skill_name=skill_name,
            subtasks=subtasks,
        ))
    return requests
async def evolve_skill_library(config, output_dir, requests):
    run_root = output_dir / "evolve"
    working_skills_dir = Path(config["working_skills_dir"])
    backup_dir = Path(config["skill_backup_dir"])
 
    for request in requests:
        prompt = build_evolve_prompt(
            prompt_path=config["evolve_prompt_path"],
            request=request,
            working_skills_dir=working_skills_dir,
        )
        evolve_output = await run_codex_with_schema(prompt, EvolveOutput)
        write_evolution_log(run_root, request, evolve_output)
 
        for action in evolve_output.actions:
            if action.action_type in {{"error_fix", "knowledge_addition", "prerequisite_addition"}}:
                backup_skill(action.target_skill_name, working_skills_dir, backup_dir)
                copy_edited_skill_back(action.target_skill_name, run_root, working_skills_dir)
            elif action.action_type == "create_skill" and action.skill_dir_path:
                copy_created_skill_dir(action.skill_dir_path, run_root, working_skills_dir)
            else:
                continue
    return run_root

3.6 Harbor 集成：把推荐、反馈、演化挂到实验流水线

src/skills_vote/harbor/hooks.py 把 feedback 与 evolve 接到 Harbor trial lifecycle。_step_feedback 根据 agent_kind 选择 Codex 或 Claude Code 实现；_run_evolve_batch 会读取 pending feedback，调用 aggregate_feedback_payloads 与 feedback_to_evolve_requests，如果没有 evolvable subtasks 就写 skipped marker，否则调用 _step_evolve。这对应论文中的 online evolution：任务流中每完成若干 trial，就用已归因证据更新 working_skills。

async def harbor_evolve_after_trials(records, config, trigger_trial_dir):
    feedback_payloads = load_pending_feedback(records)
    aggregated = aggregate_feedback_payloads(feedback_payloads)
    requests = feedback_to_evolve_requests(aggregated)
    if not requests:
        write_skipped_evolution_root(trigger_trial_dir)
        return None
 
    run_root = await step_evolve(
        skills_vote_config=config,
        output_dir=trigger_trial_dir,
        requests=requests,
    )
    write_evolve_feedback_index(records=records, run_root=run_root)
    return run_root

论文公式与 released code 实现差异：论文没有提出可训练 neural loss，而是把目标定义为 lifecycle governance policy；released code 将这些 policy 落到 Pydantic schema、structured Codex output、attribution 枚举和 action routing。当前检查未发现正文 Table 3/4/5 的 judge、attribution、action 类型与代码枚举存在语义冲突；代码额外把 success_skill_used_with_extra_exploration 细分为可 edit 的唯一成功归因，其余成功探索默认进入 create request。

Code reference: main @ 86fd7391 (2026-05-19) — pseudocode and mapping based on this commit

Paper ConceptSource FileKey Class/Function
Agentic skill recommendationsrc/skills_vote/recommend/codex.pystep_recommend
Recommendation output schemasrc/skills_vote/recommend/model.pyRecommendConfig, RecommendOutput
Post-task attribution / feedbacksrc/skills_vote/feedback/codex.pystep_feedback
Judge and attribution schemasrc/skills_vote/feedback/model.pyJudge, Attribution, FeedbackOutputSubtask, FeedbackPayload
Evidence-to-request routingsrc/skills_vote/evolve/model.pyEVOLVABLE_ATTRIBUTIONS, EVOLVE_EDIT_ATTRIBUTIONS, feedback_to_evolve_requests
Skill edit/create executionsrc/skills_vote/evolve/codex.pystep_evolve
Harbor online evolution hooksrc/skills_vote/harbor/hooks.py_step_feedback, _run_evolve_batch, _step_evolve
Experiment launch/configsscripts/run_tb_pro_search_offline_then_tb2_search_gpt_5_2.sh, scripts/configs/**offline seed build, online evolve, seeded transfer configs

4. Experimental Setup (实验设置)

Datasets / benchmarks

  • Terminal-Bench 2.0：89 个困难 terminal tasks，来自真实 workflow；按 leaderboards 报告 avg@5 Accuracy，并分 Easy 4 / Medium 55 / Hard 30。
  • SWE-Bench Pro public：731 个 long-horizon software-engineering tasks，来自 11 个 public repositories；按 repository 顺序评估，报告 avg@1 Resolve Rate。
  • Terminal-Bench Pro：用于 offline data，保留 48 个 public software-engineering / system-administration tasks，排除 2 个 environment-unstable tasks。Offline setting 先在这 48 个历史任务上演化 cold-start library，再冻结迁移到 Terminal-Bench 2.0。

Baselines and settings

论文比较三个设置：

  • No-skill baseline：不使用 skill library。
  • Online evolution：从空 skill library 开始，任务级 recommendation + 每个任务流中的证据演化。
  • Offline evolution：先从 Terminal-Bench Pro 历史任务蒸馏 skill library，再把 frozen library 迁移到 Terminal-Bench 2.0 做 recommendation only。

Metrics

  • avg@5 Accuracy：Terminal-Bench 2.0 上每题最多 5 次采样/尝试的平均通过率。
  • avg@1 Resolve Rate：SWE-Bench Pro public 上单次尝试的 overall resolved task ratio。
  • Task-level delta：Figure 5 中相对 no-skill baseline 的逐任务 avg@5 变化，用于分析 positive/negative transfer。

Model / runtime / hyperparameters from released configs

论文实验使用 Codex with GPT-5.2 或 GPT-5.4 mini。Released code 中的实际配置锚点如下：

Terminal-Bench 2.0 baseline and online

  • Config path: scripts/configs/tb2/codex/gpt_5_2/baseline.yaml。
  • Baseline: n_concurrent_trials=16, agents[0].model_name=openai/gpt-5.2, reasoning_effort=medium, Codex CLI version=0.125.0, dataset version=2.0。
  • Online config: scripts/configs/tb2/codex/gpt_5_2/search_online_evolve.yaml uses n_concurrent_trials=1, evolve_every_n_trials=1, evolve_timeout_sec=1800, working_skills_dir=${{jobs_dir}}/${{job_name}}/working_skills, skill_backup_dir=${{jobs_dir}}/${{job_name}}/skills_backup, and recommendation skills mounted at /skills。
  • GPT-5.4 mini online: scripts/configs/tb2/codex/gpt_5_4_mini/search_online_evolve.yaml mirrors the above with agents[0].model_name=openai/gpt-5.4-mini。

Offline Terminal-Bench Pro → Terminal-Bench 2.0 transfer

  • Launch path: scripts/run_tb_pro_search_offline_then_tb2_search_gpt_5_2.sh。
  • Offline source config: scripts/configs/tb_pro/codex/gpt_5_2/search_offline_evolve_task_48_agg_4_ep_1.yaml uses Terminal-Bench Pro version=1.0, n_concurrent_trials=4, evolve_every_n_trials=4, evolve_timeout_sec=1800。
  • Transfer config: scripts/configs/tb2/codex/gpt_5_2/search_seed_tb_pro_search_offline_evolve_task_48_agg_4_ep_1.yaml uses n_concurrent_trials=8, dataset version=2.0, recommendation skills mounted at /skills。
  • Seed publishing: launch script copies ${{TB_PRO_SEARCH_OFFLINE_JOB_DIR}}/working_skills into .skills_vote/gpt_5_2_medium_tb_pro_search_offline_evolve_task_48_agg_4_ep_1 before starting the Terminal-Bench 2.0 transfer job。

SWE-Bench Pro online

  • Config family: scripts/configs/swebenchpro_repos/codex/gpt_5_2/*_search_online_evolve.yaml and scripts/configs/swebenchpro_repos/codex/gpt_5_4_mini/*_search_online_evolve.yaml。
  • Example config: scripts/configs/swebenchpro_repos/codex/gpt_5_2/ansible_ansible_search_online_evolve.yaml uses n_concurrent_trials=1, agents[0].model_name=openai/gpt-5.2, reasoning_effort=medium, Codex CLI version=0.125.0, dataset version=1.0, evolve_every_n_trials=1, evolve_timeout_sec=1800。
  • Hardware: 论文与仓库没有报告 GPU 型号/数量；这是 API/tool-use agent evaluation，不是本地神经网络训练。可复现配置主要由 Harbor benchmark config、Codex model identifier、concurrency、evolve cadence 和 timeout 决定。

5. Experimental Results (实验结果)

Main overview

Figure 1 解读：这张图汇总了 Terminal-Bench 2.0 与 SWE-Bench Pro 上的主要收益。最清晰的提升来自 offline evolution：从 Terminal-Bench Pro 蒸馏出的 frozen library 能迁移到未见过的 Terminal-Bench 2.0；online evolution 的收益较小但在两个 backbone 和两个 benchmark 上整体为正。

Terminal-Bench 2.0 main results

Table 1 使用 avg@5 Accuracy，括号中为任务数；delta 是相对对应 no-skill baseline 的绝对百分点。

Model / SettingOverall (89)Easy (4)Medium (55)Hard (30)
GPT-5.2 Medium51.075.054.940.7
GPT-5.2 Online53.7 ↑2.775.062.9 ↑8.034.0 ↓6.7
GPT-5.2 Offline58.9 ↑7.990.0 ↑15.065.1 ↑10.243.3 ↑2.7
GPT-5.4 mini Medium51.775.061.830.0
GPT-5.4 mini Online52.8 ↑1.175.063.6 ↑1.830.0
GPT-5.4 mini Offline57.5 ↑5.865.0 ↓10.064.7 ↑2.943.3 ↑13.3

主要结论：GPT-5.2 的 offline evolution 从 51.0 到 58.9，提升 +7.9 pp；GPT-5.4 mini 的 offline evolution 从 51.7 到 57.5，提升 +5.8 pp。Online evolution 也为正：GPT-5.2 +2.7 pp，GPT-5.4 mini +1.1 pp，但 Hard 子集上 GPT-5.2 online 出现 -6.7 pp，说明早期在线技能库如果不够成熟，仍可能产生负迁移。

SWE-Bench Pro public main results

Table 2 使用 avg@1 Resolve Rate；overall delta 是相对 no-skill baseline 的绝对百分点。

Model / SettingOverallansib.openl.quteb.flipttelep.vulsnavid.webcl.eleme.nodeb.tutan.
GPT-5.2 Medium47.649.064.862.032.934.254.849.143.150.047.70.0
GPT-5.2 Online50.2 ↑2.656.263.768.432.935.556.545.638.550.072.70.0
GPT-5.4 mini Medium46.952.155.064.631.835.550.050.938.546.461.40.0
GPT-5.4 mini Online49.0 ↑2.151.059.368.432.938.256.549.138.551.861.40.0

SWE-Bench Pro 的整体收益较稳定：GPT-5.2 从 47.6 到 50.2（+2.6 pp），GPT-5.4 mini 从 46.9 到 49.0（+2.1 pp）。但 per-repository 结果差异很大，例如 GPT-5.2 online 在 nodeb. 从 47.7 到 72.7，同时在 webcl. 从 43.1 到 38.5，说明技能积累有用但受 repo/task distribution 影响。

Recommendation controls negative transfer

Figure 5 解读：这张图在 Terminal-Bench 2.0 Hard 子集上比较直接暴露整个 skill library 与 task-conditioned recommendation。Online library 没有 recommendation 时，平均 gain/loss contribution 是 +3.3/−6.7；有 recommendation 后变成 +6.0/−6.0，负面影响被过滤到不再主导。Offline transferred library 本身更有用，但 recommendation 仍把正贡献从 +11.3 提到 +15.3，并把 loss 从 −3.3 降到 −2.0。

这说明技能曝光不是中性操作：技能库即使包含有用经验，也可能把不适合当前任务的 guidance 放进上下文。Recommendation 的作用不是简单提高 recall，而是在 solver 之前做 noise filtering 和 redundancy control。

Offline evolution accumulates transferable procedures

Figure 6 解读：左图显示在 Terminal-Bench Pro 上 checkpointed libraries 被冻结后迁移到 Terminal-Bench 2.0 Hard，指标为 avg@3；右图显示 library growth 同时包含 new skill creation 和 edits to existing skills。论文强调 source-side Terminal-Bench Pro performance 会波动，但 transfer-side utility 随 checkpoint 增强，这说明 offline evolution 不是简单拟合源 benchmark，而是在积累可跨任务复用的 operational procedures。

重要观察是：skill library growth 不是 append-only trajectory storage。系统会创建新 skill，也会编辑旧 skill，把重复证据合并为持久技能 artifact。这样才能避免 skill library 变成一堆相似轨迹片段。

Case study: Apache-backed website → Git-server deployment

Figure 7 解读：示例中，源任务是用 Apache 搭建网站，offline evolution 把 persistent Apache configuration、service installation、apache2ctl -S 检查、end-to-end curl validation 等知识蒸馏到 ubuntu-apache-vhost skill。迁移到 unseen Git-server deployment task 时，evolved run 没有复制源解法，而是复用操作模式：用稳定 Apache service 部署 endpoint，把 Git post-receive hook 接到 served directory，并通过请求完整验证路径。

这个 case study 支持论文的核心主张：SkillsVote 保留的不是 task answer，而是跨任务可用的 procedure、precondition 和 validation pattern。

Limitations and caveats

  • 适用范围受 verifier 限制：preference-driven、open-world、hardware-intensive skills 不能被强行转成 verifiable Harbor tasks，只能做 profiling。
  • Online evolution 的收益不均匀：Terminal-Bench Hard 和 SWE-Bench Pro 的 per-repo 结果都显示负迁移仍可能出现；recommendation 是必要控制层，不是可选优化。
  • 依赖可见 outcome signal：如果只有 human preference 或 unknown judge，代码会把这些 subtask 保留为诊断证据，但不会直接触发演化。
  • 论文未报告硬件细节：实验是 Codex/GPT API tool-use evaluation，主要复现锚点在 model identifier、Harbor config、concurrency、evolve cadence 和 timeout，而非 GPU training recipe。

Overall conclusion

SkillsVote 的实验说明：当系统同时控制 skill exposure、credit assignment 和 library preservation 时，外部技能库可以成为 frozen agent 的可扩展经验层。Offline evolution 的大幅提升证明历史轨迹能被蒸馏成 transferable procedures；online evolution 的小幅稳定收益证明 skill library 可以随任务流增长；recommendation ablation 则证明治理层本身很关键，否则技能上下文会带来负迁移。