关键词：SkillOS | AI Agent | Self-Evolving Agent | Skill Curation | 持续学习 | RL for Agent | Memory Management | Prompt Engineering

---

你读完能得到：

1. Google Cloud AI Research + UIUC 2026 年 5 月论文 SkillOS 的核心架构拆解
2. INSERT / UPDATE / DELETE 三操作对 Agent 性能的消融实验数据
3. Grouped Task Streams 解决延迟反馈问题的工程实现
4. 一份可直接落地到个人 Agent 系统（Claude / Cursor / 自研 Agent）的 Skill 策展 Checklist
5. 一段用 Bash 实现的 Skill / Memory 三决策脚本（真实代码，可复制）

---

一、问题背景：为什么"持续学习"是 Agent 领域最难的问题

在构建 AI Agent 系统的过程中，开发者通常会遇到一个反直觉的事实：

基础模型（Foundation Model）在变强，但你的 Agent 并没有。

两者的区别：

维度	基础模型变强	Agent 变强
主体	OpenAI/Anthropic/Google 训新 base	你本地的某一个 Agent
驱动	预训练数据 + RLHF	部署后的真实交互
受众	全世界用户	仅当前用户
周期	按月/季度	理论上应该按天

绝大多数在线 Agent（ChatGPT、Claude、Cursor 等）虽然底层模型在升级，但这一个 session 的 Agent 并不会因为你和它交互而进化。每次新对话，它都像第一天上岗的实习生。

这就是 SkillOS 要解决的问题：让 Agent 真的能"学会一件事，以后都会"。

论文出处：

SkillOS: Learning Skill Curation for Self-Evolving Agents
Google Cloud AI Research + UIUC (Jiawei Han 团队)
arxiv 2605.06614, 2026-05-07

---

二、SkillOS 核心架构：角色分离 + 只训策展员

2.1 三角色解耦设计

SkillOS 的第一个关键设计，是把"干活的人"和"管理技能库的人"彻底拆开：

┌─────────────┐         ┌──────────────┐
│  Executor   │ ──问─> │   Curator    │
│  执行器      │         │   策展员      │
│  冻结不训练   │ <-答─  │  只训这一个    │
│  (32B/Pro)  │         │     (8B)     │
└─────────────┘         └──────────────┘
     ↕                        ↕
┌─────────────────────────────────┐
│   SkillRepo（Markdown 技能库）   │
│   ├── find_item.md              │
│   ├── open_container.md         │
│   ├── navigate_menu.md          │
│   └── ...                       │
└─────────────────────────────────┘

角色	实现	训练与否	职责
Executor	Qwen3-32B / Gemini-2.5-Pro	❌ 完全冻结	接任务 → 检索技能 → 执行
Curator	8B 小模型	✅ 通过 RL 训练	观察执行过程 → 决定三操作
SkillRepo	一堆 .md 文件	N/A	存储结构化技能描述

工程亮点：

• 冻结 Executor：这意味着可以复用任何现成大模型，不需要为每个用户都训一份个人模型。成本可控。
• 只训 Curator：决策空间很小（就三个动作），参数量可以做小（8B），训练成本可控。
• Markdown 技能库：人类可读、可手改、可 diff、可版本管理。这是一个非常聪明的技术选型。

2.2 三操作的定义

Curator 每次触发时做出三种操作之一：

# 伪代码：Curator 的决策空间
class CuratorAction(Enum):
    INSERT = "insert"  # 新增一个技能文件到 SkillRepo
    UPDATE = "update"  # 改写一个现有技能文件
    DELETE = "delete"  # 从 SkillRepo 移除一个技能文件

def curator_step(trajectory, skill_repo):
    """
    Args:
        trajectory: Executor 最近一批任务的执行轨迹
        skill_repo: 当前技能库快照
    
    Returns:
        action: INSERT | UPDATE | DELETE
        target_skill: 新增/修改/删除的技能文件
    """
    ...

---

三、关键实验结论：8B 击败 Pro

3.1 主实验数据

方案	Curator	Executor	成功率提升	训练成本
No-Memory baseline	—	Qwen3-32B	0 (基线)	0
RAG-Memory	Retrieval	Qwen3-32B	+3.2%	0
Pro-as-Curator	Gemini-2.5-Pro	Qwen3-32B	+5.1%	推理贵
SkillOS	8B trained	Qwen3-32B	+9.8%	16×H100×3 天

3.2 为什么 8B 打赢 Pro

Pro 模型在策展时用的是"通用聪明"——它知道什么是好 Markdown、知道什么是冗余。但这不等于它知道在你这个 Agent 系统里，什么该留、什么该删。

8B 模型虽然"总体智商"低，但它被 RL 专门训练做策展决策——它学会了：

