32Harness→Model 反馈闭环

核心命题:Harness 是 production 信号的金矿。每天百万级 trace 记录模型在哪些场景成功、失败、用户怎么修正。这些信号要回流训练团队,形成"模型 → harness → 数据 → 模型"的闭环。这一条做不好,训练团队不知道线上痛点,harness 团队不知道下个版本会变什么。

四条回流路径:

1. 成功 trace → SFT 数据。挑选满足"用户未修改 + verifier 通过 + tool 调用合理 + 最终输出有用"四个条件的 trace 作为 supervised fine-tuning 样本。关键不是数量,是质量过滤——大多数线上 trace 是平庸的,只有 top 1~5% 有训练价值。Harness 工程师要设计这条 filter pipeline。

2. 失败模式 → RLHF reward signal。更有价值的是失败信号。当用户 reject、手动修正、或 reflection-and-retry 后第二次才对——这构成了天然的 preference pair(rejected vs preferred),直接喂 RLHF/DPO。Claude Code 的 thumbs down + 用户修正前后对比、Cursor 的 "Apply" vs "Reject" 按钮就是这个数据的产生源。Harness 工程师设计 UI 时就要考虑"这次交互能不能产出 preference pair"。

3. Edge case → 内部 eval 集。线上罕见但重要的 case(年报生成、跨语言重构、敏感操作),单频次低但代表"我们最关心模型不能错的"。攒成 internal eval set,模型每次发版必跑,作为 release gate——过线才发。这个 set 通常公司不公开,因为公开就被训练数据污染。

4. Failure taxonomy → 训练目标。Harness 工程师做的失败分类(见 #28)告诉训练团队"模型在 X 类任务上系统性出错",指导下一轮数据采集 priority。"模型有点笨"是没用的反馈,"tool 参数 hallucination 在 27% 的 file-system 任务中出现"是 actionable。

契约式交付(harness 团队 → 训练团队):

· 每 sprint 交付 N 条 high-signal SFT 样本(数量化 KPI,不是"尽量")

· 每月更新 failure taxonomy 文档,标注新出现的失败模式 + 占比

· 每个模型版本发布前提供 internal eval set 跑结果,gate release

· 季度会议:"哪些 harness workaround 在补模型短板,下个版本能否训练消除"

这要求 harness 工程师和研究员有共同语言——知道 SFT vs RLHF 数据要求的差异、知道评测集的 bias 风险(distribution shift、reward hacking、benchmark contamination)、知道 failure case 怎么标注才训练得动(per-step label vs trajectory-level)。

Sprint 12,Cursor harness 团队 → 训练团队的交付包:
─────────────────────────────────────────────

【SFT 数据】1,247 条
  filter pipeline 跑 production 一周 trace(2.3M 条):
    - 用户未触发任何 edit 撤销         (剩 412K)
    - verifier 通过(代码能跑、tests pass)(剩 78K)
    - tool 调用 ≤ 平均值 1.5×           (剩 23K)
    - 任务完整完成(end_turn 自然退出) (剩 1.2K)
  人工 review 抽样 50 条质量 ≥ 4/5    → 通过

【Preference pairs】3,891 对
  来源:
    - "Apply" 接受的版本 vs 用户 manual edit 后版本  (2,103 对)
    - 模型第一次出错 → reflection retry 第二次对的   (1,247 对)
    - 用户 thumbs down 后 regenerate 的对比         (541 对)

【Failure taxonomy 更新】
  上月已知:6 类
  本月新发现 2 类:
    - "tool 参数 enum 值带空格"(27 例,3% 占比)
    - "并发改同一文件 race condition"(11 例,1.2% 占比)

【Internal eval set 跑结果】(下版本 candidate)
  153 个 edge case 测试:
    通过 134(87.6%),不及格 19
    不及格的 19 个 → 反馈给训练团队作为 priority

【季度回顾建议】
  workaround #7(prompt augmentation v3)在 Sonnet 4.5 已不需要,
  建议下一代 Opus 训练时不要刻意保留对应模式

这种结构化的反馈才有杠杆——训练团队拿到能直接用,不是"我们觉得 agent 还可以再好"。