SkillOpt 怎么训练 Agent Skill：从 SKILL.md 到 best_skill.md 的工程流程

SkillOpt 适合被理解成“优化技能文档的评测闭环”，而不是给模型重新训练一遍。它把目标模型固定下来，围绕可重复的任务收集轨迹与评分，再让优化器提出对 SKILL.md 的受限修改；候选版本必须在未参与拟合的验证样本上接受检查，才有机会进入下一轮。这个边界很重要，因为技能文件影响的是工具调用顺序、检查动作和输出格式，改错一条规则就可能让整个工作流变得不稳定。

它解决的不是“模型不会回答”这一类问题，而是“同一个任务每次都在犯相似的流程错误”。例如代码代理总是先改文件后跑测试，研究代理总是把未经核实的摘录当结论，或者部署代理忘记记录回滚点。人工不断追加提醒会让文档越来越长，却未必更有效。SkillOpt 的价值在于把失败样本、候选修改、评分变化和拒绝理由放到同一条可复盘的流水线上。

开始前先确认数据和评分是否可靠

第一道门槛是任务必须足够重复。一次性的创意写作很难定义稳定评分，而“把一个仓库改到测试通过”或“按固定字段整理一批资料”更容易产生可比较的结果。第二道门槛是评分不能只看模型自评。可以把测试是否通过、JSON 是否能解析、引用是否可访问、人工抽查是否通过组合成明确指标，并保留失败原因，而不是只存一个漂亮的总分。

• 建立训练集与验证集，验证样本不应在编辑过程中反复泄漏。
• 限定每轮可改动的行数、段落数或规则范围，防止一次修改吞掉原有约束。
• 保存旧版技能、输入样本、工具结果和评分，确保候选版本可以回滚。
• 涉及源码、客户资料或凭证时，先做脱敏和访问审计，再决定能否送入外部模型。

从失败轨迹到可审查的规则

一个稳妥的流程是先把失败归类，再允许优化器提出规则。若问题是“没有运行测试”，规则可以要求在宣称完成前执行指定命令；若问题是“把猜测写成事实”，规则应要求标注来源和不确定性。不要把某一次事故的表面动作直接写成永久禁令，否则技能会针对一个例外过拟合。每条新增规则都应有对应的反例：它在什么情况下不适用，如何判断需要人工介入。

候选验证也要分层。先做语法与 schema 检查，再执行低成本的离线样本，最后用少量真实环境任务确认工具权限、网络和文件副作用。验证集分数上升但工具调用次数暴涨，或者通过率提高却让结果更保守，都应作为回归记录下来。所谓“变好”必须同时说明改善了什么、付出了什么代价。

什么时候不该使用

如果任务数量太少、评分标准经常变化、训练样本含有未审查的秘密，或者团队没有人负责批准文档变更，就不应急着自动优化。SkillOpt 不能替团队定义正确目标，也不能替代安全审查。即使候选版本在离线集上表现更好，生产发布仍应经过人工 diff、最小权限验证和可回滚部署。把它当成受控的文档工程工具，而不是“会自行变聪明”的承诺，才是更安全的采用方式。