Skills 自进化综述：Agent 如何沉淀、验证和复用执行经验

公众号名称：居丽叶的大模型视界

作者名称：居丽叶

发布时间：2026-07-04 18:20

大家好，我是居丽叶。

最近半年，Skills 自进化突然变热了，学术圈和工业界同时在往这个方向探索。今天我们就来聊聊：

目前主流的 Skills 自进化，有哪些实现路线？它们各自解决什么问题？如果你要把它用到自己的 Agent 项目里，应该怎么设计？

我会把最近半年重要的几类工作放在一起看：Hermes、Trace2Skill、CoEvoSkills、SkillX、SkillClaw、SkillOpt、SkillOS，以及 SKILL0 / Skill1 这一组 RL 路线。

读完你应该能分清楚：

什么时候应该让 Agent 在线生成 Skill
什么时候应该从 Trace 里离线蒸馏 Skill
什么时候需要 Verifier
什么时候要把 Skill 当成外部参数来优化
什么时候才值得上 RL
以及怎么把这套东西落到自己的项目里

定义

先给一个工程化的定义：

Skills 自进化，指的是 Agent 在执行任务的过程中，把可复用的操作经验沉淀为外部 Skill，并通过检索、使用、验证、修补、发布和淘汰，让这个 Skill 集合持续变得更适合后续任务。

这个定义里面有这样几个关键词：

外部化、可验证、可回滚、可传播。

为什么强调外部化？

因为对大多数工程团队来说，直接让模型权重在线学习很难。闭源模型没法改权重，开源模型在线训练成本高、安全风险也大。更现实的路径是：先把经验写成 SKILL.md、脚本、模板、约束、验证步骤这类外部工件。

它跟 Memory 不一样。

Memory 更多回答”是什么”：用户偏好是什么、环境变量怎么配、这个工具有什么脾气、项目约定是什么。

Skill 回答”怎么做”：遇到某类任务时，应该先检查什么、调用哪些工具、常见坑在哪里、怎么验证结果。

为什么是现在？

因为 Agent 正在从 Context 阶段，走到 Harness 和 Loop 阶段。

以前你优化的是一句 Prompt：“你是一个专业的代码助手，请一步一步思考。”

后来你开始优化 Context：“哪些文件要放进上下文？哪些历史要压缩？哪些检索结果更相关？”

再往后，真正难的是 Harness：Agent 在什么环境里执行？能调用哪些工具？权限怎么卡？失败怎么恢复？怎么验证？怎么审计？

而 Skills 自进化，卡在 Harness 和 Loop 的交界处。

Harness 给 Agent 提供一次执行的工具、权限、上下文和验证环境；Loop 让系统反复执行、观察、总结、更新、再执行。Skills 自进化要回答的问题是：

Agent 每一轮执行留下来的经验，怎么变成下一轮更稳定的能力？

这件事如果做得好，收益很明显：

1.不用每次从零探索同一类任务
2.项目里的坑可以被系统记住
3.一个人或一个 Agent 发现的流程，可以复用给其他 Agent
4.Skill 是文本和文件，能审计、能 diff、能回滚
5.相比改模型权重，更轻量，落地成本更低

但它的难点在于：

经验不是天然等于 Skill。

一次成功轨迹里可能有很多偶然因素；一次失败可能是环境问题，不是 Skill 问题；一个 Skill 对强模型有帮助，对弱模型可能是噪声；一个用户场景里有用的步骤，放到另一个用户环境里可能直接错。

所以主流方法的区别，本质上都在回答同一个问题：怎么把嘈杂、局部、偶然的执行经验，变成稳定、可迁移、可验证的 Skill？

下面我们按实现路线来讲。

路线一：Hermes，在线闭环，边用边沉淀

“ 链接：https://github.com/NousResearch/hermes-agent

最容易理解的一条路线，是 Hermes 代表的在线 Skills 闭环。

它的思路很直接：Agent 在真实使用过程中发现复杂流程，就自动保存为 Skill；后续任务遇到类似场景，按需加载；如果使用中发现 Skill 缺步骤、命令错、坑点没写，就立刻 patch。

Hermes 的 Skills 闭环拆成七步：

