论文链接：arXiv:2608.11727 代码仓库：论文声明将公开释放（642 条 YAML 规则库、60 个编程题、2160 条判定记录与分析脚本），具体释放地址将在后续版本给出 发表时间：2026 年 8 月（Date 标注 July 15, 2026；v1 提交于 12 Aug 2026） 机构：ByteDance Seed（字节跳动种子团队）为第一机构，第一作者 Zining Huang 兼具清华大学学生身份、Haoran Que 兼具北京大学学生身份（典型"企业 + 高校学生"合著，核心工作在 ByteDance Seed 完成） 领域标签：cs.AI（人工智能）；ACM 分类 I.2.7 / D.2.5 / I.2.6 通讯作者：Shen Yan（sheny@bytedance.com）
一、论文背景
要把这篇论文读懂，得先明白三件事：编程 Agent 是怎么"读指令"的、现在大家是怎么"测它听不听话"的、以及为什么这两件事对不上号。
1.1 编程 Agent 的"指令栈"是什么
用过 Claude Code、Cursor、Codex CLI 这类编程 Agent 的人都知道，它不是一个"输入一句话就出一段代码"的玩具，而是一个能在你的代码仓库里读文件、改代码、跑测试、调工具、跨多个回合行动的"数字员工"。而在它真正"动手"之前，它要先读一摞指令，这一摞指令在 Harness-IF 里被叫做 Instruction Stack（指令栈），由六个层次组成（论文叫它们 Instruction Surfaces，指令表面）：
| 简称 | 全称 | 是谁写的 | 举例 |
|---|---|---|---|
| HD | Harness Default（外壳默认） | Agent 平台自己塞的，用户一般改不了 | 每次运行前自动加的运行时前言 |
| SP | System Prompt（系统提示） | 平台开发者 | “提交信息用英文” / “不要泄露密钥” |
| TD | Tool Description（工具描述） | 工具作者 | “编辑前先检查目标文件” |
| SD | Skill Description（技能描述） | 技能作者 | “数字用十进制表示” |
| PF | Project File（项目文件） | 项目维护者 | CLAUDE.md / AGENTS.md / CONTRIBUTING.md，如"提交信息用中文" |
| UI | User Instruction（用户指令） | 用户本人 | “修一下 auth.py，别动测试” |
这套东西并非 Harness-IF 凭空发明，而是业界主流编程 Agent（如 Anthropic 的 Claude Code）已经在用的真实配置。你可以把它理解成：Agent 不是在读"一条"指令，而是在读"一整本员工手册 + 工具说明书 + 项目规章 + 老板口头交代"，而且这些来源之间还会打架（比如系统提示说英文提交，项目文件却说中文提交）。
“Skill（技能）“这个概念值得单独说一下：它是 Anthropic 在 Claude 生态里力推的模块化能力，一个 Skill 就是一个带 SKILL.md 的文件夹，里面写着"什么时候该用我、用我的时候要遵守哪些规则”。你可以把它类比成岗位操作手册——它不是工具本身，而是"在什么情况下、用什么方式去使用工具和流程"的说明书。这正是 SD 这一表面存在的原因。
1.2 现在大家怎么测"听不听话”
在 Harness-IF 之前，评测 LLM"指令遵循(Instruction Following, IF)“有两类主流做法，但它们各自瞎了一只眼：
第一类：纯 IF 评测——以 IFEval(2023, Google) 为代表，后续演化出 FollowBench、ComplexBench、InfoBench、Multi-IF、CFBench、LIFBench、EIFBench、IFBench、AgentIF、CodeIF-Bench 等一堆兄弟。它们的共同特征是：把所有规则都塞进"用户那一轮(user turn)“里，然后用正则/AST/LLM 判官去检查约束有没有被满足。它们做得很好的一件事是把"指令遵循"从主观偏好打分变成了客观可验证的约束检查，但它们的盲区是：根本没考虑"指令在真实 Agent 里来自多个表面"这件事。
第二类：编程 Agent 评测——以 SWE-bench / SWE-Bench Pro、Terminal-Bench、MLE-bench、PaperBench、AppWorld、τ-bench/τ²-bench、BFCL、GAIA、AgentBench、WebArena、OSWorld 为代表。它们的共同特征是：极度逼真，跑真实的代码仓库、真实的多轮工具调用，但它们的衡量标尺只有一把——最终任务成不成功(task success)。至于"Agent 在中途有没有真的遵守那条’提交信息用英文’的规矩”，它们是不关心的，只看最后一颗 PASS/FAIL。
换句话说：
- 第一类只看用户那一轮，看不到 Agent 的真实工作场景；
- 第二类只看最终任务，看不到规则有没有被真的遵守。
更致命的是，两者都存在一个共同的根本缺陷——无法区分"遵从"和"巧合”。这一点正是 Harness-IF 要解决的核心问题，我们在第三章会详细展开。
1.3 还有一支相关脉络：指令层级(Instruction Hierarchy)
OpenAI 的 Eric Wallace 等人在 2024 年发表 “The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions”，提出了"不同信任级别的指令冲突时该听谁的"这一思想（系统提示 > 用户 > 工具输出），并用合成数据训练模型遵守这一层级。后续 IHEval(NAACL 2025) 把它做成了一个评测：在 system / user / history / tool-output 四种消息之间制造合成冲突，看模型听谁的。
这条脉络关注的是"冲突时谁赢"（特权/安全问题，防止提示注入攻击），Harness-IF 则把它推进一步——关注"同一规则在哪个表面更容易被遵守"以及"冲突时表面优先级到底服从什么规律"，并且把表面从"消息角色"扩展到了更贴近真实编程 Agent 的"配置位置"（项目文件、技能描述等）。
1.4 为什么现在必须做这件事
到 2026 年，编程 Agent 已经不是 demo，而是每天在生产环境里改代码的真实劳动力。这时候一个尖锐的问题冒出来：当一个 Agent 在一个长链路工作流里"恰好"输出了符合规则的结果，它到底是真的读懂并遵守了指令，还是它本来就打算这么做（甚至根本没注意到这条指令）？这个区别对工程团队、合规审计、Agent 供应商选型都至关重要——你不会希望一个号称"100% 遵守安全规范"的 Agent，其实只是因为这些规范恰好和它的默认行为重合，一旦规范反着写它就翻车。
正是这个被所有既有评测忽视的盲区，催生了 Harness-IF。
二、论文定位和关联工作
2.1 三条研究脉络的交汇点
Harness-IF 站在三条既有脉络的交汇处，它的定位可以用"取三者之长、补三者之短“来概括：
脉络 A：纯 IF 评测（IFEval → AgentIF）
- 核心思想：用可验证的约束去检查"有没有听话”。
- 关键演进：IFEval(2023) → FollowBench/InfoBench/ComplexBench(2024, 多约束/分级难度) → Multi-IF/CFBench/LIFBench/EIFBench/IFBench(2024-2025, 多语言/长上下文/极端复杂) → AgentIF(2025, 把 IF 搬进 Agent 场景)。
- 共同盲区：规则都被塞在"用户那一轮"，没有人把"指令来自多个表面"当成实验变量。
脉络 B：编程/Agent 评测（SWE-bench → SpecBench）
- 核心思想：在真实环境里跑 Agent，看最终任务完成度。
- 关键演进：AgentBench/GAIA → SWE-bench/SWE-agent → SWE-Bench Pro/Terminal-Bench/MLE-bench/PaperBench。同期还出现了 SpecBench(2026)：研究"长链路编程 Agent 的 reward hacking / 规范钻营"——Agent 为了通过可见测试而偏离了用户的真实意图，这和 Harness-IF 的"区分真遵从 vs 巧合"在精神上是同源的。
- 共同盲区：把整条轨迹坍缩成一个"任务成功"分数，规则级合规被完全淹没。
脉络 C：指令层级与冲突（Instruction Hierarchy → IHEval）
- 核心思想：不同信任级别的指令冲突时，模型应该听特权的。
- 关键演进：Instruction Hierarchy(OpenAI, 2024, 训练模型遵守层级) → IHEval(NAACL 2025, 合成冲突评测) → ManyIH(2026, 多层级冲突)。
- 关键区别：它们关心的是"冲突时谁赢"（安全/特权），假设存在一个固定的层级；Harness-IF 关心的是"同一规则在不同表面是否被遵守、冲突时表面的实际优先级是否服从一个简单规律"，并且不假设存在普适层级。
2.2 关键前序工作的关键区别
| 工作 | 年份 | 表面数 | 多轮 | 工具 | 先验控制 | 规则级打分 | 与 Harness-IF 的关键区别 |
|---|---|---|---|---|---|---|---|
| IFEval | 2023 | 1 | – | – | – | ✓ | 只在用户轮，不进 Agent |
| ComplexBench | 2024 | 1 | – | – | – | ✓ | 同上，多约束组合 |
| IFBench | 2025 | 1 | • | • | – | ✓ | 同上，扩展可验证规则 |
| AgentIF | 2025 | 2 | • | • | – | ✓ | 进了 Agent 场景，但仍主要在用户/系统两层 |
| CodeIF-Bench | 2025 | 1 | ✓ | • | – | ✓ | 面向代码生成，仍是单表面 |
| BFCL | 2025 | 1 | ✓ | ✓ | – | – | 只评工具调用，不评规则 |
| AppWorld | 2024 | 1 | ✓ | ✓ | – | • | 任务级，不是规则级 |
| τ²-bench | 2025 | 2 | ✓ | ✓ | – | • | 任务级，双控制环境 |
| SWE-Bench Pro | 2025 | 1 | ✓ | ✓ | • | – | 任务成功度，不评指令遵循 |
| Terminal-Bench | 2026 | 1 | ✓ | ✓ | • | – | 同上 |
| IHEval | 2025 | 4 类消息 | – | – | – | ✓ | 关心冲突谁赢，假设固定层级 |
| Harness-IF | 2026 | 6 | ✓ | ✓ | ✓ | ✓ | 同时具备 6 表面 + 多轮 + 工具 + 先验控制 + 规则级打分 |
表中所列数字均来自论文 Table 1 与 Related Work 章节。可以看到，Harness-IF 是第一个把"多表面 + 多轮 + 工具 + 先验控制 + 规则级打分"这五件事同时凑齐的工作，这正是它的定位突破点。
2.3 它在这个研究图谱里的位置
一句话定位：Harness-IF 把"指令遵循"从"用户轮的约束检查"和"任务级成功度"这两座孤岛，搬进了"真实编程 Agent 的多表面工作流"，并用 AP-Acc 这一先验控制指标，第一次让"遵从"和"巧合"变得可区分。
它既不是纯 IF 评测的"再加一个更难的版本"，也不是编程 Agent 评测的"再换一个赛道"，而是在两者的交界处开了一块新地：保留前者的"可验证约束"思想，嫁接后者的"真实 Agent 执行"环境，再用"先验控制"这把新手术刀，切开了过去混在一起的"真遵从 vs 巧合"。
三、问题定义
3.1 从具体场景里提炼本质问题
具体场景：你给一个编程 Agent 布置了一个多轮编程任务，同时在它的系统提示里写了一条"提交信息用英文"。它跑完之后，提交信息确实是英文的。问：它真的遵守了这条指令吗？
问题来了：如果你把这条规则抽掉、其他什么都不变，重跑一次，发现它输出的提交信息本来就是英文的——那它第一次"遵守"规则这件事，有多少分量？答案是：几乎为零。因为它"本来就要这么做"，规则有没有都一样。这就是论文开篇那句话的意思：
“When a coding agent obeys a rule, it may simply have been going to do that anyway.” （当一个编程 Agent 遵守了一条规则，它可能只是本来就要这么做。）
这就是"巧合(coincidence)"——表面的"遵守"掩盖了"并未真正处理指令"的事实。
3.2 把它抽象成一个结构化问题
剥离掉"编程 Agent"、“提交信息"这些具体场景，Harness-IF 实际上在解一个测量学层面的抽象问题：
给定一个 Agent
a、一条原子规则r、一个把它投放到表面s的指令栈，以及 Agent 在此栈下的一次执行轨迹。 求：一个能区分"真遵从"与"巧合"的规则级合规度量M(a, r, s)。 约束：
- 度量必须建立在执行证据上（trace、diff、测试、产物、日志），而不是猜测；
- 度量必须控制 Agent 的"无指令默认行为(prior)”——也就是把规则抽掉后它本来会怎么做；
- 度量必须能在真实多轮编程工作流中运行，而不是一个合成 toy；
- 度量本身要可复现——用同一个 2160 条记录的面板，任何人都能重算出论文里每一个数。
3.3 这个抽象的精妙之处
这个定义有两个关键判断，它们是整篇论文的"题眼"：
第一，把"指令放在哪个表面"本身变成实验变量。 过去的 IF 评测把"规则内容"当唯一变量，Harness-IF 却问了一个别人没问过的问题：同一条规则，换个表面投放，Agent 还听吗？ 这就打开了"表面维度"这扇门。
第二，把"先验"作为对照系引入。 这是从因果推断里借来的思想——要判断"处理(给规则)“的效应，就必须知道"对照(不给规则)“会怎样。AP-Acc 本质上就是把"反先验规则”（你给规则后它会反过来做的事）当作"处理组"来报告，从而把"巧合"从"真遵从"里剔出去。这一步是整篇论文方法学上最锋利的一刀。
四、问题解法
Harness-IF 的解法是一个完整的测量系统，它由五个部件组成：规则库、任务与表面投放、证据采集与规则判定、先验标定、度量定义。我们一个一个拆。
4.1 部件一：642 条原子规则库（测量对象）
是什么：从公开 GitHub 软件仓库的 CLAUDE.md、AGENTS.md、CONTRIBUTING.md、SKILL.md、工具 schema 里，手工 + LLM 辅助提炼出 642 条"原子约束(atomic constraint)”。每条规则都窄到能从一次执行的证据里判定为 pass / fail / n/a（不适用）。
怎么标注的：每条规则沿8 个独立轴打标签（附录 A）：
| 轴 | 取值数 | 含义 |
|---|---|---|
| Family（规则家族） | 7 | 专业写作 / 输出控制 / 代码风格 / 工作流 / 数量限制 / 条件逻辑 / 工具使用 |
| Modality（逻辑模态） | 7 | require / forbid / conditional-require / limit-max / limit-min / prefer / allow |
| Prior（行为先验） | 3 | align-prior（与默认一致）/ against-prior（与默认相逆）/ neutral |
| Observability（可观察性） | 4 | surface / structural / behavioral / deep |
| Verifiability（可验证性） | 3 | deterministic / rubric（LLM 判官）/ subjective |
| Universality（普适性） | 4 | universal / cross-coding / cross-non-coding / specific |
| Surface fit（表面适配） | 每表面 {none,low,med,high} | 该规则能否被合理放到某表面 |
| Surface variants（表面变体） | 每适用表面一份 | 保语义但贴合该表面语气 |
为什么关键：前三个轴（Family / Modality / Prior）构成了后面所有分析（“哪类规则最难”、“哪类失败最多”）的坐标系；Prior 轴尤其关键，它是 AP-Acc 的基础——只有先给每条规则标上"它是顺着还是逆着模型默认行为"，才能区分遵从与巧合。
规则库的分布（论文 Figure 3）：Requirement 模态占 60%（主流），professional-writing 家族占 28%（但只在非编程扩展里考）。先验标签故意混着：18% align、44% against、38% neutral——这样面板就不可能靠"默认行为"蒙混过关。
4.2 部件二：60 个多轮编程任务 + 表面投放（测量场地）
是什么：从 13 个场景库里选 8 个场景（后端、前端、系统、数据/ML、自动化、安全测试、工具编排、技术文档），构造出 80 个候选 item，经过质量审计（难度 + 区分度）淘汰 20 个，留下 60 个多轮编程 item。
每个 item 里装了什么：一个代码场景 + 多轮用户指令 + 一包 25–35 条规则（其中 10–27 条能在该 item 里被评分，视该 item 创造的判定机会而定）+ 每条规则的表面分配 + ground-truth 评分脚本。
表面怎么分配：一条规则在某些表面上是"可合理投放"的（比如分支命名规则可以放项目文件或系统提示，但不能放工具 schema 里）。当多个表面都可投放时，均匀随机抽一个，并用"表面适配的措辞"保证语义不变。这是主面板的做法；另有 E0 实验做"控制式重定位"，把同一规则放到冲突的两个表面上去比（见 4.6）。
规则覆盖：60 个 item 实例化了 642 条规则里的 302 条，其中 256 条至少拿到一次判定——这就是主面板的评分对象。
4.3 部件三：证据采集与规则判定（测量传感器）
执行规模：12 个前沿模型 × 60 个 item × 3 轮 = 2160 次 agent–item–round 运行，产生 40,104 条规则级判定行。每次运行产出一个"证据包(evidence bundle)"：trace（多轮轨迹）+ diff（状态差）+ 测试结果 + 产物 + 日志。
判定方法有 6 种（附录 B），按"能机器判就机器判"原则选：
- regex：最后一轮消息或特定文件上的正则；
- ast：AST 结构匹配（函数存在、装饰器、import 顺序）；
- cross-file：跨文件一致性；
- command-output：跑编译/测试脚本看退出码和 stdout；
- hybrid：先机器预筛再 LLM 精修；
- LLM-judge：用 GPT-5.2（温度 0.3）按 rubric 打分，三次独立评估取多数。
机器判 vs LLM 判的比例：确定性判定（regex+ast+cross-file+command-output）覆盖 13.3% 的合格判定行；hybrid + LLM-judge 合计覆盖 86.8%——也就是说，绝大部分判定走的是 LLM 判官。这个比例在后面讲"可靠性"时会变成一个重要的不确定性来源。
4.4 部件四：先验标定（“巧合"的对照系）
这一步是 Harness-IF 最有创造性的一步。
目标：给每条规则标上"如果不给这条规则，Agent 本来会怎么做”。
做法一（可恢复的）——零注入探针(zero-injection probe)：把目标规则抽掉，其他不变，在 9 个探针模型 build 上重跑任务。一条规则如果在 9 个 build 里至少 5 个一致同意，就给它一个"共识先验标签"。这一步能恢复 287 条规则的先验标签（106 align / 170 against / 11 其他）。
做法二（不可恢复的）——既有标注：剩下的规则用论文既有 curation 的先验标注，或在无法恢复时标为 unknown。
最终先验分布：115 align-prior、282 against-prior、245 neutral。
一个关键的方法学声明：论文明确说，AP-Acc 是一个"行为分层(behavioral stratification)"，不是"训练溯源(training provenance)声明"——它不关心模型是在训练里学到的默认行为，还是推理时的默认倾向，它只关心"在当前 build 上，不给规则时它本来会怎么做"。这一点很重要，它把 AP-Acc 从一个"难以证伪的因果主张"降格成一个"可观察、可复现的行为描述"，反而更稳健。
4.5 部件五：核心度量（Acc、F-Acc、DW-Acc、AP-Acc）
设 z_{a,i,r} = 1 表示 agent a 在 item i 上满足了规则 r，E_a 是 a 的所有 pass/fail 规则实例集合（n/a 的不算分母）。
Acc（基础准确率）——所有合格实例一视同仁：
$$Acc(a) = \frac{\sum_{(i,r)\in E_a} z_{a,i,r}}{|E_a|}$$F-Acc（过滤准确率）——只算"在这个模型队列里能区分模型"的 item–rule 对（D 集合），去掉所有模型都 pass 或都 fail 的：
$$F\text{-}Acc(a) = \frac{\sum_{(i,r)\in E_a \cap D} z_{a,i,r}}{|E_a \cap D|}$$DW-Acc（区分度加权准确率）——用规则 r 对模型区分度 d_r（模型在 r 上的 pass 率与其总体 Acc 的 Pearson 相关）做权重：
AP-Acc（反先验准确率，本文核心新指标）——只算"反先验规则集 P“上的：
这四个度量的关系：
- Acc 是"全规则平均”，会被 align-prior 规则（模型本来就做）抬高，掩盖真实遵从能力；
- F-Acc 和 DW-Acc 是队列相关的诊断指标，用来描述"在这个 12 模型队列里"的相对位置，队列换了它们就变；
- AP-Acc 是唯一控制了"巧合"的度量——它只看"你给规则后它会反过来做"的那些规则，这些规则上 pass 了，才是"真遵从"的硬证据。
4.6 配套实验 E0：表面优先级的对照实验
主面板是"把规则放到它能合理去的表面"（描述性），它不能回答"两个表面冲突时谁赢"。要回答这个，得靠配套的 E0 实验：
- 设计：counterbalanced（平衡对照）——同一个固定任务，把一对互相冲突的规则（比如"用英文提交" vs “用中文提交”）分派到两个不同表面，各跑一次 AB 和 BA 方向。
- 规模：9 个较老的模型 build（注意：和主面板的 12 个模型不完全重合，这是故意的，E0 永远不和主面板 pool）、4 对合成冲突、916 次运行、889 次有效。
- 分析方法：Bradley–Terry 模型——这是 paired comparison（两两对比）里估计"实力/优先级"的经典统计方法，常用于体育排名、棋类 Elo 的变体。它给每个表面估一个"强度参数"，排序即优先级。
- 稳健性检验：方向分离拟合、留一对冲突 / 留一模型 out、等权重 cell、4 种对错误的保守归属、crossed bootstrap（交叉自助法 10000 次）。完整顺序 SP/PF/UI > TD > SD 在 9652/10000 次重采样里存活。
E0 的结论我们放第六章解释根源时再展开。
五、评估指标与实验证据
这一章我们要回答：作者用什么指标、在什么数据上、通过什么实验设计，证明了他们想证明的论点？这些证据真的有证明力吗？
5.1 三条核心主张 vs 证明它们的实验
论文有三条核心主张，每条都有对应的实验设计：
| 主张 | 证明它的实验 | 关键指标 | 证明力评价 |
|---|---|---|---|
| (1) 聚合分数高估了真实遵从 | 主面板 12×60×3 | Acc 与 AP-Acc 之差 Δ | 强：12 个模型无一例外 Δ>0，且 common-support 配对区间下界仍 >0 |
| (2) 高估程度因模型而异 | 主面板 | Δ 的分布 | 强：Δ 跨 3.6–7.4 分，两倍差距，导致 3 对相邻排名互换 |
| (3) 表面优先级不服从提示深度 | E0 | Bradley–Terry 表面排名 | 中-强：pooled 趋势稳健（9652/10000），但个别模型拟合只 6/9 复现 |
5.2 核心数字：12 个前沿模型的主面板结果
下表是论文 Table 2 的核心数据，按 Acc 降序：
| 模型 | Acc (%) | F-Acc (%) | DW-Acc (%) | AP-Acc (%) | Δ = Acc − AP-Acc |
|---|---|---|---|---|---|
| Claude-Opus-4.7 | 85.9 | 79.3 | 88.5 | 78.6 | +7.3 |
| GPT-5.5 | 83.1 | 75.5 | 81.2 | 77.0 | +6.1 |
| Claude-Sonnet-4.6 | 82.5 | 73.9 | 82.2 | 78.5 | +4.0 |
| Claude-Haiku-4.5 | 79.0 | 69.4 | 75.9 | 71.9 | +7.2 |
| GLM-5.1 | 78.8 | 67.9 | 75.6 | 75.2 | +3.6 |
| Qwen-3.6-Max | 76.7 | 65.9 | 70.5 | 71.7 | +5.1 |
| Hy3 | 76.2 | 65.2 | 69.7 | 70.8 | +5.4 |
| Kimi-K2.6 | 76.1 | 65.0 | 70.3 | 70.0 | +6.1 |
| Gemini-3.1-Pro | 75.4 | 64.0 | 70.0 | 69.8 | +5.6 |
| MiniMax-M2.7 | 73.6 | 61.2 | 65.1 | 67.7 | +5.9 |
| Seed-2.0-Pro | 73.6 | 61.1 | 63.2 | 66.1 | +7.4 |
| StepFun-3.5 | 72.1 | 59.1 | 62.5 | 66.2 | +5.9 |
怎么读这张表：
- Acc 跨度 13.7 分（72.1–85.9），标准差 4.2 分；
- AP-Acc 跨度 12.5 分（66.1–78.6），但排名不完全一致；
- Δ 全部为正，均值 +5.81 分，范围 +3.6 到 +7.4——两倍差距，这是"高估程度因模型而异"的直接证据；
- Claude-Opus-4.7 四列全第一，所以先验控制不改变头名；
- 但先验控制交换了 3 对相邻排名（2–3、4–5、11–12），说明在不分模型的情况下用 Acc 排座次是不可靠的。
5.3 这个实验设计为什么能证明主张(1)和(2)
主张(1)“聚合分数高估真实遵从"的证明力来自三个层面的稳健性：
- 全面板：12 个模型 Δ 全正，均值 +5.81（37,616 条合格判定，其中 19,449 条 against-prior）；
- common-support（共同支撑）：只保留每个模型都给出干净 pass/fail 的 (item, round, rule) 观测，保留 2,430/3,342 = 72.7%。在这一固定分母上做 item-clustered（按 item 聚类）的 95% 百分位自助区间，每个模型的 Δ 下界都 >0（最低 +1.06，最高 +4.83）；
- 确定性子集：在 5,013 条纯机器判定里 Δ 平均 +13.09 分（更大，因为该子集过度代表了模式/命令检查类规则）。
为什么这个设计有证明力：因为"巧合"只会让 Acc 虚高、不会让 AP-Acc 虚高（反先验规则上"模型本来就要做"的方向和规则要求相反），所以 Δ>0 的方向是结构必然，而非偶然。common-support + item-clustered 的设计排除了"分母差异"和"item 间相关"两个主要混淆因素，使结论带上了因果推断的"对照"意味。
主张(2)“高估因模型而异"的证明力来自 Δ 的两倍跨度（3.6–7.4）：这不是一个会自然抵消的常数，所以不能说"用 Acc 排名虽然绝对值偏高但相对顺序不变”——事实上它交换了 3 对相邻排名，这是直接证伪。
5.4 失败结构：哪类规则失败最多
论文 §4.2 的失败分解（Figure 4，共 8,440 次失败）是另一个有证明力的分析。它按”被违反的规则要求什么“来分类——这个分类完全可从规则定义恢复，不需要读判官理由文本，所以是可复现的：
| 类别 | 失败数 | 失败占比 | 自身失败率 |
|---|---|---|---|
| Shortfall（要求行动 / 设下限，但没做够） | 6,507 | 77.1% | 23.8% |
| Overstep（禁止 / 设上限，但做过了头） | 1,758 | 20.8% | 20.8% |
| Preference（软偏好） | 175 | 2.1% | 9.4% |
关键洞察：Shortfall（该做的没做）占了 77.1% 的失败质量，但它的自身失败率（23.8%）和 Overstep（20.8%）几乎一样。也就是说，差距来自曝光量——面板里 Shortfall 实例（27,306 次）远多于 Overstep（8,443 次）。这背后的本质是：现实里的工程规则大多是"要求做某事"而不是"禁止做某事”，所以"未完成要求的遗漏"才是失败主体，而那些专门检测"过度输出"的检查器只能覆盖约 1/5 的失败质量。
按家族（family）看：失败质量最多的是 Output Control（输出控制，27.6%）+ Workflow（工作流，26.3%），合计 53.9%。Output Control 同时是自身通过率最低的家族（70.9%），这使它成为"最值得优先治理"的规则家族——这是给工程团队的直接可操作结论。
5.5 难度分布：哪类规则最难
Figure 5 给出按模态和家族的通过率：
按模态（pooled）：
- Preference（偏好）90.6%（最容易——因为偏好常常和默认行为重合）；
- Conditional（条件）79.7%；
- Numeric bounds（数值边界）79.4%；
- Commanding（命令式 require/forbid）76.0%（最难）——因为命令常常要求偏离默认行为，这和 AP-Acc 的逻辑自洽。
按家族（pooled，6 个家族）：
- Quantitative 82.6%（最高）；
- Output Control 70.9%（最低，且 12 个 build 里 11 个是最低）。
5.6 E0 的表面优先级证据
Figure 6 的核心数字（9 个较老模型上的 E0，deterministic-only）：
| 表面 | Bradley–Terry 平均排名（越低越优先） |
|---|---|
| System Prompt (SP) | 2.22（并列第一） |
| Project File (PF) | 2.22（并列第一） |
| User Instruction (UI) | 2.22（并列第一） |
| Tool Description (TD) | 3.78 |
| Skill Description (SD) | 4.56（最弱） |
为什么这个证据有证明力：
- 完整顺序 SP/PF/UI > TD > SD 在 9652/10000 次 crossed-bootstrap 里存活；
- 留一对冲突 / 留一模型 / 等权重 cell / 4 种错误归属全部存活；
- 但只有 6/9 个单模型拟合完全复现——所以作者很诚实地把它定位为"pooled cross-build tendency（跨模型的池化趋势）"，而不是"universal hierarchy（普适层级）"。
反直觉之处：如果"提示深度（prompt 里越晚出现越优先）“是对的，那么 UI（用户轮，最后出现）应该最强——但 UI 只是并列第一，这与深度解释矛盾。SP 和 PF（出现在 prompt 早期）居然和 UI 平起平坐，说明表面优先级不服从简单的位置规律，背后可能涉及训练时模型对不同"来源权威性"的内化。
5.7 可靠性边界：作者主动暴露的不确定性
这是这篇论文特别值得称赞的一点——它主动暴露了自己测量的不确定性边界：
- Test–retest ICC：跨模型 0.725，跨 agent–item cell 0.599；单个 cell 跨 3 轮的 Acc 平均波动 15.6 分，比整个排行榜的 13.7 分跨度还大——这意味着单轮比较相邻模型是没意义的，必须 3 轮 pooled；
- Judge-swap（把判官从 GPT-5.2 换成 Claude-Opus-4.7）：在 116 行配对干净子集上 raw agreement 仅 62.1%，κ=0.163——这是测量里最大的不确定性来源，因为 86.8% 的判定行涉及判官；
- 历史人审参考：一个 5-vote 配置的历史研究给出 69.0% agreement，κ=0.515（n=919），作为"中等强度的人参考校准”，但作者明确说这不是对当前冻结面板的直接验证。
这些边界为什么重要：因为 86.8% 判定走 LLM 判官，而判官一换 κ 就掉到 0.163，所以绝对分数是仪器相关的（instrument-specific）。作者因此把主张限定在跨模型比较（共享同一仪器）和prior-alignment 对比上，而不是宣称"模型 X 的绝对 AP-Acc 就是 78.6%"。这种"测量学上的诚实"是这篇论文方法学上最值得学的地方之一。
六、效果优势的根源解释
这一章我们从根源解释：为什么 AP-Acc 这个设计能揭示出 Acc 看不到的东西？为什么 E0 的表面排序会是 SP/PF/UI > TD > SD？禁止"因为用了 X 所以好"的表面归因。
6.1 根源一：AP-Acc 为什么能切开"遵从 vs 巧合"——对照系的引入
baseline 是什么：过去的 Acc 把所有规则一视同仁地平均。它的根本局限不在于"算得粗"，而在于它没有对照系——它无法回答"如果不给规则会怎样"。
AP-Acc 的根本改变：它从因果推断里借来了"对照组思想"——通过零注入探针，在不给规则的情况下观察模型默认行为，从而把规则集分成 align / against / neutral 三组。只报 against 组的通过率等价于"只看处理组（给规则且规则逆默认）的效应"。
机制因果链：
- 方法差异：AP-Acc 只保留 against-prior 规则；Acc 保留全部。
- 机制变化：against-prior 规则上"模型本来要做的方向"和"规则要求的方向"相反，所以模型 pass 这条规则只能是因为它处理并遵从了规则——巧合在这里结构上不可能；
- 瓶颈缓解：Acc 的瓶颈是"align 规则会蒙混过关，把分数抬高"；AP-Acc 直接把 align 规则排除出分母，这个瓶颈被釜底抽薪；
- 体现在指标上：12 个模型 Δ 全正，均值 +5.81 分。
反事实推理：如果去掉"先验标定"这一步、只用 Acc，会发生什么？答案就在 Table 2 里——3 对相邻排名会被错排。比如 Claude-Sonnet-4.6（Acc 82.5，AP-Acc 78.5）和 GPT-5.5（Acc 83.1，AP-Acc 77.0）：按 Acc 排 Sonnet 输给 GPT-5.5，但按 AP-Acc（真正控制了巧合的指标）Sonnet 反而高出 1.5 分。这就是"巧合"造成的排名错位。
根源结论：AP-Acc 的优势不是"算得更精"，而是它在测量学层面引入了因果推断里"对照"这一根本思想，把"规则是否被真正处理"从"规则是否被表面满足"里剥离出来。这是范式性的进步，不是工程优化。
6.2 根源二：表面优先级为什么不服从提示深度——训练内化的权威感
baseline 是什么：“提示深度"解释——它假设模型像读流水账一样，越晚出现的指令越容易被记住和执行。这个解释在某些场景下有效（recency bias 是真实存在的）。
E0 数据反驳了什么：UI（用户轮，最晚出现）只和 SP、PF 并列第一，而不是独占鳌头。如果深度解释完全成立，UI 应该最强、SP/PF（最早出现）应该最弱——但事实相反。
可能的机制解释（论文未直接断言，但数据支持的方向）：
- 训练时的权威内化：模型在 RLHF / 指令微调阶段被反复训练"系统提示具有更高特权”（Wallace et al., 2024 的 instruction hierarchy 训练）。这种训练让模型形成了"SP 是权威源"的内化倾向，它在推理时不需要"看到 SP 在前面"就遵守，而是认出这是 SP 类内容就遵守；
- 项目文件的权威性：PF（
CLAUDE.md之类）在训练语料里常常是"项目级强制规范"的化身，模型可能内化了"项目文件 = 项目宪法"的关联； - 用户轮并列第一：UI 仍受 recency bias 加持，所以它即使没有"特权训练"的优势，也能靠"最后出现"挤进第一梯队；
- 工具描述和技能描述垫底：TD 和 SD 在训练语料里更多是"辅助说明"而非"权威规范"，模型对它们的"权威权重"内化得弱；同时它们常常以结构化（schema/YAML）形式出现，模型可能将其当成"参考"而非"命令"。
这个解释的可验证性：论文 D.4 指出，主面板的描述性分层和 E0 的冲突排名是两件事，不矛盾——主面板里 SD 的单独通过率（78.6%）高于 SP（73.6%），但 E0 冲突里 SD 输给 SP。一个表面"单独时好遵守"和"冲突时输"是完全兼容的（就像一个选手单打成绩好但双打时让位）。
根源结论：表面优先级不是"prompt 里位置靠后的赢"，而是模型在训练里把不同来源的"权威性"内化成了不同的权重。这意味着想靠"调整表面位置"来改变 Agent 行为是低效的——真正决定优先级的是模型训练时对不同表面的权威性塑造。这是一个对 Agent 部署者极有价值的洞察。
6.3 根源三：为什么"要求做"比"禁止做"更难（Shortfall 主导失败）
数据：Shortfall（要求做）占失败 77.1%，但自身失败率（23.8%）和 Overstep（20.8%）接近。
根源：这是曝光不对称而不是能力不对称。面板里 Shortfall 实例是 Overstep 的 3.2 倍，因为现实工程规则大多是"要求做某事"（写提交信息、跑测试、加注释），少部分是"禁止做某事"（不许泄露密钥、不许超长输出）。
机制含义：这意味着对 Agent 的治理重心应该放在"确保它做够"而非"防止它做过头"——前者才是失败主体。那些只检测"过度输出"的检查器（很多合规系统是这样的）只能覆盖约 1/5 的失败质量。
6.4 一处需要如实说明的地方：Output Control 最难，部分原因在工程
Output Control 家族是"最难、失败质量最大"的双重最差，但论文没完全从根源解释为什么。一个合理的推测是：输出控制规则常常要求模型抑制被 fixture 上下文诱发的模仿倾向（附录 F 的 Example D：模型把 fixture 里的语言/格式镜像进了最终响应，违反了响应语言约束）。这属于"上下文诱发 vs 规则要求"的对抗，机制上和 against-prior 是一类，但论文没把它明确归因，所以我们如实标注：这部分有工程因素（fixture 设计诱发）参与，不能完全归因于方法层面的根本差异。
七、必要知识反推
假设找一个完全没有相关知识的人去做这项工作，他最少必须掌握什么？我们按层次反推。
7.1 领域知识层（不懂就没法构造测量对象）
- 编程 Agent 的真实工作流：必须知道 Claude Code / Codex CLI 这类 Agent 是怎么读一摞指令、调工具、改代码的，否则你根本想不到"指令来自多个表面"这件事——这是整个工作的起点洞察。
- 指令表面的真实分布：必须知道 HD/SP/TD/SD/PF/UI 这六个表面是真实存在的（不是杜撰），它们由不同主体撰写（平台开发者、工具作者、技能作者、项目维护者、用户），且在部署中会冲突——否则你无法构造"可投放规则"的合理表面集。
- CLAUDE.md / AGENTS.md / SKILL.md 这些约定的语义：必须知道项目文件在编程 Agent 生态里的"项目宪法"地位，以及 Skill（SD）作为"岗位操作手册"的定位——否则你无法判断一条规则在哪个表面是"admissible（可投放）“的。
7.2 方法论知识层（不懂就没法设计度量）
- 因果推断里的对照思想：必须知道"要判断处理的效应就必须知道对照会怎样”——这是 AP-Acc 的源头。零注入探针本质就是"构造对照组"。
- IFEval 及其后继的约束检查范式：必须知道 IFEval 确立了"可验证约束"这一标准，否则你不知道自己站在谁的肩膀上，也无法在 Table 1 里定位自己的差异化。
- 指令层级（Wallace et al., 2024）和 IHEval 的冲突范式：必须知道这条脉络，才能设计 E0 的 counterbalanced 冲突实验，并用 Bradley–Terry 分析。
- Bradley–Terry 模型：这是 paired comparison 排名的经典工具，不懂它就无法从"成对冲突胜负"里估出"表面强度排序"。
- 统计可靠性工具：item-clustered bootstrap、ICC、Cohen’s κ、common-support 分析——不懂这些就没法诚实地报告"哪些结论稳、哪些不稳"。
- LLM-as-judge 的敏感性：必须知道换判官会让 κ 大幅波动——这是论文主动暴露的最大不确定性，不报告这一点就是不诚实。
7.3 工程知识层（不懂就没法把测量跑起来）
- Agent harness 的工程实现：怎么在 12 个模型上跑 60 个 item × 3 轮、收 trace/diff/test/artifact/log，并保证可复现；
- 6 种判定方法的选型与级联：regex / ast / cross-file / command-output / hybrid / LLM-judge——必须知道每种方法的适用范围和边界，否则判定会出系统性偏差；
- 规则库的 curation 工程：从 GitHub 文档里提炼 642 条原子规则、8 轴标注、表面变体保语义——这是一项浩大的数据工程；
- 可复现释放的工程：用一个脚本从 2160 条记录重算论文每个数——这要求严格的版本冻结和审计 trail。
7.4 知识融合的关键节点
融合节点 1（最关键）：把"因果对照"嫁接到"约束检查"上。 单独懂 IFEval 的人会做约束检查但想不到对照；单独懂因果推断的人会做对照但想不到把它用于 IF 评测。Harness-IF 的核心创造力是在这两个领域的交界处切了一刀——用零注入探针构造对照组，只在反先验规则上报告通过率。这个洞察不是任何单一领域的自然产物。
融合节点 2：把"表面"从"消息角色"扩展到"配置位置"。 指令层级 / IHEval 把表面理解为 system/user/tool-output 等消息角色，Harness-IF 把它扩展成了真实编程 Agent 的配置位置（项目文件、技能描述、工具 schema）。这要求同时懂"安全研究里的消息层级"和"工程里的 Agent 配置生态"，两者缺一不可。
融合节点 3：在统计诚实和实用结论之间找平衡。 单纯懂统计的人会把所有结论都限定到不可用（“都不显著”）；单纯懂工程的人会过度解读（“模型 X 就是第一”）。Harness-IF 的做法是：用 common-support + item-clustered 把能证的证到稳（Δ>0 模型级稳），把不能证的诚实标出（相邻排名不可区分），再给出可操作的限定性结论（Output Control 是优先治理目标）。这种"知道什么能说什么不能说"的判断力，是统计、工程、领域知识三者融合的产物。
八、论文中可以提取的通用性灵感
这一章我们提炼 Harness-IF 里可推广到其他领域的普适性思想，每条都有论文证据支撑。
8.1 灵感一：任何"合规/遵从"评测，都必须构造对照系
- 核心思想：要测一个系统"是否真正因为某项要求而改变了行为"，就必须知道"没有这项要求时它本来会怎么做"。光看"要求被满足"是不够的——可能只是巧合。
- 论文证据：12 个模型在 against-prior 规则上无一例外比总体更差（Δ 全正，均值 +5.81），证明"巧合"在常规指标里贡献了可观的虚高。
- 推广场景：
- 内容推荐系统：测"推荐是否真的命中了用户兴趣"——必须对照"不给推荐时用户本来会点什么"，否则会把"热门内容本来就流行"误判为"推荐有效"。
- 安全合规审计：测"员工是否真的因为培训而遵守了某项规定"——必须对照"没培训时默认行为"，否则会把"本来就会做"误判为"培训有效"。
- RLHF / 对齐评测：测"模型是否真的因为某条原则而改变了输出"——必须对照"不给原则时默认输出"，否则会把"模型本来就这么答"误判为"原则被遵守"。
- 医疗治疗评估：测"药物是否真的改变了患者结局"——必须对照"不吃药时患者本来会怎样"（这正是 RCT 的思想，AP-Acc 是它在规则评测上的投影）。
8.2 灵感二：把"指令来源/投放位置"当成实验变量，而不仅仅是内容
- 核心思想：当一个系统从多个来源接收指令/信号时，“指令通过哪个渠道送达"本身会显著影响遵从度，这个维度值得被独立测量。
- 论文证据：E0 的 SP/PF/UI > TD > SD 优先级，以及主面板里同一规则在不同表面的通过率差异（附录 F Example A：skill 摆放规则在 PF 上 100% 通过，在 SD 上只有 67%）。
- 推广场景：
- 组织管理：一项政策通过"CEO 邮件 / 部门规章 / 同事口头 / 系统提示"四个渠道下达，员工遵从度会有显著差异——值得独立测量每个渠道的"权威权重”。
- 产品设计 / UX：功能引导放在"系统弹窗 / 设置页 / 帮助文档 / tooltip"四个位置，用户执行率不同——值得做"表面级"转化分析。
- 多 Agent 协作：一条任务指令从 leader agent / peer agent / 用户 / 工具输出四个来源发出时，worker agent 的遵从度不同——值得测量每个来源的"可信度权重"。
- 教育系统：同一学习要求从"教材 / 老师 / 同伴 / 系统"四个来源下达，学生执行度不同——值得做来源级归因。
8.3 灵感三：失败分解要分清"曝光量"和"自身失败率"，否则治理方向会错
- 核心思想：当我们说"X 类问题占失败的 70%“时，要先问"是因为 X 本身特别难，还是因为 X 在样本里特别多”。这两者对应的治理策略完全不同。
- 论文证据：Shortfall 占失败 77.1%，但自身失败率（23.8%）和 Overstep（20.8%）接近——失败质量大是因为 Shortfall 实例数是 Overstep 的 3.2 倍（曝光不对称）。
- 推广场景：
- 线上事故分析：某类故障占事故 70% 不代表它"最容易出错"，可能只是因为它出现得最频繁。要分清"频率权重"和"条件概率"。
- 模型错误分析：某类 benchmark 题目错得多，先问"是这类题难还是这类题多"——混淆这两个会被诱导去优化错误的方向。
- 医疗误诊分析：某疾病误诊占 70%，先问"是该病难诊断还是该病就诊量大"——前者要改进诊断能力，后者只需扩大筛查。
8.4 灵感四：诚实报告测量不确定性，反而让结论更可信
- 核心思想：主动暴露自己测量的边界（什么能证、什么不能证、仪器敏感性多大）不会削弱论文，反而让可证的结论更稳、更可信。
- 论文证据：Harness-IF 主动报告了 judge-swap 后 κ 从 0.515 掉到 0.163、test-retest 单 cell 波动 15.6 分大于排行榜跨度、只有 6/9 单模型复现 E0 完整顺序——然后把主张限定在这些边界之内（跨模型比较、prior-alignment 方向）。
- 推广场景：
- 任何评估基准：主动报告"换判官/换种子/换时点"的敏感性，把主张限定在稳健区间——这应该成为评估论文的标配。
- A/B 测试结论：主动报告"不同分析者/不同子样本"下的结论稳定性，而不是只报一个 p 值。
- 政策评估：主动报告"测量误差/数据缺失/模型假设"的影响区间，让决策者知道结论的可靠半径。
8.5 灵感五：对"长链路 Agent"的评估，要从"任务成功"细化到"过程合规"
- 核心思想：当一个 Agent 系统能完成长链路任务时，“最终任务成功"会掩盖过程中的大量违规。评估必须细化到过程级的规则合规。
- 论文证据：论文 §1 明确指出"coding-agent benchmarks emphasize final task success"的局限，并用规则级判定（每条规则一次 pass/fail/n/a）取代任务级坍缩。这与同期的 SpecBench（测长链路 Agent 的 reward hacking）在精神上同源。
- 推广场景：
- 自动驾驶评估：不能只看"到没到目的地”，要看全程有没有遵守每一条交规——过程级合规比终点级成功更难也更必要。
- 自动化运维 Agent：不能只看"故障修没修好"，要看修复过程有没有违反变更窗口、审批流、回滚规程。
- 科研自动化 Agent：不能只看"实验做完没"，要看过程有没有遵守实验记录、对照设置、数据完整性规则。
- 法律 AI Agent：不能只看"文书生成没"，要看过程有没有遵守每一条取证、告知、保密规则——这里过程违规的代价远大于终点失败。
附录：几个值得记的关键数字
- 642 条原子规则库（8 轴标注）
- 60 个多轮编程 item（从 80 候选审计出）
- 256 条规则在主面板拿到判定
- 12 个前沿模型 × 3 轮 = 2,160 次 agent–item–round 运行
- 40,104 条规则级判定行（其中 86.8% 走 LLM 判官）
- Acc 跨度 72.1–85.9 分；AP-Acc 跨度 66.1–78.6 分
- Δ = Acc − AP-Acc：全部为正，均值 +5.81 分，范围 3.6–7.4 分（两倍差距）
- Shortfall 占失败 77.1%（曝光不对称而非能力不对称）
- Output Control 是最差家族：70.9% 通过率，11/12 模型里垫底
- E0 表面优先级：SP/PF/UI 并列第一（rank 2.22）> TD（3.78）> SD（4.56）
- Judge-swap κ：0.515 → 0.163（测量最大不确定性来源）
- Test-retest 单 cell 平均波动：15.6 分（大于排行榜跨度 13.7 分）
这些数字都可直接从论文释放的 2,160 条记录面板上用单一脚本复算——这是这项工作"可复现"承诺的硬基础。
一句话总结：Harness-IF 把"编程 Agent 是否真的在听话"这件事，第一次变成了规则级、表面感知、先验控制、统计诚实的可测量问题。它的核心贡献不是"造了一个更难的 benchmark"，而是给整个 Agent 评估社区示范了一种新的测量学范式——任何宣称"我的 Agent 遵守了 X 规则"的工作，今后都得回答一个问题：你是真的在遵从，还是只是本来就要这么做？