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