1.创建。System Prompt 里写了一条触发规则：“完成一个涉及 5 次以上工具调用的复杂任务、修复了一个棘手的错误、或发现了一个值得复用的工作流后，把方法保存为 Skill。“Agent 自主判断该不该记，不需要人催。触发后调用skill_manage(action=“create”)，文件过七道安全检查：名称验证、大小限制（≤100KB）、分类验证、Frontmatter 格式校验、名称冲突检查、原子写入、安全扫描。
2.索引。一个用户可能有几十上百个 Skill，每次启动都递归扫描目录、解析 frontmatter，开销不可忽视。Hermes 做了两层缓存：进程内 LRU 缓存（最多 8 条，缓存键是五元组：目录路径、外部目录、工具集、工具集组、平台标识）和磁盘快照（只存 manifest，mtime 变了才触发全量扫描）。LRU 命中约 0.001ms，快照命中约 1ms，全量扫描 50-500ms。
3.条件激活。不是所有 Skill 在所有时候都该出现。Frontmatter 里的requires_toolsets、fallback_for_toolsets、platforms字段决定了一个 Skill 在当期环境下是否可见。这解决的是索引膨胀问题——System Prompt 里塞太多 Skill，token 成本直接上天。
4.渐进加载。三级披露策略。Tier 0（索引）：System Prompt 里只放 Skill 名称和描述，每个约 20 tokens，100 个 Skill 只增加 2000 tokens。Tier 1（按需加载）：Agent 调用skill_view(name)加载完整内容。Tier 2（支撑文件）：API 文档、模板等按需加载。这就是 Anthropic Claude Skills 启发的”渐进式披露”。
5.注入。这是整个闭环里最反直觉的决策。Skill 内容加载后，作为一条 User Message 注入（前面加[SYSTEM: …]前缀），而不是追加到 System Prompt。为什么？为了保护 Prompt Cache。Anthropic 的 Prompt Caching 允许缓存 System Prompt 的处理结果，能省 90% 以上的 token 成本，但前提是 System Prompt 在整个对话过程中不能变。代价是 User Message 的指令跟随权重通常低于 System Prompt，Hermes 用前缀和强制措辞来弥补。这是一个深思熟虑的成本-效果权衡。
6.自改进。System Prompt 写死了触发条件：“如果你加载的 Skill 缺少步骤、命令错误、或遗漏了你发现的坑点，在当前任务结束前更新它。“注意两个强制要求：patch immediately 和 before finishing。Patch 操作复用了文件编辑工具的 Fuzzy Match 引擎——LLM 回忆 Skill 内容时常有微小差异，严格字符串匹配会让大量合理 patch 失败。Patch 成功后清理缓存，但效果要到下一个对话才体现（Prompt Cache 保护），形成最终一致性模型。
7.安全扫描。Skills 系统最大的安全隐患是 Skill 本身成为攻击载体。90+ 种威胁正则模式，覆盖环境变量泄漏、越狱攻击、路径穿越、隐形字符。还有符号链接逃逸检测——恶意 Skill 可能通过 symlink 指向/etc/shadow。不同来源的 Skill 适用不同信任策略：内置 Skill 全放行，社区 Skill 遇到 caution 级别就阻止，Agent 自建 Skill 遇到 dangerous 级别询问用户。

这条路线非常适合个人 Agent、桌面 Agent、开发者工具。它离真实使用最近，你今天踩的坑，明天就能沉淀成 Skill。

但在线闭环最大的风险也在这里：它太容易把局部经验固化成全局规则。

比如某次部署失败，是因为这个项目的.nvmrc写错了。Agent 如果总结成”部署前必须修改 Node 版本”，这就是错的。正确的 Skill 应该写成：“部署前检查.nvmrc、package.json engines和平台运行时版本是否一致；若不一致，先向用户确认，而不是直接修改。”

所以 Hermes 这类在线系统一定要有几个工程阈值：简单任务不存；新 Skill 先是草稿；Patch 保留 diff 和理由；危险操作过安全扫描；不同来源有不同信任等级。

路线二：Trace2Skill，把大量轨迹蒸馏成可迁移 SOP

“ 链接：http://arxiv.org/pdf/2603.25158 机构：Qwen

Trace2Skill走的是离线批量归纳的路线，核心思路是：不要跑一条轨迹就改一次技能，先攒一大批带成败标记的完整执行记录，再统一从中提炼稳定通用的操作规范，逻辑和资深专家梳理标准化SOP完全对齐。

就像人类也不会只靠一次excel的操作就定下永久流程，一定是看多组案例，分清偶发情况、孤立bug和反复出现的固定规律，最后整理出一套精简通用的操作手册，Trace2Skill用的就是这套思路。

