真要微调：训什么，以及怎么不把 harness 冻死

先看一组不好看的真实数字。

CLAP 是一套面向领域 agent 后训练的闭环框架，在五批制造业数据上做了实测：

五批里只有三批变好，有些批次是退步的，而且 GRPO 暴露出较高的 KL 风险。

这就是领域微调在真实业务数据上的样子：不是一条一路向上的曲线，是一堆有涨有跌、需要门禁去筛的批次。 上一篇说先修 harness 的杠杆更大，这一篇的第一句话是：就算走到微调这一步，也别指望它像论文标题那样漂亮。

那篇自己给的结论也是这个意思 —— 该管理的是 数据 → 训练 → 评测 → 发布 这一整个闭环，而不是「训练跑完了」或者「某个离线分数好看」。

训什么：三条路线

一、SFT 蒸馏：把流程性知识灌进权重。

最直接的一条：拿高质量轨迹做监督微调，让模型把领域的程序性推理内化。适合的场景是「每次都要在提示词里解释同一套流程」—— 那段解释乘以调用次数，就是你在付的税。

二、RL（GRPO 一类）：让模型在环境里学。

需要有可判定的奖励。测试生成这个垂类天然有一部分是可判的（用例跑没跑通、断言成不成立），但也有一大部分不可判（覆盖得全不全）。奖励能不能定义清楚，决定了这条路走不走得通。

CLAP 那组数里「GRPO 暴露出较高的 KL 风险」是个具体警告：RL 容易把模型推离原始分布，换来分布内的一点提升，代价是分布外的稳定性。

三、失败驱动的领域特化：让小模型在一格里变强。

Learn from Weaknesses 那条路我认为对垂类最实用：让小的 computer-use agent 先跑，自动分析它自己的失败模式，针对性地合成训练数据，再微调。2B–8B 的模型在单一领域上追大模型。

它的价值不在「省钱」，在目标明确：不是让小模型变通用，是让它把某一格做到够用。而「哪一格」这个问题，你的失败日志已经替你回答了。

怎么不把 harness 冻死

上一篇留了个矛盾：微调必须在最终 harness 下做，可 harness 又一直在改。这不是能靠「等它稳定」解决的 —— 垂类 harness 的稳定期可能永远不来。

Co-Harness 给的答案是不让它冻：让 harness 和权重交替进化。

它指出了现有做法的一个盲点：常规流水线在固定的 harness 下训练模型，于是「数据是怎么产生的」这件事被留在了优化目标之外。而数据恰恰是 harness 产的 —— harness 差，产出的轨迹就差，训出来的模型也就差。

它的循环长这样：

跑 → 失败轨迹
      ↓
  HarnessCritic（一个 LLM）分析失败
      ↓
  定位到 harness 级别的失败模式，提出经过验证的局部改动
      ↓
  用改好的 harness 重新产轨迹
      ↓
  拿高质量轨迹微调模型 —— 把有效的脚手架蒸馏进权重
      ↓
  再回到第一步

关键在那个「蒸馏进权重」：harness 里那些一开始必须显式提供的信息，逐渐变成模型自己就会的东西，于是 harness 可以变薄。这正好回应了 Anthropic 那句「每个组件都编码了一个『模型做不到什么』的假设」—— 假设被推翻了，组件就该退休。

它还报了一个 200 多小时的自主案例研究：系统自己从崩溃里恢复、自己提效、自己发现了集成策略，全程无人干预。

这套东西最现实的一半是 HarnessCritic，而它不需要微调也能用。 失败轨迹你已经有了（前提是你的日志记全了），拿一个模型去读它、提改进建议 —— 这是今天就能做的事，而且是整条路上性价比最高的一步。

发布门禁：训完不等于能上

CLAP 那套值得抄的不是训练方法，是发布控制。它把业务数据加工成好几种产物，其中最该留意的是留出集和发布门禁记录 —— 前者保证评测没被污染，后者让「这个 adapter 为什么放行」事后查得到。

然后用一组门去判断一个 adapter 该不该上线。前面几道是常规的数据校验和 reward/KL 诊断，最后一道是应用链重放。

最后那一项最该记住：拿真实的应用链把这个 adapter 重放一遍，而不是只看一个离线分数。因为离线分数高而应用链上退步，正是那五批数据里「有些批次退步」的样子。

对照着看，一个垂类项目在微调之前至少要先有：

• 留出集，而且是从头到尾没参与过调优的那种
• 配对的评测（同一批题跑两版相减），否则涨的那点分不清是模型还是运气
• 一条能重放的应用链，也就是第一篇说的 execution lineage

这三样没有的话，微调跑完你不知道自己得到了什么。

那我们什么时候才轮得到

对一个还在改 harness 的垂类项目，我的判断是：现在不是时候，但有两件事该提前做。

第一件：把日志记成能训的形状。 微调要轨迹，而轨迹就是日志。如果日志里只有「这一步失败了」，没有当时模型看到什么、回了什么，那这些日志将来一条都用不上。记日志的成本在今天，收益在微调那天 —— 而等到那天再补，历史数据已经没了。

第二件：把 HarnessCritic 那半截先跑起来。 它不依赖微调，只依赖失败轨迹。让模型定期读一遍失败日志、提 harness 改进建议 —— 这是 Co-Harness 循环里最便宜的一段，也是唯一现在就能兑现的一段。

至于真正的微调，判据我认为有三条，全部满足才动手：

1. harness 那一侧的杠杆已经量过并且拉满了（上一篇那三组数说明这一步经常被跳过）
2. 有留出集和配对评测，涨了能证明是真涨
3. harness 已经稳定到「再改就是小修」，或者已经上了 Co-Harness 那种交替进化的结构

边界与代价

这一篇全是转述，我一次微调都没跑过。 上面每个数字都来自别人的论文，我能做的是把它们的实验条件说清楚，不能替它们担保能复现。转述的实验和自己跑过的实验，可信度不是一回事 —— 这句话在这一篇里必须重复。

+0.0098 这个数要小心解读。 它是特定行业、特定五批数据上的总分提升，不代表领域微调普遍只能涨这么点。但它确实说明一件事：真实业务数据上的收益，比论文摘要里的百分点小得多，而且不稳定。

Co-Harness 的自主循环有个明显风险：HarnessCritic 提的改进由模型判断、由模型验证，是模型在给自己打分。Anthropic 那篇点名过这个失败模式 —— 模型会自信地夸奖自己的产出。所以那个 validated 到底验到什么程度，是我读摘要读不出来、也不敢替它保证的部分。

微调会锁住的不只是 harness，还有模型供应商。 一份为 Qwen 微调的权重换不到别家。在模型换代速度这么快的时候，这笔账要算进去。

这个调研系列到这里

四篇合起来回答的是同一个问题：harness agent 到底是什么，以及一个垂类项目该怎么排优先级。

• 第一篇：它是六类运行时职责，loop 管行为、harness 管环境、graph 管什么被允许继续
• 第二篇：垂类里有三格对不上，而最难的两格通用清单上没有
• 第三篇：微调之前，harness 那侧常常还有几十个点没拿
• 这一篇：真要微调，先有留出集、配对评测和可重放的应用链

接下来是实作：按这六类职责，把手上那套测试用例生成的东西重新排一遍 —— 哪几格已经有了、哪几格是空的、哪几格根本不该有。