作者先围绕弱模型调整提示、工具和运行时检查,得到一套执行程序(harness),再用强模型的成功执行记录微调弱模型,成绩反而下降。Qwen3-Coder 在调整后的程序下原本达到 78.0%,完整模仿 Gemini 后降到 63.1%。作者改为保留 Qwen 自己的执行记录,只让专家模型重写错误发生的那一轮回复与工具调用,最终得到 79.7%。下面分别解释执行程序怎样改、训练记录怎样修,以及这些分数测什么。
1. Motivation:为弱模型调好的执行程序,为什么会被完整模仿打乱?
作者的解释是,演化后的 harness 已适配弱模型的检查与提交节奏,完整模仿却同时改变知识和执行习惯。 在文中的案例里,强模型少解释、少做中间检查,也较早提交答案。弱模型模仿了这种做法,却未必获得支撑这套执行顺序的能力。
Gemini 在 Qwen 的 h* 下达到 93.6%,比 Qwen 的 78.0% 高 15.6 个百分点。但 h* 的提示、工具、调用处理与执行顺序,是根据 Qwen 的失败记录逐步改出来的。完整模仿改变了 Qwen 常走的步骤、检查时机与提交时机;外层规则没变,模型却未必按这些规则原先预期的节奏执行。
查看 Figure 1 完整原图
论文用一个必要的对照支持这个解释:同样的完整专家模仿方案放回未演化的 h0 后,Qwen 从 29.2% 升到 35.5%。专家记录在普通执行程序下有正收益;它与已经适配 Qwen 的 h* 组合时,才出现明显退化。
2. Related Work:与联合优化、Harness-Zero 和普通局部纠错的区别
这篇论文研究的是“先演化 harness、再更新模型”时,模型与 harness 能否继续配合。 它不移除演化后的执行程序,也不证明修正模型能换用另一套工具;部署仍是修正后的 Qwen 加上原来的 h*。
展开:相关路线的逐项对照
| 路线 | 训练时改变什么 | 部署时保留什么 | 与本文的边界 |
|---|---|---|---|
| Meta-Harness / Better Harnesses | 搜索提示、工具、调用处理与执行流程 | 固定模型 + 演化后程序 | 提供上游程序演化;不更新模型权重。 |
| Co-Harness / WHALE / HarnessForge | 交替或联合优化程序与权重 | 最终配合使用的模型与程序 | 证明两者可协同;本文专门隔离完整模仿引起的负迁移。 |
| 普通 on-policy expert correction | 在学生实际遇到的状态上请教师接管或续写 | 模型 + 固定接口 | 本文把同一思想放进围绕特定模型调过的程序,目标是维持二者配合。 |
| Harness-Zero | 把原专用程序的行为改成目标接口可执行动作后训练模型 | 模型 + 更小的目标接口 | Harness-Zero 要移除原专用程序;本文始终保留 h*。 |
| Grow the Harness | 把重复控制写进可执行代码 | 固定模型 + 专用程序 | 与本文部署立场接近,但它主要优化可复用代码,不修正模型。 |
论文给出的关键反例是:教师更强、记录全部成功且格式正确,学生仍可能因为执行计划改变而退化。 这比笼统地说“on-policy 比 off-policy 好”更有信息量。
3. Method:执行程序演化与修正数据的构造
先改外层执行程序,再比较两种微调数据:完整专家记录,或只修学生记录中定位到的一轮错误回复。
3.1 七类任务与执行程序演化
作者沿用 Yang et al. (2026) 的七类企业任务:考勤与工资审计、预算审批、库存警报、物联网异常检测、Playwright 浏览器自动化、网站管理和代码重构。论文称这些任务有客观验收程序,但未重新列出各划分任务数、逐题验收或原始任务包。
作者对上游环境做了两处修改:在涉及 MCP 工具的任务中,Agent 必须通过工具访问数据,不能直接修改任务数据库;工具调用错误也会交给程序修改模型。论文因此提醒,本文绝对分数不能直接与 Yang et al. 的原结果比较。
每类任务单独演化执行程序,过程如下:
- 1 · ROLLOUTQwen 在当前程序下执行一小批任务。
- 2 · FEEDBACK验收判定、执行记录与工具错误交给修改模型。
- 3 · EDITGemini 修改系统提示,也可增删工具或调用处理。
- 4 · VALIDATE只有小批任务表现改善的修改,才进入候选集合。
- 5 · SELECT三个随机种子,每类任务预算 $20,单次执行最多 600 秒;按验证分选
h*,同分取较早版本。
训练和验证划分用于优化程序与模型,测试划分不参与选择。主表报告三次运行的测试成功率均值与 SEM(均值的标准误)。
3.2 完整模仿的数据怎样构造?
作者先收集 Gemini 在 h* 下得分为 1.0 的完整成功记录,再加入 Qwen 自己的成功轨迹,转换成 Qwen 的消息与工具调用格式后做 LoRA-SFT。主实验对三个独立 LoRA 随机种子(0、101、202)取平均。
训练配置是 rank 16 或 64 取较好结果、训练 2 遍、学习率 1e-4、bf16、有效批量为 8。论文未说明 rank 按哪份数据的分数选择。默认序列长度为 49,152 tokens;当超过 5% 训练样本被截断时,作者再训练一个 98,304-token 版本。Adapter 合并为约 57 到 61 GB 的模型权重,在两张 H200 上推理;论文称一次训练少于一小时,不包括收集记录、专家生成和候选选择的全部成本。
3.3 学生失败记录上的局部修正怎样构造?
作者改从 Qwen 在 h* 下的失败记录出发。自动定位程序找出一轮导致失败的回复与工具调用;论文没有定义“最早错误”的搜索算法。Gemini 看到任务说明、截至该轮的执行记录和失败检查点,只输出“一句修正策略 + 修正后的工具调用”。每个位置采样三个候选,再由质量评分者选一个。
# Article reconstruction from Appendix B, not official code.
def make_training_example(student_rollout, failed_checkpoint):
turn = failure_localizer.locate_failing_turn(
rollout=student_rollout,
checkpoint=failed_checkpoint,
)
candidates = [
expert.rewrite_only_this_turn(
task=student_rollout.task,
prefix=student_rollout.before(turn),
failed_checkpoint=failed_checkpoint,
)
for _ in range(3)
]
correction = quality_judge.select_best(candidates)
return student_rollout.replace(turn, correction)
最终训练集约 500 条:约 400 条局部修正,加约 50 条 Qwen 成功记录;成功样本优先选择同题有时成功、有时失败的情况。论文未解释这些约数剩余的差额,也未公开错误定位提示、质量评分者身份、筛选标准或修正记录的重新执行比例。
修正后不是重新生成整条成功轨迹。 按附录描述,作者替换错误回复,其他学生内容保持不变。工具调用改了,后面的环境状态本来可能也会改变;论文没有公开重新执行比例,因此不能把这 400 条都称作“已验证的修正成功轨迹”。质量评分者选出的合理回复,与真实环境重跑后成功,是两层不同证据。
3.4 两条真实失败:验证循环与漏掉筛选
Case 1:Payroll audit,算对了却没提交
- 任务要求汇总考勤并计算薪资。
h*写清员工级汇总、部门均值的计算,以及先向上取整再乘薪资和最终舍入规则。 - 原始 Qwen 按“计算 → 验证一次 → 提交”执行,同一例子的三次执行都在 14 到 20 步内得到 1.0。
- 完整模仿后的 Qwen 仍写出了正确部门汇总,说明计算规则已学会。
- 它随后把一次检查变成循环:同一视图请求发出 29 次、提示约重读 20 次,78 步内仍没有调用结束工具,因此任务验收给 0。
Case 2:WebArena,351 不是 346
- 问题询问 Magento Admin 中 Approved(已批准)评论的总数,参考答案是 346。
h*给出明确过程:找到状态列,筛选 Approved(已批准),读取筛选后的总数,再用结束工具返回。- 原始 Gemma 先筛选再计数,返回 346。
- SFT-imitation 后的 Gemma 进入评论表格后直接读取未筛选的 “351 records found”,跳过筛选并提前提交 351。
这两条是作者选出的真实解释案例,不是随机抽取的错误样本。论文没有公开原始日志和验收代码,本文只能核对 Appendix D 的叙述,不能独立重放。
4. Experiments:主结果、失败分类和第二模型验证
主要增益来自 harness 演化;局部修正避免完整模仿的回退,只比未微调模型再高 1.7 个百分点。
4.1 主结果:harness 很强,完整模仿七项全退
Qwen 从 h0 的 29.2±0.61 升到 h* 的 78.0±0.97,说明执行程序演化是主要增益来源。Gemini 也能使用这套为 Qwen 演化的 harness,从 84.4±0.85 升到 93.6±0.46,证明 h* 不只是 Qwen 能触发的一组脆弱提示。
Gemini 的平均分提高,不代表每项都不退步:Attendance 从 97.4 降到 97.0,Budget 从 97.2 降到 93.2,Refactor 保持 85.0。论文概括的“各任务都不低于原程序”与 Table 1 不符,应以这些逐项数字限定结论。
问题出现在权重更新。Qwen 在 h* 下做完整模仿后降到 63.1±0.81,七项任务全部下降,范围是 −4.2 到 −29.9 个百分点。On-policy correction 则达到 79.7±0.67:五项上升,Attendance 与 Budget 分别 −0.4、−0.6,作者将其视为接近饱和条件下的噪声范围。
4.2 机制证据:计算规则学会了,执行节奏却变差
完整模仿后,部门计算规则的使用率从 30.8% 升到 76.1%。Table 3 的分母则是各条件下得 0 分的失败记录:其中知识不足占比从 46.2% 降到 44.5%,规划失败占比从 1.1% 跳到 14.6%。局部修正组相应为 43.2% 与 1.8%。这些比例描述失败组成,不能读成全部任务的失败概率。
§3.4 还报告总体失败率 28.9%→26.8%,却没有给出匹配的样本数与聚合方式。它们不是 Table 1 七项平均成功率 78.0%→79.7% 的补数;本文保留这处记账缺口,不把两组统计直接相减或换算。
这组证据与“执行计划改变破坏模型与程序配合”一致,但仍属于行为归因。失败类型由模型分类器判定;论文未报告人工一致率、评分模型、提示或混淆矩阵,因此不能把 14.6% 当成无争议的人工诊断。
4.3 Gemma 复查排除了什么?
作者在 WebArena 任务上把弱模型换成 Gemma-4-26B-A4B。Harness evolution 让它从 46.7% 升到 55.6%;Gemini 使用同一 harness 时从 71.1% 升到 81.1%;Gemma 做完整模仿后降到 41.1%。这说明退化不只出现在 Qwen-Gemini 组合里,也难以只用表面输出风格不同来解释。
它没有排除更多因素:Gemma 只测了一类任务,仍用同一个专家和同一套 LoRA 方案,也没有比较 DAgger、RL、KL 约束或不同修正范围。
5. Discussion:模型升级后应重新检查执行程序兼容性
升级模型权重后,旧 harness 要重新做兼容性回归测试。 为某个模型调过的工具规则、子 Agent 分工、重试处理或历史压缩,不保证适合更新后的检查和提交节奏。
收集修正数据时,应先运行当前学生,找出真正导致后续失败的一步,再请专家修正。这样输入的仓库、工具输出和历史更接近学生实际会遇到的情况,而非照搬专家访问的状态。
采用了某条规则,不等于能顺利完成任务。 本文完整模仿后的模型更常使用计算规则,却更易陷入循环或提前提交;应同时看任务成功率、循环次数、结束行为和未完成原因。
扩展到 Claude Code/Codex 时,至少比较完整模仿、单步修正与短窗口修正;跨模型版本测试旧 harness;让人工复核定位出的错误;最后在环境里执行修正调用并重新生成后续,确认修改不只在文本上合理。
本文的两个训练组同时改变了学生访问的状态、修正长度、成功与失败样本比例和数据量。还需要在同样的学生状态上,比较专家续写整条后续与单轮修正,并匹配数据量和 LoRA 配置,才能分清收益来自哪些因素。
6. Conclusion:负结果的价值与局部修正尚未证明的部分
它给出了一个很有价值的负结果:专家成功执行记录也可能是错误的训练单位。 围绕 78.0→63.1 的异常,作者补了初始程序对照、第二模型家族、新增规则使用统计、失败分类和两个可读案例。证据比只提出一种新监督微调方案完整得多。
需要保留的限制也很明确:
我的判断是:这篇论文应该和 Harness-Zero、Multi-Harness RL 一起读。 Harness-Zero 问怎样把行为带离原专用程序,Multi-Harness RL 说明混合多个 harness 不会自动产生可换接口的能力,而本文指出即使继续使用同一个演化后程序,粗暴的完整轨迹模仿也会破坏兼容性。三篇合起来,把“数据在哪套执行程序里产生、来自学生还是专家实际遇到的状态、部署还保留哪套程序”三个问题分开了。
论文为 arXiv:2609.09134v1,arXiv 页面标注 CC0 1.0。本文直接引用 Figure 1 并注明来源,其余图表均根据 Tables 1-3 与 Appendix D 数据重绘。2026-10-20 重查 arXiv 条目与原文,仍无本工作官方代码或修正数据的发布链接;这不等于证明作者没有在其他位置发布未链接的材料。



留言