先看这张对比图，左边是常规串行迭代方式，轨迹按顺序逐条流入，每跑完一条就增量更新技能，最终规则会受执行先后顺序干扰，容易把单次偶然问题固化成通用要求；右边Trace2Skill会先把所有轨迹汇总到统一轨迹池，所有执行经验平等参与归纳，不会产生时序偏见，最终只沉淀高频可复用逻辑，剔除一次性临时方案。

整套流程分完整三步，对应下面的Pipeline图：

1.先用固定Agent搭配初始技能批量跑完所有任务，靠校验工具自动区分成功、失败两类轨迹完整存档；
2.启动多组并行分析子智能体，成功轨迹交给正向分析师提炼高效复用步骤，失败轨迹交由交互式故障分析师，复现报错、验证修复逻辑后输出针对性优化补丁，每条轨迹独立分析互不干扰；
3.所有补丁统一送入独立Merge算子分层合并，自动去重、消解规则冲突，按出现频次区分核心通用流程和小众边缘场景，最终输出一整套完整、无冗余的全新Skill目录。

它和常见的记忆检索方案有本质取舍：记忆检索是推理阶段实时拉取相似历史案例塞进上下文，开销大、跨模型跨任务很难复用；Trace2Skill选择离线一次性压缩全部经验，推理时不用额外检索任何原始轨迹，只加载一份静态技能文件就行。

论文实验也验证了这套压缩逻辑的优势，蒸馏得到的技能不受原模型限制，既能适配不同参数量底座，也能跨模型家族、分布外任务直接迁移，excel场景下小模型产出的技能给大模型使用，指标最高能提升57.65个百分点。

这套方案很适合有标准化任务、配套自动校验工具的场景，表格/PDF/PPT自动化、数学推理、文档问答、标准化代码修复这类Agent都能落地。

路线三：CoEvoSkills，用生成器和验证器一起进化

“ 链接：https://arxiv.org/pdf/2604.01687

像 Trace2Skill 这类方案，前提是要有大批量标注好成功 / 失败的执行轨迹，但很多真实业务场景根本不具备这个条件：科研分析、复杂软件修复、企业长链路数据流水线都是开放任务，拿不到标准答案，也没法提前批量产出规整轨迹，很难靠离线蒸馏产出高质量技能，CoEvoSkills 就是适配这类场景的闭环自进化方案。

先分清关键概念：很多人误以为 Skill 只是一段prompt，但论文严格区分了工具和生产级技能。工具只是单个独立函数；完整技能是一整套多文件文件夹包，包含 SKILL.md 流程文档、可执行脚本、模板、领域参考资料，单段 prompt 承载不了多步骤复杂任务的完整执行逻辑，这也是单次生成技能普遍效果很差的原因。

CoEvoSkills 最巧妙的设计是两套独立 AI 隔离互评打磨，这里先解释两个陌生名词：

1.Surrogate Verifier（代理仿真校验器）：独立的 AI 校验单元，不掌握最终标准答案，只模拟各类测试场景、排查技能漏洞，用来做高频迭代自检；

2.真值校验器：掌握任务真实验收标准，只会输出 “合格 / 不合格”，不会透露具体错在哪，仅作为最终终审；

所谓 “协同打磨”，就是写技能的 AI 和挑错的 AI 来回循环，不断修复技能里的各类问题。

两套 AI 完全隔离运行，不会互通思考内容，规避 “自己写的逻辑自己看不出漏洞” 的自审盲区：Skill Generator 负责从零迭代产出完整多文件技能包；代理仿真校验器看不到生成器的思考过程，只根据任务要求、技能运行后的产出文件自主设计测试用例，输出精准故障原因和可落地修改方案。二者循环优化，只有仿真校验全测通过后，才会送入真值校验器终审，而且全程不会把真值的测试细节泄露给生成器，避免技能专门投机适配验收标准、丧失泛化能力。

完整打磨循环流程：

1.生成器从零产出完整多文件技能包，放到沙箱环境运行，生成任务输出文件；
2.独立代理校验器批量生成测试规则，逐条检测，输出详细 bug 根因和修改建议；
3.生成器根据反馈修改文档、脚本、模板，改完重新交给校验器复测；
4.多轮自检全部达标后，送入真值校验做最终审核，仅返回通过 / 不通过；
5.如果终审判定不合格，代理校验器会自动设计更严苛的测试用例，开启新一轮打磨。

这种隔离互评的模式，能跳出生成器固有的思维定式，揪出文件依赖、执行流程、输出规范等隐性结构性缺陷。实验结果很直观：在 SkillsBench 基准测试中，CoEvoSkills 任务通过率达到 71.1%，远高于人工手写技能（53.5%）、Anthropic 官方 Skill-Creator（34.1%）等所有对比方案，仅 5 轮迭代就能全面超越人工制作的技能。

