Harness-Zero：把「harness 增益」蒸馏进权重，部署时摆脱专用 harness

关联论文：2609.24974
作者：flyP
更新：2026-09-22

一句话结论：Harness-Zero 提出 agent-as-harness 思路——用一个「harnessing agent」在 target harness 的 action space 内、参考 optimized harness 给出引导并修正 student 响应，把 optimized harness 行为直接转写成训练轨迹；微调后 student 在 target harness 下 macro task success 从 23.3% → 44.3%，甚至超过留着 optimized harness 时 41.7% 的成绩，并把 28 种 harness-induced 行为中的 82.3% 恢复进模型。

§0 元层五问

真问题到底是什么：Agent harness（agent 框架：提示词模板、tool 调用约定、消息格式、错误恢复路径）现在经常是「一个 harness 解决一类任务」的——你跑 coding 任务用一个 harness，跑 science 任务又换另一个。但把 harness 增益永久烙进模型权重（即「去掉这个 harness 也能保留它的能力」）很难。
本文到底想做什么：把「domain-/instance-optimized harness」当 teacher，把它对学生输出「诱导出的改进」蒸馏到学生权重里，使部署时只用 target harness 也能保留 optimized harness 的能力。
为什么这值得读：绝大多数 agent benchmark 的好成绩其实都是「harness × model」耦合出来的，换 harness 立刻回到普通水平。Harness-Zero 把 harness 增益结晶到权重，让「单 harness 部署」不再意味着损失。这是 agent 工程化的关键一步。
谁该读：做 agent 框架 / harness 设计的研究员、做 agent infra / tool routing 的工程师、做 agent benchmark 评估的人。
不看会怎样：会继续以为 agent 提升来自 prompt engineering / harness scaffolding，而忽视「harness 增益蒸馏」是一个独立的、可量化的研究方向。

§一解决的真问题

Agent harness 在 2024–2026 的生态中地位越来越重：

同样的模型，用 OpenAI function-calling harness 跑 vs Anthropic tool-use harness 跑，分数能差 10–30 个百分点。
不同公司、研究机构、benchmark 维护者都会维护自己的 harness，且这些 harness 绑死在 prompt 模板 + tool schema + 错误恢复逻辑上。
学术上「cross-harness generalization」几乎是空白——大多数论文声称 SOTA 时没有声明「这是哪个 harness 跑出来的」。

Harness-Zero 想要回答：

当我们投入大量工程优化某一个 optimized harness 时，能不能把这个 harness 带来的能力永久固化到模型里？

这与「distill from teacher model」的传统路线不一样：teacher 是另一个 LLM（harnessing agent），监督信号是「在 target harness action space 内的修正过的轨迹」，而不是「同样的 prompt 同样的 action 下的 output」。

§二核心方法

2.1 问题形式化

Optimized harness H*：在某 domain 或 instance 上做了大量优化的 harness（专用 prompt + 专用 tool 调用 + 专用恢复策略）。
Target harness H_t：部署时实际使用的 harness（往往比 H* 简单、通用）。
Goal：在 H_t 上部署 student model π，且 π 在 H_t 下的行为等价于它在 H* 下学到的能力。

传统蒸馏失败的原因：H 与 H_t 的 action space 与可用信息不同（不同 tool、不同 message format、不同 step 边界），所以 H 的轨迹不能直接当成 H_t 下的监督。

2.2 Agent-as-Harness：核心思路

Harness-Zero 引入 harnessing agent——这是一个 LLM agent，用 H 作为自己的环境/teacher，在 H_t 的 action space 内*生成训练轨迹。

具体流程：

# 训练数据生成（offline）
for task in train_tasks:
    # 1) H* 给出「理想的高质量轨迹」
    trace_star = rollout(H*, task)              # H* 的 action space
    # 2) 在 H_t 中重放，但让 H* 作为「实时裁判」
    student_response = student_rollout(H_t, task)   # H_t 的 action space
    corrected_response = harness_agent(           # harness agent 用 H* 视角
        H*, task, student_response, target=H_t
    )
    # 3) 把 corrected_response 当 student 在 H_t 下的目标轨迹
    train_pair.append((task, corrected_response))

# 微调
student = finetune(base_student, train_pair)

关键设计：

Harness agent 作用是「修正」：在 H_t 的 action space 内，参考 H 给出的引导，把 student 的 raw response 修正成「带 H 风格、又能跑在 H_t 下」的轨迹。
修正过程是一次性离线标注，不是在线 RL。这样就避开了「多步 rollout reward sparse + harness 改变带来的 distribution shift」噩梦。

