Harness 与 Model 协同进化：为什么「模型不行」往往是 Harness 问题 · 干货攻略

  • 链接: https://x.com/omarsar0/status/2097958286146605446
  • 分类: x-tips
  • 来源: X @omarsar0
  • 作者: Jay
  • 更新: 2026-09-11
  • 论文: arXiv:2609.09134 · DAIR.AI Academy

这是什么

2026 年 9 月 8 日，Salesforce AI 研究团队发布了论文 "Co-Evolving Harnesses and Models: On-Policy Correction Helps Weaker Models Catch Up Where Imitation Fails"（arXiv:2609.09134）。论文研究了一个核心问题：当小模型配合专业工具调用（harness）仍然表现不足时，应该继续调模型还是调 Harness？两者能否协同进化？

论文的核心发现反直觉：大多数"模型很蠢"其实是 Harness 问题；然而，在进化后的 Harness 上直接让小模型模仿专家轨迹，反而会让模型性能下降 4–30 个百分点。 团队进而提出了基于同策略修正（on-policy correction）的协同进化方案。

Harness 在此论文中的定义：围绕 LLM 的系统提示词、工具集、执行钩子（hooks）和上下文管理脚手架，即决定模型"能看到什么"和"能做什么"的所有配置。

为什么值得关注

谁分享的

@omarsar0（Omar Khreich）是 DAIR.AI 的联合创始人，长期系统追踪 AI Agent 领域的前沿论文，其 X 账号是该领域高质量技术情报源之一。

解决什么问题

企业 Agent 部署中普遍面临一个两难：

  • 调模型：换用更大更强的模型效果明显，但成本高昂（GPT-4o API 调用费用是 Qwen3-Coder 的数十倍）。
  • 调 Harness：已有大量研究表明，改进 Harness 可以让小模型在特定任务上接近前沿水平（Yang et al., 2026; Agrawal et al., 2025）。然而，单独调 Harness 有天花板，模型本身的能力差距无法靠配置弥合。

于是自然想到：两者协同进化——先用弱模型进化 Harness，再用专家轨迹微调弱模型。 这条路是否走得通？

论文的结论是：这条路表面通、实际坑，必须在方法上做手术才能真正协同。

反直觉核心

论文的七项企业 Agent 基准测试涵盖：工资审计、预算审批、股票预警、IoT 异常检测、浏览器自动化、网站管理和代码重构。实验设置：

弱模型 规格
Qwen3-Coder-30B-A3B 30B 总参 / 3B 活跃参数
Gemma 4-26B-A4B 26B 总参 / 4B 活跃参数

关键结果（原文描述）：

  1. 单独进化 Harness：Qwen 弱模型在进化后的 Harness 上，任务成功率从 29.2% 提升至 78.0%，提升 48.8 个百分点——全程不改模型权重。
  2. 更强专家使用同一 Harness：将进化后的 Harness 给 Gemini-3.1-Pro 使用，专家在每一项任务上都优于弱模型，甚至超越自身默认 Harness 的表现。这说明 Harness 进化成果可跨模型迁移。
  3. 模仿专家轨迹微调弱模型：将专家在进化 Harness 上的完整轨迹用于 SFT 微调弱模型——结果所有七项任务全部性能回退 4–30 个百分点（即负 4 到负 30）。

这第三条是论文最反直觉的发现。用作者的话说：弱模型"习得了专家的知识，增加了 Harness 的使用频率"，但丢掉了与 Harness 的配合默契（model–harness fit）——它学会了专家的规划策略，却没有执行能力，最终两头不靠。

核验过程

官方来源：

  • arXiv:2609.09134（论文全文，2026-09-08 提交）：包含完整 abstract、introduction、实验设计和结论，是本攻略的主要引用来源。
  • DAIR.AI Academy 论文页（academy.dair.ai/papers/co-evolving-harnesses-and-models...）：提供了论文摘要和作者信息，确认作者团队来自 Salesforce AI，通讯作者为 Zhou Yu 和 Bin Bi。
  • arXiv:2608.07545（DarwinX 论文，同团队前期工作）：描述了进化 Harness 的 preserve-and-extend 框架，与本论文使用相同的任务套件和 GEPA-style 搜索方法（引用自 Agrawal et al., 2025）。

交叉验证结论：

  • VentureBeat 报道（2026 年 9 月）确认了核心数字：Harness 进化使 Qwen 模型从 29.2% 升至 78.0%，同时提到 Salesforce 整体 Enterprise AI Harness 战略。
  • 2026 年 4 月 Addy Osmani 的 "Agent Harness Engineering" 文章确认了 Harness 作为独立工程工件的行业认知趋势，LangChain 案例显示单靠改 Harness（不改模型）将 Terminal Bench 2.0 从 52.8% 提升至 66.5%。
  • 原帖 @omarsar0 描述"大多数'模型很蠢'其实是 Harness 问题"与论文 abstract 及 VentureBeat 报道吻合，属于论文核心论点，非夸大。
  • 论文提及的"7 项企业任务"与原帖"企业 Agent 7 任务验证"一致，数字来源可对应。
  • ⚠️ 不确定处：论文未公开具体 7 项任务的逐一性能数字（原文仅给出范围"−4 到 −30 points"），攻略中"29.2% → 78.0%"数字来源于 VentureBeat 报道，尚未在论文原文中直接找到原文对应表述，标注为原帖/报道主张，供参考。