同时这套方法产出的技能通用性极强，不存在模型绑定问题：用 Claude Opus 打磨出的技能，直接给到 GPT、通义千问、DeepSeek 等 6 家不同厂商大模型使用，全部能带来 35～44 个百分点的效果提升，证明它沉淀的是通用任务处理流程，不是只适配单一模型的专属逻辑。

从全领域评测能看到一个问题：人工编写技能存在人机认知错位，部分领域（自然科学）人工技能甚至会降低Agent效果，而CoEvoSkills产出的技能贴合大模型真实推理、工具调用习惯，11个评测领域里9项表现优于人工技能。

路线四：SkillX，把经验组织成分层技能知识库

“ 链接：https://arxiv.org/pdf/2604.04804

SkillX 回答的是另一个问题：经验应该以什么形态存，才能被不同 Agent、不同环境复用？

它给出的解法是三级分层模块化技能架构，试图解决传统单文档技能杂乱臃肿、检索低效、迁移性差的问题。

1.Planning Skills（规划层技能）：顶层全局调度，定义完整任务的拆解逻辑、步骤先后顺序、分支判断、前置依赖；比如客服场景先判断用户诉求、再匹配对应处理链路，规定退款 / 补发两条不同执行分支。
2.Functional Skills（功能层技能）：中层可复用子流程，封装一组联动工具，专门完成固定子目标；比如统一封装「查询物流 + 整理物流说明」整套复用逻辑，任意工单任务都能直接调用。
3.Atomic Skills（原子层技能）：底层工具基础规范，绑定单个 API / 工具，写明入参格式、返回结构、常见报错、调用限制；比如订单查询接口的字段定义、超时错误处理规则。

三层结构天然适配复杂交互类 Agent，举个例子，航空理赔工单的三层分工：

Planning：先识别用户诉求是否为延误理赔→调取用户信息→匹配订单→核算赔付→推送通知；识别话题切换时自动跳转对应流程
Functional：封装「检索历史航班 + 核对延误记录」子流程，所有理赔单通用
Atomic：航班查询 API 传参规则、接口限流报错规避

SkillX 另一个重要的设计是 plug-and-play：用强模型（GLM-4.6）自动构建 SkillKB，再插到弱一些的 Agent 上复用。背后的思想是：强模型负责探索和总结，弱模型负责低成本执行。

路线五：SkillClaw，把多用户经验变成集体进化

“ 链接：https://arxiv.org/pdf/2604.08377 机构：高德

前面 Trace2Skill、CoEvoSkills、SkillX 默认都是单 Agent 或单项目，可线上真实落地的 Agent 产品往往是多租户、多用户共用一套技能库，每个使用者会碰到独有的环境差异、工具版本 bug、任务边界问题，各自踩坑、各自摸索，经验完全互相隔绝，形成 “经验孤岛”，单个用户的试错教训没法沉淀给全体使用者，系统整体能力长期没法持续迭代，SkillClaw 就是专门解决这个规模化产品痛点的

集体进化框架。

整套全自动循环链路完整跑通多用户经验流转：

1.全量终端用户日常使用 Agent，完整留存每一轮会话的工具动作、环境反馈、最终成败的完整因果轨迹；
2.后台统一归集所有会话数据，按每条会话调用的技能自动分组，同一技能下聚合海量正向成功案例、高频报错故障；
3.内置独立 Evolver 智能分析单元，批量研判聚合后的证据，做出三类决策：优化现有技能、新增独立技能、当前证据不足暂不改动；
4.根据决策修改 / 新增技能，统一更新到全局共享 SkillHub 仓库；
5.完成版本更新后，将迭代后的全套技能同步下发给全部在线用户，所有人复用集体沉淀下来的最优操作规范。

这条路线的价值是打破单用户经验孤岛：单独一个人的会话样本太少，只能看到局部场景，很难分清某个报错是个人环境特例，还是技能通用缺陷；聚合成千上百条不同用户的执行记录后，系统能完整摸清一套技能的真实适用边界，自动识别通用高频故障、局部偶发问题、容易误导 Agent 的模糊指令，针对性补齐流程漏洞，而不是只靠少量样本做片面修改。在 WildClawBench 多领域真实任务基准上，这套多用户聚合进化方案能稳定提升基座模型 Qwen3-Max 的任务完成率。

但多用户路线也有更高的治理要求。因为用户轨迹里可能有隐私、密钥、业务数据；不同用户环境也不一致。你不能简单把 A 用户的经验同步给 B 用户。所以落地 SkillClaw 式系统时，至少要考虑：

