SkillOpt：第三种适配 Frontier Agent 的方式

适配 frontier agent 有两种已知方式：改权重，或改 prompt/harness。

Microsoft、上海交大、同济、复旦联合提出的 SkillOpt 论文主张第三种：agent 的 skill 文件成为可训练工件，由独立优化器模型在 bounded updates 和 held-out gate 下编辑。

结果：52 个评估单元全部最优或并列。GPT-5.5 在 direct chat 中提升 +23.5 分，Codex 中 +24.8，Claude Code 中 +19.1。部署工件始终低于 2,000 tokens。

核心概念

论文中的 skill 是一个 Markdown 文件，prepend 到 agent 的上下文中。它保存程序性规则：如何使用工具、验证什么、如何格式化答案、避免什么失败模式。Frontier 模型不在权重中保存这类领域 procedure。

SkillOpt 把这个文件当作冻结目标模型的外部状态。目标模型从不移动。独立的优化器模型从 scored rollouts 中编辑 skill。部署时只有一个 best_skill.md，379 到 1,995 tokens。部署时没有优化器调用。

深度学习类比

这个类比是 operational 的，不是装饰性的：

Rollouts = 前向传播
对成功和失败轨迹的 reflection batch = 反向传播
Edit budget = 学习率
Held-out validation gate = 验证
Epoch-wise slow update = 动量

五个 Optimizer 控制

1. Edit Budget（文本学习率）

每次 reflection 以 top-N cut 结束。默认 edit budget 是 4，cosine decay 到 floor 2。没有 cap 时，loop 变成 ad hoc prompt rewriting。

移除 budget 后 SearchQA / SpreadsheetBench / LiveMath 掉到 84.6 / 75.7 / 57.3，对比默认的 87.1 / 77.5 / 61.3。Bounded edits 保持相邻 skill 版本足够接近，让下一次优化器调用仍能从上一次学习。无界重写会在任何后续控制有机会使用之前破坏优化历史。

2. Held-out Gate

候选 skill 只有在 held-out selection score 严格大于 当前最优时才被接受。平局拒绝。Selection split 只用于 accept-or-reject 决策。Test split 单独报告。

这就是防止 reflection 变成 drift 的机制。6 个 benchmark 中，每个 skill 只有 1-4 个 edit 进入部署工件。优化器提议的多得多。LiveMathematicianBench 的 +29.3 分来自单个 accepted edit。OfficeQA 的 +39.0 分也来自一个 accepted edit。

3. Failure Buffer

未通过 gate 的 edit 不被丢弃。它们进入 epoch-local memory，优化器在提议下一 batch 前读取，连同它们导致的 score drop。

这给 loop 提供了训练期间的负反馈，不增加任何推理时模型调用。移除 buffer 后 SearchQA / SpreadsheetBench / LiveMath 下降 1.6 / 4.6 / 2.4 分。

4. Slow Update

每个 epoch 边界，优化器在上一 epoch skill 和当前 epoch skill 下运行相同的采样训练项目。结果分为 improved、regressed、persistent failure、stable success。

一个简洁的 longitudinal guidance block 写入 skill 文件的保护区域。Step-level edit 不能覆盖该区域。

5. Meta Skill

优化器端记忆：哪些 edit pattern 跨 epoch 有帮助或伤害，prepend 到未来优化器 prompt。它不随 best_skill.md 一起发布。

移除 slow update 和 meta skill 两者，SpreadsheetBench 从 77.5 掉到 55.0。这是论文中最大的单次 ablation，22.5 分。

跨 Harness 迁移

一个 Markdown 文件部署到三个 harness：

Direct chat
Codex CLI（workspace-write sandbox）
Claude Code CLI

适配器合约很小：build batches、inject skill、运行原生执行循环、返回 scored trajectories。

迁移数据支撑 claim：

SpreadsheetBench skill 在 Codex 中训练，部署到 Claude Code 增加 +59.7 分（22.1 → 81.8），略超 in-domain Claude Code SkillOpt reference
反向：Claude Code 中训练，回 Codex 增加 +43.6 分（27.5 → 71.1）

训练 skill 是 portable artifact，不是 harness-specific 的命令配方。训练成本在部署面上摊销。

部署：一个 Markdown 文件

部署工件是单个 Markdown 文件，映射到 agent 已加载 procedure state 的任何地方：

Claude Code：放入 ~/.claude/skills/，session 开始时加载
Codex / OpenAI Agents：渲染为 per-task SKILL.md 或 AGENTS.md
通用 harness：CLAUDE.md、.cursorrules、或任何 agent 的 system-prompt slot
Hermes-style 持久运行时：skill-folder entry

训练成本与限制

绝对测试点每分的训练 token 成本：0.6M（SpreadsheetBench）到 46.4M（DocVQA）。总训练 token 消耗：20.8M（OfficeQA）到 213.8M（SearchQA）。

Loop 需要 scored tasks。SkillOpt 是带 verifier 的优化器。开放式创意工作、战略文档、设计判断没有 gate 可 gate，除非叠加 preference model（论文未提供）。

Repo 不附带数据集。读者自带 train/selection/test split 和凭证。这是 research code，不是 turnkey product。

真正的新东西

真正的新东西是 reframe：agent 遵循的 procedure 变成可训练、可检查的文本工件。不是权重。不是静态 prompt。中间的东西，有版本历史、accepted/rejected edit 的审计追踪、379-1995 token 的部署 footprint。

论文指向两个 next move：

跨领域共享基础设施的 skill libraries
训练 skill 自蒸馏回目标模型权重

两者都假设 skill 本身是被优化的对象，不是 prompting 的副产品。

你当前 agent 栈的哪部分会首先作为文本被训练：CLAUDE.md、skill folder、还是 AGENTS.md？