SkillOS：Agent技能库不是越大越好，需要学会"断舍离"

论文：SkillOS: Learning Skill Curation for Self-Evolving Agents
arXiv: 2605.06614
团队：UIUC · Google Cloud AI · MIT
核心命题：Agent技能库的瓶颈不在"新增技能"，而在"管理技能"——哪些该留、哪些该删、哪些需要迭代

导语：你的Agent hoarder了

让LLM Agent玩多轮游戏、做复杂推理，一个常见做法是给Agent配一个技能库——遇到任务就检索相关技能，按步骤执行。听起来合理，但有一个根本问题：

技能库只进不出，越堆越臃肿。

现有技能库管理方案要么靠人工维护（累死人），要么靠硬编码规则（死板），要么只学新增不学删除（ hoarder 模式）。结果是：

• 新技能被老技能干扰（interference）
• 冗余技能拖慢检索、稀释注意力
• 技能质量参差不齐，低质技能反而降低成功率

SkillOS 的洞察是：技能管理本身应该是一个学习问题，而不是规则问题。

01｜架构：双模块分离，策展器独立训练

任务流 x₁, x₂, ..., xₙ
       │
       ▼
┌──────────┐    ┌──────────┐
│  BM25   │───▶│  Agent   │
│ 检索相关 │    │ Executor │
│ 技能 Ŝ   │    │  π_L(冻结)│
└──────────┘    └──────────┘
       │              │
       │  执行轨迹 ξ    │
       │  正确性信号   │
       ▼              ▼
┌──────────────────────┐
│   Skill Curator      │
│   π_S(可训练)        │
│  Insert/Update/Delete│
└──────────────────────┘
       │
       ▼
┌──────────┐
│ SkillRepo│
│ 技能仓库  │
└──────────┘

Agent Executor（π_L）：执行任务的主体模型。可以是 Qwen3-8B、Qwen3-32B、甚至 Gemini-2.5-Pro。关键：完全冻结，不参与训练。

Skill Curator（π_S）：一个小模型（默认 Qwen3-8B），专门学习技能管理。它观察执行器在任务中的轨迹，决定：

• insert_skill：新增技能
• update_skill：更新技能
• delete_skill：删除技能

SkillRepo：外部技能仓库，用 Markdown 格式存储。每个技能包含：名称、描述、工作流、禁用条件、前置约束。

这种设计的关键是解耦：执行器负责"用技能"，策展器负责"管技能"。执行器不需要知道技能是怎么来的，策展器不需要会执行任务。

02｜四重复合奖励：不只关心"做对了没"

策展器的决策效果不会立刻显现——你今天新增一个技能，可能要过几个任务后才知道它有没有用。这是延迟反馈问题。

SkillOS 的解法：把任务分组，用前置任务更新技能库，后置任务验证效果。然后设计了一个四重复合奖励函数：

关键设计：第一个任务用空技能库跑，确保奖励反映的是策展决策的真实效果，而不是执行器本身的能力。

训练用 GRPO（Group Relative Policy Optimization），每组采样 8 个独立 rollout，用相对优势更新策略，丢弃 KL 项鼓励探索。

03｜分组训练：同类任务一起学，解决延迟反馈

策展器面对一个核心难题：技能管理的效果是延迟的、间接的。 你今天新增的技能，可能明天才派上用场；你今天删的技能，可能后天才发现不该删。

SkillOS 的解法：把任务按特征聚类分组，每组内前置任务更新技能库，后置任务验证效果。

比如把"找物品"类任务放一组：

• 先跑任务1，策展器根据轨迹决定是否新增/更新/删除技能
• 再跑任务2、3，用更新后的技能库执行
• 奖励基于任务2、3的表现，回传给任务1的策展决策

消融实验显示：去掉分组训练，性能从 61.2% 掉到 57.3%。这是最关键的组件。

04｜实验结果：8B策展器打败Gemini-2.5-Pro

