SkillOS 论文深度拆解：为什么 AI Agent 的“遗忘能力“比“学习能力“同样重要

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

2.2 三操作的定义

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

# 伪代码：Curator 的决策空间classCuratorAction(Enum):INSERT="insert"# 新增一个技能文件到 SkillRepoUPDATE="update"# 改写一个现有技能文件DELETE="delete"# 从 SkillRepo 移除一个技能文件defcurator_step(trajectory,skill_repo):""" Args: trajectory: Executor 最近一批任务的执行轨迹 skill_repo: 当前技能库快照 Returns: action: INSERT | UPDATE | DELETE target_skill: 新增/修改/删除的技能文件 """...

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

3.1 主实验数据

3.2 为什么 8B 打赢 Pro

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

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

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

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

3.3 DELETE 能力的消融实验

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

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 分组机制的消融数据

分组机制是整个论文最硬的设计——移除它的影响超过移除任何单个 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 / UPDATEimportosfromdatetimeimportdatetime,timedeltafrompathlibimportPath SKILL_DIR=Path.home()/".codebuddy"/"skills"USAGE_LOG=Path.home()/".codebuddy"/"skill-usage.log"THRESHOLD_DAYS=30defscan_skills():"""按 SkillOS 三决策视角扫描 skill 目录"""now=datetime.now()recent_usage=parse_usage_log(USAGE_LOG,days=THRESHOLD_DAYS)results={"keep":[],"update_candidate":[],"delete_candidate":[]}forskill_pathinSKILL_DIR.glob("*/SKILL.md"):skill_name=skill_path.parent.name usage_count=recent_usage.get(skill_name,0)ifusage_count==0:results["delete_candidate"].append({"name":skill_name,"reason":f"{THRESHOLD_DAYS}天未使用"})elifusage_count<3:results["update_candidate"].append({"name":skill_name,"reason":f"低频使用（{usage_count}次），考虑合并"})else:results["keep"].append({"name":skill_name,"usage":usage_count})returnresultsdefparse_usage_log(log_path,days):"""解析使用日志，返回 {skill_name: count}"""cutoff=datetime.now()-timedelta(days=days)usage={}ifnotlog_path.exists():returnusagewithopen(log_path)asf:forlineinf:# 格式: 2026-05-08 10:30 | skill_nameparts=line.strip().split(" | ")iflen(parts)<2:continuets=datetime.strptime(parts[0],"%Y-%m-%d %H:%M")ifts>=cutoff:usage[parts[1]]=usage.get(parts[1],0)+1returnusageif__name__=="__main__":results=scan_skills()print(f"✅ 保留:{len(results['keep'])}")print(f"⚠️ 候选 UPDATE:{len(results['update_candidate'])}")foriteminresults["update_candidate"]:print(f" -{item['name']}:{item['reason']}")print(f"❌ 候选 DELETE:{len(results['delete_candidate'])}")foriteminresults["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 的长期协作，欢迎在评论区聊聊你的"记忆爆炸"经验。