轨迹脱敏；
用户/租户隔离；
Skill 变更的灰度发布；
按环境标签分发 Skill；
失败回滚；
谁贡献了经验、谁批准了发布的审计链。

这条路线适合平台型产品，比如企业 Agent 平台、浏览器 Agent、办公自动化 Agent、代码助手生态。

路线六：SkillOpt，把 Skill 当成外部参数来优化

“ 链接：https://arxiv.org/pdf/2605.23904 机构：Microsoft

在前面 Trace2Skill、CoEvoSkills、SkillX、SkillClaw 几条方案里，大多是让模型自由全文重写技能，迭代过程极易出现内容来回震荡、能力持续漂移，看着一直在更新，整体水平却没有稳步上涨。SkillOpt 是落地工程友好度最高的一条路线，它把 Skill 更新看成：Skill 文档本身就是一个可以调控的外部状态，而不是”让模型反思一下然后重写”。

用深度学习来做一个类比（实际上并不会做模型训练）：

参数：Skill.md 技能文档（唯一优化对象）
梯度方向：从 rollout 里分析出的增 / 删 / 替换等编辑方向
学习率：本轮允许修改多少文本（textual learning-rate budget），防止一次性大幅推翻成熟规则
验证集：held-out validation 独立测试任务
拒绝样本：被验证门控拒掉的编辑，进入 rejected-edit buffer
动量 / 慢更新：跨 epoch 保留稳定改动方向

流程是：

1.目标 Agent 带着当前 Skill 跑一批任务
2.优化器模型分析成功 / 失败轨迹
3.提出 add / delete / replace 这类有边界的文本编辑
4.根据 textual learning-rate budget 控制改动幅度
5.在 held-out validation 上验证
6.只有严格提升才接受
7.被拒绝的编辑进入 rejected-edit buffer，作为后续负反馈

这个设计解决了一个常见的问题：很多 Skill 自进化实际上在漂移，不在进化。

今天 Agent 觉得应该加一段，明天觉得应该删一段，后天又把整个文档重写。看起来一直在改，实际没有稳定变好。

SkillOpt 用三个东西把它管住：bounded edit（每次只允许有限修改）、validation gate（没提升就不接受）、rejected buffer（失败改动也要被记住，避免反复犯同样的优化错误）。

实验覆盖了六个 benchmark、七个目标模型、三个执行 harness（direct chat、Codex、Claude Code），在全部 52 个 (model, benchmark, harness) 单元上都是最优或并列最优。在 GPT-5.5 上，相比无 Skill baseline，direct chat 提升 23.5 分，Codex agentic loop 提升 24.8 分，Claude Code 提升 19.1 分。

路线七：SkillOS，用强化学习训练一个专门的 Skill 管理员

“ 链接：https://arxiv.org/pdf/2605.06614 机构：Google

SkillOS 更像是在问：能不能专门训练一个可学习的技能管理员 Curator？全权负责技能仓库全生命周期治理，任务执行器全程冻结、只负责干活不参与技能更新。

它把系统拆成两个角色：

Agent Executor：冻结，不负责学习，只负责检索和使用 Skill 完成任务，所有经验、成败轨迹全部输出给管理员，自身不沉淀任何可复用流程。
Skill Curator：可训练，负责对 SkillRepo 做 insert / update / delete，一个长期运行的 SkillRepo 必须会：插入新 Skill、更新旧 Skill、删除冗余或有害 Skill、保持文档紧凑、让后续任务真的受益。

传统prompt驱动的管理员只能靠固定手写规则增删技能，缺陷非常明显：只能看单条任务即时效果，无法评估一份技能对后续同类任务的长期增益；新增大量技能后仓库臃肿，推理时检索成本暴涨，过时错误技能持续拖垮后续任务。SkillOS 采用 GRPO 强化学习训练 Curator，专门解决延迟奖励这个问题。

训练设计逻辑

