大多数构建LLM代理人的团队，都还在手动维护一堆prompt模板、few-shot示例和硬编码的工具调用链。每次新任务上线，就得重新写一堆“技能”，上线后发现效果一般，再手动迭代——效率低到让人怀疑“agentic AI”到底是不是真命题。
Google最新SkillOS论文，直接把这个痛点翻转了。它把技能管理升级成一套完整的“操作系统”：代理人不再是被动执行prompt，而是拥有一个可持久化、可自我演化的SkillRepo。执行器只负责用技能，curator负责观察轨迹、判断成败，然后自动增删改技能仓库。整个循环用强化学习闭合，代理人在真实环境中“打怪升级”，技能越用越聪明。
这不是又一个“让LLM自己写prompt”的玩具实验，而是真正把记忆管理从人类手里解放出来的架构级创新。
我起初以为，提升代理人性能必然要全量fine-tune执行器模型。后来深入拆解SkillOS源码思路和训练流程，才发现Google的杀手锏恰恰是“冻结执行器，只训练curator”。这看似反直觉，却把计算成本压到最低，同时让技能仓库像人类专家的知识体系一样持续进化。
SkillOS的核心三件套：像操作系统一样组织代理人记忆
SkillOS把技能管理抽象成操作系统范式：SkillRepo就是文件系统，curator就是内核调度器，executor就是应用层。
Agent Executor（冻结状态）：这是真正干活的LLM。它只做一件事——从SkillRepo里通过BM25检索top-k相关技能，然后带着任务描述和技能内容去和环境交互，产生完整trajectory。训练期间它的权重完全不动，性能提升100%来自仓库里的技能质量提升。
Skill Curator（可训练）：这是真正的大脑。它接收executor的完整执行轨迹、正确性信号（由独立Qwen3-32B judge给出）和之前检索到的技能，判断要不要insert新技能、update现有技能，还是delete冗余技能。它本身是一个ReAct风格的LLM，输出结构化的function calls。
SkillRepo：持久化存储，所有技能以Markdown文件形式存在。每份技能严格遵循YAML frontmatter + 正文结构：
--- name: frontend-design-principles description: 当用户要求设计网页UI时，先加载本技能，遵循响应式、对比度、无障碍三条核心原则，避免视觉混乱 --- # Workflow 1. 分析用户提供的设计需求和现有页面截图 2. 确定布局类型（dashboard / marketing / form等） 3. 应用... # When NOT to use - 纯代码生成需求（此时应调用programming-patterns技能）这种结构化设计让BM25检索极其高效，也让技能天然可组合、可复用。
技能发现的完整闭环：从原始轨迹到可复用知识
SkillOS的真正硬核在于“有机发现”机制，而不是人工编写。整个过程形成一个清晰的强化学习循环，我用Mermaid时序图直观展示：
- Executor带着已有技能硬着头皮去完成任务，产生真实成败轨迹。
- Curator拿到“病例”（轨迹+诊断结果），像资深医生一样提炼通用规律。
- 它输出精确的操作：新技能insert时给出完整MD内容，update时精准替换，delete时移除低价值项。
- 外部judge再给curator的输出打内容质量分，形成RL reward，驱动curator越训越会“写技能”。
训练过程中curator的行为也呈现出人类专家进阶的特征：早期疯狂insert填满空仓库，中期update为主开始精炼，后期delete占比微升开始做减法。这正是知识管理最健康的演化路径。
传统技能工程 vs SkillOS的本质权衡
| 维度 | 传统手动技能工程 | SkillOS自演化框架 | 核心权衡 |
|---|---|---|---|
| 技能创建 | 工程师手动编写prompt | Curator从真实轨迹自动提炼 | 人工成本 vs 探索成本 |
| 迭代速度 | 任务上线后人工review、改prompt | 每次失败/成功都触发curator自动优化 | 延迟反馈 vs 实时闭环 |
| 可扩展性 | 技能数量增长后检索和维护爆炸 | BM25 + 结构化MD，天然支持几百上千技能 | 短期简单 vs 长期系统韧性 |
| 执行器依赖 | 经常需要升级底层模型 | Executor完全冻结，性能只取决于技能仓库 | 算力浪费 vs 参数效率 |
| 知识保鲜 | 容易过时、重复劳动 | 持续从生产轨迹中学习，自动prune | 静态文档 vs 动态OS |
为什么SkillOS可能是下一代代理人基础设施
它真正解决了当前agent最大的瓶颈：知识无法累积、技能无法复用、每次任务都像从零开始。SkillOS把“记忆”变成了可审计、可版本化、可自我优化的资产。未来当我们谈论“生产级AI代理人”时，SkillRepo的质量很可能成为比模型参数量更重要的护城河。
更深一层，这套范式把代理人从“聪明的一次性工具”升级成了“有操作系统支撑的智能体”。executor负责执行，curator负责进化，repo负责存储——三者分工明确，又通过RL形成正反馈。这才是真正的agent OS。
在自己的项目里落地SkillOS思路前必须先做的三件事
- 选一个高频、边界清晰、容易产生可观测轨迹的窄领域（比如代码生成、UI设计、数据分析），先用现有agent harness跑几百次任务，收集真实trajectory。
- 把技能格式标准化：严格YAML frontmatter + Workflow + When NOT to use + 示例，描述字段必须为BM25检索优化。
- 搭建最小curator循环：用一个强judge模型先人工/半自动评估技能质量，形成早期reward信号，再逐步把curator本身放进RL训练。
做完这些，你会发现代理人的表现开始出现“复利”——今天积累的技能，会直接让明天完全不同的任务变得更简单。
这套思路不只属于Google。它已经可以被任何有agent构建能力的团队复现。真正拉开差距的，不是谁先用上GPT-5.5，而是谁先把技能仓库从“临时笔记”升级成“公司级操作系统”。
你目前构建的agent最头疼的技能管理痛点是什么？是检索不准、技能老化、还是难以提炼通用模式？欢迎在评论区分享你的场景，我们一起拆解如何用类似SkillOS的思路解决。
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。