ALFWorld（多轮智能体任务）

反直觉发现：策展器不一定越大越好

论文做了一个对比实验：让 Gemini-2.5-Pro 直接做策展（不训练，零样本），对比用 Qwen3-8B RL 训练后的策展器。

结果：Gemini-2.5-Pro 直接策展 79.3% < Qwen3-8B 训练后策展 80.2%。

结论：策展是一个需要专门训练的技能，不是"更强的推理能力=更好的策展"。这有点像：写代码好的工程师不一定是最会写技术文档的人——策展是另一种能力。

WebShop + 推理任务

跨任务泛化：用推理任务（AIME/GPQA）训练的策展器，迁移到智能体任务（ALFWorld）效果出奇地好——因为推理训练产生的策展策略更抽象，包含分解、验证、自适应规划等元能力。

05｜策展器会进化：从"疯狂新增"到"精炼存量"

训练过程中策展器的操作分布变化：

行为演化：

• 早期：疯狂新增技能，技能库快速膨胀
• 中期：开始更新现有技能，优化存量
• 后期：以更新为主，新增放缓，删除比例缓慢上升

技能库内容也从"通用提示、建议"（早期）演化为"失败处理逻辑、条件分支、系统搜索策略"（后期）——元技能涌现。

技能利用率数据：

• SkillOS 使用更少但更精准的技能（每例平均 1.95 个 vs 基线 2.24 个）
• 成功技能使用率从 61.2% 提升到 88.6%
• 技能覆盖率从 53.6% 提升到 72.9%

这说明策展器学会了 质量>数量——不是把技能库堆满，而是把技能库优化到"每个技能都有用"。

06｜局限与行业意义

局限

1. 训练成本：3-5天 H100 GPU，不是小团队能随便跑的
2. 任务分组依赖人工：需要按属性聚类，自动发现最优分组策略还没解决
3. 执行器冻结：论文假设执行器固定，联合优化可能更好但复杂度更高
4. Markdown格式限制：简化研究但可能限制复杂技能表达

行业意义

SkillOS 回答了 Agent 领域一个长期被忽视的问题：技能库不是越大越好，管理比积累更重要。

当前很多 Agent 框架（如 OpenAI 的 Function Calling、LangChain 的 Tools）都假设技能是静态的、人工维护的。SkillOS 证明了技能管理可以自动化、可学习、可进化。

对实际产品的影响：

• 个人助手：从"预设技能集"进化为"根据你的使用习惯自动增减技能"
• 企业 Agent：不同部门共用技能库，策展器自动沉淀最佳实践、淘汰过时流程
• 游戏 AI：NPC从硬编码行为树进化为"学会新技能、遗忘旧习惯"

结论

SkillOS 的核心贡献不是"让 Agent 学会新技能"，而是 "让 Agent 学会管理技能"。

在技能数量爆炸的时代（一个复杂 Agent 可能有上百个技能），"哪些该留、哪些该删、哪些该迭代"比"新增第101个技能"更重要。SkillOS 用 RL 训练了一个小策展器，让它在任务流中自主决策技能库的增删改，效果比人工维护更好，甚至比直接用最强模型做策展更好。

最有趣的发现是策展器的行为演化：从早期疯狂扩张到后期精炼存量，技能库从具体提示演化为元策略。这像是 Agent 的"职业发展"——从执行具体任务到掌握抽象方法论。

如果你的 Agent 技能库越堆越乱，SkillOS 提供了一条出路：不是请人维护，而是训练一个专门管技能的"小管家"。

参考来源

• arXiv: 2605.06614 — Ouyang et al., "SkillOS: Learning Skill Curation for Self-Evolving Agents", May 2026
• 论文代码与数据：未公开（截至 2026-06-30）

#SkillOS #Agent技能管理 #强化学习 #UIUC #GoogleCloudAI #自我进化Agent #小凯