1.为什么一定要训练 Curator，不能只写 Prompt 规则？
2.技能治理的收益是延迟的：你在当前任务更新 / 新增的技能，价值不会立刻体现在本次交互，而是作用于未来一批高度相似的同类任务。固定启发式规则只能依据单次任务成败做即时修改，分不清 “短期有用但会污染后续流程” 和 “短期收益低、长期大幅降本” 的技能，极易越治理仓库越混乱。只有通过强化学习，让管理员以一批关联任务整体收益为目标做决策，才能学会长期最优的仓库管理策略。
3.分组式训练样本构造
4.不会单任务单独给奖励，而是把主题、底层逻辑、所需技能相近的任务打包为任务组 G；训练时按时序顺序跑完组内前置任务，Curator 根据交互轨迹增改删技能，再用组内后置同类任务检验本次仓库变更的真实效果。前置任务提供经验素材，后置任务作为长期收益的校验标准，完美匹配技能 “当下更新、后续复用” 的延迟价值特性。
5.复合多维度奖励函数，不只看任务是否做对
6.训练时综合多项指标加权计算回报，避免管理员只追求单次任务通关而产出臃肿仓库：

主奖励：下游后置任务整体完成成功率（核心，衡量技能长期复用价值）
辅助 1：技能操作合法性，杜绝无效 / 错误的增删调用
辅助 2：技能文本抽象质量，惩罚只复制任务特例、无法通用的碎片内容
辅助 3：仓库紧凑度，控制总技能数量，抑制无脑新增、不清理冗余
辅助 4：交互步数优化，优质技能应减少 Agent 工具试错次数

整套 GRPO 训练循环：批量采样任务组→执行前置任务、Curator 操作仓库→运行后置任务统计多维度回报→计算优势值迭代更新管理员策略；经过多轮迭代后，Curator 能自主判断：哪些流程值得固化为新技能、哪些旧技能失效需要淘汰、哪些仅需小幅修订，平衡仓库规模与任务效果。

经过持续迭代训练后，Curator 治理下的 SkillRepo 会自发演化：初期以大量任务专属零散技能为主，随着训练推进，管理员会主动合并同类、清理低价值特例，沉淀出跨场景高层元技能（Meta-Skill），形成分层、高复用的技能知识库，而非杂乱的经验碎片。

实验验证：在多轮交互仿真（ALFWorld/WebShop）、单步数学推理两类主流 Agent 基准中，经过 RL 训练的 Curator，效果全面超越无记忆 Agent、固定规则记忆库（ReasoningBank、MemP）；更关键的是训练得到的管理员具备强泛化能力，更换不同规模、不同架构的冻结执行器、切换全新任务领域后，依然能稳定完成技能治理，无需重新调优或重写prompt。

适配落地场景：面向长期持续在线、任务具备连续业务流、技能库会持续膨胀的 Agent 系统，典型如个人 / 企业智能助理、自动化办公 Agent、仿真游戏交互 Agent、长期数据处理机器人。

路线八：SKILL0 + Skill1，RL 路线——从使用到内化

最后讲 SKILL0 和 Skill1。把它们当一组看，因为它们都在往 RL 方向走，属于”训练时用 Skill，训练完不一定需要 Skill”的路线。但两者解决的问题不一样。

SKILL0：训练时有 Skill，推理时不要 Skill

“ 链接：https://arxiv.org/pdf/2604.02268 机构：LongCat

现在很多方法是在推理时检索 Skill，把 Skill 内容塞进上下文，让模型照着做。这有三个问题：检索会错，错 Skill 污染上下文；Skill 内容有 token 成本，多轮任务里会累计；模型只是”照着读”，并没有真正学会。

所以 SKILL0 的目标是：训练时用 Skill 指导，推理时把 Skill 拿掉。这叫 skill internalization。

具体怎么做？一套三阶段的课程学习：

阶段一：Skill 分组。离线把 Skill 按领域和子任务关联起来。比如 ALFWorld 里，“Look at object in light”这个子任务对应一个 skill file，“Pick heat then place in receptacle”对应另一个。每个 skill file 有一个专门的验证子任务，用来评估它对当前策略还有没有帮助。

阶段二：In-Context RL。训练时把 Skill 和交互历史一起渲染成紧凑的视觉上下文（RGB 图像，经过 vision encoder 压缩），降低 token 开销。Policy 同时学习选择 action 和控制压缩比。奖励函数由任务成功 + 压缩效率共同组成。

阶段三：动态课程。

训练分成多个 stage，每个 stage 的 skill budget 递减。在每个 stage 里，定期评估每个 skill file 对当前策略的 on-policy helpfulness——分别跑”带这个 Skill”和”不带这个 Skill”的验证任务，看差值。只保留 helpfulness 为正的 Skill，按 helpfulness 排序，选 top-m 个继续用。Skill budget 线性衰减到零，Agent 最终在 zero-shot 下执行。