核心机制：同策略修正（On-Policy Correction）

论文提出的解法叫同策略专家修正管道，核心思想是：不让弱模型模仿完整的专家轨迹，而是让它先自己跑一遍（on-policy），然后用元级 MLE Agent 定位"哪一步坏了"，让专家只重写那一步。

弱模型自 rollout → 元 Agent 定位失败 turn → 专家只重写该 turn → 保留弱模型规划风格

这样做的好处： - 弱模型的规划风格（planning style）保持不变，只是执行能力被修正 - 与 Harness 的配合默契得以保留 - 结合了 Harness 进化的收益和模型微调的收益

论文将此提炼为一条可复用的协同进化配方（co-evolution recipe），适用于资源受限的企业 Agent 场景。

上手步骤：如何在自己的项目里用这一发现

第一步：确认瓶颈在 Harness 而非模型

在投入资源调模型之前，先用以下方法确认 Harness 是否是主要瓶颈：

  1. 将当前任务 Prompt 改为更详细的指令（显式描述工具调用时机、错误处理策略）
  2. 如果性能明显提升，说明 Harness 有优化空间
  3. 参考 Addy Osmani 的做法：在 Hook 层拦截 Agent 的 early-exit 行为，强制继续执行完整任务

第二步：用 GEPA-style 搜索进化 Harness

论文使用的 harness 进化方法基于 Generalized Evolution Prompting（GEPA，Agrawal et al., 2025）。实践中可以简化：

  1. 收集弱模型在当前 Harness 上的失败案例（轨迹 + 错误类型）
  2. 用强模型（如 GPT-4o / Claude）作为 meta-agent 分析失败原因
  3. 针对每类失败，生成 3–5 种 Harness 修改方案（Prompt 调整 / 添加工具 / 修改执行钩子）
  4. 用弱模型在修改后的 Harness 上重新跑，对比成功率
  5. 保留胜出的修改，进入下一轮迭代

第三步：避免全轨迹模仿的陷阱

如果你的目标是让小模型变强（而不只是让它使用更好的 Harness），不要直接用大模型轨迹做 SFT：

  • 改用 on-policy correction：让小模型自己跑，定位失败步，只让大模型重写那一步
  • 或者直接用 RL（如 GRPO）而非 SFT，让模型通过环境反馈学习，避免规划风格偏移

第四步：测试跨模型迁移

Harness 进化的一个重要副产品是跨模型可迁移性：为弱模型进化的 Harness，强模型也能用，而且往往用得更好。

在企业场景中，这意味着： - 可以用小模型 + 进化 Harness 做快速原型验证 - 验证通过后，直接将同一 Harness 部署在更强模型上，性能往往还会提升

坑与适用边界

坑 说明
Harness 进化有边际递减 超过一定轮次后，继续优化 Harness 的收益变小，需要引入模型权重更新。论文的核心贡献就是找到两者联合的最优路径。
不是所有任务都值得进化 Harness 如果任务种类多、分布广，逐任务进化 Harness 的成本会超过收益。此时应优先考虑路由到更强模型。
全轨迹模仿在小模型上几乎必定失败 这个坑在论文中跨越两个模型家族（Qwen3-Coder 和 Gemma 4）都复现了，是结构性而非偶发性问题。
on-policy correction 需要元级 Agent 论文使用 meta-level MLE agent 自动化失败定位和修正生成，搭建这套基础设施本身有成本。
适用场景主要是企业级 Agent 论文基准是工资审计、IoT 异常检测等有客观验证函数的任务；开放性任务（如开放式对话）不适用此框架。

一句话结论

当你的 Agent 表现不及预期，先问"Harness 够不够好"再问"模型够不够强"——因为进化 Harness 可以让弱模型在企业任务上提升近 50 个百分点，而错误的微调路径反而会把这些收益全部吃掉。同策略修正（只重写失败那一步）才是 Harness 与 Model 协同进化的正确打开方式。

📚 论文引用：Yu, Z., Bi, B., Pentyala, S. K., et al. (2026). Co-Evolving Harnesses and Models: On-Policy Correction Helps Weaker Models Catch Up Where Imitation Fails. arXiv:2609.09134. Salesforce AI.

🔗 来源推文：@omarsar0（Omar Khreich）· DAIR.AI 联合创始人 · 2026-09-11