关键词SkillOS | AI Agent | Self-Evolving Agent | Skill Curation | 持续学习 | RL for Agent | Memory Management | Prompt Engineering你读完能得到Google Cloud AI Research UIUC 2026 年 5 月论文 SkillOS 的核心架构拆解INSERT / UPDATE / DELETE 三操作对 Agent 性能的消融实验数据Grouped Task Streams 解决延迟反馈问题的工程实现一份可直接落地到个人 Agent 系统Claude / Cursor / 自研 Agent的 Skill 策展 Checklist一段用 Bash 实现的 Skill / Memory 三决策脚本真实代码可复制一、问题背景为什么持续学习是 Agent 领域最难的问题在构建 AI Agent 系统的过程中开发者通常会遇到一个反直觉的事实基础模型Foundation Model在变强但你的 Agent 并没有。两者的区别维度基础模型变强Agent 变强主体OpenAI/Anthropic/Google 训新 base你本地的某一个 Agent驱动预训练数据 RLHF部署后的真实交互受众全世界用户仅当前用户周期按月/季度理论上应该按天绝大多数在线 AgentChatGPT、Claude、Cursor 等虽然底层模型在升级但这一个 session 的 Agent 并不会因为你和它交互而进化。每次新对话它都像第一天上岗的实习生。这就是 SkillOS 要解决的问题让 Agent 真的能学会一件事以后都会。论文出处SkillOS: Learning Skill Curation for Self-Evolving AgentsGoogle Cloud AI Research UIUC (Jiawei Han 团队)arxiv 2605.06614, 2026-05-07二、SkillOS 核心架构角色分离 只训策展员2.1 三角色解耦设计SkillOS 的第一个关键设计是把干活的人和管理技能库的人彻底拆开┌─────────────┐ ┌──────────────┐ │ Executor │ ──问─ │ Curator │ │ 执行器 │ │ 策展员 │ │ 冻结不训练 │ -答─ │ 只训这一个 │ │ (32B/Pro) │ │ (8B) │ └─────────────┘ └──────────────┘ ↕ ↕ ┌─────────────────────────────────┐ │ SkillRepoMarkdown 技能库 │ │ ├── find_item.md │ │ ├── open_container.md │ │ ├── navigate_menu.md │ │ └── ... │ └─────────────────────────────────┘角色实现训练与否职责ExecutorQwen3-32B / Gemini-2.5-Pro❌ 完全冻结接任务 → 检索技能 → 执行Curator8B 小模型✅ 通过 RL 训练观察执行过程 → 决定三操作SkillRepo一堆 .md 文件N/A存储结构化技能描述工程亮点冻结 Executor这意味着可以复用任何现成大模型不需要为每个用户都训一份个人模型。成本可控。只训 Curator决策空间很小就三个动作参数量可以做小8B训练成本可控。Markdown 技能库人类可读、可手改、可 diff、可版本管理。这是一个非常聪明的技术选型。2.2 三操作的定义Curator 每次触发时做出三种操作之一# 伪代码Curator 的决策空间classCuratorAction(Enum):INSERTinsert# 新增一个技能文件到 SkillRepoUPDATEupdate# 改写一个现有技能文件DELETEdelete# 从 SkillRepo 移除一个技能文件defcurator_step(trajectory,skill_repo): Args: trajectory: Executor 最近一批任务的执行轨迹 skill_repo: 当前技能库快照 Returns: action: INSERT | UPDATE | DELETE target_skill: 新增/修改/删除的技能文件 ...三、关键实验结论8B 击败 Pro3.1 主实验数据方案CuratorExecutor成功率提升训练成本No-Memory baseline—Qwen3-32B0 (基线)0RAG-MemoryRetrievalQwen3-32B3.2%0Pro-as-CuratorGemini-2.5-ProQwen3-32B5.1%推理贵SkillOS8B trainedQwen3-32B9.8%16×H100×3 天3.2 为什么 8B 打赢 ProPro 模型在策展时用的是通用聪明——它知道什么是好 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 设计会遇到两个问题信用分配性能提升到底是哪次 Curator 决策带来的反馈周期如果反馈要等几十个任务才出现训练样本效率极低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 三决策catEOF~/.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 必须在日报里输出三个数字INSERTX, UPDATEY, DELETEZ - 三者都为 0 说明今天做梦效率低需要反思 EOF5.2 Skill Repository 定期扫描# skill_curation_scan.py# 每周扫描一次本地 skill 目录标记候选 DELETE / UPDATEimportosfromdatetimeimportdatetime,timedeltafrompathlibimportPath SKILL_DIRPath.home()/.codebuddy/skillsUSAGE_LOGPath.home()/.codebuddy/skill-usage.logTHRESHOLD_DAYS30defscan_skills():按 SkillOS 三决策视角扫描 skill 目录nowdatetime.now()recent_usageparse_usage_log(USAGE_LOG,daysTHRESHOLD_DAYS)results{keep:[],update_candidate:[],delete_candidate:[]}forskill_pathinSKILL_DIR.glob(*/SKILL.md):skill_nameskill_path.parent.name usage_countrecent_usage.get(skill_name,0)ifusage_count0:results[delete_candidate].append({name:skill_name,reason:f{THRESHOLD_DAYS}天未使用})elifusage_count3: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}cutoffdatetime.now()-timedelta(daysdays)usage{}ifnotlog_path.exists():returnusagewithopen(log_path)asf:forlineinf:# 格式: 2026-05-08 10:30 | skill_namepartsline.strip().split( | )iflen(parts)2:continuetsdatetime.strptime(parts[0],%Y-%m-%d %H:%M)iftscutoff:usage[parts[1]]usage.get(parts[1],0)1returnusageif__name____main__:resultsscan_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 的长期协作欢迎在评论区聊聊你的记忆爆炸经验。