实验结果显示，在 ALFWorld 上，SKILL0 达到 89.8%（7B），比 GRPO 高 8.0 分，比 SkillRL 的 89.9% 持平但 token 成本从 2.21k/step 降到 0.41k/step——不到五分之一。在 WebShop 上，skill-free 推理的 SKILL0（7B）达到 85.1 分 / 74.2% 准确率，超过 AgentOCR 6.5 分 / 14.9 个百分点，token 成本只有 0.46k。

论文中的这个训练动态曲线能直观展示内化全过程：helpfulness 随训练先升后降，早期 policy 还没学会利用 Skill，中期逐渐学会把 Skill 当指导，后期 Skill 被逐步撤掉、policy 自己内化了能力、helpfulness 收敛到零。这就是内化的完整轨迹。

它的优势是推理时轻、没有 Skill 检索开销、少了 runtime 注入噪声。但代价也明显：不如外部 Skill 可审计、更新成本更高、不适合闭源模型、新知识上线没有改 SKILL.md 那么快。

所以也不建议普通业务项目一上来就走 SKILL0。它更像是平台方、模型方在做的事情：把稳定、高频、验证充分的 Skill，逐渐内化到模型能力里。

Skill1：选择、使用、蒸馏，三件事一起训练

“ 链接：https://arxiv.org/pdf/2605.06130 机构：LongCat

Skill1 解决的是另一个问题。

一个 skill-augmented Agent 不是只会”用 Skill”就够了，它至少有三个能力：Selection（当前任务该选哪个 Skill）、Utilization（选中后怎么用）、Distillation（任务结束后怎么把经验蒸馏成新 Skill）。

很多方法只优化其中一部分。检索器是外部模块，蒸馏靠另一个 teacher，执行策略又靠自己的 reward。结果三个部分的目标不一致。

Skill1 的思路是：用一个共享的 task-outcome signal，让同一个 policy 同时学习选择、使用和蒸馏。

具体怎么做？

Selection。

Policy 生成一个自然语言 query，用冻结的 encoder 检索 top-K 候选 Skill，然后自己 re-rank，选出最佳的。Query 质量通过 utilization reward 间接优化——更好的 query 检索到更好的 Skill，任务更容易成功。Re-rank 通过 skill utility trend 来监督——utility 是每个 Skill 的指数移动平均成功率，鼓励 policy 把长期稳定有效的 Skill 排前面。

Utilization。Policy 基于选中 Skill 执行多轮交互，直接拿任务成功信号 r(τ) 做 reward。

Distillation。

Policy 在 rollout 结束后反思轨迹，生成新的 skill strategy 和 scenario description。蒸馏的 reward 来自 task outcome 的高频变化分量——r(τ) 减去当前 skill library 的 best utility baseline。简单理解：如果这次蒸馏能让结果超过库里的最好水平，就说明这个新 Skill 有边际贡献。只有成功轨迹的 Skill 才被收入库。库满时按 utility × log(usage) 淘汰最弱的。

三个 reward 信号全部从同一个 r(τ) 派生：低频趋势归因给 selection，当前结果归因给 utilization，相对趋势的改善归因给 distillation。

ALFWorld 上达到 97.5% 平均成功率，超过 RetroAgent 2.6 分，在全部六个子任务中五个排第一。WebShop 上 82.9% 成功率，与 RetroAgent 的 82.3% 持平。消融实验显示，去掉 selection signal 掉 5.7 分，去掉 distillation 掉 5.1 分，同时去掉两者掉 7.3 分——三个信号互补，缺一不可。

上图的消融实验显示：selection precision、utilization success rate、distillation positive rate 三条曲线同步上升。任何一个信号被拿掉，三条线都受影响。这就是 co-evolution 的证据。

SKILL0 和 Skill1 这组路线，我的定位是：

当 Skill 已经被外部系统验证充分，且你有训练能力时，可以考虑 RL；然而在大多数工程项目早期，先做外部 Skill 闭环和验证门控会更现实。

总结一下上面的八条路线

路线	代表方法	主要输入	更新对象	最适合场景
在线闭环	Hermes	当前任务经验	本地 Skill 文件	个人 Agent、开发者工具
轨迹蒸馏	Trace2Skill	批量成功/失败 trace	可迁移 Skill 目录	有评测集的垂直任务
共进化验证	CoEvoSkills	任务说明、环境、验证反馈	多文件 Skill 包	企业流程、复杂工具链
分层知识库	SkillX	强 Agent rollouts	三层 SkillKB	多工具、可迁移知识库
集体演化	SkillClaw	多用户 session	共享 SkillHub	平台型 Agent 产品
文本优化	SkillOpt	rollout + validation	单个 Skill 文档	有回归集/CI 的项目
Repo 治理	SkillOS	相关任务流	Curator 管理策略	长期运行 Agent
RL 内化	SKILL0	环境交互 + skill curriculum	模型参数（内化）	模型方、平台方
RL 协同	Skill1	环境交互 + reward decomposition	统一 policy（选+用+蒸馏）	可训练 Agent 系统