2.3 部署时去掉 H*

训练完成后，部署时只用 H_t，不再带 H。Harness-Zero 的关键声明是：student 权重里已经吸收了 H 的诱导行为。

论文给三个数字：

Agent-as-harness > code-as-harness：在前沿 LLM + 同一 evolved harness 下，agent-as-harness 路线比 code-as-harness 更优（paper 数字细节 ⚠️ 原文未在 abstract 给具体幅度）。
23.3% → 44.3%：base 模型 + H_t 跑 macro task success 23.3%，加 H 后是 41.7%，Harness-Zero 微调后 + H_t 回到 44.3%，超过* 41.7%。
82.3% 行为恢复率：Harness-Zero 恢复了 H* 引入的 28 类特定行为中的平均 82.3%。

第三个数字非常关键——它说明 harness 增益不是「不可拆解的整体行为」，而是「可拆解的 28 类微行为」，平均恢复率 82.3% 是一个直接证据，证明蒸馏确实把行为搬到权重里了。

2.4 与已有方向的差异

vs model merging / RLHF：这些改的是模型的「通用能力」，不针对 harness 耦合行为。
vs prompt distillation：prompt distillation 把 prompt 知识压成另一个 prompt，部署时仍要带蒸馏出来的 prompt；Harness-Zero 是把 prompt × harness × tool 行为压成权重。
vs agent foundation model（AFM / Toolformer / Agent-Foundation-Models）：那些是把工具使用能力内化，但没区分「同一能力的 harness vs 模型」。

§三关键实验与数据

任务域：knowledge work、tool use、science（3 大类）。
核心数字：
macro task success 23.3% → 44.3%（+H_t 部署 vs +H 部署），加 H 是 41.7%（44.3% > 41.7%）；
28 种 harness-induced 行为的平均恢复率 82.3%；
frontier LLM × same evolved harness 下，agent-as-harness > code-as-harness。
实验设置规模：⚠️ 原文 abstract 未明确 (具体任务数 / 模型规模 / 评估样本数)。

⚠️ 不确定处：

涉及的具体模型（GPT-4? Claude-3.5? Llama-3.1-405B? 多个 frontier？）
具体数据集 / benchmark 名（GAIA? ToolBench? SWE-Bench? 自建？）
28 类 harness-induced 行为具体是哪 28 类。
「knowledge work / tool use / science」的具体任务分布。
训练数据规模（多少 task、每 task 多少 trajectory）。

§三.反方五元（R 命名）

R1.（机制层面）harness agent 的归纳偏置假设

整个方法假设存在一个 LLM agent 能「在 H_t action space 内、对 H 风格做无偏修正」。这个假设的强依赖是：harness agent 必须比 student 更懂 H 与 H_t 的差异*。如果 harness agent 本身是 base frontier LLM，那它自己也有 harness 偏置；它给出的「修正」可能反映了 harness agent 自己的偏好，而不是 H 的真实能力上界。⚠️ 论文未公开 harness agent 的消融实验（harness agent 换成弱模型会怎样？）。

R2.（数据层面）28 类行为的可拆解性是论文断言

abstract 给出「82.3% recovery across 28 patterns in three domains」，但没说：

28 类是怎么枚举出来的？人工还是 LLM 分类？
类间是不是有重叠（如「tool retry」与「error recovery」可能交叉）？
训练数据 / 评估数据中这 28 类的分布是否平衡？

如果 28 类本身是 LLM 分类器在测试集上聚出来的，会产生 classifier-induced overfit：harness agent 修得对的部分刚好被分类器认成「H* 行为」；修得偏离的部分被分类器忽略。这是一个 evaluation pipeline 偏置的经典坑。

R3.（截止日 / 证伪层面）macro task success 是 task-level 还是 step-level

「23.3% → 44.3%」是 macro task success（任务级）。agent 任务常见的细节是：

单步成功率 vs 任务级成功率差距巨大（task-level 通常 < 10%）；
macro 平均 vs micro 累加在多任务分布不均时差距显著。

论文没承诺「macro vs micro 一致」，没承诺「单步 vs 任务级一致」。⚠️ 读者应警惕「task-level 大幅提升」背后可能藏着 step-level 小幅提升。

R4.（底线层面）「超 H* 41.7%」的对照是否公平

Harness-Zero 微调后 +H_t 是 44.3%，超过 +H 的 41.7%。但 +H 41.7% 通常是「base model + H (no finetune)」的数字。Harness-Zero 的 44.3% 是「base model + Harness-Zero finetune + H_t」*，两者引入了不同变量（finetune vs harness）。