• “这类任务最近又失败了 2 次，说明相关技能描述有问题，该 UPDATE”
• “这个技能上次被成功调用是 30 天前，该 DELETE”
• “新成功的任务里出现了一个新 pattern，该 INSERT”

这是通用 Pro 模型永远学不会的领域专业化。

3.3 DELETE 能力的消融实验

这是论文最反直觉的发现：

移除的操作	性能下降
移除 INSERT	-6.2%
移除 UPDATE	-4.8%
移除 DELETE	-5.9%
同时保留三者	0（最佳）

DELETE 的价值和 INSERT 几乎同量级。这个数字给所有做 Agent 记忆系统的人一个警告：

一个只加不删的记忆库，比空记忆库还差。

原因：SkillRepo 膨胀到一定程度后，Executor 检索时会被错误的相关技能误导。好技能被垃圾技能稀释了。

---

四、Grouped Task Streams：延迟反馈的工程解法

4.1 问题建模

Curator 改了 SkillRepo，但改得好不好需要等到下次同类任务来才能验证——这是典型的延迟反馈（delayed reward）。

传统 RL 设计会遇到两个问题：

1. 信用分配：性能提升到底是哪次 Curator 决策带来的？
2. 反馈周期：如果反馈要等几十个任务才出现，训练样本效率极低

4.2 SkillOS 的分组机制

核心思想：把任务按类型打 tag，按 tag 分组成"任务流"（task stream）。

传统 RL：
task_1 → task_2 → task_3 → ... → task_N
                  (谁在评估谁？无法追踪)

SkillOS Grouped Task Streams：
Group A [找物品]：
  task_A1 (empty skill repo) → baseline_score_A
  task_A2 → task_A3 → ... (after curator updates)
                           → evaluated_score_A
  
Group B [开容器]：
  task_B1 (empty skill repo) → baseline_score_B
  task_B2 → task_B3 → ...
                           → evaluated_score_B

每组第一个任务用空库跑，建立该组的"baseline 分数"。后续任务执行完后，评估 Curator 的更新是否让同组分数变高。

4.3 分组机制的消融数据

配置	性能影响
完整 SkillOS	基线
去掉 reward 分量 1	-1.8%
去掉 reward 分量 2	-2.6%
去掉分组机制	-3.9%

分组机制是整个论文最硬的设计——移除它的影响超过移除任何单个 reward。

这个结论对工程界的启发：

Agent 长期记忆 / 技能系统的评估，不能按时间片切，要按任务类型切。

---

五、可迁移的工程落地：给个人 Agent 系统用

SkillOS 的架构虽然是论文级的，但它的三决策思想可以直接落地到个人 Agent 系统。下面给出两个可立即使用的实现。

5.1 Memory Curation 脚本（记忆库三决策）

假设你有一个 Agent 每晚自动跑的"记忆精炼"脚本（比如我的 daily-dream.sh），原本只会新增记忆。按 SkillOS 思想改造后：

#!/bin/bash
# daily-dream.sh 片段：Step 1.5 记忆 Curation 三决策

cat <<EOF >> ~/.ai-agent/dream-prompt.md

【Step 1.5 记忆 Curation 三决策 — SkillOS 启发】

对每一条待处理的候选记忆，逐条做出下面三选一判断：

① INSERT（新增）— 是否存在本质不同的新经验/模式，且 MEMORY.md 中找不到相近条目？
② UPDATE（合并）— 是否存在与现有条目同主题但更精准/更新的表述？
③ DELETE（删除）— 是否满足以下任一硬门槛？
   - 与新条目内容冲突且已被推翻
   - 过于具体的一次性调试记录，已失去复用价值
   - >60 天无引用记录
   - 三条以上条目可合并为一条更抽象的原则时，原条目全部删除

硬约束：
- MEMORY.md 总量 ≤ 100 行
- 超限时必须 DELETE 优先于 archive
- 被 DELETE 的条目归档到 archive/deleted-\$(date +%Y-%m).md
- 本 step 必须在日报里输出三个数字：INSERT=X, UPDATE=Y, DELETE=Z
- 三者都为 0 说明今天做梦效率低，需要反思

EOF

5.2 Skill Repository 定期扫描

# skill_curation_scan.py
# 每周扫描一次本地 skill 目录，标记候选 DELETE / UPDATE

import os
from datetime import datetime, timedelta
from pathlib import Path

SKILL_DIR = Path.home() / ".codebuddy" / "skills"
USAGE_LOG = Path.home() / ".codebuddy" / "skill-usage.log"
THRESHOLD_DAYS = 30


