SkillOpt 让你的 Skill 实现自进化
上周，在介绍 bugfix 小工具 Superlog 时，热心群友 Frank 提到了一个小工具 SkillOpt，表示它能把 Skill 当作模型来训练，基于方法论来训练你的 Skill。
所以，本文就带你来领略下这个开源项目的有用之处。
SkillOpt 是什么
我们先来简单地认识下 SkillOpt。它是微软开源的一个 text-space optimizer，也就是“在文本空间里优化 skills 的工具”。
根据 SkillOpt 的定义，我们可以明白它优化的对象不是模型参数，而是一份自然语言写成的 skill 文档。这份文档通常是由 Markdown 编写而成，里面有写任务流程、工具规则、项目约定、错误处理方式、输出格式、边界条件，甚至是一些只有长期使用者才知道的经验。
换句话说，SkillOpt 处理的是 Agent 外部的经验层。它最后留下的东西也很简单，就是一份best_skill.md。真正部署时，Agent 依然用原来的模型，推理链路也不用变；只是原本手写的 skill，变成了一份经过任务验证的 skill。
所以，SkillOpt 更关注的是：把 skills 放进一套可以训练、验证和持续更新的流程里。
图注：从人工优化 skill 到 SkillOpt 自动迭代 skill
这张图可以先按左右两部分来看。
左边是传统做法：Agent 跑任务，遇到问题之后，人再回头修改 skill。这个流程能跑起来，但它很依赖个人经验。哪条规则该加，哪条规则该删，哪次修改真的有效，往往只能靠感觉判断。
右边是 SkillOpt 的做法：Agent 依然要带着当前 skill 跑任务，但任务执行之后会留下轨迹和结果。optimizer model 会根据这些样本提出修改建议，修改后的 skill 还要经过验证集筛选。通过验证的版本，才会被留下来。
这样一来，skill 的更新就从“人工补规则”，变成了“任务驱动的迭代”。
运行原理
如果把右边这套流程单独抽出来，可以压缩成下面这条主线：
图注：SkillOpt 的 skill 迭代循环 SkillOpt 优化的是 Agent 使用的 skill 文档，模型权重保持不变。这张图主要是帮我们对齐后面的环节：
Current Skill是起点，也就是当前那份 skill 文档。Rollout负责让 Agent 带着它去跑任务。Reflect负责回看任务轨迹，分析哪里成功、哪里失败。Update是把修改写回 skill。Validation Gate是验证门控，用来判断这次修改能不能留下。Best Skill是最终通过验证的版本。
图里为了简洁，省略了Reflect和Update之间的两个内部动作：aggregate和select。Reflect之后，optimizer model 会拿到一批修改建议，但这些建议不会立刻全部写回 skill。SkillOpt 会先用aggregate把相似建议收拢到一起，再用select从候选建议里挑出真正需要写回去的部分，用来控制每一轮写回 skill 的修改量。
这样处理主要是为了避免 skill 越改越臃肿。失败样本一多，很容易生成一堆零散规则；如果每条规则都写进 skill，文档会越来越难维护，也可能影响原本已经稳定的经验。所以，SkillOpt 会先压缩候选修改，再进入Update。写回之后，还要经过Validation Gate：修改后的 skill 会重新在验证集上跑一遍，通过验证的版本才会被保留；没有提升的修改会被拒绝。
一个本地使用案例
为了让 SkillOpt 的用途更有实感，Frank 告知了小七他的实践姿势。
他的场景是知识库管理和代码驱动的 workflow。早期 skills 主要是根据个人经验写出来的，也有一些版本迭代，但整体还是人工维护。
这次他拿 GPT-5.4 + cursor-agent 做了更深的迭代和测试。
他的验证方式很直接：同一类任务，对比带 skill 和不带 skill 的输出质量，看 Agent 在真实流程里是不是更稳定。
先看第一组结果。当前已完成两轮有代表性的本地迭代：
图源：Frank
这组结果比较好理解，像init / update / check这种任务，本身就强依赖流程约定。如果 Agent 不知道一开始该初始化什么、更新时该改哪里、检查时该看哪些口径，就很容易漏步骤。带上 skill 以后，它不需要每次从零推断流程，结果自然更稳定。
第二项“非 canonical 文档回归”也很典型。在知识库和项目文档里，经常会存在多个看起来都相关的文件。人知道哪份是权威来源，Agent 未必知道。如果 skill 里写清楚了 canonical source 的判断方式，Agent 在回归这类任务时就更不容易被旁支文档带偏。
再看第二组数据。当前已完成 4 轮有代表性的本地迭代：
图源：Frank
这组数据更贴近日常工程问题。附件 API、Webhook、评论权限都是容易让 Agent 误判的细节。因为它们不只是代码逻辑，还涉及权限、状态、调用顺序和产品规则。
任务跨项目迁移也一样。表面上只是把任务从一个项目挪到另一个项目，实际可能涉及负责人、状态、关联文档、历史记录、权限边界。Agent 如果只按字面执行，很容易完成了“迁移”这个动作，却漏掉迁移后的状态一致性。
有意思的是，第三轮“迁移失败路径显式 guardrail”里，with_skill 和 without_skill 都是 1.00。这说明 skill 并不会在所有任务上都带来明显差异。有些任务本身足够明确，模型裸跑也能做好；真正容易拉开差距的，往往是那些容易漏步骤、容易走偏、强依赖项目经验的任务。
回到 SkillOpt，它最后留下的best_skill.md看起来仍然只是一份 Markdown 文档，但这份文档已经经过任务执行、失败分析和验证集筛选。对于正在把 Agent 放进长期工作流的人来说，这比临时补几句 prompt 更像一套可持续维护的办法。
Agent 越来越像一个长期工作的执行体，skills 也开始承担外部经验层的角色。SkillOpt 做的，就是让这层经验可以随着真实任务继续迭代。