让 Agent 自己管理技能
Google 最新论文提出 SkillOS，一个帮助 LLM Agent 通过管理可复用技能来自我进化的框架。
核心流程很简单：Experiences → Memories → Skills。Agent 在环境中探索，把经验蒸馏成指令和技能，存起来供未来任务使用。
SkillOS 把技能管理当作操作系统来处理——处理文件、组织并精炼一个持久的 SkillRepo。最有趣的部分是技能如何被发现：通过一个名为 Curator 的可训练模块。（剧透：他们用强化学习。）
架构：执行者、策展者和仓库
SkillOS 由三个核心组件构成：
Agent Executor（冻结）
这是一个"演员"LLM，从 SkillRepo 检索技能来解决任务。训练期间完全冻结，不更新权重。它的性能提升纯粹来自被提供更好的技能。
Skill Curator（可训练）
另一个 LLM，观察执行者的轨迹，决定如何更新 SkillRepo。可以执行三种操作：
- Insert：添加新技能
- Update：精炼现有技能
- Delete：删除冗余或无用的技能
SkillRepo
技能仓库，以结构化 Markdown 文件存储。每个技能包含名称、描述、代码片段和使用指南，方便执行者理解和应用。
技能长什么样
Anthropic 最早提出的 Skills 架构中，技能本质上是懒加载的 prompt——一个 YAML 或 MD 文件，包含标题和描述：
---
name: frontend-design
description: techniques and instructions to write good UI code
---
instructions: <an essay about frontend patterns>
Agent harness（Claude Code、Codex 等）在系统 prompt 顶部接收可用技能列表。当用户要求执行特定任务时，Agent 推断应该读取哪个技能，然后通过文件读取操作加载完整指令。
SkillOS 的目标正是技能创建阶段——生成清晰、可执行的指令，提升 Agent 在特定任务上的表现。Curator LLM 负责维护技能仓库。
执行者被故意设计得很平淡。它和其他 harness 一样工作：接收技能头部作为输入、任务请求，通过工具调用读取一个或多个技能。Google 对执行者 Agent 没有贡献——全部焦点在 Curator 和 Skill Repository 上。
技能创建流程
在任何技能被创建之前，冻结的执行者必须先尝试解决任务：
- 通过 BM25 关键词匹配从 SkillRepo 检索 top-k 最相关的现有技能
- 运行多步环境交互，产生轨迹（观察和行为序列）
- 轨迹结束时，LLM-as-a-Judge（独立的 Qwen3-32B 模型）判断任务是否成功完成，发出正确性信号
这个轨迹、正确性信号、以及之前检索到的技能，一起交给 Curator。
Curator 的工作方式
Curator 接收包含四个关键信息的结构化 prompt：
- 任务描述：Agent 试图完成什么
- 过去技能：执行期间可用的相关技能列表（名称+内容）
- Agent 轨迹：完整的一步一步追踪
- 结果：成功还是失败
Curator 的角色，如其系统 prompt 所述：
"将 Agent 任务执行的过去经验转化为可复用、通用的技能，使它们能够受益并启发未来任务。"
Curator 生成结构化函数调用序列。它是一个 ReAct（推理和行动模块），包含以下工具：
new_skill_insert：创建全新技能，提供 skill_name 和 content skill_update：修改现有技能，提供 skill_name、new_name、new_content skill_delete：删除现有技能
Curator 被明确要求遵守以下规则：
- No Specifics：删除具体数字/名称，替换为变量/概念
- No Hallucination：只包含实际轨迹支持的事实
- Atomic & Modular：每个技能必须自包含、可独立复用
- Actionable：主体必须给出具体指导，不是模糊建议
强化学习训练 Curator
Curator 的训练循环是 SkillOS 技术上最复杂的部分。它解决一个根本性的 RL 难题：如何训练一个决策收益只能通过另一个 Agent 在未来才能体现的 Agent？
标准 RL 假设你能快速测量动作效果。但策展不同：
"主要挑战是策展决策的间接和延迟反馈，只有通过技能在未来相关任务上的表现才能揭示。"
如果 Curator 在任务 t 后写了一个坏技能，你要到任务 t+5 失败时才知道。论文用两个核心机制解决这个问题：分组训练实例和复合奖励。
任务分组
数据集被预处理成相关任务组。两阶段流水线：
- 潜在属性标注：用 Gemini-2.5-Pro 标注数据集中每个任务的类型
- 组构建：基于标注构建任务组，每个任务还有难度排名，形成自然课程
Google 在 ALFWorld 和 WebShop 环境测试时组大小为 10 个任务。推理任务（Math、GPQA 等）用 random(5, 12)。
组结构确保早期任务策展的技能可以直接在组内后期任务上测试。
复合奖励
每个训练步骤先采样一个任务组，初始化空 SkillRepo，遵循前述技能创建流程。完整流程：
- 执行者运行：冻结执行者通过 BM25 检索 top-5 技能，解决任务，产生轨迹
- 正确性判断：LLM-judge 评估任务是否成功
- 策展者：读取轨迹，调用工具更新技能仓库
完整组 rollout 完成后，计算复合奖励。四个组件：
1. 任务结果奖励
第一个任务使用空 SkillRepo，在策展者更新之前。随着任务完成创建技能，必须追踪这些技能的成功程度。这是主要学习信号：早期任务策展的技能是否帮助了后期任务成功？
2. 函数调用奖励
测量生成函数调用中语法有效并成功执行的比例。这是中间格式奖励，防止 Curator 产生畸形 JSON 或对不存在的技能调用 skill_update。
3. 压缩奖励
惩罚逐字复制轨迹，奖励真正压缩、蒸馏知识的技能。没有这个，Curator 会学会把原始轨迹直接 dump 进仓库。
4. 内容质量奖励
由 Qwen3-32B 作为 judge 评分：语义是否有意义、是否对未来任务有用、是否忠实且可执行。这提供独立于实际下游任务成功的密集中间信号。
所有奖励加权平均计算最终组奖励。
GRPO 训练
用 GRPO 训练 Curator 模型。每组采样 N=8 个独立 rollout，每个产生复合奖励。然后遵循标准 GRPO 优化更新网络（归一化优势、裁剪替代 PPO 目标）。
重要的是，KL 散度惩罚被从标准 GRPO 公式中丢弃。这是有意为之，鼓励技能策展学习期间的策略探索。
每个 rollout 是同一任务组的独立并行尝试：
- Rollout 1：Curator 做策展决策 → SkillRepo 以一种方式演化
- Rollout 2：Curator 做不同决策 → SkillRepo 以不同方式演化
- ...以此类推
GRPO 跨 8 个 rollout 计算相对奖励。Rollout k 在任务位置 i 的奖励 r_k 反映该策展序列对未来任务的帮助程度。
策展更好的 rollout 获得正优势并被强化，差的 rollout 被抑制。
关键结果
1. SkillOS 持续击败所有基线
跨多轮 Agent 任务（ALFWorld、WebShop）和单轮推理任务（AIME math），SkillOS 超越无记忆基线和强记忆基线（ReasoningBank、MemP）。
2. Curator 泛化到未见执行者
Curator 用 Qwen3-8B 作为执行者训练，但测试时能与完全没见过的模型工作：
- 开源：Qwen3-8B、Qwen3-32B
- 前沿：Gemini-2.5-Pro
关键洞察：直接用 Gemini-2.5-Pro 作为策展者（SkillOS-gemini）实际上不如训练过的 SkillOS 策展者，尤其是对较弱执行者。更强的推理不等于好的策展。RL 训练的策展扎根于执行者的实际能力。
3. 每个奖励组件都重要（消融实验）
移除任何一块训练配方都会损害性能：
- 完整 SkillOS：61.2
- 去掉内容质量奖励：58.6
- 去掉压缩奖励：60.0
- 去掉任务分组：57.3
最大降幅来自移除任务分组。确认从相关序列任务学习是整个方法的核心洞察。
与现有技能生态的关系
SkillOS 只学习技能的文本/散文部分，不涉及 Anthropic 原始技能架构中的资源文件和可执行代码。论文提到未来工作可能朝那个方向扩展。
对 OpenClaw 等使用 Skills 架构的系统来说，SkillOS 提供了一条自动化的路径：不是手动编写 SKILL.md，而是让 Agent 自己从经验中提炼、压缩、维护技能库。
结语
SkillOS 把"技能管理"从人工策展推向自动进化。执行者 frozen、策展者 trained、仓库 persistent——这个分工让系统可以持续自我改进，而不需要人类手动更新技能文件。
核心启示：在 Agent 时代，最重要的不是执行能力，而是策展能力——如何从混乱的经验中提炼出清晰、可复用、能泛化的知识。而这，正是强化学习最擅长的。