论文链接：arXiv:2608.12307 HTML 全文：arxiv.org/html/2608.12307v1 发表时间：2026 年 8 月 12 日 机构：Salesforce AI Research（Cheng Qian, Wenting Zhao, Liangwei Yang, Heng Wang, Jielin Qiu, Heng Ji, Silvio Savarese, Huan Wang, Shelby Heinecke）+ University of Illinois Urbana-Champaign（Heng Ji 组）+ University of Notre Dame。重点关注：这是一篇典型的"高校学者 + 企业研究院合著"论文——Heng Ji 教授（UIUC，知名事件/知识图谱与 ToM 研究学者）与 Salesforce AI Research 的 Shelby Heinecke、Huan Wang、Silvio Savarese 等稳定合作，高校提供 ToM 评测与认知建模视角，Salesforce 提供 harness 工程与 agent 基础设施经验。 领域标签：cs.LG / cs.AI / cs.CL（机器学习、人工智能、计算语言学）
一、论文背景
要理解这篇论文，需要先理解它要回答的根本问题：一个强模型，能不能不靠改弱模型的参数，就把能力"传"给弱模型？ 这个问题把两件事联系在一起——一是"知识蒸馏"这一传统研究方向，二是"harness 工程"这一新兴的工程对象。下面分别拆解。
1.1 什么是知识蒸馏？它解决了什么、又留下了什么遗憾？
知识蒸馏（Knowledge Distillation, KD） 是一种把"大模型的能力搬到小模型里"的经典技术。它的基本思路是：让一个容量很大的"教师模型"（teacher）生成预测分布（称为 soft target / 软标签），再用这些软标签去训练一个更小、更快的"学生模型"（student）。最早的提法可以追溯到 Hinton 等人 2015 年的工作《Distilling the Knowledge in a Neural Network》。
为什么需要蒸馏？因为大模型又慢又贵，小模型又快又便宜但能力弱。蒸馏能让小模型在保持轻量的前提下，逼近大模型的表现——例如 DistilBERT 在保留约 97% BERT 能力的同时，把参数减少了 40%、推理快了 60%；DeepSeek-R1 把自己的推理能力蒸馏进 Qwen / Llama 等开源小模型，让"强推理"能力下沉到可部署尺寸。
但是，所有这些方法有一个共同的前提：必须更新学生模型的参数。 也就是说，能力传递发生在"训练时"（training-time），而非"推理时"（test-time）。这带来三个遗憾：
- 需要训练权限：你必须能够修改学生模型的权重。但很多实际场景里，你只是一个调用闭源 API 的应用方，根本没有训练权限。
- 训练成本高：数据准备、GPU、对齐、评测，一整套训练流程下来非常昂贵。
- 能力迁移是"隐式"的：蒸馏后的小模型到底学到了什么？它的行为是否可解释、可审计？训练时方法很难给出清晰的答案。
这些遗憾直接催生了一个根本问题：如果不改参数，能力还能传过去吗？ 本论文回答：“能，通过 harness。”
1.2 什么是 Harness？为什么它成了一个新的工程对象？
Harness（字面意思是"马具 / 挽具"，引申为"系统骨架 / 脚手架"）指的是包裹在语言模型外围、把模型从"一个会生成文本的东西"变成"一个能在环境中行动的 agent"的整个编排层。它管的事情包括：准备上下文、路由工具、处理重试、管理记忆、校验输出格式、跑循环、做错误恢复。
一个通俗的类比：模型本身只是"一只会写字的手"，harness 才是让这只手能在真实世界里干活的"工作台 + 流程手册 + 工具架"。 同一只手，放在乱糟糟的桌子上可能写不出一份完整报告；放在有收件箱、模板、检查清单、复核员的工作台上，就能稳定产出。
2026 年 6 月 Martin Fowler 的文章《Harness Engineering for Coding Agent Users》、以及同期的《Agent Harness Engineering: A Survey》都把 harness 明确提升为一个独立的工程对象——它与 prompt engineering、context engineering 构成递进的三个层次：prompt 关注"怎么问"、context 关注"给什么背景"、harness 关注"整个执行生命周期的编排"。
Harness 的核心问题在于：它通常是手写的，依赖经验，难以系统化优化。 这就引出了论文的关键洞察——既然 harness 这么重要，能不能让一个强模型自己去构建并迭代优化一个 harness，让弱模型在推理时受益？
1.3 为什么选 Theory-of-Mind（心智理论）作为测试床？
心智理论（Theory-of-Mind, ToM） 是指推断他人心理状态（信念、意图、目标、知识）的认知能力。它在 LLM 评测中尤其"硬"，因为它要求模型做到：
- 嵌套信念跟踪：“A 认为 B 以为 C 知道 X”——递归地维护多层心智状态。
- 视角转换：区分"世界真实状态"与"某个 agent 看到的状态"。
- 隐藏信息处理：处理欺骗、未观察到的变化、信息不对称。
- 贝叶斯目标推断：从行为轨迹反推 agent 的目标与信念。
选择 ToM 的关键理由是：它对"推理可靠性"极其敏感。 一次视角混淆、一次极性反转（把"相信"算成"不相信"），整道题就错。这种任务结构恰恰是检验"把不稳定推理卸载为确定性代码"这一假设的最佳压力测试——如果 harness 能在 ToM 上把弱模型大幅拉起来，说明它确实是在补"可靠性"的短板，而不是在堆"更多推理"。
综上，论文的研究背景可以概括为：训练时蒸馏留了"不能不改参数"的遗憾；harness 工程提供了"在外围补能力"的新可能；ToM 任务恰好是检验"可靠性补强"假设的理想压力测试。 三者交汇，就构成了本论文要回答的核心问题。
二、论文定位和关联工作
本论文不是孤立的工作。它同时受到四条研究脉络的滋养，又在它们的交叉点上开辟了新视角。
2.1 脉络一：训练时强到弱能力传递（蒸馏路线）
| 工作 | 核心思想 | 与本论文的关键区别 |
|---|---|---|
| Hinton 等《Distilling the Knowledge》(2015) | 用教师 soft target 训练学生 | 改参数；本论文不改参数 |
| DistilBERT / DeepSeek-R1 蒸馏 | 实践中的大规模蒸馏 | 训练时；本论文是推理时 |
| 弱到强泛化（Burns 等） | 弱监督能否激发强模型 | 方向相反（弱→强），且仍在训练框架内 |
本论文的突破：把"能力传递"从"训练时改参数"挪到"推理时改 harness"，开辟了第二条互补路线。
2.2 脉络二：推理时推理、提示与分解
| 工作 | 核心思想 | 与本论文的关键区别 |
|---|---|---|
| Chain-of-Thought (CoT) | 让模型逐步推理 | 固定模板；本论文让强模型自动设计推理结构 |
| Self-Consistency | 多次采样投票 | 只在"如何采样"上做文章；本论文在"整个 harness"上做文章 |
| Least-to-Most / Decomposition | 把难题拆成子问题 | 人工设计分解策略；本论文让 builder 自动发现分解 |
| Self-Refine / Tree-of-Thoughts | 模型自我反馈或搜索 | 仍是"让模型自己想得更多"；本论文是"让另一个强模型为它搭好脚手架" |
本论文的突破：把"推理时增强"的对象从"提示词 / 采样策略"升级为"完整的可执行 harness 程序"。
2.3 脉络三：工具使用、程序化推理与确定性卸载
| 工作 | 核心思想 | 与本论文的关键区别 |
|---|---|---|
| Toolformer / ReAct | 模型决定何时调工具 | 仍以模型为主；本论文把确定性求解器作为一等公民 |
| PAL / Program-of-Thoughts | 把问题翻译成可执行代码 | 单一模板；本论文让 builder 自动选择何时、如何卸载 |
| Faithful CoT（Lygin 等, 2023） | NL→符号链，确定性 solver 执行 | 手工设计的两阶段框架；本论文把这种思路自动化、任务自适应化 |
| Logic-LM | LLM 把逻辑题形式化，符号 solver 解 | 针对逻辑题；本论文针对 ToM，且 builder 自动决定是否卸载 |
这一脉络是本论文最重要的灵感来源：Faithful CoT 已经证明"把推理卸载到确定性 solver"既能提升准确性又能保证忠实性。本论文把这个原则交给一个强 builder 模型去自动发现和实施——builder 自己决定哪些子任务值得卸载、用什么数据结构、怎么路由。
2.4 脉络四：Harness 工程与自动脚手架构建
| 工作 | 核心思想 | 与本论文的关键区别 |
|---|---|---|
| DSPy（Khattab 等, Stanford） | 把 LM pipeline 声明式化，编译器自动优化 prompt / few-shot | 优化的是模块内的 prompt；本论文优化的是整个可执行 harness 程序 |
| SWE-agent | agent-computer 界面影响编码 agent 性能 | 关注界面设计；本论文关注跨模型的能力传递 |
| ADAS（Automated Design of Agentic Systems） | 元 agent 发现代码定义的 agent 工件 | 发现 agent 架构；本论文聚焦"强→弱"这一特殊设定 |
| UserHarness（Wilf 等, 2026） | 显式重构用户信念/意图/观察/行动来解 ToM | 人工设计的 ToM 专用 harness；本论文让 builder 自动构建，且 UserHarness 是论文的重要 baseline |
本论文的突破：第一次把"自动 harness 构建"明确放进"强到弱能力传递"的设定里——builder 不只是优化 prompt，而是把任务结构编译成可执行的推理时程序，让弱 target 模型在其中运行。
2.5 本论文在研究脉络中的定位
| 维度 | 之前的路线 | 本论文的突破 |
|---|---|---|
| 能力传递时机 | 训练时（改参数） | 推理时（改 harness） |
| 增强对象 | prompt / 采样策略 / 模块 | 完整可执行 harness 程序 |
| 构建方式 | 人工设计（如 UserHarness） | 强 builder 自动构建并迭代 |
| 验证机制 | 依赖完整测试集 | 仅用 5% 验证集，且与全集高度相关（r=0.96） |
| 核心机制假设 | “让模型想得更多” | “把不稳定推理卸载为确定性代码” |
一句话定位：本论文是"训练时蒸馏"与"harness 工程"两条路线的交汇点——它用 harness 工程的方法，回答了蒸馏路线的核心问题（强→弱能力传递），但绕开了蒸馏的最大约束（必须改参数）。
三、问题定义
3.1 从具体场景到抽象问题
具体场景：我们有一个弱的 target 模型 $M_{\text{tar}}$（比如 GPT-5.4-mini），它在 Theory-of-Mind 任务上只有 0.488 的准确率。我们希望它变强，但又不能改它的参数（比如它是个闭源 API）。怎么办？
论文的核心洞察：弱模型答错，不一定是因为它"能力不够"，也可能是因为任务呈现方式给它施加了"过度认知负荷"。一个强模型如果能把这个任务的结构看清楚，并把它"翻译"成一种对弱模型更友好的呈现方式（路由、模板、确定性 solver、格式强制），弱模型就能答对很多原本答错的题。
这就引出了一个深层的类比：
| 深度学习训练 | 强到弱脚手架构建 |
|---|---|
| 训练数据 | 验证集（5% 数据） |
| 模型参数 | harness 程序 $S$ |
| 损失函数 | target 模型在验证集上的错误率 |
| 梯度下降 | builder 模型基于错误诊断修订 harness |
| 训练后的模型 | 最终提交的 harness $\hat{S}$ |
| 测试集准确率 | 隐藏测试集上 target 模型的准确率 |
精妙之处：这个类比揭示了——“训练模型"和"为模型搭脚手架"在结构上是同构的。前者优化的是模型内部的参数，后者优化的是模型外部的程序。两者都在"用有限的反馈信号，改进一个可调对象，使其在隐藏测试集上表现更好”。
3.2 形式化的问题定义
给定：
- 目标模型 $M_{\text{tar}}$（参数固定，不可训练）
- 构建模型 $M_{\text{build}}$（参数固定，但可调用、可控制推理预算）
- 第 $j$ 个基准的数据集 $\mathcal{D}^{(j)}$，划分为可见验证集 $\mathcal{V}^{(j)}$（5%）和隐藏测试集 $\mathcal{T}^{(j)}$（95%）
- 初始工作空间 $\mathcal{W}_0 = \{\mathcal{R}, \mathcal{C}_{\text{demo}}, \mathcal{V}\}$（规则文件、demo、验证集）
求：一个 harness $S$（一段可执行程序，可包含提示模板、路由逻辑、确定性 solver、格式强制、少样本示例等任意组件），使得：
$$S^{\star} = \arg\max_{S \in \mathcal{S}} \text{Acc}(S, M_{\text{tar}}; \mathcal{T})$$约束：
- 信息约束：builder 只能看到验证集 $\mathcal{V}$，看不到测试集 $\mathcal{T}$。这防止了"记忆答案"作弊。
- 能力约束：$M_{\text{tar}}$ 的参数完全不动，只接受 harness 的输入、产出 harness 想要的输出。
- 泛化约束：成功的 harness 必须捕捉可重用的任务结构，而非记忆特定答案——否则在验证集上的提升不会迁移到测试集。
实际代理目标（因为测试集对 builder 不可见）：
$$\hat{S} = \arg\max_{S \in \mathcal{S}_{\text{build}}} \text{Acc}(S, M_{\text{tar}}; \mathcal{V})$$3.3 这个抽象为什么合理？
这个定义最聪明的地方在于：它把"能力传递"这个模糊的概念，变成了一个清晰的优化问题，且优化对象（harness 程序）是可以审计、可以迁移、可以复用的。
- 训练时蒸馏传递的是"隐式的、编码在参数里的能力"——你拿不走、看不见。
- 推理时脚手架传递的是"显式的、编码在代码里的任务结构"——你可以读它、改它、给别的弱模型用、甚至给同一个模型在别的任务上用。
论文的一句关键论断值得记住：“有能力的 builder 模型可以作为任务能力编译器（task-capability compiler）。它花费一次推理预算识别任务中的结构，并将该结构编码到推理时 harness 中。” 这个"编译器"的隐喻，是整篇论文最深刻的抽象。
四、问题解法
4.1 算法总览：递归脚手架构建
整个方法（论文算法 1）是一个"构建—评估—诊断—修订"的循环，结构上非常像深度学习的训练循环，但优化的不是参数而是 harness 程序。
| 步骤 | 深度学习训练循环 | 强到弱脚手架构建循环 |
|---|---|---|
| 初始化 | 随机初始化参数 $\theta_0$ | 空 harness $S_0 = \emptyset$，工作空间 $\mathcal{W}_0$ |
| 前向 | 模型在 batch 上前向 | target 模型在验证集上跑当前 harness |
| 评估 | 计算 loss | 计算验证集准确率 + 错误集 $\mathcal{E}_k$ |
| 反向 | 反向传播梯度 | builder 阅读 $S_k$、错误集 $\mathcal{E}_k$、规则文件 |
| 更新 | $\theta_{k+1} = \theta_k - \eta \nabla L$ | $S_{k+1} = M_{\text{build}}(\mathcal{W}_{k+1})$（builder 重写 harness） |
| 终止 | loss 收敛 / 达到 epoch | builder 提交最终 harness（导出入口点） |
| 测试 | 在隐藏测试集上评估 | 在隐藏测试集 $\mathcal{T}$ 上运行 $f_{\hat{S}}(\mathcal{T}; M_{\text{tar}})$ |
关键设计决策：
- builder 不直接调 target 模型猜答案，而是写一段程序。这段程序可以调用 target 模型、也可以不调（直接用确定性 solver 算出来）。
- 验证集评估由一个"人工评估器"执行（即一个固定的、builder 无法干预的脚本），保证 builder 看到的反馈是真实的。
- 每次修订，builder 都能看到上一次的错误（哪些题错了、错在哪），这相当于"梯度信号"。
4.2 工作空间与信息流
builder 在每轮迭代中能看到的工作空间 $\mathcal{W}_k$ 包含：
- 规则文件 $\mathcal{R}$：描述任务格式、输入输出契约的说明文档。
- demo $\mathcal{C}_{\text{demo}}$：少量示例。
- 验证集 $\mathcal{V}$：195 项（5%），固定随机种子采样。
- 历史错误集 $\mathcal{E}_k$：前几轮 harness 在验证集上答错的题目。
- 当前 harness $S_k$：builder 自己上一轮写的代码。
builder 产出的是一个新的 harness $S_{k+1}$，它是一段 Python 代码，内部可以调用 target 模型、可以路由、可以用确定性 solver。
4.3 Harness 的自由度：builder 能写什么？
论文故意不给 builder 固定的模板，让它自由发挥。从 57 次运行的代码分析中，builder 实际使用的技术包括（按流行度排序）：
| 技术类别 | 具体做法 | 出现频率 |
|---|---|---|
| 格式强制 | 严格解析 target 输出，强制答案格式 | 57/57 (100%) |
| 贪婪/温度控制 | 用 temperature=0、top-p=1 保证可复现 | 56/57 (98%) |
| 基准路由 | 检测输入属于哪个 ToM 子集，走不同分支 | 54/57 (95%) |
| 强制 CoT | 在 prompt 里要求逐步推理 | 45/57 (79%) |
| 极性/否定逻辑 | 用代码处理"不"“没"等否定，避免模型搞反 | 45/57 (79%) |
| Token 预算调整 | 调整 max_tokens 等 | 43/57 (75%) |
| 混合回退 | 先试确定性 solver，失败再问模型 | 34/57 (60%) |
| 确定性求解器 | 直接用代码（不调模型）算出答案 | 31/57 (54%) |
| 结构化提取 | 从故事里提取结构化信念状态 | 29/57 (51%) |
| 少样本示例 | 在 prompt 里放几个例子 | 12/57 (21%) |
| 验证/仲裁 | 多个分支投票或校验 | 7/57 (12%) |
| 自一致性投票 | 多次采样投票 | 3/57 (5%) |
这张表是理解论文机制的关键。注意一个反直觉的现象：最流行的不一定是增益最大的。格式强制、贪婪解码人人都在用（因为它们便宜且必要），但它们只是"可靠性基线”；真正区分强 harness 和弱 harness 的，是极性逻辑、结构化提取、确定性求解器这些"任务结构利用"技术。
4.4 两个层次的 harness 设计
论文在分析中把有效 harness 的设计原则归纳为两个层次：
第一层：可靠性基线（reliability baseline）
这一层防止"可避免的错误"——答案明明算对了，却因为格式不对、采样抖动、路由错误而丢分。几乎所有 harness 都会做，且必须做。类比深度学习里的"数据预处理 + 归一化"——不做一定亏，做了不会让你赢。
第二层：任务结构利用（task-structure exploitation）
这一层把任务里可被确定性代码处理的部分识别出来，直接用代码算，绕开模型的不稳定推理。这是区分顶级 harness 的关键。类比深度学习里"选择正确的归纳偏置（inductive bias）"——它决定了你的上限。
两层的分工：第一层保证你不会因为低级错误丢分；第二层保证你能在模型本身能力不足的地方"作弊"（用代码补上）。论文的证据（见第六部分）表明，第二层才是增益的主要来源。
4.5 全景流程图（文字描述）
┌─────────────────────────────────────────────────────────────┐
│ 阶段一：递归脚手架构建（builder 只看 5% 验证集） │
│ │
│ 规则文件 + demo + 验证集 ──► builder 模型 │
│ │ │
│ ▼ │
│ 草拟 harness S_k │
│ │ │
│ ▼ │
│ 人工评估器在验证集上跑 S_k │
│ │ │
│ ▼ │
│ 错误集 E_k + 当前 S_k │
│ │ │
│ ▼ │
│ builder 诊断错误，修订 harness │
│ │ │
│ ▼ │
│ 新 harness S_{k+1} │
│ │ │
│ （循环直到 builder 提交） │
│ │ │
│ ▼ │
│ 最终 harness \hat{S} │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段二：隐藏测试评估（在 95% 测试集上） │
│ │
│ 固定的 target 模型 + \hat{S} ──► 最终准确率 │
└─────────────────────────────────────────────────────────────┘
五、评估指标与实验证据
5.1 评估指标体系
主指标：四个 ToM 基准准确率的未加权宏平均。选宏平均（而非微平均）是为了不让数据量大的基准（BigToM、Hi-ToM）淹没数据量小的基准（MMToM-QA）。
辅助指标（用于多角度验证）：
- 验证-全集差距（Val-Full Gap）：验证集准确率减去全集准确率，衡量验证集的代表性。越小越好。
- 运行间标准差（run-to-run sd）：同一设置重复 3 次的标准差，衡量可复现性。
- 确定性分数（Determinism Fraction）：完全由代码或结构规则回答的 item 比例，衡量"认知卸载"程度。
- 修复/破坏比（Fixed/Broke）：harness 修复了多少个基线错误的 item，又破坏了多少个基线正确的 item。
消融指标：
- 构建模型身份（8+ 个模型）× 平台（3 个）× 推理努力（4 档）× 目标模型（2 个）= 72 次运行的全因子实验。
- 每种技术的"使用 vs 不使用"对比，用于归因。
5.2 数据集与基准
| 数据集 | 规模 | 任务特点 | 为什么选它 |
|---|---|---|---|
| BigToM | 1200 | 二元信念/目标/行动，基于 agent 是否观察到变化 | 经典 ToM，结构清晰，可卸载性高 |
| Hi-ToM | 1200 | 0-4 阶递归嵌套信念，含欺骗 | 检验嵌套推理，随深度退化明显 |
| MMToM-QA | 600 | 从行动轨迹做贝叶斯目标/信念推断 | 检验贝叶斯推断，最难卸载 |
| MuMA-ToM | 900 | 多 agent 信念/社会目标，3 选 1 | 检验多 agent 场景，社会推理 |
总计 3900 项测试 + 195 项验证。这四个基准合在一起，恰好覆盖了 ToM 从"可结构化"（BigToM）到"难结构化"（MuMA-ToM）的整个谱系——这让论文能回答"哪些任务适合 harness 补强，哪些不适合"。
5.3 核心实验结果
结果一：主要结果（RQ1 — harness 有效吗？）
固定 target = GPT-5.4-mini（基线 0.488），聚合各 builder：
| 配置 | 宏平均准确率 | 增益 Δ |
|---|---|---|
| Vanilla 基线（无 harness） | 0.488 | — |
| 所有 57 次运行均值 | 0.763 | +0.275 |
| 最佳单次（GPT-5.5 on GPT Codex） | 0.912 | +0.423 |
| Human-Inspired Harness（UserHarness） | 0.939 | +0.451 |
关键判断：
- 100% 的运行超过基线——不是"有时候有效"，而是"总是有效"。
- 平均增益 +0.275 接近基线的 56%，最佳运行 +0.423 相当于 86.7% 的相对提升。
- 自动构建的 harness（0.912）已经逼近人工设计的 UserHarness（0.939），说明 builder 模型确实能"编译"出接近人类专家水平的任务结构。
这个实验为什么有证明力？ 因为它同时满足了三个条件：（1）100% 胜率排除了"运气好"的可能；（2）跨 11 个 builder、3 个平台的稳定性排除了"某个模型特别适配"的可能；（3）与人工设计 harness 的对比给出了"理论上限"的参照。
结果二：验证集的代表性（RQ2 — 5% 验证集够吗？）
- 最佳验证分数与最终全集准确率的 Pearson r = 0.96（几乎一一对应）。
- 验证-全集差距均值仅 0.021（轻微乐观，但不严重）。
- 验证迭代次数与最终准确率 r = 0.17（几乎无关）。
这个实验为什么有证明力？ 它证明了"信息约束"没有伤害效果——builder 用 5% 数据选出的 harness，在 95% 隐藏数据上表现一致。这说明 harness 捕捉的是可泛化的任务结构，而非记忆答案。同时，“迭代次数无关"这一反直觉发现表明：瓶颈不是反馈量，而是 builder 假设的质量。
结果三：确定性卸载是核心机制（RQ3 — 为什么有效？）
- 确定性分数与准确率的 Pearson r = 0.72（强相关）。
- 各基准的可卸载性：BigToM ≈ 0.94，Hi-ToM ≈ 0.51，MMToM-QA ≈ 0.44，MuMA-ToM ≈ 0.36。
- 脚手架代码大小与准确率仅 r ≈ 0.22（弱相关）——不是"代码越多越好”。
这个实验为什么有证明力？ 它直接把"机制假设"和"指标提升"挂钩：越是能把任务卸载为确定性代码的基准（BigToM），harness 增益越大；越难卸载的基准（MuMA-ToM），增益越小。 这种跨基准的相关性，比单一数字更有说服力——它排除了"harness 只是在堆代码量"的替代解释。
结果四：builder 推理努力是单调杠杆（RQ4 — 什么因素主导效果？）
固定 builder = Opus-4.7，扫描推理努力（low→med→high→x-high）：
| 努力档位 | 池化准确率 |
|---|---|
| low | 0.711 |
| medium | 0.793 |
| high | 0.807 |
| extra-high | 0.856 |
Spearman ρ = 0.77，且 x-high 显著优于 high（p=0.013）和 low（p=0.002）。
反直觉的对比：
- 平台效应（Cursor vs Claude Code vs GPT Codex）：配对置换检验 p=0.484，不显著。从 Cursor 换到 native 平台，准确率仅变化 +0.013。
- builder 推理努力：Spearman ρ=0.77，强单调。
这个实验为什么有证明力？ 它回答了一个关键的实践问题——“我应该花预算在哪个环节？“答案是：花在 builder 的推理上，而不是花在换平台上。平台是二阶因素，builder 的"想清楚"才是一阶因素。
结果五：目标模型的"空间法则”（RQ5 — 增益取决于什么？）
跨两个 target 模型（GPT-5.4-mini 基线 0.488 vs Gemini-3.5-flash 基线 0.761）：
- 实现增益与目标在该基准上的可用空间（1 - 基线）强相关：Pearson r = 0.75。
- 对 Gemini-3.5-flash（基线已高），9/20 案例出现回归（harness 反而拉低了表现）。
这个实验为什么有证明力？ 它揭示了一个重要的边界条件：harness 是"能力恢复机制”，不是"能力增强机制"。当目标模型已经接近天花板时，harness 从"协助"变成"干扰"。这个发现对实践至关重要——它告诉你"harness 该用在哪"。
结果六：修复 vs 破坏（RQ6 — 改进是真实的还是重新分布？）
最佳 harness（GPT-5.5/GPT Codex on GPT-5.4-mini）的 item 级统计：
- 修复 1717 个基线错误
- 破坏 105 个基线正确
- 修复:破坏 = 16:1
- χ² = 1424.4，p < 10⁻⁴
这个实验为什么有证明力？ 它排除了"harness 只是把错误重新分布"的可能。如果是重新分布，修复数 ≈ 破坏数。16:1 的比例证明 harness 是广泛纠正性的——它真的让 target 模型变好了，而不是让它在一些题上变好、另一些题上变差。
5.4 指标到主张的映射
| 论文主张 | 支撑该主张的关键实验 + 指标 |
|---|---|
| 推理时能力传递有效 | 100% 运行超基线；均值 +0.275；最佳 +0.423 |
| 5% 验证集足够 | Val-Full r=0.96；gap=0.021 |
| 核心机制是确定性卸载 | 确定性分数 vs 准确率 r=0.72；跨基准可卸载性递减 |
| builder 能力主导平台 | 推理努力 ρ=0.77；平台 p=0.484 |
| 增益取决于目标空间 | 空间-增益 r=0.75；强目标出现回归 |
| 改进是真实的非重分布 | 修复:破坏 = 16:1；χ²≫10⁴ |
六、效果优势的根源解释
本节回答最关键的问题：为什么这种方法比 baseline（无 harness 的 target 模型）好这么多？ 答案不是"因为加了 harness"（表面解释），而是要从机制层面追溯因果链。
6.1 Baseline 的根本局限：不稳定的自然语言推理
无 harness 的 target 模型为什么会错？论文的错误分析指向三个根源：
- 格式不稳定：模型算对了，但输出格式不对，解析失败。
- 推理路径不稳定：同样的题，temperature>0 时有时对有时错；CoT 推理链里某一步极性反转（把"相信"算成"不相信"），整道题错。
- 视角混淆：在嵌套信念题里，模型分不清"A 的视角"和"世界的真实状态"，把"世界里发生了 X"当成"A 知道 X"。
这三个根源的共同本质：模型在用概率性的自然语言生成去完成确定性的符号推理任务。这是根本性的不匹配——自然语言生成是"采样"，符号推理需要的是"计算"，两者天然冲突。这就是 baseline 的不可逾越的障碍：只要答案由模型的自然语言生成决定，就必然有不可消除的抖动和错误。
6.2 本文方法的根本性改变：把推理从"生成"变成"计算"
harness 做的最关键的事，是把尽可能多的推理步骤从"模型生成"挪到"代码计算"。具体机制：
机制 A：确定性卸载（deterministic offloading）
对于可以结构化的子任务（比如 BigToM 的"agent 是否观察到了变化"），harness 直接用 Python 代码维护一个状态机，不调模型。模型只负责"从故事里提取事实"（结构化提取），而"根据事实推断信念"这一步由代码的逻辑规则完成。
- 信息流变化：原来"故事 → 模型 → 答案"（全程概率性），变成"故事 → 模型提取事实 → 代码算答案"（前半概率性，后半确定性）。
- 瓶颈缓解：消除了"推理路径不稳定"这一根源。
- 指标体现：确定性分数与准确率 r=0.72；BigToM（可卸载性 0.94）几乎被 solve 到天花板。
机制 B：结构化信念状态（structured belief-state extraction）
对于不能完全卸载的任务（Hi-ToM 的嵌套信念），harness 强制模型先输出一个结构化的信念状态（比如 JSON 格式的"A 相信 X，B 相信 Y"），再用代码做嵌套推理。
- 信息流变化：把"模型一次性给出最终答案"拆成"模型给出中间状态 + 代码组合中间状态"。
- 瓶颈缓解：消除了"视角混淆"——因为每一步都显式标注"这是谁的视角"。
- 指标体现：极性逻辑（+0.090）和结构化提取（+0.055）是增益最大的两项任务结构利用技术。
机制 C：可靠性基线（reliability baseline）
格式强制、贪婪解码、路由——这些不是增益的主要来源，但它们防止了"算对了却丢分"的低级错误。
- 信息流变化：消除了输出阶段的随机性。
- 指标体现：几乎所有 harness 都用，但单独贡献小。
6.3 完整的因果链
把上述机制串起来，就是论文增益的完整因果链：
baseline 的根本不匹配：
概率性的自然语言生成 ⟷ 需要确定性的符号推理
│
▼ 导致
三类错误：格式不稳定 / 推理抖动 / 视角混淆
│
▼ 被 harness 的三层机制处理
机制 C（可靠性基线）：消除格式抖动 → 防止低级丢分
机制 B（结构化状态）：显式标注视角 → 消除视角混淆
机制 A（确定性卸载）：把推理从生成变成计算 → 消除推理抖动（核心）
│
▼ 体现在指标上
100% 运行超基线（机制 C 兜底）
确定性分数 r=0.72（机制 A 主导）
修复:破坏 = 16:1（三层机制合力）
BigToM 接近天花板，MuMA-ToM 仍有缺口（机制 A 的边界）
6.4 反事实推理：去掉关键设计会怎样？
论文没有直接做"去掉确定性 solver"的消融，但有几个间接证据：
- 确定性求解器使用 vs 不使用：使用组 0.775 vs 不使用组 0.750，差 +0.026。看起来不大？但注意，这个对比是"跨所有 harness"的，很多 harness 即使不用确定性 solver 也用了其他任务结构技术。真正的影响要看最强 harness 几乎都用确定性 solver这一事实——表 4 里准确率 >0.85 的配置，确定性分数几乎都 >0.75。
- BigToM vs MuMA-ToM 的对比：BigToM 可卸载性 0.94，harness 把它 solve 到 0.99+；MuMA-ToM 可卸载性 0.36，harness 只能到 0.71。这是同一次实验、同一个 builder、同一套方法，唯一的区别就是"任务能不能卸载"——而效果差距巨大。这是对"机制 A 是核心"的最强反事实验证。
6.5 为什么 UserHarness（0.939）比最佳自动 harness（0.912）还高？
UserHarness 是 Wilf 等人 2026 年提出的人工设计的 ToM 专用 harness，它显式地重构用户的"感知-信念-意图-行动"循环。它比最佳自动 harness 高 0.027。这个差距的根源解释是：
- UserHarness 是针对 ToM 专门设计的，它的"感知-信念-意图-行动"分解恰好命中了 ToM 的任务结构。
- 自动 harness 是 builder 在有限验证集上发现的，它可能没发现 UserHarness 那么精巧的分解。
但要注意：UserHarness 是人工设计、ToM 专用的，无法迁移到其他任务；而自动 harness 的方法是任务无关的——给 builder 任何任务的验证集，它都能尝试构建 harness。这是"专用最优"和"通用次优"的经典权衡。论文的定位是后者。
6.6 无法从根源解释的部分
论文诚实指出，验证迭代次数与最终准确率几乎无关（r=0.17）。这意味着"builder 在验证集上多试几次"并不能稳定提升效果——真正的瓶颈是 builder 单次推理的质量（假设形成能力），而不是反馈量。这一点目前只有现象层面的观察，论文没有给出更深层的解释，这可能是未来工作的方向。
七、必要知识反推
假设找一个完全没有知识和信息的人去做这个工作，他必须掌握哪些知识？以及这些知识如何在关键节点上融合？
7.1 领域知识层
知识 1：知识蒸馏的训练时范式及其局限
- 为什么必须：如果不知道"蒸馏必须改参数"这一约束，就无法意识到"推理时传递"是一个新的、有价值的问题。论文的核心动机正是建立在对训练时蒸馏局限的清醒认识上。
- 掌握深度：不仅要知道 KD 是什么，还要知道它的变体（teacher forcing、on-policy、逐步蒸馏）以及它们共同的"必须改参数"前提。
知识 2：Theory-of-Mind 任务的认知结构与失败模式
- 为什么必须：如果选错测试床，结论没有说服力。选 ToM 是因为它的失败模式（视角混淆、极性反转、嵌套丢失）恰好能被"确定性卸载"解决——这构成了一种"任务-方法"的结构性匹配。
- 掌握深度：要知道 ToM 的四个子能力（信念跟踪、视角转换、隐藏信息、贝叶斯推断），以及它们各自的可结构化程度。
知识 3：Harness 作为独立工程对象的存在
- 为什么必须：如果还停留在"prompt engineering"的认知里，就想不到"优化一段可执行程序"这个层次。
- 掌握深度：要理解 prompt / context / harness 的三层递进，以及 harness 为什么是"可优化"的（因为它有明确的输入输出契约，可以被评估）。
7.2 方法论知识层
知识 4：Faithful CoT 及其"翻译-求解"两阶段范式
- 为什么必须：这是论文最重要的灵感来源。Faithful CoT 已经证明"NL→符号链→确定性 solver"能同时提升准确性和忠实性。论文的 builder 本质上是在自动发现每个任务的 Faithful CoT 分解。
- 掌握深度：要知道为什么"把推理卸载到 solver"比"让模型自己推理"更可靠——因为前者是计算，后者是采样。
知识 5：DSPy 的声明式优化思想
- 为什么必须：DSPy 教会了社区"prompt 不是手写的，是编译出来的"。论文把这种思想从"优化 prompt"升级到"优化 harness 程序"。
- 掌握深度：要理解"声明式定义 + 自动优化"的范式，以及它为什么比"手工调参"更可扩展。
知识 6：弱到强泛化（Weak-to-Strong Generalization）的反向问题
- 为什么必须：Burns 等人的工作问"弱监督能否激发强模型"，论文问的是反向问题"强模型能否帮助弱模型"。这种"反向提问"本身就是一种方法论素养。
- 掌握深度：要知道"弱到强"和"强到弱"不是对称的——前者是训练时问题，后者可以是推理时问题。
7.3 工程知识层
知识 7：大规模受控实验设计（全因子 + 配对检验）
- 为什么必须：论文的 72 次运行、配对置换检验、Spearman 相关、χ² 检验，是结论可信的基础。如果只会跑一两个配置就下结论，会被方差误导。
- 掌握深度：要知道"平台效应 p=0.484 不显著"和"推理努力 ρ=0.77 显著"这种判断的标准。
知识 8：验证集设计与小样本代表性
- 为什么必须：5% 验证集是否够用，决定了整个方法的实用性。作者必须知道如何评估"验证集代表性"（Val-Full gap、Pearson r），否则无法回答"这是不是过拟合"。
7.4 知识融合的关键节点
融合节点 1：把"能力传递"重新定义为"任务结构编译"
- 融合的知识：知识 1（蒸馏局限）+ 知识 3（harness 是可优化对象）+ 知识 5（DSPy 的编译思想）。
- 化学反应：三者融合产生了论文的核心隐喻——“builder 是任务能力编译器”。这个隐喻把"能力传递"从"参数空间"挪到了"程序空间"，是整篇论文的智力核心。
融合节点 2：用 ToM 作为"确定性卸载"假设的压力测试
- 融合的知识：知识 2（ToM 的失败模式）+ 知识 4（Faithful CoT 的卸载思想）。
- 化学反应：ToM 的失败模式（视角混淆、极性反转）恰好是"自然语言推理不稳定"的典型表现，而 Faithful CoT 的解法（卸载到确定性 solver）恰好能对症下药。这种"问题-方法的结构性匹配"不是巧合，而是作者对两者都有深刻理解的产物。
融合节点 3：用受控实验区分"机制"和"工程"
- 融合的知识：知识 7（实验设计）+ 知识 4（卸载机制）。
- 化学反应：作者设计了"确定性分数 vs 准确率"这个指标（r=0.72），把"为什么有效"从口号变成了可验证的相关性。这种"给机制假设配一个量化指标"的做法，是优秀实证研究的标志。
八、论文中可以提取的通用性灵感
本节提取论文中可推广到其他领域的普适性原理。每条都有论文的具体证据支撑。
灵感一：把不稳定的"生成"重新分配为稳定的"计算"
核心思想：当一个系统（模型 / 人 / 流程）在某个环节表现不稳定时，不要试图"让它更稳定"，而是把这个环节从系统里拿出来，交给一个确定性的执行体。系统的整体可靠性由最不可靠的环节决定，与其改进不可靠环节，不如绕过它。
论文证据：确定性分数与准确率 r=0.72；BigToM（可卸载性 0.94）被 solve 到 0.99+，而 MuMA-ToM（可卸载性 0.36）只能到 0.71——效果严格取决于"多少推理能被挪到代码里"。
推广场景：
- 数据 pipeline：把"用 LLM 判断字段类型"这种不稳定步骤，替换为"用正则 + schema 校验"的确定性步骤。
- 客服系统：把"用 LLM 决定工单优先级"（不稳定）改为"用规则引擎决定优先级 + LLM 只做情感分析"（稳定）。
- 代码 review：把"用 LLM 找 bug"（漏报多）改为"用静态分析工具找 bug + LLM 只解释 bug"（漏报少）。
- 个人决策：把"凭直觉判断"的环节（如投资决策）替换为"用 checklist + 量化规则"的确定性流程。
灵感二：用"强者为弱者搭脚手架"代替"直接训练弱者"
核心思想：当你想让一个弱系统（小模型 / 新员工 / 初学者）完成它目前做不到的任务时，有两种路径——（A）训练它（改参数 / 培训）；（B）给它搭一个外部脚手架（harness / 工具 / 流程）。路径 B 的优势是：可审计、可迁移、不侵犯弱系统的自主性，且成本通常远低于路径 A。
论文证据：自动 harness 把 GPT-5.4-mini 从 0.488 拉到 0.912，且这个 harness 是一段可读的 Python 代码，可以给人看、给别的模型用、给同一个模型在别的任务上用。相比之下，蒸馏后的参数是"黑箱"。
推广场景：
- 团队管理：资深工程师为新工程师搭建"脚手架"（代码模板、CI/CD 配置、checklist），而不是试图"培训他们三个月"。脚手架可复用、可迭代、可审计。
- 教育：优秀教师为初学者搭建"认知脚手架"（解题模板、思维导图、分步提示），而不是直接"训练学生的大脑"。脚手架可以分享、可以跨班级复用。
- 产品设计：为"新手用户"设计向导流程（wizard）和模板，而不是要求他们"学会所有功能"。向导是可退出的——用户熟练后可以绕过它。
- 医疗诊断：资深医生为年轻医生搭建"诊断决策树"（确定性流程），年轻医生在决策树框架内工作，既保证了下限，又保留了判断空间。
灵感三：5% 的验证信号，足以支撑高质量的迭代优化
核心思想：在一个设计良好的优化循环里，少量但精准的反馈信号（验证集）往往比大量粗糙的反馈更有效。关键不是"反馈多"，而是"反馈信号是否指向真正的瓶颈"。
论文证据：5% 验证集（195 项）选出的 harness，在 95% 隐藏测试集上表现高度一致（r=0.96）；而"多迭代几次"几乎没有帮助（r=0.17）。这说明瓶颈是假设质量（单次推理的深度），不是反馈量。
推广场景：
- 产品迭代：与其做大规模 A/B 测试（反馈量大但粗糙），不如做小规模深度用户访谈（反馈量小但精准），前提是访谈问题设计得好。
- 个人学习：与其刷 1000 道题（反馈量大），不如精做 50 道题并对每道题做深度复盘（反馈量小但精准）。关键是复盘能否触及"为什么错"的根源。
- 科研：与其跑 100 个实验（反馈量大），不如设计 3 个关键实验（反馈量小但能区分假设）。论文的 72 次运行看似多，但每个设置都经过精心设计（全因子 + 配对），不是"堆量"。
灵感四：识别"二阶因素"和"一阶因素"，把预算花在一阶因素上
核心思想：在任何系统里，影响结果的因素都有"一阶"（主导）和"二阶"（次要）之分。优秀的工程决策是把预算花在一阶因素上，而不是在二阶因素上内卷。
论文证据：builder 推理努力（一阶，ρ=0.77）vs 平台选择（二阶，p=0.484）。换平台只带来 +0.013 的变化，而从 low 推理努力升到 x-high 带来 +0.145 的变化。两者相差一个数量级。
推广场景：
- 创业：产品-市场匹配（一阶）远重要于办公室选址、工具选型（二阶）。很多团队在二阶因素上花太多时间。
- 模型训练：数据质量（一阶）远重要于超参微调（二阶）。与其花一周调学习率，不如花一周清洗数据。
- 健康：睡眠和饮食（一阶）远重要于补剂品牌（二阶）。很多人在补剂上内卷，却熬夜。
- 投资：资产配置比例（一阶）远重要于择时和选股（二阶）。
灵感五：当一个系统接近天花板时，“协助"会变成"干扰”
核心思想：任何"脚手架 / 辅助 / 流程"都有一个边界——当被辅助的对象已经足够强时，继续施加辅助反而会拖累它。知道何时"退出脚手架"，和知道何时"搭建脚手架"一样重要。
论文证据：对基线 0.488 的 GPT-5.4-mini，harness 在所有基准上都正向；但对基线 0.761 的 Gemini-3.5-flash，9/20 案例出现回归——harness 在 Gemini 已经擅长的基准（Hi-ToM、MuMA-ToM）上反而拉低了表现。增益与"可用空间"（1-基线）强相关（r=0.75）。
推广场景：
- 管理：对新员工，详细的流程和模板（脚手架）有帮助；对资深员工，同样的流程可能成为束缚。好的管理者知道何时"撤脚手架"。
- 教学：对初学者，分步示范有帮助；对高阶学生，同样的示范可能限制创造力。因材施教本质上是"动态调整脚手架"。
- 工具设计：为新手设计的"向导模式"应该有明确的退出路径——用户熟练后必须能切到"专家模式"，否则工具会成为天花板。
- API 设计：为简单场景设计的"便捷封装"（脚手架）在复杂场景里会成为限制。好的 API 应该同时提供"高层封装"和"低层原语"，让用户按需切换。
灵感六：把"能力"从"参数空间"外化为"程序空间"，获得可审计性和可迁移性
核心思想：当一个能力被编码在神经网络的参数里时，它是隐式的、不可读的、不可迁移的；当同样的能力被编码在一段程序里时，它是显式的、可读的、可迁移的。在能用程序表达的时候，优先用程序。
论文证据：自动 harness 是一段可读的 Python 代码，它捕捉了"如何路由 ToM 子任务"“如何提取信念状态"“何时调用确定性 solver"等能力。这段代码可以给人看、可以审计、可以给别的弱模型用。而蒸馏后的参数做不到这些。
推广场景：
- 知识管理：把"资深员工的隐性知识"外化为"可读的 SOP 文档 / 决策树代码”，比试图"培训新人让他们内化"更高效。SOP 可审计、可版本化、可跨团队复用。
- 可解释 AI：与其要求"模型自己解释为什么”（不可靠），不如把决策逻辑放在模型外部的程序里（可审计）。这正是 Faithful CoT 和本论文的共同启示。
- 系统工程：把"魔法常量 / 启发式规则"从代码里提取到配置文件，获得可审计性和可修改性。同理，把"能力"从参数里提取到程序里。
- 法律合规：把"人工判断"外化为"明确的规则 + 例外清单"，既保证一致性，又便于审计。
附录：核心数据速查表
A.1 主要结果（target = GPT-5.4-mini, 基线 0.488）
| 配置 | 宏平均 | Δ |
|---|---|---|
| Vanilla 基线 | 0.488 | — |
| 所有运行均值 | 0.763 | +0.275 |
| 最佳（GPT-5.5 / GPT Codex） | 0.912 | +0.423 |
| UserHarness（人工） | 0.939 | +0.451 |
A.2 各 builder 主要结果（按宏平均降序）
| Builder | RR | BigToM | Hi-ToM | MMToM | MuMA | Avg | Δ |
|---|---|---|---|---|---|---|---|
| GPT-5.5 | 6 | 1.000 | 0.803 | 0.842 | 0.857 | 0.875 | +0.387 |
| Opus-4.7 (x-high) | 6 | 0.970 | 0.791 | 0.788 | 0.876 | 0.856 | +0.368 |
| Gemini-3.5-flash | 3 | 0.986 | 0.712 | 0.778 | 0.777 | 0.813 | +0.325 |
| Sonnet-4.6 | 6 | 0.977 | 0.712 | 0.742 | 0.810 | 0.810 | +0.322 |
| Opus-4.7 (high) | 6 | 0.922 | 0.739 | 0.777 | 0.791 | 0.807 | +0.319 |
| Opus-4.7 (med) | 6 | 0.944 | 0.699 | 0.751 | 0.778 | 0.793 | +0.305 |
| Gemini-3.1-Pro | 3 | 0.910 | 0.732 | 0.618 | 0.593 | 0.713 | +0.225 |
| Opus-4.7 (low) | 6 | 0.887 | 0.688 | 0.609 | 0.659 | 0.711 | +0.222 |
| GPT-5.4-mini | 6 | 0.981 | 0.649 | 0.619 | 0.474 | 0.681 | +0.193 |
| Codex-5.3 | 6 | 0.983 | 0.625 | 0.563 | 0.528 | 0.675 | +0.187 |
| Grok-0.1 | 3 | 0.613 | 0.592 | 0.537 | 0.511 | 0.563 | +0.075 |
A.3 实用配方（论文结论）
- 使用最强可用的 builder 模型。
- 在 harness 构建期间分配高推理努力。
- 仅花费适度的验证评估次数（中位数 5 次即可）。
- 对可证明的子任务优先认知卸载（确定性 solver）。
- 预算允许时构建多个独立 harness 并选择 / 集成（顶级 harness 的修复并集覆盖 97% 的基线错误）。
A.4 两条互补路线（论文最终观点）
“提升模型内部能力（大多数后训练工作）“与"降低任务执行难度（harness 和脚手架设计）”不应被视为竞争者。长期来看，模型可能被训练为更有效地使用特定 harness，而 harness 可能围绕特定模型的优势和弱点自动优化。