11 月 2 号在 arXiv 上刷到一篇，编号 2611.03219，cs.SE 交叉 cs.AI，作者 Shangziqi Zhao、Yitong Zhang、Jia Li。让我点开的不是标题，是摘要里那对数字：DeepSeek-V4-Flash-0731 配 Meta-Harness，在 SWE-Bench 上演化到 94.0%；换 FeatureBench 继续演化，到第五轮，同一个组合在 SWE-Bench 上只剩 32.0%，相对降幅六成多。
这个幅度不像笔误，更像实验设计本身在说话。所以这篇笔记就把它拆开看看：它测的是什么、掉的是什么，以及我准备照着自己项目改的那一处流程。
先说它测的是什么。harness 自演化这条路子的前提是：不动模型参数，只动外面那层运行框架——上下文怎么拼、工具怎么暴露、流程怎么排、失败之后怎么重试——能力就能往上走。这个前提我认，脚手架调对了，同一个模型的产出能差出一大截。问题在于绝大多数这类工作只在一个任务上验证演化效果。这篇把这处缺口挑明了：真实写代码的智能体不是只干一件事，今天修 bug、明天做特性、后天补测试，harness 得活在这种切换里。
他们的实验设计是：三套软件工程数据集整理成六种演化方向，用两种有代表性的 harness 演化方法沿这些方向持续演化。六种方向这个数字值得停一下——方向顺序本身就是变量，换个顺序结论可能就不一样。也就是说他们确实把「持续」当回事，同时这套结论天然带着协议依赖，后面再讲。
掉分那一段是核心：在后续数据集上继续演化，先前数据集上的表现明显下滑，94.0% → 32.0% 是这个现象最刺眼的一个切片。
这里我想掰一下归因。权重没动，参数没动，「遗忘」这个词就得打个引号。我一开始顺手把它归成灾难性遗忘，写到这儿觉得不准确——掉的大概率不是模型本身的能力，而是脚手架对上一个任务形态的过拟合：演化把 prompt 结构、工具调用顺序、重试策略调成了适配 A 类任务的形状，换到 B 类再调，A 类的形状被覆盖掉。这只是我的读法，作者在摘要层面只说「显著损害」，没把机制说死，我正文还没读完，这条先留个问号，回头补。但不管哪种归因，对天天写代码的人结论一样：harness 的演化不是单调曲线，它会往回走。
我现在的做法很土，就是把「锚定任务集」当一个硬约束，仓库里固定留这么一小块：
evals/
├── anchor/
│ ├── fix-import-cycle/
│ ├── add-pagination/
│ └── flaky-test-timeout/
└── runs/
└── 2026-11-08-r3.log
三个任务分别对应修 bug、加特性、排查不稳定测试，每个任务一条命令、一个判定脚本，不追求覆盖，追求跑得动：
for t in evals/anchor/*/; do
./run-task.sh "$t" >> "evals/runs/$(date +%F)-r${ROUND}.log"
done
每改一次 harness——哪怕只是往 CLAUDE.md 里加一条规则、改一段工具描述、调一轮重试次数——改之前跑一遍，改之后跑一遍，两份 log 并排放着看。听起来笨，但这是我在自己机器上唯一能复现「有没有把上一个任务的形状覆盖掉」的办法。💡 小技巧：log 里把每次改动的 diff hash 一起打出来，过两周回头看，能直接对上哪次改动把哪条从通过变成失败，省掉翻提交历史。
坑记两条。第一条是 prompt 改动和结构改动混在同一次提交里，出了问题分不清是哪一处引起的，后来强制自己一次只动一层，diff 好读，回滚也好回。第二条是只跑新任务不跑老任务——这条不用多解释，这篇论文讲的就是它，而我之前的习惯正好长成它描述的那个失败模式。
再说回六种演化方向。这个设计对想抄作业的人有个隐含要求：你得接受「顺序可变」。锚定集里只有一个任务，本质上还是拿单一方向的结果当结论，跟论文批评的现状没区别。三个任务是我目前觉得还能接受的成本下限，再多就跑不动；而跑不动的东西最后一定不会跑，这点我信自己的懒惰胜过信自己的决心。
划重点：第一，harness 演化出来的收益跟任务形状绑定，换任务继续演化会把旧形状覆盖掉，这是机制不是意外；第二，94.0% 和 32.0% 要放在一起看，单拎任何一个都会得出反的结论；第三，最划算的一步是留三到五个任务的小锚定集，每次动 harness 前后各跑一遍；第四，一次提交只动一层，prompt 和结构别混着改。这条记下来了，下次应该用得上。你可以顺手翻一下自己仓库里 AGENTS.md 或 CLAUDE.md 的提交历史，看看最近十次改动里有没有跑过任何一次回放——如果没有，这篇说的坑你大概率已经在里面了。