研究背景与文献综述
分析 SkillOpt 的研究问题：为什么 Agent 技能文档需要从手写提示演化为可训练、可验证、可复用的外部状态
研究问题的核心定位
SkillOpt 关注的是一个正在变得重要但还没有被充分形式化的问题：当 Agent 的程序性能力越来越多地存在于外部文本中时，这些文本应该如何被优化？
在当前 Agent 系统里，模型权重并不是唯一的能力载体。一个可用的 Agent 往往还依赖：
| 能力载体 | 典型内容 | 是否容易部署 |
|---|---|---|
| 模型权重 | 通用语言能力、推理模式、代码知识 | 闭源模型不可改，开源模型微调成本高 |
| 系统提示 | 角色、约束、输出格式 | 易改，但通常一次性手写 |
| 技能文档 | 工具策略、领域流程、失败规避、格式规则 | 易审计、易迁移，但优化方法不成熟 |
| 运行时 harness | 文件系统、工具、执行器、验证器 | 强依赖环境 |
| 记忆系统 | 历史经验、长期偏好、项目规则 | 容易膨胀且难验证 |
SkillOpt 的基本判断是：对于许多实际任务，Agent 缺的不是抽象推理能力，而是稳定执行某类任务的过程纪律。比如 spreadsheet 任务里要先检查 workbook 结构、再写静态值并保存验证；document QA 里要把问题绑定到具体表格行列；embodied agent 里要维护 visited/frontier ledger。这些规则不像模型能力那样必须写进权重，也不像普通提示那样只靠一次性创作就足够，它们更适合被训练成一个小型、可读、可迁移的 skill artifact。
为什么不是直接微调权重
权重微调当然是适配模型的一条路径，但在 frontier-agent 场景里有三个现实阻碍。
第一，许多最强模型是闭源 API，用户无法修改权重。第二，工具使用和执行 harness 的行为并不只由语言模型决定，还受文件系统、命令行、验证器、环境状态影响，单纯微调语言数据未必覆盖这些交互细节。第三，很多组织想要的是可审计的流程规则，而不是不可解释的权重变化。
SkillOpt 把技能文档定义为冻结模型外部的 trainable state，实际是在权重微调和手写提示之间开辟一层：
flowchart LR
A["任务分布"] --> B["Agent 轨迹"]
B --> C["可评分反馈"]
C --> D["技能文档编辑"]
D --> E["验证集门控"]
E --> F["best_skill.md"]
F --> G["冻结目标 Agent"]这个层的价值在于：它保留文本可解释性，同时吸收训练循环的严谨性。
与 prompt auto tuning 的关系
SkillOpt 与 TextGrad、GEPA 等 prompt optimization 工作共享一个重要前提：语言对象也可以被优化。只要任务有可评分反馈，就可以让模型反思失败轨迹，修改提示或策略文本，再评估新版本。
但 SkillOpt 和一般 prompt tuning 有几个差异：
| 维度 | Prompt optimization | SkillOpt |
|---|---|---|
| 优化对象 | 通常是 prompt 或 system instruction | 单个持久技能文档 |
| 部署形态 | 优化后的 prompt | best_skill.md 技能 artifact |
| 编辑方式 | 常见为自由重写或候选搜索 | bounded add/delete/replace edits |
| 验证机制 | 视方法而定 | strict held-out gate |
| 负反馈 | 不一定显式保留 | rejected-edit buffer |
| 长期状态 | 通常较弱 | slow update + optimizer-side meta skill |
这意味着 SkillOpt 不是简单“自动写提示”，而是把技能文档当成一个在多步训练中逐渐收敛的文本参数。
与 skill construction / skill evolution 的关系
近两年 Agent 技能相关工作大致可以分为三类。
第一类是技能构造：从轨迹、任务经验或人类知识中蒸馏可复用技能，例如把成功/失败经验总结成工具使用规则。
第二类是技能库增长：让 Agent 在生命周期中不断创建、索引、复用和组合技能。这类系统关注“技能生态”的覆盖面。
第三类是技能演化：围绕失败分析、生成-评估-修订循环、共同演化的 generator/verifier 等机制改进技能。
SkillOpt 的位置更聚焦：它不试图解决所有技能发现和库管理问题，而是研究如何训练一个 compact domain skill。这个边界让它可以引入更像深度学习优化的控制手段：
- rollout batch：每次更新前收集一批目标模型真实执行轨迹；
- reflection minibatch：把成功和失败样本分批分析，避免单例过拟合；
- textual learning rate：限制每一步最多应用多少编辑；
- validation gate：只接受 selection split 上严格提升的候选技能；
- rejected-edit buffer：记录失败编辑，避免重复走坏方向；
- slow/meta update：跨 epoch 累积长期规律，但不把训练侧元知识塞进部署技能。
研究空白
SkillOpt 填补的研究空白可以概括为三个问题。
空白一：技能文档缺乏训练范式
手写技能可以有效，但质量依赖专家。一次性 LLM 生成技能可以快速起步，但没有反馈闭环。松散 self-revision 看似能改进，但容易引入看起来合理、实际伤害性能的规则。SkillOpt 的贡献在于提出一个可控训练循环，并用 held-out validation 把“反思”变成“可检验优化”。
空白二：Agent 适配缺乏跨 harness 验证
许多方法只在 direct chat 或单一 benchmark 上有效。SkillOpt 特别强调同一个技能格式可以进入 direct chat、Codex harness 和 Claude Code harness，并做了跨 harness transfer。对于真实工程，这是关键证据：如果技能只在一个执行环境里生效，它更像环境 hack；如果可以迁移，它更像可复用程序性知识。
空白三：技能优化缺乏成本和可审计性分析
论文不仅报告准确率，也报告最终技能长度、接受编辑数量、训练 token 成本、代表性规则。这个角度很重要：一个提升很高但生成 50k token 规则库的方法，部署和审计都困难。SkillOpt 的最终技能保持在 379-1,995 tokens，通常只有 1-4 个接受编辑，说明它优化的是少量高价值规则，而不是把所有轨迹反思堆进提示。
关键概念解释
Skill
论文中的 skill 是插入 Agent context 的自然语言策略文档。它可以包含程序步骤、工具策略、输出规范、错误规避规则和领域知识。它不是模型权重，也不一定是一个可执行程序。
Target model
被适配的冻结模型。它执行任务，产生轨迹和分数。SkillOpt 不改它的权重。
Optimizer model
读取轨迹、提出技能编辑的模型。它只在离线训练时使用，不在部署时调用。
Selection split
用于接受或拒绝候选技能的 held-out split。论文强调 test split 只用于最终报告，selection split 只用于模型选择和门控。
Textual learning rate
一个文本空间的学习率类比：每步最多接受多少个 skill edit。它不控制梯度步长，而控制技能文档从当前版本移动多远。
本文如何推进领域
SkillOpt 的贡献不是提出“用模型改提示”这个宽泛想法，而是把技能文档优化工程化为一个可复现、可对照、可审计的训练算法。它把 Agent 适配从 prompt craft 推向 skill training，并给出一组值得复用的设计原则：小步编辑、验证门控、失败编辑记忆、长期元更新、部署 artifact 与训练状态分离。