假设你团队里有个新同事，第一天处理客户投诉花了两个小时。第二天又来一个同类问题，他还是花两小时——因为他完全不记得昨天干过什么。三个月后，第一百个同类问题来了，他依然像第一天一样从头摸索。
这恰恰是当前绝大多数 LLM Agent 的真实状态：每次面对新任务都从零开始思考，对过去做过的事情一无所记。这种「一次性解题器」的范式严重限制了 Agent 在需要持续积累经验场景中的表现。
Google Cloud AI Research 联合 UIUC 和 MIT 最近发表的 SkillOS 正是冲着这个痛点来的。核心思路很清晰：不改造 Agent 本身，而是训练一个专门的「技能策展器」（Skill Curator），让它自动管理 Agent 的技能库。结果很有意思——一个基于 Qwen3-8B 训练的小策展器，策展效果超过了直接用 Gemini-2.5-Pro 做策展。
架构：把「干活」和「管经验」拆成两个人
SkillOS 最关键的设计决策是解耦。传统思路是让 Agent 一边执行任务一边自己维护记忆，同一个模型同时负责推理、执行和记忆管理，每个环节都分走注意力。
SkillOS 的方案很简单——拆成两个角色：
- Agent Executor（冻结）：执行任务，从技能库检索并应用技能
- Skill Curator（RL 训练）：观察执行轨迹，决定技能库的增/删/改
- SkillRepo：外部技能存储库，Markdown 格式，动态更新
Executor 可以是任何现成模型（Qwen、Gemini 都行），不用改它；Curator 专门学习「怎么从经验中提取可复用的技能」，而且 RL 训练信号来自下游任务的真实反馈。
交互闭环：新任务到来 → 从 SkillRepo 检索相关技能 → Executor 基于技能执行任务 → Curator 观察执行轨迹并自判结果 → Curator 决策 insert/update/delete → 更新 SkillRepo 用于下一个任务。
技能格式采用了 Anthropic SKILL.md 格式——每个技能文件包含 YAML frontmatter（技能名称 + 使用场景描述）和 Markdown 正文（可执行知识、工作流、约束条件），与当前主流 Agent 技能系统兼容。
训练方法：分组任务流 + 复合奖励
分组任务流（Grouped Task Streams）可能是整篇论文最重要的设计。RL 训练需要明确奖励信号，但技能策展有个天然难题：你无法立刻判断一个技能是好是坏，它要到未来相关任务中才能体现价值。
SkillOS 的做法是把任务按技能相关性分组：先用 Gemini-2.5-Pro 给每个任务打技能标签，然后基于标签相似度和依赖关系聚类成组。组内 SkillRepo 从空开始，前面任务的执行轨迹用来更新技能库，后面相关任务的成败来评估这些更新的价值。这解决了「延迟反馈」问题——消融实验中，去掉分组用随机任务序列训练，成功率直接掉了 3.9 个百分点。
复合奖励函数包含四个子奖励：
| 奖励组件 | 含义 | 权重 |
|---|---|---|
| r_task | 下游任务成功率 | 1.0 |
| r_fc | 函数调用有效性 | 1.0 |
| r_cnt | 内容质量（Qwen3-32B 评分） | 0.1 |
| r_comp | 压缩奖励（技能越精炼越好） | 0.05 |
压缩奖励的设计尤其值得注意：r_comp = 1 - |技能 token 数| / |输入上下文 token 数|，即技能占用的 token 越少越好。这驱动 Curator 学会提炼精炼的技能，而不是把整段执行轨迹照抄进来。
训练使用 GRPO 算法，基座模型 Qwen3-8B，16 张 H100 GPU，训练 2.5-5 天。
结果：8B 小管家为什么比 Gemini 好
在 ALFWorld（文本交互式家居任务）上，以 Qwen3-8B 作为 Executor，SkillOS（RL 训练后）平均成功率 61.2%，比最强基线 ReasoningBank 的 55.7% 提高 5.5 个百分点，同时交互步数减少 2.2 步。
更关键的是，当 8B 的 RL 训练策展器搭配更强 Executor 时效果还在涨：
- 配 Qwen3-32B Executor：成功率 68.6%
- 配 Gemini-2.5-Pro Executor：成功率 80.2%
在推理任务（AIME24/25、GPQA-Diamond）上同样全面领先，平均准确率从 69.6% 提升到 73.8%。
为什么 8B 训练的 Curator 能超过 Gemini？论文给出了一个很妙的解释：frontier 模型生成的技能可能与 Executor 的能力不匹配。Gemini 很强，但它不了解执行它的那个 8B 小模型会怎么犯错、哪里容易卡住。RL 训练的 Curator 则是在和 Executor 的真实交互中学习的——它知道 Executor 的盲区和弱点，技能自然更有针对性。
技能库演化：从「狂加」到「精修」
SkillOS 对技能库的演化过程做了详细分析：训练初期 insert_skill 占绝对主导（疯狂积累技能），训练后期 insert_skill 下降、update_skill 成为主流（从扩张转向精炼）。delete_skill 占比始终很小——压缩奖励有效抑制了技能膨胀。
技能内容本身也在演化：早期偏「表面丰富」（泛化建议、通用提示），后期转向「可执行结构」（失败处理逻辑、条件分支、验证策略）。更高层面的变化是 SkillRepo 从大量孤立的、任务特定的技能逐步演化为包含元策略技能的整体知识体系——通用的验证方法、回退规划、系统搜索策略。
Curator 从「做笔记的实习生」进化成了「写 SOP 的资深员工」。
苏米注
SkillOS 对正在做 Agent 产品的团队有三个切实启示：①技能系统不要和 Agent 本体耦合——Executor 冻结、Curator 独立训练，可以在不改 Executor 代码的情况下训练专属策展器；②技能管理可以自动化、可学习——当前多数 Agent 产品的技能库还是人工维护的，SkillOS 证明了一条可行的自动化路径；③跨域泛化是可能的——用推理任务训练的 Curator 可以很好地迁移到 Agent 任务上。
论文：Ouyang et al., "SkillOS: Learning Skill Curation for Self-Evolving Agents", arXiv:2605.06614, May 2026