当 Agent 学会了"简历筛选"：SkillsVote 把 168 万个技能文件变成了可控的终身学习系统

一句话结论：MemTensor 团队从 GitHub 上挖出了 168 万个 SKILL.md 文件，发现其中 79 万是格式有效的 Agent 技能。但他们没有简单地把这些技能丢给 LLM，而是设计了一套"生命周期治理"框架——像 HR 筛选简历一样，先给技能做画像（环境要求、质量、可验证性），再像猎头推荐一样做智能匹配，最后像绩效评估一样归因任务成败。结果是：冻结的 GPT-5.2 不需要任何微调，仅靠外部技能库的治理和演化，就在 Terminal-Bench 2.0 上提升了 7.9 个百分点。

一、问题的根源：技能越多，Agent 越笨？

2025-2026 年，Agent Skills 生态经历了爆发式增长。Anthropic 的 Skills 体系、OpenClaw 的技能市场、各种 SKILL.md 仓库——技能从"手工艺品"变成了"工业化零件"。

但规模带来了一个反直觉的问题：技能越多，Agent 表现可能越差。

原因很简单：

1. 冗余：同一个功能有 20 个技能实现，质量参差不齐
2. 环境敏感：一个依赖 Docker 的技能在裸机环境上会失败
3. 污染：把失败的轨迹直接塞进技能库，等于让 Agent 反复学习错误
4. 暴露过度：把所有技能都加载到上下文，信息过载比信息不足更致命

SkillsVote 的论文一针见血地指出了这个问题：

"Open skill ecosystems contain redundant, uneven, environment-sensitive artifacts, and indiscriminate updates can pollute future context."

这不是理论问题。论文引用的 SkillsBench、SkillCraft、SkVM 等基准测试都表明：弱相关或低质量的技能会直接降低 Agent 性能。

二、核心洞察：技能不是代码，是"经验 Schema"

SkillsVote 的第一个关键决策是：重新定义什么是 Agent Skill。

传统理解中，Skill = 可执行脚本 + 描述文档。但 SkillsVote 把它提升到了"经验表示"的层面：

Agent Skill = 可执行脚本 + 不可执行流程指引 + 适用边界 + 依赖约束

这种"经验 Schema"的视角带来了几个好处：

• 可审计：技能文件本身就是版本控制的对象
• 可移植：跨 Harness（Claude Code、Codex、OpenClaw）可用
• 可验证：有明确的成功标准和执行边界
• 可组合：多个技能可以像乐高一样拼接

论文中最有趣的发现来自 GitHub 语料挖掘：

这意味着：超过一半自称"技能"的文件，其实连基本格式都不达标。在把它们喂给 Agent 之前，先做一次"体检"是必要的。

三、生命周期框架：从原始矿石到精密零件

SkillsVote 的核心是一个五阶段闭环：

收集(Collect) → 画像(Profile) → 推荐(Recommend) → 归因(Attribute) → 演化(Evolve)
     ↑                                                              |
     └──────────────── 闭环反馈 ────────────────────────────────────┘

3.1 收集：百万级语料勘探

SkillsVote 从 GitHub 上挖掘了 168 万个 SKILL.md 文件，构建了"世界上最大的开源 Agent 技能库"。但这些文件不是直接可用的——它们来自不同的仓库、遵循不同的约定、依赖不同的环境。

3.2 画像：三维技能体检

每个技能必须通过三重过滤：

第一维：Runtime Requirement Profile（环境需求画像）

• 操作系统假设（Linux/macOS/Windows？）
• 写权限需求
• sudo 需求
• 网络访问
• API Key 依赖
• 命令行工具依赖
• MCP Server 依赖
• 环境变量需求

第二维：Quality Profile（质量画像）

• 一致性：技能描述与实现是否匹配
• 完整性：脚本、依赖、文档是否齐全
• 任务导向：是否有明确的输入输出边界

第三维：Verifiability Profile（可验证性画像）

• 成功条件是否低歧义
• 是否有可复现的 Sandbox 环境
• 构造测试任务的成本是否合理

通过这三维画像，SkillsVote 把"原始矿石"分拣为：

• 可直接执行的技能：通过全部三维度画像
• 需要适配的技能：环境不匹配但质量过关
• 不可验证的技能：保留在语料库但不进入推荐池
• 废弃技能：质量不达标或依赖已过时

3.3 推荐：Agentic Library Search

传统技能推荐的做法是：把技能描述向量化，做语义检索，返回 top-k 个最相关的技能。但 SkillsVote 认为这不够——技能的名字和描述常常不能反映它的真正能力。

