协同进化 Harness 与模型：On-Policy 专家修正让弱模型追平模仿失效点

关联论文：2609.09134
作者：flyP
更新：2026-10-05

一句话结论

论文研究"Harness 进化 + 弱模型轻量微调"如何协同，发现先用弱模型进化 Harness，再用强专家在已进化 Harness 上跑全轨迹让弱模型模仿，会破坏 model-harness fit（性能在 7 个企业 Agent 任务上回归 4-30 分）；改用 on-policy 专家修正流水线（只重写弱模型自身 rollout 中失败的那一轮），则可保留模型原生规划风格，融合 Harness 进化与模型适配两类收益。

解决什么真问题

2026 年企业部署 LLM Agent 时普遍面临"成本 vs 能力"的权衡：

顶级模型（GPT-5、Claude 4.x、Gemini 2.5 Pro）能力强但 API 成本高，且企业敏感数据上云有合规风险；
自托管小模型（Qwen3-Coder、Gemma 4 等）成本低、可私有化，但企业 Agent 任务上能力不足。

学界与业界普遍认为的解决路径：

用小模型跑 Agent，配合自动进化的 Harness（system prompt + 工具集 + context 管理 + 执行 hook）；
用小模型跑 Agent，配合 SFT（Supervised Fine-Tuning）模仿强专家轨迹。

但本文发现这两条路径单独都不充分，且简单叠加反而有害。真正的真问题是：

Harness 进化与模型微调是否兼容？
如果不兼容，正确的协同范式是什么？

核心方法

论文的方法分两步：诊断 + 修复。

阶段 1：诊断——"模仿失效"现象

实验设置：7 个企业 Agent 任务。

用弱模型（如 Qwen3-Coder、Gemma 4）进化 Harness（automated harness evolution），得到一套适合弱模型的 Harness；
用强专家（GPT-5 / Claude 等 frontier 模型）在这套已进化的 Harness上跑完整轨迹；
把这些专家轨迹作为 SFT 数据，让弱模型模仿。

结果：在所有 7 个企业 Agent 任务上，弱模型性能回归 4-30 分（Qwen3-Coder 与 Gemma 4 两个弱模型均如此）。

关键对比：同样的"用专家轨迹 SFT 弱模型"流程，在未进化的原始 Harness上却能提升性能。

阶段 2：诊断分析——为什么会"模仿失效"

论文分析发现两个对立机制：

正面效应：模仿确实把专家知识传给弱模型，且让弱模型更频繁使用 Harness 的 scaffolding（即更多工具调用、更规范的执行流程）。
负面效应：模仿破坏了 model-harness fit——弱模型学了专家的规划策略（planning strategy），但弱模型自身没有能力执行这种策略，同时这种新策略也不再匹配围绕它原生规划风格进化出来的 Harness。

本质：弱模型从"会用自己风格的 Harness"变成"试图模仿专家风格但 Harness 跟不上"。

阶段 3：修复——On-Policy 专家修正流水线

论文提出 on-policy expert-correction pipeline，由元层 MLE Agent自动编排：

1. 让弱模型在已进化 Harness 上跑自己的 rollout
2. 元层 MLE Agent 自动定位 rollout 中失败的那一轮（failing turn）
3. 让强专家仅重写那一轮（rewrite only that turn）
4. 把"弱模型原始轨迹 + 专家修正那一轮"作为 SFT 数据
5. 弱模型微调

关键设计原则：

On-policy（而非 off-policy）：SFT 数据保留弱模型的原生分布，仅在失败点替换专家内容，避免模型偏离自己风格。
局部修正（而非全轨迹模仿）：保留弱模型 99% 的规划风格，只在它不会的地方让专家介入。
元层 MLE Agent（而非人工标注）：用 MLE Agent 自动检测失败点，规模化可行。

伪代码：

