上周聊到 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 后，Agent 无需每次从零推断流程，结果自然更加稳定。

第二项“非 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 所做的，就是让这层经验能够随着真实任务持续迭代。