SkillsVote 的做法更接近"深度研究"式的 agentic search：

1. 任务理解：解析当前任务的指令、约束、目标
2. 库内搜索：遍历结构化技能库，读取候选 SKILL.md 及其资源
3. 环境匹配：过滤掉在当前环境无法运行的技能
4. 互补性检查：确保推荐的技能之间不重复、可组合
5. 压缩输出：给 Agent 提供精简的技能上下文 + 使用指南，而非完整库

这个设计有一个精妙的副作用：推荐记录本身就是归因的锚点。执行后，SkillsVote 可以回头检查"推荐出去的技能是否真的被使用了"。

3.4 归因：Subtask-Level 功劳分配

这是 SkillsVote 最深层的技术创新。

长程 Agent 轨迹（trajectory）是一团乱麻：技能指导的步骤、Agent 自主探索的步骤、失败后的修正步骤、重复尝试的步骤——混在一起。如果把整个轨迹直接蒸馏成"经验"，等于让 Agent 同时学习"正确做法"和"错误尝试"。

SkillsVote 的解决方案是：把轨迹分解成"子任务"（subtask）级别的归因单元。

一个子任务的定义很严格：

• 有独立的语义目标
• 有单一的主评估信号
• 最多关联一个技能上下文

然后，每个子任务通过三轴归因：

轴一：Outcome Evidence（结果证据）

• 客观环境反馈（如测试通过/失败）
• 人类偏好（如 UI 美观度）
• 无明确信号（如探索性步骤）

轴二：Responsibility Assignment（责任分配）

• 技能指导的执行（Skill-guided）
• Agent 独立探索（Exploration）
• 观察不相关技能后的探索（Irrelevant-skill-triggered）
• 失败保留为诊断证据，但不驱动演化

轴三：Reusable Delta（可复用增量）

• 只提取真正可复用的发现：缺失的步骤、前置条件、恢复模式
• 丢弃：常规试错、任务特定常量、重复操作

这种细粒度的归因，让 SkillsVote 能回答一个关键问题：这次任务的成功，到底是因为技能好用，还是因为 Agent 自己探索出来的？

3.5 演化：Evidence-Gated Updates（证据门限更新）

归因完成后，不是直接更新技能库。SkillsVote 设计了三道闸门：

闸门一：Admissibility（准入审查）

• 只有成功的子任务 + 包含可复用探索 = 才能触发演化
• 失败、不确定、弱支持的证据 → 保留诊断价值，但不驱动编辑

闸门二：Aggregation（聚合）

• 支持同一个可复用程序的多个证据单元合并为单一更新提议
• 防止重复观察产生碎片化的多次编辑

闸门三：Routing（路由）

• 证据扩展了实际使用的技能 → 最小化编辑该技能（修复、补充、收紧前置条件）
• 证据反映独立的新能力 → 创建新技能
• 证据弱、冗余、语义不匹配 → 跳过

这种"保守演化"的设计哲学是：宁可少更新，也不要错更新。因为技能库是长期资产，一次错误的更新可能污染未来数百次任务。

四、实验验证：冻结模型也能进化

SkillsVote 的实验设计围绕三个核心问题：

4.1 离线演化：历史轨迹能变成冷启动技能库吗？

实验设置：

• 从 Terminal-Bench Pro 的 48 个公开任务中蒸馏技能库
• 每 4 个任务触发一次演化
• 将"冻结"的技能库迁移到 Terminal-Bench 2.0 的未见任务上
• 对比：无技能基线、直接暴露完整库、SkillsVote 推荐

结果（Terminal-Bench 2.0，avg@5 Accuracy）：

关键发现：直接暴露完整库反而产生负迁移——大量弱相关技能干扰了 Agent 的判断。SkillsVote 的推荐层像一个噪声过滤器，只让真正相关的技能进入上下文。

4.2 在线演化：任务流中能持续积累有用的经验吗？

实验设置：

• 从空库开始
• 每完成一个任务，根据归因结果更新技能库
• 在 SWE-Bench Pro（731 个长程软件工程任务）上测试

结果（SWE-Bench Pro，avg@1 Resolve Rate）：

关键发现：在线演化的增益比离线小，但对两个模型都稳定有效。增益在任务序列早期较低（库还空），中期逐渐提升，后期趋于稳定。

4.3 推荐的保护作用：为什么暴露全部技能反而有害？

论文 Figure 5 揭示了一个反直觉的现象：

• 无推荐直接暴露完整库：正向增益平均 +3.3pp，负向拖累平均 -6.7pp → 净负效果
• SkillsVote 推荐后暴露：正向 +6.0pp，负向 -6.0pp → 净效果中性偏正