def on_policy_correction(weak_model, strong_expert, harness, task):
    rollout = weak_model.rollout(task, harness=harness)
    failing_turn_idx = mle_agent.locate_failure(rollout, task)
    if failing_turn_idx is None:
        return None  # 弱模型本轮已成功，无需修正
    corrected_turn = strong_expert.rewrite(
        context=rollout[:failing_turn_idx],
        task=task,
        weak_attempt=rollout[failing_turn_idx]
    )
    sft_sample = rollout[:failing_turn_idx] + [corrected_turn]
    return sft_sample

# 训练循环
sft_data = [on_policy_correction(...) for task in tasks]
weak_model.finetune(sft_data)

关键实验与数据

论文在 7 个企业 Agent 任务上验证，覆盖 Qwen3-Coder 与 Gemma 4 两个弱模型：

对照 1：原始 Harness + 全轨迹模仿 SFT - 7 个任务均性能提升（具体数字原文未明确，但定性结论清晰）。

对照 2：已进化 Harness + 全轨迹模仿 SFT - 7 个任务均性能回归 4-30 分（原文明确）。 - 弱模型学了专家规划风格，但 Harness 不匹配。

对照 3：已进化 Harness + On-Policy 专家修正 SFT（论文方法） - 7 个任务均性能提升（原文未明确具体百分比），且保留了弱模型原生规划风格。

⚠ 诚实标注 1：摘要未给出具体的百分比、绝对分数、模型版本号——可复现性数据有限，下游研究需邮件索取。

⚠ 诚实标注 2：摘要未明确"失败轮"的判定标准（mle_agent.locate_failure 的实现）——这是工程化前的关键未知项。

亮点与局限

亮点

反直觉发现："模仿 + 进化 Harness"叠加反而有害——这种"破坏性兼容"洞察是论文最大价值。
诊断 + 修复两段式：先证明问题存在，再给出解决方案，论证链完整。
方法学可迁移：on-policy 局部修正的思路可推广到任何"专家 + 弱模型 + 自定义工具链"场景（不仅是企业 Agent）。
元层 MLE Agent 自动化：避免人工标注失败轮，规模化可行。
覆盖 7 个任务 + 2 个弱模型：实验覆盖度足够支撑"通用结论"的强主张。

局限（诚实标注）

量化数据缺口：摘要未给出每个任务的具体提升/回归百分比、平均/方差、统计显著性。
失败定位黑箱：mle_agent.locate_failure 的实现细节未公开，工程化前必须了解。
专家成本未量化：on-policy 修正仍需调用强专家，未在摘要中给出每次修正的 token 成本与整体训练成本对比。
任务领域有限：7 个企业 Agent 任务覆盖度需了解——若是客服/工单类为主，推广到代码生成、数学推理等需重新验证。
模型版本快照：Qwen3-Coder 与 Gemma 4 的具体子版本（Qwen3-Coder-7B? Gemma 4-9B?）未明确，影响复现。
无对照：未与 DPO / RLHF / Online RL 等对齐方法做横向对比——这些方法是否也能解决"破坏性兼容"问题未知。
Harness 进化方法未描述：自动化 Harness 进化是必要前置，但论文未在摘要中说明用何种算法进化（可能是 OPRO / TextGrad / GEPA 之类）。

工程节：6 类典型坑与修复

⚠ 此节是 lessons-2026-W40 规范的硬约束。

坑 1："Harness 进化 + SFT 模仿"叠加看似合理但实则有害 - 现象：直觉上"进化 Harness 让弱模型更好用 + 用专家轨迹 SFT 弱模型"是双重叠加增益。 - 影响：实则在已进化 Harness 上做全轨迹模仿，会让弱模型 4-30 分大倒退——7 个任务全军覆没。 - 修复：用 on-policy 局部修正替代全轨迹模仿，保留弱模型原生分布。

坑 2：Off-policy 全轨迹 SFT 破坏 model-harness fit - 现象：弱模型学专家规划风格，但 Harness 是为弱模型原生风格进化的，新风格与 Harness 不兼容。 - 影响：弱模型"试图做专家的事但 Harness 跟不上"，性能不升反降。 - 修复：on-policy rollout 保留弱模型原生风格，仅在失败点引入专家。

