PAPER DEEP DIVE
Harness-Zero：以智能体作为运行时实现智能体运行时蒸馏
Harness-Zero 将优化后的学生侧运行时适配为教师私有审查规范，在每次响应执行前把运行时指导改写为目标运行时可用动作，再通过筛选后的轨迹 SFT 把行为蒸馏进模型；部署时仅保留固定最小运行时。
一句话总结：Harness-Zero 让一个审查智能体依据优化运行时生成的私有规范，在学生每次动作执行前完成纠正，再用可执行且经过筛选的轨迹做监督微调，使优化运行时的行为在部署时沉淀到模型权重里。
研究背景：运行时既塑造能力，也把能力锁在系统之外
大模型智能体的任务能力并不只来自模型参数。上下文组织、工具接口、中间件、技能文件、记忆结构以及执行循环共同决定模型能看到什么、能做什么，以及何时停止。论文把这些位于模型之外、负责连接模型与环境的系统统称为智能体运行时，也就是 harness。相同的基座模型换用不同运行时，任务成功率可能相差数十个百分点，因此运行时已经成为智能体能力的一部分。
问题在于，优化得到的运行时通常与部署条件绑定。某个领域表现最好的运行时，未必适合另一个领域；针对一个模型调好的动作接口，也可能不适合更新后的模型。若一个通用智能体要覆盖知识工作、软件工具和科学推理，它要么选择一个折中的共享运行时，要么在不断增长的专家运行时集合之间路由。前者牺牲峰值能力，后者增加部署、维护和上下文切换成本。
已有工作大致有两条路线。第一条是代码型运行时优化，直接修改提示、工具与中间件，让模型在优化后的系统中工作。第二条是训练模型，让模型在固定系统里变得更强。前者容易形成领域专用的复杂代码，收益在移除系统后消失；后者不直接利用优秀运行时所诱导出的行为。论文提出的关键问题是：能否把优化运行时的作用当作训练信号，让学生模型在最小运行时中重新表现出这些行为？
这个目标并不等同于普通的行为克隆。优化运行时的动作空间可能包含学生根本没有的工具，附加上下文也可能包含学生目标运行时不允许出现的信息。若直接把优化运行时下的轨迹交给学生，学生会学到无法执行的命令，或者依赖部署时不存在的观测。因此，真正困难的是跨运行时转换，而非收集更多轨迹。
作者将问题命名为智能体运行时蒸馏。它要求在训练时使用领域或实例优化后的运行时，在部署时只保留一个固定的目标运行时。训练信号来自优化运行时所诱导的行为，最终载体却是模型参数。这一表述把“设计更好的外部系统”和“训练更强的内部策略”连接起来，也解释了论文方法的边界：蒸馏完成后仍需要运行时，只是不再需要那个复杂且昂贵的专家运行时。
预备概念：目标运行时、优化运行时与私有参考运行时
论文用 h 表示部署时固定的目标运行时。实验中，它是一个精简的 mini-SWE-agent 风格系统，只提供固定系统提示和一个 Bash 执行工具。用 h* 表示在训练任务上自动演化出的学生侧专家运行时，它可包含更多工具、中间件、技能和记忆。用 K 表示从 h* 适配出来、供审查智能体私下阅读的参考运行时。三者不是同一对象的三个名字，而是训练和部署阶段承担不同职责的系统。
学生策略记作 πθh：参数为 θ 的模型在运行时 h 下产生的响应分布。状态转移记作 Th(c,y)：给定学生当前可见上下文 c 和响应 y，运行时 h 执行动作并返回下一轮学生可见上下文。这个记号把模型策略和环境转移分开，便于讨论动作空间不匹配：模型可以生成某个字符串，但只有 h 能决定该字符串是否可执行、执行结果如何进入上下文。
“智能体作为运行时”并不是让审查智能体取代沙箱。它是在学生响应边界增加一个私有审查层。学生仍然在 h 下行动，所有最终动作仍由 h 执行；审查智能体只读取 h* 适配后的规范，对尚未执行的学生响应进行通过或替换。这样，优化运行时的知识可以改变轨迹，却不必把不可执行的专家工具直接塞进部署系统。
方法总览：先适配规范，再在响应边界纠正，最后做监督微调
论文的方法分为三步。第一，在训练任务上演化出学生侧专家运行时 h*，再把它适配成审查智能体可读的私有参考运行时 K。第二，让学生仍在 h 下产生每一步响应，由审查智能体在动作执行前判断是否通过；若拒绝，就生成一个完整、可在 h 中执行、从学生视角书写的替换响应。第三，只保留成功轨迹，对被接受的原响应和替换响应做 SFT。部署时删除 h*、K 和审查智能体，只留下蒸馏后的模型与 h。
flowchart LR
A["Training tasks D_train"] --> B["Evolve optimized harness h*"]
B --> C["Adapt h* relative to target h"]
C --> D["Private review guidance K"]
E["Student proposal y_t under h"] --> F{"Harnessing agent reviews"}
D --> F
F -->|PASS| G["Accepted y_t"]
F -->|REPLACE| H["Complete replacement z_t valid under h"]
G --> I["Execute through target harness h"]
H --> I
I --> J["Student-visible observation c_t+1"]
J --> E
I --> K["Keep successful reviewed trajectories"]
K --> L["SFT on accepted responses"]
L --> M["Deploy distilled model under h only"]
图 1 的三个区域与上述阶段一一对应。左侧是运行时演化与适配；中间是训练轨迹采集，学生与审查智能体共享任务上下文但拥有不同可见信息；右侧是训练与部署，审查视角的推理会被屏蔽，最终系统不再携带专家运行时。图中底部的回合示例说明审查并不总是改写：当学生已经调用技能并读取工作簿时，审查可以返回 PASS；当学生过早结束时，审查会替换为继续读取输入输出文件并完善交付物的动作。
图 1：Harness-Zero 的运行时演化、审查式轨迹采集、监督微调与部署流程。图片来源：论文 Figure 1。
第一步：演化运行时，再把它翻译成审查规范
给定训练任务集合 Dtrain，论文先执行运行时演化，再相对目标运行时 h 做适配：
$$ h^{\star}=\operatorname{Evolve}(\mathcal{D}_{\mathrm{train}}), \qquad \mathcal{K}=\operatorname{Adapt}(h^{\star};h). $$
这个公式定义了两个不能合并的对象。h* 是面向学生的优化运行时，K 则是为审查智能体准备的行为规范。适配必须参考 h，因为最终替换响应要在 h 的工具接口与观测结构里成立。作者没有假设两个运行时具有相同动作，而是把差异显式放到 Adapt 操作中。
实现上，演化步骤使用一个由技能引导的迭代循环：在训练任务上运行，分析反复出现的失败，再更新领域运行时。论文把 h* 放在 DeepAgents 抽象下，组件包括工具、中间件、技能和记忆。演化过程并非本文的核心创新，作者有意把它当作可替换的前置优化器。这一点使 Harness-Zero 可以接收不同自动运行时优化方法产生的 h*，而不必绑死某一种搜索算法。
适配阶段重新安排组件的受众与生效位置。专家运行时中的额外工具不会原样复制给学生，而会被改写为构造学生原生等价动作的规格；原本直接阻断或修改学生执行的中间件，会变成只在私有侧提醒审查智能体的审查中间件；技能和记忆则转成诊断条件与干预指南。部分领域还会生成附加系统提示，用来告诉审查智能体应优先检查哪些失败模式。
这种转换解决了动作空间不一致，但也设定了信息优势边界。审查智能体只可读取 K，不可读取隐藏答案或验证器反馈，也不能直接访问学生上下文之外的环境状态。如果它要确认某个中间结果，必须提出一个 h 可执行的检查动作，再把检查结果写回学生可见轨迹。由此产生的训练样本既包含更优行为，也包含学生将来能够观察到的证据。
第二步：每条响应先审查，再进入环境
代码型运行时方法直接让基础模型在 h* 中行动，转移关系为：
$$ y_t\sim\pi_{\theta_0}^{h^{\star}}(\cdot\mid c_t), \qquad c_{t+1}=T_{h^{\star}}(c_t,y_t). $$
这里的响应由 h* 塑造并由 h* 执行，因此优化收益依赖 h* 在部署时仍然存在。Harness-Zero 则让学生仍在目标运行时下提出响应：
$$ y_t\sim\pi_{\theta_0}^{h}(\cdot\mid c_t). $$
学生先给出未执行提案，审查智能体结合当前上下文、该提案、私有规范 K 和此前审查历史 r<t，输出决策与实际替换内容：
$$ (d_t,z_t)\sim\pi_H(\cdot\mid c_t,y_t,\mathcal{K},r_{{<t}}). $$
最终进入环境的响应由决策决定：
$$ \tilde y_t= \begin{cases} y_t,&d_t=\textsc{pass}\\ z_t,&d_t=\textsc{replace} \end{cases} $$
目标运行时随后执行被接受的响应，并产生下一轮学生可见上下文：
$$ c_{t+1}=T_h(c_t,\tilde y_t). $$
这组公式体现了论文最重要的架构选择：审查发生在执行边界，而不是运行在另一条独立轨迹上。被拒绝的原提案和私有审查过程不进入学生上下文，只有被接受的原响应或替换响应会被执行。这样，学生看到的训练序列与部署时运行的调用形状一致；审查智能体的特权知识不会以隐藏提示的形式泄漏到测试时输入。
替换策略强调最小改动。学生提案正确时原样通过；需要介入时，审查智能体生成一个完整且可执行的替换，并尽量保留其余内容。这里采用完整响应替换而非局部 token 编辑，是因为运行时接口以一条消息或一次工具调用为单位。完整响应可以保证工具调用、可见文本和推理结构彼此一致。代价是干预粒度较粗，论文也把它列为未来可改进之处。
整个学生 rollout 对应一个持续的审查会话。每轮审查智能体只接收上次审查后新增的学生可见事件和当前未执行提案，因此能理解局部进展，又不必重放全部环境。这个设计让纠正具有条件性：同一个命令在不同前序状态下可能一个通过、一个被替换，而不是依赖一组与上下文无关的静态规则。
源码对应：PASS 与 REPLACE 在实现中不是提示约定
仓库把审查边界写成了带类型约束的中间件。在 src/harness_zero/student.py:98-208 中，HarnessReviewMiddleware 拦截每次模型调用，把未执行响应写成审查候选，检查候选编号，并限制替换次数与总轮数。若审查预算耗尽，代码会显式通过当前候选；否则调用审查器。关键分支如下：
if submission.decision == "PASS":
accepted = candidate.original
accepted_message = original_message
else:
accepted = submission.replacement
assert accepted is not None
accepted_message = accepted.to_message(candidate_id=candidate_id)
self._replacement_count += 1
self._store.append_review(candidate, submission, accepted)代码位置：src/harness_zero/student.py:154-171。这段实现表明，环境真正收到的不是审查器返回的任意文本，而是原消息或经过完整重建的替换消息。
src/harness_zero/review.py:15-96 进一步定义了 PASS 与 REPLACE 的互斥语义：PASS 不允许携带替换，REPLACE 必须携带一个至少包含可见内容或工具调用的完整响应。该模型还要求每个提交只有一个候选编号和一条理由。类型模型把论文中的“通过或替换”从自然语言约定变成可验证接口，减少审查器输出半个补丁、空动作或同时给出两个决策的情况。
if self.decision == "PASS" and self.replacement is not None:
raise ValueError("PASS must not include a replacement")
if self.decision == "REPLACE" and self.replacement is None:
raise ValueError("REPLACE requires a complete replacement")
if self.replacement is not None and not self.replacement.is_actionable:
raise ValueError("a replacement must contain visible content or a tool call")代码位置：src/harness_zero/review.py:65-72。替换必须是可执行响应，而不能只写一句“这里应该再检查一下”。
第三步：从成功轨迹中学习，但不能让学生模仿审查视角
轨迹采集完成后，论文将所有被接受响应组成监督数据。令 Dreview 为保留下来的轨迹集合，Tτ 为一条轨迹的已接受响应轮数，优化目标为：
$$ \hat\theta= \arg\min_\theta-\sum_{\tau\in\mathcal{D}_{\mathrm{review}}} \sum_{t=1}^{T_\tau} \log\pi_\theta^h(\tilde y_t\mid c_t). $$
目标函数没有直接拟合 h* 的动作，也没有向学生提供审查器的私有上下文。训练样本的输入是学生在 h 中可见的 ct，标签是经过审查接受的响应。这里同时包含原样通过的提案与替换响应，使学生既学习保留自身合理的行动方式，也学习在关键位置采用优化运行时诱导出的程序。
一个容易被低估的风险是审查者口吻泄漏。替换响应由审查智能体在私有上下文中生成，可能在推理里出现“该候选动作不完整”“我选择替换”等只对审查者成立的描述。如果这些句子进入 SFT 标签，学生会在部署时无端评价一个不存在的候选，或者误以为自己拥有审查权限。仓库在 src/harness_zero/sft.py:12-77 中只接收成功且无异常的 trial，并利用 reasoning_leaks_review 找出包含审查口吻的推理轮次，再在训练侧屏蔽相应推理 token。
if reward < reward_threshold or exception is not None:
skipped_trials += 1
continue
events = [
json.loads(line)
for line in events_path.read_text(encoding="utf-8").splitlines()
if line.strip()
]代码位置：src/harness_zero/sft.py:20-29。只有成功、可读出轨迹且无异常的 trial 才进入训练数据，避免把失败过程当成正面示范。
src/harness_zero/dataset_utils.py:15-113 还维护私有标记过滤和“只保留学生可见消息”的断言。训练消息中一旦出现教师组件路径、候选文件、审查提交工具或审查中间件名称，数据构建会直接报错。这个校验把论文中的隐私边界落实为数据管道不变量。换言之，系统不是先训练再寄望模型忘掉审查信息，而是在训练样本生成时就删除审查侧结构。
训练配置与“运行时蒸馏”相匹配。论文对 Qwen3.5-9B 做 LoRA SFT，秩为 32，峰值学习率 2×10-4，最终学习率 1×10-6，批大小 8，最大长度 65,536，训练两个 epoch。三种任务分别保留 487、282、500 条轨迹。长上下文上限很重要，因为被接受的响应可能包含命令、文件内容与执行反馈，蒸馏目标不只是短问答。
部署公式非常简洁：
$$ y_t\sim\pi_{\hat\theta}^{h}(\cdot\mid c_t), \qquad c_{t+1}=T_h(c_t,y_t). $$
对比训练公式可以看到，h 始终没有改变，改变的只是策略参数。模型学会了在最小 Bash 运行时里产生此前需要专家运行时和审查智能体共同诱导的动作序列。部署系统是 (πθhat,h)，不包含 h*、K 或审查智能体。
实验设计：三类任务覆盖程序、交互与领域知识
SpreadsheetBench Verified 包含 400 个真实电子表格操作任务，论文使用 300 个任务做运行时演化与训练数据采集，保留 100 个任务评估。它检验状态检查、局部修改、公式操作和交付物验证等程序性行为。模型必须通过 Bash 操作文件，并理解表格中的输入输出约束。
AppWorld 使用官方训练集与开发集合并成 147 个训练任务，评估集为 168 个 test_normal 任务，按 56 个三任务场景组织。它要求模型跨多个模拟应用进行交互式工具使用。指标为场景目标完成率，而非单个 API 调用是否语法正确。这个任务更依赖长程状态管理和跨应用信息衔接。
USPTO Retrosynthesis 从反应语料构造 500 个训练任务和 100 个互斥测试任务，并平衡十种反应类别。目标是预测单步前体，既包含程序性的候选验证，也包含化学先验、候选生成和 SMILES 合法性等更深领域知识。它因此成为检验“可迁移程序”和“难迁移知识”差异的关键场景。
推理实验使用 GPT-5.6 Sol 与 DeepSeek-V4-Pro，对比代码型运行时和智能体型运行时。蒸馏实验以 Qwen3.5-9B 为学生，以 GPT-5.6 Sol 为审查智能体；运行时演化使用 Kimi K3。所有模型开启推理，条件允许时将推理强度设为 high。这样安排使推理阶段的审查收益不能简单归因于“教师比学生强”，因为在无训练对比中，同一模型可同时扮演学生和审查者。
结果一：审查本身不是收益来源，适配后的规范才是
表 1 比较四种设置：最小运行时 h、专家运行时 h*、带空规范的审查智能体，以及带演化规范 K 的审查智能体。平均结果分别为 68.6、78.1、69.2 和 81.1。带空规范时只比最小运行时高 0.6 个百分点，说明多一次模型调用、让审查者泛泛检查响应，并不能自动提高任务成功率。
| 设置 | 平均成功率 | 相对 h 的变化 | 解释 |
|---|---|---|---|
| mini-SWE-agent，运行 h | 68.6 | 基线 | 只有一个 Bash 动作接口 |
| meta-harness，运行 h* | 78.1 | +9.5 | 直接使用专家运行时 |
| 智能体运行时，空 K | 69.2 | +0.6 | 审查存在，但没有专家行为规范 |
| 智能体运行时，演化 K | 81.1 | +12.5 | 私有规范把审查转成定向干预 |
表中数据来自论文 Table 1 的六组基准与模型平均值。智能体运行时在六个单元格上都优于或等于最小运行时；相对 h*，它在平均分上高 3.0 个百分点。较明显的例子是 DeepSeek-V4-Pro 的 AppWorld：h* 为 91.1，而智能体运行时为 89.3，略低；但同一模型在 SpreadsheetBench 从 77.0 提升到 86.0，在 USPTO 从 56.0 提升到 60.0，说明审查智能体不是机械复刻固定运行时的动作。
这种差异来自规范的使用方式。代码型运行时把优化结果固化为环境组件，模型必须以运行时设计者预设的方式行动；智能体型运行时保留目标动作空间，却让审查者根据当前轨迹解释规范，决定何时通过、何时替换。它把“怎样写运行时逻辑”的一部分变成“怎样在响应边界做上下文判断”，因而能针对当前模型和当前实例改变干预位置。
图 2：论文 Table 1，代码型运行时与智能体型运行时的比较。公开副本按站点图片宽度规格缩放。
结果二：蒸馏后移除专家运行时，平均成功率仍超过运行时直挂
表 2 是最能支持论文核心主张的实验。基础 Qwen3.5-9B 在 h 下平均成功率为 23.3；把 h* 直接装上后提高到 41.7；Harness-Zero 蒸馏后只运行 h，平均达到 44.3。相对于基础模型，绝对增益为 21.0 个百分点，相对增益为 90.1%。相对于仍然携带专家运行时的版本，蒸馏结果也高 2.6 个百分点。
| 设置 | SpreadsheetBench | AppWorld | USPTO | 平均值 |
|---|---|---|---|---|
| 基础模型，运行 h | 31.0 | 26.8 | 12.0 | 23.3 |
| 基础模型，运行 h* | 39.0 | 48.2 | 38.0 | 41.7 |
| 基础模型，DeepAgents | 35.0 | 19.6 | 7.0 | 20.5 |
| 基础模型，Claude Code | 31.0 | 10.7 | 6.0 | 15.9 |
| Harness-Zero，运行 h | 44.0 | 58.9 | 30.0 | 44.3 |
分领域看，Harness-Zero 在 SpreadsheetBench 得 44.0，高于 h* 的 39.0；在 AppWorld 得 58.9，明显高于 h* 的 48.2。这两个任务的行为主要体现为查看状态、做局部修改、调用检查、跨应用搬运信息等程序。审查智能体可以在具体上下文中示范这些程序，SFT 又把这些程序写进学生策略，所以移除复杂运行时后仍能保留。
USPTO 的情况相反：基础模型 12.0，h* 38.0，Harness-Zero 30.0。蒸馏带来 18.0 个百分点提升，但仍落后 h* 8.0 个百分点。论文对此的解释是，h* 不只是提供行动顺序，还携带反应先验、候选生成逻辑和 SMILES 可执行验证。程序能被演示，深层领域知识却不容易由少量响应级监督完整内化。这一结果划出了方法的现实边界，比单一平均值更能说明适用条件。
两个通用运行时的结果也值得注意。DeepAgents 平均 20.5，Claude Code 平均 15.9，均低于最小 h。作者指出，9B 模型难以处理更大的通用工具集合和更长上下文；对 AppWorld 与 USPTO 来说，缺少领域约束和专用工具时，工具越多反而越分散。这与“运行时越大越好”的直觉相反，也解释了为什么要蒸馏领域运行时的行为，而不是直接把通用运行时塞给弱模型。
图 3：论文 Table 2，基础模型、专家运行时、通用运行时与蒸馏模型的跨领域结果。
结果三：监督信号必须同时匹配目标动作空间和优化行为
为了区分“更多成功数据”和“运行时指导数据”，论文在 USPTO 上比较六种监督来源。教师 rollout 的采集成功率为 52.0，但蒸馏后测试 pass@1 只有 12.0；教师直接在 h* 下行动时采集成功率 62.0，蒸馏后只有 3.0。学生自己在 h* 下采集的成功率为 39.4，最终仍为 12.0。空私有运行时的审查采集率 44.2，最终为 11.0；只给 oracle 答案时采集率 98.6，最终也只到 15.0。
| 轨迹来源 | 采集成功率 | 蒸馏后测试 pass@1 | 相对基础模型 |
|---|---|---|---|
| 基础模型，未训练 | — | 12.0 | 0.0 |
| 教师 rollout | 52.0 | 12.0 | 0.0 |
| 教师运行 h* | 62.0 | 3.0 | -9.0 |
| 学生运行 h* | 39.4 | 12.0 | 0.0 |
| 空私有运行时审查 | 44.2 | 11.0 | -1.0 |
| 只提供 oracle 答案 | 98.6 | 15.0 | +3.0 |
| Harness-Zero，带 K | 59.4 | 30.0 | +18.0 |
高采集成功率不等于高蒸馏价值。oracle 答案几乎总能完成任务，却没有展示学生如何在 h 中一步步得到答案；教师运行 h* 的轨迹可能包含学生无法执行的专家动作；教师普通 rollout 虽然成功，也未必携带目标运行时可复现的过程。Harness-Zero 的 59.4 并不是最高采集率，但它的响应与 h 的动作空间一致，又由 K 引导到专家行为，因此蒸馏效果最好。
这一消融还反驳了一种简单方案：既然教师更强，只要让教师多跑并做模仿学习即可。教师成功轨迹可能让学生学到结果相关片段，却学不到可执行策略；oracle 更是直接泄漏结果而不提供过程。论文用 30.0 对 3.0 至 15.0 的差距表明，训练信号的结构比采集量更重要。
图 4：论文 Table 3，不同监督来源在 USPTO 上的采集成功率与蒸馏后测试成绩。
行为恢复：不只提高总分，还恢复了基础模型缺失的模式
作者不只比较最终任务成功率，还分析了专家运行时独有、基础模型在 h 下不表现、在 h* 下稳定表现的具体行为。共保留 28 个模式，其中 SpreadsheetBench 18 个、USPTO 6 个、AppWorld 4 个。对每个模式，论文在支持任务上统计 Harness-Zero 恢复该行为的比例，最终平均恢复率为 82.3%。
这些模式让“蒸馏了什么”更具体。模型学到的不只是某个最终答案，而是检查输入输出、避免草率结束、在修改后复核、使用领域验证器等过程。由于模式按运行时独有行为筛选，基础模型在 h 下的恢复起点被设为 0%，基础模型在 h* 下被设为 100%；蒸馏模型在相同目标运行时下达到 82.3%，说明收益具有行为层面的对应关系，而不只是训练集记忆。
论文也公开了限制条件。某些运行时机制无法天然写成一个学生响应，例如上下文压缩或上下文切换可能发生在运行时内部，不是模型消息中的可执行动作。此类机制不能仅靠“把审查替换响应写进 SFT”来传递。Harness-Zero 因此缩窄了运行时需要提供的功能，却没有证明可以把任意运行时完全删除。
讨论：这项工作真正改变的是训练信号的来源
从系统角度看，Harness-Zero 把运行时优化得到的隐式经验转换成模型可学习数据。传统运行时演化常常以代码、提示或工具配置为最终产物，收益被封装在外部系统里；Harness-Zero 让运行时短暂充当训练环境与监督者，最后把行为送回权重。它没有否定运行时工程，而是把运行时工程的一部分产出变成模型能力。
从机器人智能体角度看，这个思路有直接启发。机器人系统同样常把感知滤波、技能库、恢复策略、安全检查和工作流放在模型外。为每个任务手工维护一套专家运行时很难部署到实体机器人，因为接口延迟、工具权限和硬件动作空间都受限。若能把专家运行时诱导出的检查、恢复与操作程序蒸馏进一个固定最小运行时，就有机会减少外部编排复杂度。
但实体系统也放大了论文的两个前提。第一，审查动作必须可执行且可观测。语言环境中的 Bash 检查可以立刻把结果写回上下文；机器人动作可能具有不可逆物理后果，不能像替换文本一样自由重试。第二，运行时的信息优势必须明确。若私有规范依赖真实世界特权状态，替换动作可能看起来合理却无法由学生观测支撑。将方法迁移到机器人时，需要更严格的模拟、权限和观测一致性约束。
从训练方法看，审查替换天然产生了同一状态下的被拒绝响应和更优响应。当前实现只是把替换后的完整响应当作 SFT 正例，没有利用“为什么拒绝”的比较信号。论文建议未来使用偏好学习。这一方向合理：同一上下文的 PASS/REPLACE 对可以构成偏好数据，而不只是成功样本。若再结合选择性审查，可能降低每一步都调用审查器的成本。
论文还把运行时蒸馏与递归自我改进联系起来：更好的模型可以设计更好的运行时，运行时再产生训练信号，把改进沉淀回模型。这个循环有吸引力，但需要防止监督污染。审查器犯错会把错误行为写成高置信训练标签，弱模型审查更强学生时尤其如此。当前代码通过成功阈值、异常过滤和私有标记清理降低风险，但没有解决审查器系统性偏差。
局限分析：能力、成本、知识与运行时可表达性
第一项作者明确指出的局限是审查模型能力。表 1 在较强模型上显示智能体运行时优于代码型运行时，但附录 F 的较弱模型结果发生变化。DeepSeek-V4-Flash 在 h、h*、空 K 和演化 K 下分别为 33.0、58.0、32.3 和 57.0，演化 K 比 h* 低 1.0；Qwen3.6-35B-A3B 分别为 16.0、48.0、12.0 和 36.0，低 12.0。最弱模型替换了 66.0% 的审查步骤，却产生净伤害。审查不是免费的智能，错误干预会把轨迹拉向更差状态。
第二项是轨迹采集成本。当前设计审查每个学生提案，每一步至少需要一次生成和一次审查，审查还要处理轨迹前缀与参考运行时。USPTO 平均每次 trial 从 100.1 秒增至 237.2 秒，约 2.4 倍。论文强调这项开销只在训练数据采集时出现，蒸馏后的部署不再有审查调用。但若任务难度高、轨迹长，采集成本仍可能成为扩展瓶颈。
第三项是深层知识迁移不足。USPTO 蒸馏后 30.0，仍低于运行时直挂的 38.0。程序性行为可以通过响应示范，反应先验、候选空间和领域工具语义却可能超出少量轨迹的覆盖。论文认为需要更多蒸馏轨迹、更广预训练或中期训练。这个判断意味着 Harness-Zero 更适合迁移操作程序、检查习惯和工作流，而不是假定它能从几百条轨迹中教会模型一门完整学科。
第四项是运行时机理的可表达性。若专家运行时的关键优势来自上下文压缩、内部状态管理或自动工具路由，这些行为没有直接对应的学生响应。把它们改写为审查指南只能传递“何时需要压缩”“何时切换”的判断，未必能传递压缩算法本身。部署端仍需保留相应基础能力，Harness-Zero 只能缩小运行时的职责范围。
此外还有实验证据层面的风险。所有结果都是单次运行，表格中的主要比较没有给出置信区间或多种子方差。SpreadsheetBench 和 USPTO 各只有 100 个测试任务，一个任务约等于 1 个百分点；AppWorld 分成 56 个场景。审查轨迹生成又可能引入模型采样波动。因而当前数据足以支持方向性结论，但还不足以精确估计小幅优势。尤其是 Harness-Zero 44.3 与 h* 41.7 的 2.6 点差距，需要重复实验确认稳定性。
方法还有一个结构性假设：审查智能体只读取学生可见事件与 K，不能读取隐藏验证结果。这样可以保证训练输入不泄漏，但审查质量依赖它能否从当前上下文推断执行后果。论文在展望中把它称为反事实预测问题：审查者要想象执行原提案会怎样，再判断替换是否更好。若环境动态复杂，审查者的预测偏差会成为数据质量上限。
结论：从“保留更好的系统”转向“把系统带来的行为写回模型”
Harness-Zero 的核心贡献不是某个更大的工具集合，而是一个跨运行时的监督转换机制。它把优化运行时 h* 适配成私有规范 K，在目标运行时的响应边界审查学生，再将接受后的原响应与替换响应做 SFT。部署时只留下学生与 h，优化运行时的程序性收益仍能以较高比例保留。
实验给出了三条相互约束的证据。第一，空审查只带来 0.6 点平均提升，说明收益来自演化规范而非额外模型调用。第二，带 K 的审查在推理阶段平均达到 81.1，高于代码型 h* 的 78.1。第三，蒸馏后平均 44.3，高于基础模型的 23.3，也高于 h* 直挂的 41.7，但 USPTO 仍低于 h*，揭示程序与知识的迁移难度不同。这三条结果共同界定了方法的强项和边界。
对后续工作而言，最值得验证的方向是降低审查成本、利用拒绝响应的偏好信号，以及把上下文管理等非响应级运行时机制纳入蒸馏。对机器人智能体而言，还需要在具备动作不可逆性、传感器噪声和实时约束的环境中重新检验“审查后执行”范式。若这些问题被解决，运行时优化可能不再只是一次部署配置，而会成为持续向模型积累经验的数据来源。
金句：真正可带走的运行时，不是一个永远挂在模型外面的专家系统，而是专家系统在模型权重里留下的行为。