这意味着：在技能库早期阶段，推荐的主要作用不是"找到最佳技能"，而是"阻止坏技能进入上下文"。

五、技术架构拆解

5.1 技能表示层

SkillsVote 采用目录级技能包（directory-level package）：

skill-package/
├── SKILL.md          # 能力定义 + 使用条件
├── scripts/          # 可执行脚本
├── references/       # 支持文档
└── assets/           # 静态资源

这种结构与 Anthropic Skills、OpenClaw Skills 兼容，但增加了画像元数据层。

5.2 推荐引擎：Agentic Search vs. 语义检索

SkillsVote 明确区分了两种检索模式：

这种设计受到多个工作的启发：

• DCI（Deep Corpus Interaction）：让 Agent 直接与语料库交互，而非消费固定 top-k
• CodeScout / SWE-grep：多轮定位训练
• Vercel Data Agent：文件 + Shell 操作压缩查询探索
• Letta：文件系统后端做记忆检索

5.3 归因系统：Subtask 边界的判定

轨迹分解为子任务的触发条件（三者满足其一即分割）：

1. 语义目标发生变化
2. 评估信号类型发生变化
3. 关联的技能上下文发生变化

这种粒度选择是一个精妙的权衡：

• 全轨迹级别：太粗，无法分配功劳
• 单步级别：太细，一个工具调用不构成可复用知识
• Subtask 级别：刚好捕捉到"一个独立目标 + 一个评估信号 + 一个技能上下文"

5.4 演化控制：最小化编辑原则

SkillsVote 的演化策略非常保守：

• 修复而非重写：如果技能基本正确但缺少某个步骤，只补充该步骤
• 收紧而非放宽：如果探索发现某个前置条件其实是必要的，把前置条件写进技能
• 新建而非污染：如果发现的是一个独立的新能力，创建新技能而不是塞进现有技能

这种保守性可能会减慢演化速度，但它防止了"一个坏更新污染整个库"的系统性风险。

六、与现有工作的关系

6.1 与 Anthropic Skills 生态的关系

Anthropic 的 Skills 体系（Claude Code、MCP 等）定义了 SKILL.md 的标准格式。SkillsVote 的语料挖掘正是基于这个格式——79 万通过 Anthropic 官方验证器的技能文件。

但 SkillsVote 增加了 Anthropic 生态中缺失的一层：治理层。Anthropic 提供了"如何写技能"，SkillsVote 提供了"如何管理十万个技能"。

6.2 与 OpenClaw Skill 市场的关系

OpenClaw 的 Skill 市场也是基于 SKILL.md + 脚本的结构。SkillsVote 的 skills-vote-local 包可以直接对接本地或私有的 OpenClaw 技能库。

论文明确提到：

"SkillsVote connects collection, profiling, just-in-time recommendation, trajectory-based attribution, and feedback-driven evolution into one loop."

这与 OpenClaw 的"插件即技能"哲学一致，但增加了系统性的归因和演化机制。

6.3 与经验学习（Experiential Learning）的关系

Agent 经验学习的发展历程：

SkillsVote 的定位是：在"工具级"和"模型级"之间建立一个中间层——技能库可以独立于模型演化，同时保持可审计和可移植。

七、局限性与待验证问题

7.1 当前局限

1. 模型限制：实验仅使用 GPT-5.2 和 GPT-5.4mini（Codex 系列）。其他模型家族（Claude、Gemini、开源模型）的效果未知
2. 任务领域：主要在终端任务（Terminal-Bench）和软件工程（SWE-Bench）上验证。其他领域（如 Web Agent、桌面 Agent）的效果未测试
3. 规模效应：在线演化的增益在 731 个任务上测试，更大规模（数千任务）时增益是否持续？
4. 技能库冷启动：离线演化需要 48 个任务的先验数据。对于真正的新领域，如何零样本启动？
5. 归因精度：Subtask-level 归因虽然比轨迹级精细，但仍可能误判"技能指导"和"Agent 探索"的边界
6. 幻觉风险：推荐阶段如果 Agent 对技能文件产生幻觉（误解技能能力），可能导致错误的归因

7.2 未来方向

论文作者提出了几个明确的扩展方向：

1. 跨领域迁移：Terminal-Bench 的技能库能否迁移到 SWE-Bench？反之呢？
2. 多 Agent 协作：多个 Agent 共享同一个技能库时，归因和演化如何协调？
3. 人类反馈集成：当前归因依赖环境反馈和结果信号。引入人类判断（如代码审查意见）可能提升演化质量
4. 技能依赖图：技能之间可能存在依赖关系（如"部署技能"依赖"构建技能"）。显式建模这些依赖可能提升组合推荐效果
5. 对抗性测试：故意注入低质量或恶意技能，测试治理系统的鲁棒性