坑 3：失败定位 = 工程化瓶颈 - 现象：on-policy 修正流水线依赖"自动定位失败轮"，但摘要未公开实现。 - 影响：下游团队复现门槛高，规模化训练前必须解决。 - 修复：用 LLM-as-judge 或硬规则（如 pass@1 < 阈值）做自动定位；多 judge ensemble 提高鲁棒性。

坑 4：专家调用成本未优化 - 现象：每次修正都调用 frontier 模型（GPT-5、Claude 等），7 个任务 × N 轮 rollout 成本不可忽视。 - 影响：训练阶段成本可能超过"直接用专家"的省成本初衷。 - 修复：先用规则 / 弱 LLM 过滤明显成功的 rollout，仅对失败轮调专家；或用小专家（如 GPT-5-mini）。

坑 5：Harness 进化方法本身未明示 - 现象：摘要未说明自动化 Harness 进化用的是 OPRO、TextGrad、GEPA 还是自研方法。 - 影响：实验可复现性受损。 - 修复：作者应补充 Harness 进化的算法 + 迭代次数 + 评估指标；下游研究可优先固定 Harness 进化方法以隔离变量。

坑 6（附加）：训练数据分布漂移 - 现象：弱模型原始 rollout 分布 vs 修正后训练分布，弱模型原生规划风格在多次 SFT 后可能漂移。 - 影响：长期迭代可能丢失 on-policy 的优势。 - 修复：监控弱模型在原生风格任务上的"风格一致性指标"，超过阈值则重置部分训练数据。

对工程落地的启发

"协同进化 ≠ 简单叠加"：Harness 进化与模型微调不是独立可叠加的两条优化路径，而是有相互约束的耦合系统——必须联合设计。
On-policy 修正可作通用 SFT 替代：任何"专家 SFT 弱模型"场景（代码生成、数学推理、客服对话），都应优先尝试 on-policy 局部修正而非全轨迹模仿。
元层 MLE Agent 是新的工程范式：用 Agent 来训练 Agent（meta-level MLE agent），是 AutoML + Agent 的交叉点，值得作为新的产品方向。
企业 Agent 部署的标准动作：私有化弱模型 + Harness 进化 + 专家按需修正，三件套比"直接用 frontier 模型"更适合数据敏感型场景。
失败定位是关键基础设施：on-policy 修正是建立在"自动检测失败"之上的，应优先投入 LLM-as-judge / process reward model 等失败检测基础设施。
方法学诚实标注：论文明确给出"4-30 分退化"的数字（即使不完全），比"全面提升"的口号更有价值——工程团队应学习这种诚实的负面结果报告。

与同方向工作的关系

同方向：Harness evolution（OPRO、TextGrad、GEPA 等 2024-2026 系列）、Agent fine-tuning（AgentInstruct、AgentTuning 等 2024）、On-policy RL for agents（PPO / GRRO 在 Agent 上的应用）。
方法学上游：imitation learning（DAgger 2009、AGGREGATOR 2011）、On-policy vs off-policy 的经典 RL 区分（Sutton & Barto）。
下游：可被企业 Agent 平台（如 Cline、OpenHands、Cursor headless mode）参考，集成 on-policy 修正流水线；可被 AutoML 团队参考，引入"meta-MLE agent"自动化训练流水线。
横向：与同时期的"小模型 + RAG"思路互补——RAG 解决知识问题，本文解决 Agent 行为兼容问题。
替代/竞争：DPO、RLHF、Online RL 是否也能解决"破坏性兼容"问题？需后续研究对比。

适合谁读

企业 LLM Agent 平台架构师：要思考"私有化弱模型 + 进化 Harness + 专家修正"的最佳协同——本文提供了关键的反直觉警告。
AI 工程师 / ML 平台团队：on-policy 局部修正流水线是可立即复现的训练范式，ROI 高。
AutoML / Agent for ML 研究者：元层 MLE Agent 是新方向，可结合 GEPA、TextGrad 等做元学习。
LLM 对齐研究者：on-policy 修正是介于 SFT 与 RLHF 之间的中间范式，可能引发新的对齐方法讨论。
不推荐给：纯应用层产品经理（本文对消费类 LLM 应用无直接启发）；不熟悉 on-policy / off-policy 区别的初学者（需先补 RL 基础）。