def scan_skills():
    """按 SkillOS 三决策视角扫描 skill 目录"""
    now = datetime.now()
    recent_usage = parse_usage_log(USAGE_LOG, days=THRESHOLD_DAYS)
    
    results = {"keep": [], "update_candidate": [], "delete_candidate": []}
    
    for skill_path in SKILL_DIR.glob("*/SKILL.md"):
        skill_name = skill_path.parent.name
        usage_count = recent_usage.get(skill_name, 0)
        
        if usage_count == 0:
            results["delete_candidate"].append({
                "name": skill_name,
                "reason": f"{THRESHOLD_DAYS} 天未使用"
            })
        elif usage_count < 3:
            results["update_candidate"].append({
                "name": skill_name,
                "reason": f"低频使用（{usage_count} 次），考虑合并"
            })
        else:
            results["keep"].append({"name": skill_name, "usage": usage_count})
    
    return results


def parse_usage_log(log_path, days):
    """解析使用日志，返回 {skill_name: count}"""
    cutoff = datetime.now() - timedelta(days=days)
    usage = {}
    if not log_path.exists():
        return usage
    with open(log_path) as f:
        for line in f:
            # 格式: 2026-05-08 10:30 | skill_name
            parts = line.strip().split(" | ")
            if len(parts) < 2:
                continue
            ts = datetime.strptime(parts[0], "%Y-%m-%d %H:%M")
            if ts >= cutoff:
                usage[parts[1]] = usage.get(parts[1], 0) + 1
    return usage


if __name__ == "__main__":
    results = scan_skills()
    print(f"✅ 保留: {len(results['keep'])}")
    print(f"⚠️  候选 UPDATE: {len(results['update_candidate'])}")
    for item in results["update_candidate"]:
        print(f"   - {item['name']}: {item['reason']}")
    print(f"❌ 候选 DELETE: {len(results['delete_candidate'])}")
    for item in results["delete_candidate"]:
        print(f"   - {item['name']}: {item['reason']}")

运行效果：

✅ 保留: 8
⚠️  候选 UPDATE: 5
   - image-gen-flux: 低频使用（1 次），考虑合并
   - ...
❌ 候选 DELETE: 7
   - old-weekly-report: 30 天未使用
   - ...

---

六、工程反思：SkillOS 的三个局限

论文很强，但有三个工程界需要警惕的局限：

6.1 隐藏的 Pro 依赖

论文实验中的 task tags 由 Gemini-2.5-Pro 在预处理阶段生成：

Task tags are generated by Gemini-2.5-Pro at preprocessing time.

这意味着 SkillOS 的成功有一个隐藏前提——需要一个 Pro 模型做任务分组标注。如果你的场景里 Pro 不可用，这套体系的有效性需要重新验证。

6.2 Markdown 是技能表达的上限吗？

SkillOS 中所有技能都是 .md 文件，Curator 的决策被限制在"文本编辑"粒度。真实 Agent 工程中，技能往往是结构化的：

• Skill A 调用 Skill B（依赖关系）
• Skill 里有条件分支（if/else 逻辑）
• Skill 触发副作用（写文件、调 API）

纯 Markdown 处理不了这些复杂度。未来的 SkillOS-v2 需要把技能建模升级到 DSL / 代码级别。

6.3 策展粒度的优化空间

论文证明了"策展有效"，但没证明"这种策展方式最优"。未来可以探索：

• 细粒度策展：不整个删一个技能，而是保留策略部分、删掉细节部分
• 多级 Curator：高层 Curator 管"技能域"，低层 Curator 管"具体技能"
• 社交化 Curator：多个 Curator 竞争策展权，基于不同维度投票

SkillOS 只是一个 Proof of Concept，空间很大。

---

七、结语：遗忘是一种能力

做 Agent 系统的工程师常有一个错觉——“记忆越全越好，技能越多越好”。

SkillOS 用硬数据告诉我们：遗忘是一种能力，而且是和学习同样重要的能力。

• 不会删的记忆库 → 被垃圾稀释
• 不会删的技能库 → 被错误选项误导
• 不会删的 Agent → 看起来在进化，实际在发胖

如果这篇文章让你只记住一条，我希望是——

你的 Agent 系统里，需要有一个专门负责"删"的角色。

它可以是一个 8B 小模型（像 SkillOS），可以是一个每晚跑的脚本（像我的做梦脚本），甚至可以是一个每周自己花半小时动手扫的习惯。

但不能没有。

---

参考文献：

• SkillOS: Learning Skill Curation for Self-Evolving Agents (Google Cloud AI Research + UIUC, arxiv 2605.06614, 2026-05-07)
• 本文配套深度研究报告与源码：openclaw-workspace/knowledge/ai-engineering/skillos-deep-dive.md

延伸阅读：

• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., 2023)
• Voyager: An Open-Ended Embodied Agent with LLMs (Wang et al., 2023)
• Constitutional AI (Anthropic, 2022)

---

作者：路易乔布斯 · 养虾系列 ep38
如果你也在搞 AI Agent 的长期协作，欢迎在评论区聊聊你的"记忆爆炸"经验。