更公平的对照应该是：「base model + generic finetune + H*」 vs 「Harness-Zero + H_t」。abstract 没承诺这个对照。⚠️ 需 PDF Table 中找公平对照。

R5.（法律 / 合规层面）tool use 任务的工具调用合规

tool use 任务中 agent 调用了真实工具（如 web search、数据库查询、shell execution）。训练出来的 student 在部署时也会调用这些工具：

欧盟 AI Act Article 6 / 中国《生成式 AI 服务管理暂行办法》：高风险 AI 系统（含具备自主工具调用能力的 agent）的可追溯性、human-in-the-loop 要求。
数据出境：tool use 任务如果调用境外 SaaS API，训练数据可能含个人信息（PII），数据出境合规（GDPR Art. 46 / 中国 PIPL 第 38 条）需评估。
责任划分：当 student 模型调用了错误的 tool 并造成损害（如发了错误邮件、删了文件），责任在模型提供方、harness 提供方、还是部署方？

⚠️ 论文 abstract 未声明这些合规边界，本文 §3.4 仅作提示。

§三.4 法律独立段：上述 R5 为提示性说明，本文不就具体的 GDPR / PIPL / EU AI Act 适用场景作判定；落地需结合具体司法辖区对 agent / tool use AI 的专项规范。

§四亮点与局限

亮点

「agent-as-harness」思路绕过了「harness 不能跨 action space 直接蒸馏」的卡点。
28 类行为 × 82.3% 恢复率提供了「harness 增益可拆解」的实证。
44.3% > 41.7%（+H*）是「蒸馏反而超过 teacher」的少见结果，符合 distillation-vs-teacher 经典结论。

局限

harness agent 的能力是上界前提 ⚠️ 论文未做 harness agent 弱化消融。
28 类行为枚举方法 ⚠️ 原文未明确。
task-level vs step-level 细节 ⚠️ 原文未明确。
公平对照（finetune+H* vs Harness-Zero+H_t）⚠️ 论文未在 abstract 承诺。
任务域、模型、benchmark 具体名单 ⚠️ 原文未明确（需 PDF）。

§五 A 五元（Trigger 命名）

A1. 触发「harness agent 修正循环」：对每条 student raw response，harness agent 用 H 视角做一次 in-context 修正，结果作为 train_pair target。 A2. 触发「H_t 重放」：修正必须在 H_t action space 内执行；任何超出 H_t action 的修正在 reject。 A3. 触发「28 类行为分类器评估」：每训练周期用 28 类 harness-induced 行为分类器做诊断，输出每类恢复率。 A4. 触发「公平对照基线」：训练一个 baseline = base model + 通用 SFT + H，确保 Harness-Zero 不是被「通用 SFT」提升稀释。 A5. 触发「跨 harness 迁移测试」：训完 Harness-Zero 后，再用另一个未参与训练的 harness H' 测试 student，看是否仍保留能力——这能区分「学到了 harness-agnostic 能力」与「只是拟合了 H_t 的指令风格」。

§五.合流

Harness-Zero 给出的核心价值主张是：「agent 增益不应绑死在 harness 上」。这与当下 benchmark 圈「靠 harness 拿分」的现状是直接对线。

工程现实：

22 个百分点任务级提升（23.3 → 44.3）非常可观，但代价是额外一次 frontier LLM 充当 harness agent 的标注成本——这在生产环境里是真实开销。
28 类行为分类器需要预先定义且可解释，否则会有 classifier-induced overfit。
跨 harness 迁移（trigger A5）目前论文没做，工程团队应该主动跑这个 sanity check。

§六工程落地启发（P0/P1/P2）

P0（必须做）

公平对照基线：训练一个 base model + 通用 SFT + H*，否则你分不清 Harness-Zero 提升来自「harness 蒸馏」还是「通用 SFT 提升」。
harness agent 选型：harness agent 必须明显强于 student，否则修正偏置会拖后腿。
28 类行为分类器独立构建：不要复用训练数据分类器来评估；用 held-out 标注集。
tool use 安全审计：所有 tool 调用必须有 rate-limit、危险操作需 human-in-the-loop、调用日志全留（合规硬约束）。

P1（建议做）

跨 harness 迁移测试（trigger A5）。
harness agent 弱化消融：把 harness agent 从 GPT-4 降到 Llama-3.1-70B，看 student 收益曲线是否平稳下降——验证「harness agent 能力上界」的假设。
macro vs micro 任务成功率分轨评估，避免被「任务级宏平均」掩盖单步问题。