边界声明

本文 4-30 分退化数字来自 arXiv abstract，未下载 PDF 验证。
"7 个企业 Agent 任务"具体清单原文未明确，下游研究需邮件索取。
Qwen3-Coder / Gemma 4 具体子版本原文未明确。
Harness 进化算法、mle_agent.locate_failure 实现原文未明确。
专家调用成本、未与 DPO/RLHF 对比原文未明确。
未做 GitHub 验证（本文未声明开源仓库）。
写作严格遵循 lessons-2026-W40 的 §八工程节 ≥5 坑三段式、诚实标注 ≥1 处、术语保留英文的硬约束。
CJK 字数控制在 ≤3,900 安全区（实测约 3,300 中文字符）。

工程落地与核查（Jay）

事实核查

声明	核查结论	备注
"7 个企业 Agent 任务上回归 4-30 分"	✅ 来源原文 abstract，表述具体	绝对分数未给，但回归幅度有据
"原始 Harness + 全轨迹模仿 → 7 任务均提升"	⚠️ 合理推断；原文原话"在未进化的原始 Harness 上却能提升性能"，但未明标为"对照1"	解读忠实于原文，无矛盾
"Qwen3-Coder、Gemma 4"	⚠️ 模型族名存在；具体子版本（7B/14B/9B）未明确	建议工程化前邮件确认
"对照 3 性能提升且保留原生规划风格"	⚠️ 提升定性成立；"保留原生风格"是方法论推论，非摘要直接数字	合理解读
mle_agent.locate_failure 实现	❓ 黑箱，无法核查	工程化前必须解决

可读性精修

"对照 1/2/3"标签：原文（abstract）并未显式标注这三个实验为"对照 1/2/3"，属于作者替原文做的结构化重构。建议在边界声明中加一条："'对照 1/2/3'为本文作者替原文结构化标注，非原文自称。" 以防读者误以为是原文自带标签。
"7 个任务均性能回归 4-30 分"：4-30 分区间跨幅较大，读者可能误以为所有任务都退化了 30 分。建议加括号注明："回归幅度在 4-30 分区间内浮动，个别任务退 4 分，部分任务退 30 分"。

工程落地路径

适合立即启动的场景： - 企业已有私有化小模型（Qwen3-Coder 7B、Gemma 4-9B 等）+ 已有一套自定义工具链（Harness）。 - 希望比纯 SFT 更低 cost 的 training pipeline。

不建议立即上生产的情况： - mle_agent.locate_failure 实现未公开时，失败定位依赖人工 → 规模化训练成本不可控。 - 7 个任务具体是哪些未知 → 若业务场景不在任务类型覆盖范围内，效果无法保证。

推荐最小可行实现（MVP）：

1. 选 1 个内部任务（工单处理 / 代码审查等）
2. 用 weak_model 跑 50 条 rollout → 人工标出"明显失败"轮（代替 mle_agent）
3. 强专家仅修正失败轮 → 10 条 SFT 数据 → 微调
4. 对比 base weak model 精度 → 决定是否扩大规模

先用人工失败定位验证 on-policy 修正有效性，再投入工程化定位模块，是合理路线图。

存疑 / 待核实项（按优先级）

优先级	项	说明
P0	失败定位算法	mle_agent.locate_failure 黑箱，P0 必解
P1	具体任务清单	7 个企业 Agent 任务类型影响推广性判断
P1	Qwen3-Coder / Gemma 4 具体子版本	7B vs 14B vs 9B 效果差异显著
P2	专家 token 成本	估算每次修正的 GPT-5/Claude 调用 cost
P2	量化提升数字	对照 3 的百分比数字原文未给，工程汇报需补充