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 做的就是让这层经验可以随着真实任务继续迭代。