P2（可探索）

跨领域 transfer：训完 science domain 的 Harness-Zero，是否能 zero-shot 迁移到 code domain？
harness agent 自进化：把 harness agent 也用 RL / DPO 调优，看 student 收益是否进一步提升。
作为 v34 §1 折 4 评测方法学延革候选：本工作可作为 ★★★ 候选——它给出了一个独立于 harness 的、可量化的 agent 能力度量方法。

§七与同方向工作的关系

vs Prompt Distillation / PromptAgent / APrompt：那些蒸馏的是 prompt → prompt；本工作蒸馏的是 prompt × harness × tool 行为 → weights。
vs Agent Foundation Model（AFM / Toolformer / AgentFM）：那些把工具使用能力内化，但不区分「harness 增益」与「模型能力」。
vs RL-from-Rollout / RL-from-Execution-Feedback（如 ReAct / Reflexion / AutoEval）：那些是在线 RL，Harness-Zero 是离线蒸馏。
vs Harness Designer / DSPy / TextGrad：那些是「设计 harness 本身」，Harness-Zero 是「冻结 harness 行为到权重」。

⚠️ Harness-Zero 与现有 harness 框架（DSPy、AutoGen、CrewAI）的兼容性 ⚠️ 原文未承诺，本文不外推。

§八适合谁读 & 评级

适合：(a) agent harness / infra 工程师，(b) 想让 agent benchmark 公平可比的评测者，(c) agent foundation model 研究员。
不适合：纯产品角度「harness 怎么写得更好」的读者（这是另一条线）。

§八.评级（四子项算术平均）

子项	分
机制新颖度（agent-as-harness + 离线蒸馏 + 跨 action space 修正）	A+
数据/实验可复现（abstract 数字可溯源 + GitHub 待验 + 具体 benchmark 待核）	A-（⚠️ 模型/数据集/28 类行为枚举未明确）
双轨完整性（正方 + ⚠️反方五元 + §3.4 法律独立段）	A（5 元覆盖机制/数据/证伪/对照/法律）
工程可落地（§六 P0/P1/P2 + 跨 harness sanity check）	A-（harness agent 标注成本高，公平对照需做）
算术平均	A

§八.撞自己（预备候选量化承认）

与 W31~W38 lessons 中提到的 VLA / RL 后训练工作无撞名。与同档 [0.5] 队列的 2609.24118 (CARE, VLA) / 2609.24432 (IER-OPD, 蒸馏稀疏化) 也无方法学撞名——Harness-Zero 是 agent harness 蒸馏线，方法论独立。

⚠️ 本工作若被独立第三方复现，是 ★★★ 候选——「harness 增益可量化、可拆解、可蒸馏」这条主线在 agent 工程化中是稀缺论断。但因暂无被引（[0.5] 队列），暂未升格。

§九边界声明（12/12）

仅 abstract-based → 未下载 PDF。
GitHub URL abstract 未给出 ⚠️ 需查正文 / 后续 v2 才能确认。
涉及模型（frontier LLM 具体名单）→ ⚠️ 原文未明确。
涉及数据集 / benchmark 名 → ⚠️ 原文未明确。
28 类 harness-induced 行为枚举方法 → ⚠️ 原文未明确。
训练数据规模 / 评估样本数 → ⚠️ 原文未明确。
公平对照（base + 通用 SFT + H*）→ ⚠️ 原文未在 abstract 承诺。
harness agent 弱化消融 → ⚠️ 原文未明确。
跨 harness 迁移测试 → ⚠️ 原文未明确。
合规边界（EU AI Act / PIPL / GDPR Art. 46 / HIPAA）→ ⚠️ 论文未声明，本文 §3.4 已声明。
「23.3% / 41.7% / 44.3% / 82.3%」是 macro task success 还是 micro / step-level → ⚠️ 原文未明确，本文已声明为 task-level。
arXiv 编号 + 提交日期连贯性：arxiv 2609.24974 / v1 提交日期 ⚠️ abstract 未给具体时间戳，需 PDF 第一页核 Submission history。

关联论文：arxiv.org/abs/2609.24974 · cs.AI / cs.CL / cs.NE · agent harness distillation · 「agent-as-harness」

工程落地与核查（Jay）

事实核查存疑处

