27模型协同演进

这一章是 4 层中唯一的哲学层 P0,核心命题:Harness 的每一行代码都编码了"模型不能做什么"的假设;模型变强,旧 harness 机制会过时成 dead code。

这条说出来简单,工程上影响巨大——它决定你写代码时是否考虑"如果模型 6 个月后不需要这个 workaround 怎么办"。

Anthropic 公开的真实案例(必背):

Claude Sonnet 4.5:
  · 表现出 "context anxiety"
  · 感觉 context 快满时提前结束任务
  · 即使还没真的做完
  → Anthropic harness 团队加 context reset 机制
    (token 用到阈值时把 working state 抽到 progress.md,
     撕 context,fresh 启动新 session)

Claude Opus 4.5:
  · context anxiety 行为消失
  · 长 context 下能稳定推进
  → 之前加的 context reset 机制成 dead code:
    - 不删 → 每次 reset 都有 cost + 复杂度
    - 删了 → 怕模型回滚

这就是 harness 与模型代际错位的典型形态。

三条设计原则:

1. 机制开关化(feature flag everything)。每一条为特定模型行为加的逻辑都做 feature flag,模型升级时能 A/B 关掉。

// 不要写死
if (token_count > 0.7 * MAX) reset()

// 写成可关
if (config.reset_enabled) {
  if (token_count > config.reset_threshold) reset()
}
// config 和模型版本挂钩,升级时切 flag 不重写

2. 优雅退化(graceful degradation)。Harness 在更强模型下应该"自动变弱"——prompt augmentation、tool retry、infinite-loop guard,这些都是在补模型短板,模型够强就自动关掉。Anthropic 内部 review 时会问:"这个机制如果模型变强 2× 还需要吗?"——回答不出来的属于设计缺陷。

3. 不假定模型能力上限。不要写"模型一定不会做 X"的兜底——模型会让你打脸。Cursor 内部就有过模型升级后开始调一个"以前从不调"的 tool 导致权限失控的事故。写 catch-all 兜住未知行为,再针对已知失败模式做特定处理。

与训练团队的协作形态:

· 报 failure case:把 production trace 里反复出错的 case 整理成结构化 failure taxonomy(见 #28),作为训练团队下一轮数据采集的输入

· 提能力需求:"我们在 X 场景反复做 Y workaround,能不能在训练数据里 cover 这个场景"——见 #32 反馈闭环

· 对齐版本节奏:模型版本发布前 1-2 周拿到 candidate,跑 harness 的 regression set,反馈"哪些机制可以删 / 需要加"

T - 2 周:模型发版前
─────────────────────────
  · 训练团队给 harness 团队 Opus 4.5 candidate access
  · harness 团队跑 regression set(自建,见 #26)
  · 发现:
    - context_reset 机制触发率从 35% → 2%(模型不再焦虑)
    - infinite_loop_guard 触发率从 8% → 5%(轻微改善)
    - prompt_augmentation 中加的"请仔细思考"开始变冗余

T = 0:模型 GA
─────────────────────────
  · feature flag 切换:
    - reset_enabled = false (Opus 4.5 不需要)
    - loop_guard_threshold: 3 → 5 (容忍度提高)
    - augmentation_v1 = false, augmentation_v2 = true (改提示)
  · A/B 灰度:10% 用户用新配置,观察 1 周
  · 监控:回滚率、token 用量、任务完成率

T + 1 周:全量切换
─────────────────────────
  · 切到 100%,旧 reset 代码进 deprecated 队列(3 个月后清理)
  · 把这次经验回流给训练团队:"context anxiety 消失"作为
    Opus 4.5 → 下一代模型时的对照基线

这套流程不是"被动等模型 release",而是 harness 团队主动参与模型迭代,把 harness 视为"和模型一起演化"的代码库。