SkillOpt 把 Skill 维护变成可验证训练采样、反思、受限编辑、门禁筛选。原文链接AI 小老六很多 Agent 项目的瓶颈最后都会落到一份文本上。这份文本可能叫SKILL.md也可能是工具调用说明、流程手册、输出规范、故障补救规则。它不参与模型训练却会持续改变 Agent 的判断路径。问题在于我们通常把它当文档维护专家凭经验写一版线上出问题再补几句偶尔让模型帮忙重写。这个过程很快会失控因为没人能说清楚哪条规则真的改善了任务表现哪次改动只是看起来更合理。SkillOpt试图把这个问题改成一个更工程化的命题如果模型权重被冻结能不能把 Skill 文本本身当作可优化对象用真实任务轨迹来训练它答案是可以但前提不是让模型随意重写整份文档而是给 Skill 建一套类似训练循环的机制​采样执行、轨迹反思、受限编辑、验证门禁和版本沉淀​。最终产物不是一个新模型而是一份经过多轮筛选的best_skill.md。Skill 文本为什么需要训练闭环手写 Skill 的问题不在于人写得不够好而在于它缺少反馈纪律。一个 Agent 出错后维护者看到的通常是单个 case这次没查对资料、那次输出格式错了、某个工具调用顺序反了。把这些现象直接补进文档很容易得到一份越来越长、越来越碎的说明书。SkillOpt 的关键判断是​Skill 应该根据一批任务的共同失败模式更新​而不是根据某次事故临场补丁。它把 Skill 放进真实执行环境里让目标 Agent 带着当前版本去跑任务记录答案、工具调用、观察结果和评分。优化器不再凭空“改 Prompt”而是从这些 rollout evidence 里找稳定信号哪些错误重复出现哪些成功路径可以固化哪些规则没有被 Agent 执行。维护方式常见做法主要风险人工手写 Skill专家先写流程再靠线上经验补充规则来源分散难判断是否有效一次性生成 Skill让模型根据需求直接产出完整说明结构漂亮但没有经过任务验证松散 self-revision模型读失败样本后整篇重写容易覆盖原本有效的约束SkillOpt 式优化当前 Skill 跑任务再基于轨迹做小步编辑成本更高但每次改动有验证门禁这里最重要的变化是评价对象变了。Skill 不再只是“读起来是否完整”而是“它是否让冻结模型在任务集上做得更好”。Textual Parameter把 Skill 当作可编辑参数SkillOpt 里有一个很有意思的类比深度学习改的是模型参数SkillOpt 改的是自然语言 Skill。两者当然不是一回事但这个类比能帮助我们理解它为什么强调​小步、验证和回滚​。图目标模型冻结不动Skill 文本作为受控状态被小步更新这张图表达的不是“文本也能反向传播”而是 Skill 文本可以被当作受控状态来更新。目标模型f冻结不动输入任务x和 SkillS一起进入 Agent得到输出y。优化器看到轨迹和评分后只能提出有限的文本编辑。候选版本必须通过验证集才有资格替换当前 Skill。模型训练概念SkillOpt 中的对应物parameterSkill 文档里的自然语言规则gradient direction从执行轨迹推导出的修改方向learning rate每轮允许修改的编辑预算validation check独立 selection split 上的门禁stable training批量采样、缓冲区、长期指导和版本筛选这个设计避免了一个常见坑模型看到失败案例后很容易写出一段“听起来更全面”的新规则但这段规则可能让其他任务变差。SkillOpt 不接受这种凭感觉的改进。候选 Skill 必须在 held-out selection split 上严格变好持平都不算通过。Rollout Evidence先让 Agent 暴露真实错误SkillOpt 的第一步不是写建议而是执行。目标 Agent 带着当前 Skill 跑一批任务系统记录输入、推理轨迹、工具调用、观察结果、最终答案和评分。这个过程相当于训练里的​前向采样​。它的价值不只是拿到分数而是让优化器看到 Agent 实际是怎么偏离预期的。单个失败样本很危险。它可能只是数据噪声、题目歧义或一次工具波动。如果优化器被单个案例牵着走Skill 很快会变成事故备忘录。SkillOpt 采用 minibatch reflection就是为了从一组轨迹里提炼更可迁移的规则。常见的可迁移失败信号包括Agent 总是先查不可靠来源导致后续判断被污染。任务完成后跳过验证输出中混入格式错误或事实断层。工具调用顺序长期颠倒比如先写结论再补证据。遇到不确定信息时直接猜测没有进入补查或澄清流程。输出模板满足表面结构却漏掉关键字段。这些信号比“某个 case 错了”更适合写进 Skill。因为它们指向的是行为模式而不是一次性补丁。图优化器需要从一批轨迹里提炼可迁移的行为规则Patch Optimizer只允许小步编辑优化器看到 rollout 后不是自由发挥写一篇新 Skill而是输出结构化 patch。论文和实现里都强调 add / delete / replace 这类受控编辑因为 Skill 最怕大面积重写。一个典型 patch 可以长这样{ reasoning: why these edits address common failures, edits: [ { op: append, content: markdown }, { op: insert_after, target: exact heading/text, content: markdown }, { op: replace, target: exact text, content: replacement }, { op: delete, target: exact text } ] }这段结构看起来朴素但里面有几个工程约束很硬target必须命中当前 Skill 的精确文本否则替换和删除不能执行。每轮编辑数量受 textual learning rate 控制避免一次改动过大。普通 step 级编辑不应该触碰受保护区域比如长期指导或附录。append 和 insert 需要有明确落点不能把规则堆到文档末尾就算完成。受限编辑的收益在于可审计。你能知道这次到底加了什么、删了什么、为什么加、验证集是否因此变好。整篇重写也许短期看更顺但它会掩盖因果关系到底是哪条规则改善了任务哪条又带来了回退没人说得清。Selection Gate没有验证提升就拒绝SkillOpt 和普通 Prompt 迭代最大的分界线是 selection gate。候选 Skill 生成后系统会拿它去跑独立验证集。如果分数严格高于当前版本编辑被接受如果只是持平或者某些任务变差导致总分没有提升编辑会被拒绝。被拒绝不是简单丢掉相关失败模式和 rejected edits 会进入后续反思上下文提醒优化器不要重复走这条路。图候选 Skill 只有在独立验证集严格提升时才会被接受这个门禁把“合理建议”变成“可验证更新”。很多 Prompt 规则在阅读时都显得正确比如“先确认需求再输出”“必要时调用工具验证”。但只有放进任务集里才能看到它是否真的改变了 Agent 行为或者只是增加了文本噪声。Step Buffer 与 Slow Update短期纠偏长期沉淀SkillOpt 没有把每个 step 当成孤立事件。它设计了两层经验留存一层处理同一 epoch 内的短期反馈另一层处理跨 epoch 的稳定经验。Step Buffer记录当前 epoch 内看到的失败模式以及被 gate 拒绝的编辑。它的作用很实际如果某个修改方向刚被验证集证明无效后续 step 就不要再用不同措辞重复提交一遍。它还可以追踪持续问题帮助优化器识别哪些错误跨 batch 都存在。Slow Update 更像长期复盘。每个 epoch 结束后系统把上一版 Skill 和当前 Skill 放到同一批任务上比较区分四类结果结果类型含义对优化的价值improved旧版错新版对说明某些新增规则可能有效regressed旧版对新版错暴露新编辑带来的副作用persistent_fail两版都错说明当前规则还没触达问题根因stable_success两版都对识别不应被后续编辑破坏的能力Slow Update 会把这些更稳定的观察写入 Skill 的受保护区域作为后续优化的长期指导。与此同时Meta Skill 记录的是优化器自己的经验哪些编辑方向更容易有效哪些修改看似合理但常常退化。一个面向目标 Skill一个面向 optimizer model。Best Skill训练结束后的可部署工件SkillOpt 的最终输出通常是一份紧凑的best_skill.md而不是一堆运行时策略。论文描述的常见规模大约是 300 到 2000 tokens重点是​可读、可审计、可部署、可回滚​。这点很关键。SkillOpt 不要求线上推理时额外调用优化器也不把优化过程塞进生产链路。训练阶段用 rollout、reflection、gate 做重活推理阶段只加载筛选后的 Skill。对工程系统来说这比引入复杂的动态决策器更容易落地也更容易做版本管理。可以把它理解成一种文本资产训练流程冻结目标模型和 Agent 运行逻辑。用当前 Skill 跑任务收集轨迹和评分。优化器从 batch 轨迹里提出结构化编辑。编辑受预算限制只做小步更新。候选 Skill 通过验证门禁才被接受。多轮迭代后导出best_skill.md。图训练阶段做重活生产阶段只加载筛选后的 Skill 文本工程上的启发SkillOpt 真正有价值的地方不是“让模型帮我们写 Skill”而是给 Skill 维护补上了实验纪律。它提醒我们Agent 的外部规则也是系统状态。既然这份状态会改变行为就不能只靠主观 review 维护。至少在复杂任务里Skill 更新应该回答三个问题这条规则来自哪些轨迹证据它修改了哪部分行为它有没有在独立验证集上带来提升如果把这套思想放回日常工程我会先保留三个底座任务集、轨迹日志和版本门禁。没有任务集优化器只能凭感觉写建议没有轨迹失败原因会被压缩成一句“结果不对”没有门禁Skill 会越改越厚最后没人敢删。Skill 文档当然还是文本但它不该只是说明书。更准确地说它是一段会被模型执行的​工程配置​。SkillOpt 的意义就在这里把这段配置从“经验堆叠”拉回到“证据驱动的迭代”。推荐阅读Multi-Agent 执行闭环AI Coding 真正进生产要靠模型分工和工程护栏Agent Skill 状态机工程Mode-Step 网格如何拆开工作流边界Agent Skill Eval从触发信号到 A/B 基准如何把 Skill 做成可回归工程单元Loop Runtime 架构拆解别再手动催 Agent先把工程闭环跑起来GEPA 架构拆解让 Prompt 和 Skill 优化不靠玄学