八、为什么这篇论文值得被记住

8.1 它解决了一个"房间里的大象"

所有人都在谈"Agent 要终身学习"，但很少有人认真回答："学到的东西放在哪里？怎么管理？怎么防止越学越乱？"

SkillsVote 把这个问题从"工程细节"提升到了"系统设计"的层面。它证明了：Agent 的终身学习不只是模型层面的问题，更是系统架构层面的问题。

8.2 它提出了一个可操作的定义

"Skill"这个词在 2025-2026 年被用得很滥。SkillsVote 给出的定义是精确的：

"A skill combines procedural text, scripts, dependencies, and applicability boundaries, so experience remains auditable, versionable, and portable across harnesses."

这个定义把 Skill 从"高级提示词"提升到了"软件工程 artifact"的层面。

8.3 它展示了"冻结模型 + 演化外部库"的可能性

最让业界关注的发现是：不需要微调模型，仅靠外部技能库的治理和演化，就能提升 Agent 性能。

这意味着：

• 模型提供商可以继续优化基础模型
• Agent 开发者可以在模型之上构建自己的技能生态
• 企业可以在私有技能库中积累领域知识，而不需要把数据交给模型

这是一种"解耦"的架构——模型和知识分离，各自独立演化。

九、对 Agent 开发者的实践建议

9.1 如果你正在构建 Agent 技能库

1. 先做画像，再谈推荐：在增加技能数量之前，先建立 runtime requirement、quality、verifiability 的三维画像体系
2. 推荐优于暴露：不要把整个技能库加载到上下文。用某种形式的推荐（哪怕是最简单的关键词匹配）筛选技能
3. 归因先于演化：在更新技能库之前，先建立"为什么更新"的记录。哪怕只是简单的"成功/失败"标记，也比无差别更新好
4. 保守演化：宁可技能库增长慢一点，也不要让错误经验进入长期记忆

9.2 如果你正在使用 Claude Code / OpenClaw 等工具

SkillsVote 已经发布了可直接安装的 skill：

• Hosted 版本 (skills-vote)：连接 SkillsVote 云服务，获取推荐和归因反馈
• Local 版本 (skills-vote-local)：对接本地/私有技能库，无需 API Key

安装方式：

npx skills add MemTensor/skills-vote --skill skills-vote
# 或本地版本
npx skills add MemTensor/skills-vote --skill skills-vote-local

十、结论：从"写技能"到"治理技能"

SkillsVote 的意义，远不止一篇论文或一个开源项目。它标志着 Agent Skills 从"手工作坊"进入了"工业化治理"阶段。

在 SkillsVote 之前，技能生态的核心问题是"如何写好一个技能"。在 SkillsVote 之后，核心问题变成了"如何管理十万个技能的生命周期"。

这种转变类似于：

• 从"写好一段代码"到"管理一个代码库"
• 从"训练一个模型"到"运营一个模型服务"
• 从"写一篇文档"到"维护一个知识库"

SkillsVote 给出的答案是：收集→画像→推荐→归因→演化，五阶段闭环，每一步都有明确的准入标准和质量控制。

最终，这篇论文留下了一个更大的问题：如果 Agent 的技能库可以独立于模型演化，那么"智能"到底在哪里？是在模型的权重里，还是在技能库的积累中？

SkillsVote 暗示了一个可能的答案：两者都是必要的，但两者都可以独立优化。模型负责推理和泛化，技能库负责知识和经验。它们通过生命周期治理框架连接在一起，各自演化，共同进步。

参考链接

• arXiv 论文：https://arxiv.org/abs/2605.18401
• GitHub 仓库：https://github.com/MemTensor/skills-vote
• 官方网站：https://skills.vote
• Hugging Face Daily Papers：https://huggingface.co/papers/2605.18401
• Kevin Fang 每日简报：https://www.kevinf.site/daily-2026-05-20-ai-research-briefing.html
• Daily Paper Cast：https://feeds.transistor.fm/daily-paper-cast-ai
• Anthropic Skills 文档：https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/skills
• Terminal-Bench 2.0：https://github.com/laude-benchmark/terminal-bench
• SWE-Bench Pro：https://www.swebench.com/
• Harbor Agent 框架：https://github.com/laude-benchmark/harbor

#AI #Agent #LLM #SkillsVote #MemTensor #终身学习 #技能治理 #论文解读 #小凯