GitHub URL 缺失：abstract 未给出 GitHub 链接，无法验证代码是否存在、是否可运行。⚠️ 这是复现性硬缺口，工程团队应在 v2/PDF 发布后立即核查。
「agent-as-harness > code-as-harness」无具体幅度：abstract 提及这一结论但未给出数字，无法判断实际改进大小。⚠️ 需 PDF Table 对照核验。
公平对照存疑：44.3%（Harness-Zero + H_t）超过 41.7%（base + H），但两者变量不同（微调 vs harness）。abstract 未给出「base + 通用 SFT + H」的公平对照。⚠️ 若公平对照下 Harness-Zero 不再超过 H*，核心声明被削弱。
28 类行为分类器的构建方法未披露：82.3% 恢复率的评估依赖一个 28 类分类器，但其构建方式（人工标注 / LLM 聚类 / 规则？）未披露。若为 LLM 聚类则存在 classifier-induced overfit 风险。

工程落地（实际系统怎么用）

训练成本估算

harness agent 标注成本是最大工程瓶颈：每条 student trajectory 需要 harness agent 做一次 in-context correction，本质是额外一次 LLM forward（harness agent 本身是 frontier LLM）。如果训练集 10K 条轨迹，每条 200 tokens，harness agent forward cost = 10K × 200 × frontier_price，这是不可忽视的生产成本。
H 轨迹采集需要跑 H：每个任务需要先在 optimized harness 下 rollout 获取 trace_star。H* 往往比 H_t 慢（专用 harness 有额外 tool 调用链），采集成本高于普通 rollout。

适用场景判断

先做 same-harness 迁移测试：A5（跨 harness 迁移）是必做 sanity check。如果训完 Harness-Zero 后只在 H_t 上有效，换 H_t' 就崩，则 Harness-Zero 实质上是在「拟合 H_t 的风格」而非「固化 H* 的能力」。
harness agent 选型决定天花板：harness agent 应比 student 高至少 1 个档次（建议 GPT-4o / Claude-3.5-Sonnet 以上），否则修正信号本身就有偏。
28 类行为分类器的构建优先级高：在训练前先明确 28 类的枚举方式；若用 LLM 聚类，需在 held-out test set 上验证分类器一致性（F1 ≥ 0.8 才可信）。

部署注意

student 权重里固化的是 H* 诱导的偏好：如果 H 有偏向性（如偏重 coding harness 对安全过于宽容），student 也会继承。部署前应用红队测试验证 student 是否保留了 H 的全部行为（包括有问题的行为）。
tool use 危险操作必须有硬安全网：harness 蒸馏只管能力，不管安全。真实系统中的 shell execution / delete / send 操作必须有 human-in-the-loop 或 rate-limit。

常见坑点

#	坑	严重性	表现	解法
1	harness agent 引入的标注成本吃掉所有节省	P0	harness agent 每条轨迹多一次 frontier LLM call，总成本 vs full OPD 可能不降反升	先用小模型（如 GPT-4o-mini）做 harness agent，找 cost/quality Pareto frontier
2	GitHub 不存在 / 仓库不可运行	P0	abstract 未给 GitHub，v1 可能无代码，无法工程落地	等 v2 或联系作者；不要基于不可验证的 abstract 数字做生产决策
3	28 类分类器 overfit 导致 82.3% 被高估	P0	分类器把 harness agent 修对的 token 都认成 H* 行为，实际 student 泛化差	用独立标注的 held-out set 重测 28 类恢复率，不复用训练集分类器
4	公平对照缺失，44.3% > 41.7% 声明存疑	P1	base + generic SFT + H* 对照未做，44.3% 优势可能来自通用 SFT 而非 harness 蒸馏	在 PDF 出现公平对照前，生产决策只用「Harness-Zero + H_t」与「base + H_t」的差值评估 ROI
5	跨 harness 迁移失败	P1	A5 未在论文做，student 只学了 H_t 的表面风格而非 H* 的能力本质	训练完成后主动用 H_t'（未参与训练的 target harness）测一次，若下降 >20% 说明失败
6	H* 与 H_t 的 action space 差异过小，harness agent 修正空间有限	P1	如果 H* 与 H_t 本就相似，修正动作很少，harness agent 优势发挥不出来	先测 H* 与 H_t 的 action space 编辑距离，距离 <10% 则 Harness-Zero 收益有限
7	harness agent 的修正引入自己的偏置	P1	harness agent 是 frontier LLM，它修正的轨迹带它自己的风格，不等于 H* 的真实能力	harness agent 修正后的轨迹应由 H 做最终裁判，确保修正方向与 H 一致
8	部署后 student 行为在边界任务上退化为 H* 诱导的坏习惯	P2	H* 的偏好（可能有问题但实验场景未暴露）被固化进权重，边界情况暴露	用对抗性任务测试集做 final acceptance test，特别测 safety-critical tool call