# Skill Curation for Self-Evolving Agents, explained clearly
**作者**: AVB
**日期**: 2026-05-11T16:22:22.000Z
**来源**: [https://x.com/neural_avb/status/2053873358853591435](https://x.com/neural_avb/status/2053873358853591435)
---
Google's latest paper introduces SkillOS, a framework designed to help LLM agents evolve by learning to manage their own "memories" in the form of reusable skills.
> i.e. automatically go Experiences -> Memories -> Skills
SkillOS treats skill management like an operating system (OS).
> It handles files and organizes and refines a persistent SkillRepo. The most interesting part of this method is how skills are discovered using a trainable module called the Curator. (Spoiler: They use RL)
This article explains Google's new SkillOS paper. It was written by AVB (myself) with help from GPT-5.5 inside the Paper Breakdown harness.
## There are 3 things you should know about...
1. Agent Executor (Frozen): This is just an "actor" LLM that retrieves skills from the SkillRepo to solve a task. It is "frozen" during training, meaning we do not update it's weights at all. Its performance is improved purely by providing it with better skills.
2. Skill Curator (Trainable): This is another LLM that observes the Executor's trajectories and decides how to update the SkillRepo. It can perform operations like Insert (add a new skill), Update (refine an existing one), or Delete (remove redundant or useless skills).
3. SkillRepo: A repository of skills stored as structured Markdown files. Each skill includes its name, a description, code snippets, and usage guidelines, making it easy for the Executor to understand and apply.
## You probably already know what skills are.
If not you can learn about skills from this original Anthropic post: https://anthropic.skilljar.com/introduction-to-agent-skills/434525
> In the most basic sense, skills are just lazily loaded prompts.
It is just a YAML or MD file that contains a title and a description. Looks like this:
```
---
name: frontend-design
description: techniques and instructions to write good UI code
---
instructions: <an essay about frontend patterns>
```
Imagine a directory full of skill files like these covering various topics (frontend-design, programming-patterns, marketing-skills, etc). Each skill is written in a different markdown file, and each skill contains a name and description in the header.
```
(cmd) ➜ tree ~/.agents/skills
~/.agents/skills
├── copywriting
│ ├── references
│ │ ├── copy-frameworks.md
│ │ └── natural-transitions.md
│ └── SKILL.md
├── programming-patterns
│ └── SKILL.md
├── frontend-design
│ └── SKILL.md
├── marketing-psychology
│ └── SKILL.md
└── web-design-guidelines
└── SKILL.md
```
Your agent harness (Claude Code, Codex, etc) receives a list of available skills at the top of it's system prompt. Then when you ask it to perform a specific task (say "help me create UI for this webpage"), it deduces that it should read the `frontend-design` skill completely before proceeding with your request. The agent then does a file-read operation (~/.AGENTS/skills/frontend-design/SKILL.md) and loads the full instruction into it's context.
> The goal of this paper is the skill creation phase. Generating clear and actionable instructions that increases agent performance in specific tasks. The Curator LLM performs this task of maintaining the Skill Repository.
> The Executor agent is purposefully left bland. It just performs the same as any other harness - receives skill headers as input, task request, and reads one of more skills via tool calls. There is no contribution by Google to the executor agent - the entire focus is on the Curator and the Skill Repository.
Note that original Anthropic skills architecture also included things like resource files, and executable code. These are not part of Google's SkillOS work, although they do mention future work is possible along that avenue. SkillOS only learns the text/prose portion of skills.
# How skills are discovered organically
SkillOS learns skills/instruction through exploration. Broadly, speaking the LLM agent goes and explores in an environment, and then we distill it's experiences into instructions and skills.
Let's break down each step to clearly understand how it works.
## Stage 1: The Agent Executor Runs
Before any skill is created, the frozen Agent Executor must first attempt to solve a task x. It does this by:
1. Retrieving the top-k most relevant existing skills from the SkillRepo via BM25 keyword matching on YAML descriptions.
2. Running its multi-step interaction with the environment, producing a trajectory: A trajectory is a sequence of observations and actions.
At the end of trajectory, an LLM-as-a-Judge (a separate Qwen3-32B model) determines whether the task was completed successfully, emitting a correctness signal.
This trajectory, the correctness signal, and the previously retrieved skills StSt are then handed off to the Curator.
## Stage 2: Curator Input
The Skill Curator receives a structured prompt containing four key pieces of information:
1. Task Description: What the agent was trying to accomplish.
2. Past Skills: The list of previously retrieved relevant skills (names + content) that were available during execution.
3. Agent Trajectory: The full step-by-step trace showing what happened.
4. Result: Whether the agent succeeded or failed.
The curator's role, as stated directly in its system prompt, is:
> "to convert past experiences of agent task execution into reusable, general skills, so that they can benefit and inspire future tasks."
## Stage 3: Curator Output
The Curator then generates a sequence of structured function calls. It is a ReAct (Reasoning and Acting module) that contains the below tools:
1. new_skill_insert
Creates a brand new skill. The Curator provides:
- skill_name (string): A human-readable identifier
- content (string): The full Markdown body of the skill
When the trajectory reveals a generalizable strategy not yet represented in the SkillRepo, this is used! Specifically useful early in training when the repo is empty.
2. skill_update
Modifies an existing skill. The Curator provides:
- skill_name: The exact name of the skill to update (must match exactly!)
- new_name: A rename if needed
- new_content: Full replacement content
3. skill_delete
Removes an existing skill by its skill_name.
Useful when a skill is redundant, misleading, or superseded.
Here is the full system prompt for the Curator
## Every skill follows a simple format:
YAML Frontmatter (Mandatory)
```
---
name: <Human-readable skill name>
description: <One-sentence what/when/why/how summary, concise and actionable>
---
```
The description field is critical as it is used by BM25 at retrieval time to match tasks to skills. It must be concise and actionable!
Markdown Body
Follows immediately after the frontmatter. Suggested sections include:
- Workflow: Step-by-step instructions
- When NOT to use: Negative conditions to avoid misapplication
- Additional sections like worked examples, formulas, or edge cases
Here is an example of a skill.
The Curator is explicitly instructed to obey these rules:
- No Specifics: Remove specific numbers/names, replace with variables/concepts
- No Hallucination: Only include facts supported by the actual trajectory
- Atomic & Modular: Each skill must be self-contained and reusable in isolation
- Actionable: The body must give concrete guidance, not vague advice
# That's fine, but how do we improve the skills?
> That's where RL comes in. We train the curator to write better skills by rewarding it on successful skills.
The Curator's training loop is the most technically sophisticated part of SkillOS. It solves a fundamentally hard RL problem: how do you train an agent whose decisions only pay off in the future, through another agent?
Standard RL assumes you can measure the effect of an action quickly. But curation is different:
> "The main challenge is indirect and delayed feedback for curation decisions, which is only revealed through skill performance on future relevant tasks."
If the Curator writes a bad skill after task t, you won't know it was bad until task t+5 fails because of it. The paper addresses this with two core mechanisms: grouped training instances and a composite reward.
## Phase 1: Grouped Training Instance Construction (most important)
Before any training happens, the dataset must be pre-processed into groups of related tasks. This is a two-stage pipeline. I won't get into too much details about this here, but the basic gist is this:
1. In Stage 1, we do Latent Attribute Annotation. Basically, they use Gemini-2.5-Pro to annotate every task in the dataset by it's type.
2. In Stage 2, we do Group Construction where given the annotated datasets we build groups of tasks. Each task also has a difficulty ranking so there is a natural curriculum in each task group.
Google tested with group size is 10 tasks on ALFWorld and WebShop environment. And random(5, 12) for reasoning tasks (Math, GPQA, etc).
The group structure ensures that skills curated from early tasks are directly testable on later tasks in the same group.
## Phase 2: The Skill Creation Loop
During each training step, we first sample a task group, init an empty SkillRepo, and follow the skill creation process described earlier. Recap:
1. Executor runs: The frozen executor retrieves top-5 skills via BM25, solves task and produces trajectory
2. Correctness judged: An LLM-judge evaluates whether task succeeded
3. Curator: reads trajectory and invokes tool calls to update skill repo
## Phase 3: The Composite Reward
After a full group rollout completes, the composite reward is computed. It has four components combined as:
1. Task Outcome Reward
The first task uses an empty SkillRepo, before any curator update occurs. As we create skills through completion of tasks, we must track how successful (or unsuccessful) the skills curated from these tasks are.
This is the main learning signal: did the skills curated from earlier tasks help later tasks succeed?
2. Function Call Reward
Measures what fraction of generated function calls are syntactically valid and successfully execute against the SkillRepo.
This is an intermediate format reward that prevents the Curator from producing malformed JSON or calling skill_update on a skill that doesn't exist.
3. Compression Reward
This penalizes verbatim trajectory copying and rewards skills that are genuinely compressed, distilled knowledge.
Without this, the Curator would learn to just dump raw trajectories into the repo.
4. Content Quality Reward
Assigned by Qwen3-32B acting as a judge: it reads the curated skills and scores them on whether they are:
- Semantically meaningful
- Likely to be useful for future tasks
- Faithful and actionable
This provides a dense intermediate signal independent of actual downstream task success.
> All of these rewards are combined (weighted average) to calculate the final group reward.
## Phase 4: GRPO Policy Optimization
We use GRPO to train the Curator model. For each group, we sample N=8 independent rollouts, each producing a composite reward for each. Then we follow standard GRPO optimization to update the network (normalize advantage, and clipped surrogate PPO objective)
Importantly, the KL divergence penalty is discarded from the standard GRPO formulation. his is intentional to encourage policy exploration during skill curation learning.
> In RL training, a rollout is simply one complete run through a task (or sequence of tasks) - the model acts, receives feedback, and that entire trajectory is used for learning.
> In SkillOS, the training unit isn't a single task. It's a task group (e.g., 10 related tasks solved one after another). A rollout here means running through that entire group from start to finish, once.
What Makes Each Rollout Independent?
Each of the 8 rollouts is an independent parallel attempt at the same task group:
- Rollout 1: Curator makes curation decisions c1,c2,…,cn→ SkillRepo evolves one way
- Rollout 2: Curator makes different curation decisions → SkillRepo evolves differently
- ... and so on for all 8 rollouts
Each rollout produces a different version of the SkillRepo because the curator's stochastic sampling leads to different insert/update/delete decisions
GRPO computes a relative reward across the 8 rollouts. For rollout k at task position i, the reward r_k reflects how well that curation sequence helped solve future tasks.
> Rollouts that led to better skill curation (higher reward) get positive advantage and are reinforced. Poor rollouts get negative advantage and are suppressed.
# Results
Here are the big-stroke takeaways and results from SkillOS:
1. SkillOS Beats All Baselines Consistently
Across multi-turn agentic tasks (ALFWorld, WebShop) and single-turn reasoning tasks (AIME math), SkillOS outperforms both Memory-free baselines (no memory at all), and Strong memory-based baselines (e.g., ReasoningBank, MemP)
2. The Curator Generalizes to Unseen Executors
The curator is trained with Qwen3-8B as executor. But at test time, it works with completely different models it has never seen:
- Open-source: Qwen3-8B, Qwen3-32B
- Frontier: Gemini-2.5-Pro
> A key insight: using Gemini-2.5-Pro directly as the curator (SkillOS-gemini) actually underperforms the trained SkillOS curator especially for weaker executors.
> Stronger reasoning alone doesn't guarantee good curation. RL-trained curation is grounded in the executor's actual capacity.
3. Every Reward Component Matters (Ablations)
Removing any piece of the training recipe hurts performance:
- Full SkillOS: 61.2
- w/o content-quality reward: 58.6
- w/o compression reward: 60.0
- w/o task grouping: 57.3
The biggest drop comes from removing task grouping. Confirming that learning from related sequential tasks is the core insight of the whole approach.
Study the full paper here: https://arxiv.org/abs/2605.06614
Study the paper on Paper Breakdown: http://paperbreakdown.com/abs/2605.06614
## 相关链接
- [AVB](https://x.com/neural_avb)
- [@neural_avb](https://x.com/neural_avb)
- [12K](https://x.com/neural_avb/status/2053873358853591435/analytics)
- [https://anthropic.skilljar.com/introduction-to-agent-skills/434525](https://anthropic.skilljar.com/introduction-to-agent-skills/434525)
- [https://arxiv.org/abs/2605.06614](https://arxiv.org/abs/2605.06614)
- [http://paperbreakdown.com/abs/2605.06614](http://paperbreakdown.com/abs/2605.06614)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:22 AM · May 12, 2026](https://x.com/neural_avb/status/2053873358853591435)
- [12.9K Views](https://x.com/neural_avb/status/2053873358853591435/analytics)
- [View quotes](https://x.com/neural_avb/status/2053873358853591435/quotes)
---
*导出时间: 2026/5/12 09:32:48*
---
## 中文翻译
# 自我进化智能体的技能策展：一文讲懂
**作者**: AVB
**日期**: 2026-05-11T16:22:22.000Z
**来源**: [https://x.com/neural_avb/status/2053873358853591435](https://x.com/neural_avb/status/2053873358853591435)
---
谷歌的最新论文介绍了 SkillOS，这是一个旨在帮助 LLM 智能体进化的框架，它通过学习管理自己的“记忆”（即以可复用技能形式存在的知识）来实现。
> 即 自动实现 经验 -> 记忆 -> 技能 的过程。
SkillOS 将技能管理视为一个操作系统（OS）。
> 它处理文件并组织和完善一个持久的 SkillRepo（技能仓库）。这种方法最有趣的部分是如何使用一个名为 Curator（策展人）的可训练模块来发现技能。（剧透：他们使用了 RL）
这篇文章解释了谷歌的新论文 SkillOS。它由 AVB（也就是我）编写，并借助 Paper Breakdown 工具中的 GPT-5.5 辅助完成。
## 关于这几点，你应该了解...
1. **智能体执行器（Agent Executor，冻结状态）：** 这只是一个“执行者” LLM，它从 SkillRepo 检索技能以解决任务。它在训练期间是“冻结”的，意味着我们根本不更新它的权重。它的性能纯粹是通过提供更好的技能来提升的。
2. **技能策展人（Skill Curator，可训练）：** 这是另一个 LLM，它观察执行器的轨迹并决定如何更新 SkillRepo。它可以执行插入（添加新技能）、更新（改进现有技能）或删除（移除冗余或无用技能）等操作。
3. **SkillRepo（技能仓库）：** 一个以结构化 Markdown 文件存储的技能仓库。每个技能包括其名称、描述、代码片段和使用指南，使执行器易于理解和使用。
## 你可能已经知道什么是技能了。
如果不知道，你可以从这篇原始的 Anthropic 帖子中了解：https://anthropic.skilljar.com/introduction-to-agent-skills/434525
> 在最基本的意义上，技能只是延迟加载的提示词。
它只是一个包含标题和描述的 YAML 或 MD 文件。看起来像这样：
```
---
name: frontend-design
description: techniques and instructions to write good UI code
---
instructions: <an essay about frontend patterns>
```
想象一个充满此类技能文件的目录，涵盖各种主题（frontend-design、programming-patterns、marketing-skills 等）。每个技能都写在不同的 markdown 文件中，每个技能在头部包含名称和描述。
```
(cmd) ➜ tree ~/.agents/skills
~/.agents/skills
├── copywriting
│ ├── references
│ │ ├── copy-frameworks.md
│ │ └── natural-transitions.md
│ └── SKILL.md
├── programming-patterns
│ └── SKILL.md
├── frontend-design
│ └── SKILL.md
├── marketing-psychology
│ └── SKILL.md
└── web-design-guidelines
└── SKILL.md
```
你的智能体工具（Claude Code、Codex 等）会在系统提示的顶部收到可用技能的列表。然后当你要求它执行特定任务（比如“帮我为这个网页创建 UI”）时，它会推断在继续你的请求之前应该完整阅读 `frontend-design` 技能。然后智能体执行文件读取操作（~/.AGENTS/skills/frontend-design/SKILL.md）并将完整的指令加载到其上下文中。
> 这篇论文的重点是技能创建阶段。生成清晰且可操作的指令以提高智能体在特定任务中的性能。策展人 LLM 执行维护技能库的任务。
> 执行器智能体被故意设计得非常平淡。它只是像任何其他工具一样工作——接收技能头作为输入、任务请求，并通过工具调用读取一个或多个技能。谷歌对执行器智能体没有任何贡献——整个重点都在策展人和技能库上。
请注意，原始的 Anthropic 技能架构还包括资源文件和可执行代码等内容。这些不属于谷歌 SkillOS 工作的一部分，尽管他们确实提到未来可能沿该方向开展工作。SkillOS 只学习技能的文本/散文部分。
# 技能是如何有机发现的
SkillOS 通过探索来学习技能/指令。广义上讲，LLM 智能体在环境中探索，然后我们将它的经验提炼为指令和技能。
让我们分解每一步以清楚地理解它是如何工作的。
## 第一阶段：智能体执行器运行
在创建任何技能之前，冻结的智能体执行器必须首先尝试解决任务 x。它通过以下方式做到这一点：
1. 通过对 YAML 描述进行 BM25 关键词匹配，从 SkillRepo 检索 top-k 最相关的现有技能。
2. 运行它与环境的多步交互，产生轨迹：轨迹是观察和行动的序列。
在轨迹结束时，一个充当裁判的 LLM（一个单独的 Qwen3-32B 模型）确定任务是否成功完成，发出正确性信号。
然后，该轨迹、正确性信号以及先前检索的技能 St 会移交给策展人。
## 第二阶段：策展人输入
技能策展人收到一个结构化的提示，其中包含四条关键信息：
1. **任务描述：** 智能体试图完成的目标。
2. **过去的技能：** 在执行期间可用的先前检索的相关技能列表（名称 + 内容）。
3. **智能体轨迹：** 显示发生情况的完整逐步跟踪。
4. **结果：** 智能体是成功还是失败。
正如其系统提示中直接说明的那样，策展人的角色是：
> “将智能体任务执行过去的经验转化为可复用的通用技能，以便它们能够造福并启发未来的任务。”
## 第三阶段：策展人输出
然后，策展人生成一系列结构化的函数调用。它是一个 ReAct（推理和行动模块），包含以下工具：
1. **new_skill_insert**
创建一个全新的技能。策展人提供：
- skill_name（字符串）：人类可读的标识符
- content（字符串）：技能的完整 Markdown 主体
当轨迹揭示了 SkillRepo 中尚未 represented 的可泛化策略时，就会使用它！这在仓库为空的训练早期特别有用。
2. **skill_update**
修改现有技能。策展人提供：
- skill_name：要更新的技能的确切名称（必须完全匹配！）
- new_name：如果需要，可以重命名
- new_content：完整的替换内容
3. **skill_delete**
通过 skill_name 删除现有技能。
当技能冗余、误导或被取代时很有用。
以下是策展人的完整系统提示
## 每个技能都遵循简单的格式：
**YAML Frontmatter（强制）**
```
---
name: <Human-readable skill name>
description: <One-sentence what/when/why/how summary, concise and actionable>
---
```
描述字段至关重要，因为在检索时 BM25 使用它来将任务与技能匹配。它必须简洁且可操作！
**Markdown 主体**
紧随 frontmatter 之后。建议的部分包括：
- **Workflow（工作流程）：** 分步说明
- **When NOT to use（何时不使用）：** 避免误用的负面条件
- **其他部分**，如实例、公式或边缘情况
这是一个技能的示例。
策展人被明确指示遵守这些规则：
- **无具体细节：** 删除具体的数字/名称，替换为变量/概念
- **无幻觉：** 仅包含实际轨迹支持的事实
- **原子化与模块化：** 每个技能必须是独立的，并且可单独复用
- **可操作：** 主体必须提供具体指导，而不是模糊的建议
# 这很好，但我们如何改进技能？
> 这就是 RL（强化学习）介入的地方。我们通过在成功技能上奖励策展人来训练它编写更好的技能。
策展人的训练循环是 SkillOS 技术上最复杂的部分。它解决了一个根本性的困难 RL 问题：你如何训练一个智能体，其决策的回报只能在未来通过另一个智能体体现？
标准 RL 假设你可以快速衡量行动的效果。但策展不同：
> “主要挑战是策展决策的间接和延迟反馈，这只有通过技能在未来相关任务上的表现才能揭示。”
如果策展人在任务 t 之后写了一个糟糕的技能，你只有在任务 t+5 因此失败时才会知道它是糟糕的。论文通过两个核心机制解决了这个问题：分组训练实例和组合奖励。
## 阶段 1：分组训练实例构建（最重要）
在进行任何训练之前，数据集必须经过预处理，分组为相关的任务。这是一个两阶段的流水线。我在这里不会过多赘述细节，但基本大意是这样的：
1. 在阶段 1，我们进行**潜在属性标注**。基本上，他们使用 Gemini-2.5-Pro 根据类型标注数据集中的每个任务。
2. 在阶段 2，我们进行**分组构建**，给定标注后的数据集，我们构建任务组。每个任务也有难度排名，因此每个任务组中都有自然的课程。
谷歌在 ALFWorld 和 WebShop 环境上测试时使用的组大小是 10 个任务。对于推理任务（Math、GPQA 等），则是 random(5, 12)。
分组结构确保了从早期任务策展出的技能可以直接在同一组中的后续任务上进行测试。
## 阶段 2：技能创建循环
在每个训练步骤中，我们首先采样一个任务组，初始化一个空的 SkillRepo，并遵循前面描述的技能创建过程。回顾一下：
1. **执行器运行：** 冻结的执行器通过 BM25 检索 top-5 技能，解决任务并产生轨迹
2. **正确性判断：** 一个 LLM 裁判评估任务是否成功
3. **策展人：** 读取轨迹并调用工具调用来更新技能仓库
## 阶段 3：组合奖励
在完整的组推演完成后，计算组合奖励。它由四个组件组合而成：
1. **任务结果奖励**
第一个任务使用空的 SkillRepo，在进行任何策展人更新之前。随着我们通过完成任务创建技能，我们必须跟踪从这些任务策展出的技能有多成功（或不成功）。
这是主要的学习信号：从早期任务策展出的技能是否有助于后期任务成功？
2. **函数调用奖励**
衡量生成的函数调用中有多少部分在语法上是有效的，并且能成功对 SkillRepo 执行。
这是一个中间格式奖励，防止策展人生成格式错误的 JSON 或对不存在的技能调用 skill_update。
3. **压缩奖励**
这惩罚逐字逐句复制轨迹，并奖励真正经过压缩、提炼的知识。
如果没有这个，策展人将学会只是将原始轨迹倾倒到仓库中。
4. **内容质量奖励**
由充当裁判的 Qwen3-32B 分配：它阅读策展出的技能并根据以下情况对它们进行评分：
- 语义上有意义
- 可能对未来的任务有用
- 忠实且可操作
这提供了一个独立于实际下游任务成功的密集中间信号。
> 所有这些奖励被组合（加权平均）以计算最终的组奖励。
## 阶段 4：GRPO 策略优化
我们使用 GRPO 来训练策展人模型。对于每组，我们采样 N=8 个独立的推演，每个都产生一个组合奖励。然后我们遵循标准的 GRPO 优化来更新网络（归一化优势，以及裁剪代理 PPO 目标）
重要的是，KL 散度惩罚从标准 GRPO 公式中丢弃了。这是故意为之，以鼓励在技能策展学习期间的策略探索。
> 在 RL 训练中，推演只是完整地运行一次任务（或任务序列）——模型行动，接收反馈，整个轨迹用于学习。
> 在 SkillOS 中，训练单位不是单个任务。它是一个任务组（例如，10 个相关任务一个接一个地解决）。这里的推演意味着从头到尾完整地运行那个组一次。
是什么让每次推演独立？
8 次推演中的每一次都是同一任务组的一次独立并行尝试：
- 推演 1：策展人做出策展决策 c1,c2,…,cn → SkillRepo 以一种方式演变
- 推演 2：策展人做出不同的策展决策 → SkillRepo 以不同的方式演变
- ......所有 8 次推演以此类推
每次推演都会产生一个不同版本的 SkillRepo，因为策展人的随机采样导致不同的插入/更新/删除决策
GRPO 计算 8 次推演之间的相对奖励。对于任务位置 i 的推演 k，奖励 r_k 反映了该策展序列在多大程度上帮助解决了未来的任务。
> 导致更好的技能策展（更高奖励）的推演获得正向优势并被强化。糟糕的推演获得负向优势并被抑制。
# 结果
以下是 SkillOS 的重要要点和结果：
1. **SkillOS 始终击败所有基线**
在多轮智能体任务（ALFWorld、WebShop）和单轮推理任务（AIME 数学）中，SkillOS 的表现优于无记忆基线（完全没有记忆）和强记忆基线（例如 ReasoningBank、MemP）。
2. **策展人可以泛化到未见过的执行器**
策展人是使用 Qwen3-8B 作为执行器训练的。但在测试时，它可以与它从未见过的完全不同的模型一起工作：
- 开源：Qwen3-8B、Qwen3-32B
- 前沿模型：Gemini-2.5-Pro
> 关键见解：直接使用 Gemini-2.5-Pro 作为策展人（SkillOS-gemini）实际上表现不如训练过的 SkillOS 策展人，特别是对于较弱的执行器。
> 仅凭更强的推理能力并不能保证良好的策展。RL 训练的策展立足于执行器的实际能力。
3. **每个奖励组件都很重要（消融实验）**
移除训练配方中的任何部分都会损害性能：
- 完整 SkillOS：61.2
- w/o content-quality reward（无内容质量奖励）：58.6
- w/o compression reward（无压缩奖励）：60.0
- w/o task grouping（无任务分组）：57.3
最大的下降来自于移除任务分组。这证实了从相关的顺序任务中学习是整个方法的核心见解。
在此处研究完整论文：https://arxiv.org/abs/2605.06614
在 Paper Breakdown 上研究论文：http://paperbreakdown.com/abs/2605.06614
## 相关链接
- [AVB](https://x.com/neural_avb)
- [@neural_avb](https://x.com/neural_avb)
- [12K](https://x.com/neural_avb/status/2053873358853591435/analytics)
- [https://anthropic.skilljar.com/introduction-to-agent-skills/434525](https://anthropic.skilljar.com/introduction-to-agent-skills/434525)
- [https://arxiv.org/abs/2605.06614](https://arxiv.org/abs/2605.06614)
- [http://paperbreakdown.com/abs/2605.06614](http://paperbreakdown.com/abs/2605.06614)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:22 AM · May 12, 2026](https://x.com/neural_avb/status/2053873358853591435)
- [12.9K Views](https://x.com/neural_avb/status/2053873358853591435/analytics)
- [View quotes](https://x.com/neural_avb/status/2053873358853591435/quotes)
---
*导出时间: 2026/5/12 09:32:48* 