怎么落地？

如果你现在就要在项目里做一个最小可行版本：

1. Agent 执行任务
   ↓
2. 保存 trace：任务、工具调用、文件变更、验证结果、失败原因
   ↓
3. 判断是否值得沉淀：
  - 是否 5+ tool calls？
  - 是否出现重复失败？
  - 是否有明确验证信号？
  - 是否可能复用到后续任务？
   ↓
4. 生成 Skill 草稿或 patch
   ↓
5. Verifier 检查：
  - 格式是否合法
  - 是否包含 When to Use / Steps / Pitfalls / Verification
  - 是否有危险命令或敏感信息
  - 是否能通过最小回归任务
   ↓
6. 进入候选库
   ↓
7. 人工审核或灰度发布
   ↓
8. 后续任务命中 Skill 后继续收集效果

这套闭环覆盖了 Skills 自进化一条比较完整的链路：执行 → 记录 → 归纳 → 验证 → 发布 → 再评估。

这里最容易被忽略的是最后一步。Skill 发布后，评估才真正开始，远不是终点。你要继续记录：这个 Skill 被检索了多少次？被加载后成功率有没有提高？有没有导致更多工具调用？有没有让上下文变长但收益不明显？有没有在某些环境下反而拖后腿？

如果一个 Skill 长期没有贡献，或者经常被加载但任务失败，就应该降权、改写，甚至删除。这就是 SkillRepo 治理。

面试里怎么讲，才像真的懂？

如果你在面试里被问到”你了解 Skills 自进化吗？”。

可以这样答：

我理解的 Skills 自进化，是把 Agent 执行中的可复用程序性经验，沉淀为可加载、可验证、可回滚的外部 Skill，并通过后续任务反馈持续更新 SkillRepo，不是简单把历史对话存起来。

工程上至少包括六个环节：trace capture、skill candidate generation、verification gate、controlled edit、skill retrieval/loading、post-deployment evaluation。

现在主流路线大概有八类：Hermes 做在线使用中创建和 patch；Trace2Skill 从批量轨迹里离线蒸馏 SOP；CoEvoSkills 引入生成器和 surrogate verifier 共进化；SkillX 把 Skill 分成规划、功能、原子三层做知识库；SkillClaw 做多用户集体演化；SkillOpt 把 Skill 文档当成外部参数做受控文本优化；SkillOS 学一个 curator 来管理 SkillRepo；SKILL0/Skill1 更偏 RL，分别做 skill internalization 和选择/使用/蒸馏的统一训练。

如果我在项目里落地，我会先做外部 Skill 闭环，不会一上来做在线权重更新。先保存 trace 和验证结果，让 Agent 生成候选 Skill，再用测试、规则、安全扫描和人工审核做门控。只有经过多轮验证的高频稳定 Skill，才考虑共享到 SkillHub 或进一步训练内化。

追问一：“为什么不能让 Agent 每次成功后都自动写 Skill？”

单次成功轨迹里有大量偶然因素，直接固化会把局部经验写成全局规则。更稳的做法是先进入候选池，结合多条成功/失败 trace 做归纳，再用 verifier 或回归集验证。对于高风险 Skill，还要有人审、灰度发布和回滚机制。

追问二：“Skill 和 Memory 有什么区别？”

Memory 更偏事实和状态，回答”是什么”；Skill 更偏流程和操作，回答”怎么做”。Memory 可以记录用户偏好、环境细节、工具 quirks；Skill 应该记录任务触发条件、执行步骤、坑点和验证方式。二者都能自进化，但 Skill 的风险更高，因为它会直接指导 Agent 行动。

追问三：“你怎么评估一个 Skill 是否真的有用？”

不能只看最终成功率，要看 skill-aware 指标：检索命中是否准确、加载后成功率是否提升、平均工具调用和 token 是否下降、失败类型是否减少、是否引入安全风险。最好做 no-skill、human-skill、self-evolved-skill 三组对照，并保留 trace 方便失败归因。

— 完 —

欢迎扫码加入我的知识星球，内含多个Agent大项目

更有完整大模型笔记、八股速记、简历模板

戳我了解大模型训练营

内容效果不满意？点此反馈