Harness-IF：是真遵从还是巧合？扣除先验偏好后大模型全员跌落5.8分
Harness-IF: Evaluating Instruction Following Across Instruction Surfaces in Coding Agents
当一个代码智能体在多轮开发流程中完美遵守了一项规范时，它究竟是真的读取并严格执行了这条规则，还是仅仅因为底层大模型的预训练习惯“碰巧原本就打算这么做”？
ArXiv URL：https://arxiv.org/abs/2608.11727v1
现有的评估体系完全无法回答这个问题。传统的通用指令遵循评测（如 IFEval 等）大多将规则一股脑塞在用户的单轮提问中；而代码智能体评测（如 SWE-bench 系列）则几乎完全聚焦于最终的代码修复与单元测试是否通过。智能体在漫长的多轮工具调用、终端执行、文件读写中，到底遵循了哪条规则、漏掉了哪条约束，始终是一个未被打开的黑盒。
针对这一盲区，字节跳动 Seed 联合清华大学、北京大学的研究团队提出了专门针对代码智能体的指令遵循基准 Harness-IF。该工作将指令拆解为可被执行证据逐一判决的原子规则，涵盖真实运行环境中的多层“指令表面”（Instruction Surfaces），并设计了对抗先验准确率（Against-Prior Accuracy，简称 AP-Acc）指标。在覆盖 12 个前沿大模型的评测中，所有模型在对抗自身默认行为的规则上，准确率全部出现断崖式下跌，平均下滑 5.81 个百分点。这一发现表明：当前业界常用的常规综合分数，正因模型的固有先验偏差而普遍严重高估智能体的实际遵循能力。
指令并非单张提示词：解构智能体的六层“指令表面”
在真实的软件工程生产环境中，代码智能体面对的绝不是单一提示词窗口，而是一套层层嵌套、来源各异的指令堆栈。Harness-IF 将智能体在运行时接触到的文本环境解构为六个不同的“指令表面”：
第一个是平台运行时写死的环境默认预设（Harness Default，HD）；第二个是由智能体开发者定义的系统提示词（System Prompt，SP），用于界定角色边界与全局行为；第三个是各类外部工具的工具描述（Tool Description，TD），约束工具调用的参数与时机；第四个是可复用工作流的技能描述（Skill Description，SD）；第五个是代码仓库内持久化存在的项目文件（Project File，PF），例如开发者熟悉的 CLAUDE.md、CONTRIBUTING.md 或 AGENTS.md；第六个才是终端用户在当前会话中下达的用户指令（User Instruction，UI）。
这些表面分别由平台方、工具作者、项目维护者和终端用户等不同主体编写，出现在提示词上下文的不同物理深度。以往的基准往往把所有约束都硬塞在用户指令里，这与智能体在工业级 Harness 中的真实工作流严重脱节。
为了厘清不同承载表面对模型理解的影响，Harness-IF 提出了“受控迁移”（Controlled Relocation）设计。只要语义合理，同一条原子规则可以在不同的合规表面之间迁移放置。例如，一条关于 Git 分支命名格式的规范，既可以写在系统提示词里，也可以写入项目的 CLAUDE.md 文件中。这种设计不仅保证了语义的严格对齐，更为后续精细化切片分析模型在不同表面上的遵循衰减提供了受控实验的基础。
告别“任务黑盒”：构建原子规则库与执行判决系统
评测代码智能体的难点之一，在于如何跳出最终“测试用例是否全绿”的粗粒度二元结果。在很多工业场景中，智能体可能修好了 Bug，却违反了团队的代码风格、未经允许修改了非目标文件、使用了被禁用的命令行参数，或者漏掉了提交信息的特定格式要求。
Harness-IF 建立了一个包含 642 条原子规则的通用规则库，覆盖专业写作、输出格式、代码风格、工作流约束、定量限制、条件逻辑以及工具使用等七大家族。针对代码评测集，研究团队精心筛选并实例化了 60 个逼真的多轮复杂代码任务，涵盖后端接口重构、前端组件修改、数据管道调整、测试用例补全及安全审计等八大技术场景。
在评测执行中，每个任务注入 25 到 35 条规则，平均每个任务会激活 10 到 27 条具备判决条件的有效规则。评测引擎不会只看终端输出字符串，而是完整捕获整个运行轨迹（Trace）、跨轮次的文件状态变更（Diff）、单元测试结果以及命令执行日志。在整套基准中，确定性的自动化规则检查（基于正则、抽象语法树 AST、跨文件差异比对）覆盖了 13.3% 的判决，其余基于评分细则的复杂语义检查则通过大模型裁判（GPT-5.2 构建的三票多数决机制）进行仲裁，确保每一条规则都能在多轮运行后输出独立的 Pass、Fail 或 Not Applicable 判决。
剔除侥幸成分：为什么必须引入“对抗先验准确率”？
这是 Harness-IF 最具方法论深度的地方：智能体顺应了一条规则，究竟是因为它服从了当前表面的文本注入，还是仅仅因为该规则恰好贴合了该模型底层的无条件生成习惯？
为了剥离这种“碰巧做对”的先验噪音，研究团队设计了一组严谨的辅助实验——零注入基线探测（Zero-injection probe）。在保持底层任务代码和目标环境完全不变的前提下，主动扣留目标规则，让模型在完全没有该约束的情况下裸跑。如果在缺乏规则提示时，模型本就会默认输出某种特定的代码缩进、某种固定的分支前缀或特定的英文 Commit，那么当评测集里碰巧包含这条规则时，模型的遵循成功就不能算作真正的“指令遵循能力”。
基于这套探测机制，Harness-IF 为规则打上了三种行为先验标签：
-
顺应先验（Align-Prior）：规则要求与模型不加干预时的默认行为完全一致；
-
对抗先验（Against-Prior）：规则要求明确违背模型的固有默认行为（例如要求模型改变默认的命名偏好、改变默认的工具调用链）；
-
中立规则（Neutral）：没有表现出明显固有偏好依赖的常规逻辑。
在此基础上，论文正式定义了对抗先验准确率（Against-Prior Accuracy，AP-Acc），即专门仅在那些与模型先验偏好相悖的规则集合上，重新计算模型的通过率。
设 $E_a$ 为智能体 $a$ 所有产生有效判决的规则实例集合，$z_{a,i,r} \in {0, 1}$ 表示智能体 $a$ 在任务 $i$ 中对规则 $r$ 的执行结果是否通过。常规的基线准确率定义为：
\[\text{Acc}(a) = \frac{\sum_{(i,r) \in E_a} z_{a,i,r}}{\lvert E_a \rvert}\]而对于对抗先验规则子集 $P$，AP-Acc 则被形式化为：
\[\text{AP-Acc}(a) = \frac{\sum_{(i,r) \in E_a, r \in P} z_{a,i,r}}{\lvert \{(i, r) \in E_a : r \in P\} \rvert}\]二者的差值 $\Delta = \text{Acc} - \text{AP-Acc}$，直接度量了先验偏好在多大程度上粉饰了模型的指令遵循跑分。
12个前沿模型大摸底：全员缩水，排名遭遇颠覆
在由 12 款主流前沿模型参与、涉及 2160 次完整运行、累计产生 37616 条有效规则判决的大规模实验中，结果展现出了高度一致却又耐人寻味的现象。
所有参与评测的前沿大模型，在常规准确率指标上的区间为 72.1% 至 85.9%；然而一旦切换到剔除先验红利的 AP-Acc 指标，分数全线跌落至 66.1% 至 78.6%。没有任何一个模型能在对抗先验的测试集中幸免。每个模型的得分降幅在 3.6 到 7.4 个百分点之间，平均缩水高达 5.81 分。
更关键的是，这种虚高的幅度在不同模型之间并不是一个恒定的常数，而是呈现出两倍的跨度差异。这意味着，过去不考虑先验偏好的评测指标，不仅在数值上整体虚高，而且破坏了模型横向对比的公平性。
在榜首位置，Claude-Opus-4.7 展现出强大的综合控制力，以 85.9% 的常规准确率和 78.6% 的 AP-Acc 稳居双料第一。然而紧随其后的梯队却在先验控制下发生了剧烈的位次洗牌：
-
原本常规排名第 2 的 GPT-5.5（Acc 83.1%，AP-Acc 77.0%，下滑 6.1 分）与第 3 的 Claude-Sonnet-4.6（Acc 82.5%，AP-Acc 78.5%，仅下滑 4.0 分）在抗先验视角下发生了排名倒挂；
-
第 4 名的 Claude-Haiku-4.5 降幅高达 7.2 分，被降幅仅 3.6 分的 GLM-5.1 反超；
-
在靠后的梯队中，Seed-2.0-Pro 表现出高达 7.4 分的先验依赖跌幅，导致其抗先验得分直接被 StepFun-3.5 越过。
这充分说明，有些模型之所以在传统基准上显得“很守规矩”，很大程度上是因为它们的默认偏好恰好撞上了常用编码规范；一旦要求它们打破固有习惯、执行违背常理但符合特定工程要求的特殊约束时，模型的执行力就会大打折扣。
通过对各模型在单条规则上的错误率进行向量相关性分析，研究还发现，12 款模型在“哪些规则最难遵守”这一认知上展现出了惊人的共性，模型间的相关系数在 0.57 到 0.89 之间（均值达 0.80）。这意味着规则难度的客观存在具有普适性，行业需要正视这种跨模型的系统性短板。
智能体的失败解构：不是“画蛇添足”，而是“经常漏做”
智能体在多轮编码中未能遵从指令，背后的直接机制是什么？以往基于安全护栏的研究经常告诫开发者提防智能体的“越界行为”（Overstep），即模型做了指令严厉禁止的事。但在代码工程场景下，Harness-IF 的数据揭示了完全相反的真实图景。
通过将 8440 次具体失败案例按照规则性质进行拆解，研究人员发现：
因“做不到位、漏掉要求、未达下限”（Shortfall）而导致的失败，占据了总失败量的 77.1%；
而因“做过头、违背禁用限制、超过上限”（Overstep）导致的失败，仅占 20.8%；
其余 2.1% 则属于弱偏好未达成。
这种极端的比例倾斜，核心原因在于工程任务中的“风险暴露面”差异：在长达多轮的软件构建流程中，要求智能体主动完成某项动作（如补全文档、执行某种特定格式检查、在提交时附带跟踪标记）的规则，占据了绝大多数暴露频次。两类规则本身的失误率其实相差不大（Shortfall 规则失败率为 23.8%，Overstep 为 20.8%），但由于工程规范中充斥着海量的“必须做某事”，智能体最普遍的病症变成了“选择性遗忘”或执行不彻底。
如果按照规则家族划分，输出控制（Output Control）与工作流约束（Workflow）成为了智能体的重灾区，两者联手贡献了超过一半（53.9%）的违规案例。其中，输出控制不仅错误占比最高（27.6%），其整体准确率也是各大类中最低的，平均仅有 70.9%，没有任何一款被测模型能在输出控制分类上突破 79% 的准确率。相比之下，数值上下限约束（Quantitative Limits）的准确率最高，达到了 82.6%。
从逻辑模态的角度看，带有硬性要求的“强制命令类规则”（Commanding，包含 Require 和 Forbid）难度最高，综合准确率仅为 76.0%；而软性的“偏好建议类规则”（Preference）通过率高达 90.6%。这进一步印证了先验偏好的影响：建议类指令往往原本就符合常规逻辑，而强制命令往往逼迫模型脱离舒适区，进而诱发大面积违规。
颠覆“上下文越深越有效”的认知迷思
在涉及多层指令表面的复杂场景中，如果不同表面的规则发生正面冲突，智能体会听谁的？
过去大模型领域普遍存在一种“位置深度偏见”（Prompt Depth Hypothesis），认为后输入的指令在上下文注意力中具有更高的新近度（Recency），因此排在最后的 User Instruction 应当天然拥有最高优先级，能够压制前面出现的 System Prompt 或外部注入文件。
为了在严格受控的条件下测定表面之间的权威优先级，Harness-IF 搭建了一个独立的冲突基准子集（E0 Pilot）。实验设置了四组互为矛盾的指令冲突对（例如在系统提示词中强制提交信息用英文，但在项目文件 CLAUDE.md 中强制要求提交信息用中文），并在 9 款模型构建上进行了 916 次双向平衡的对抗测试，利用 Bradley-Terry 概率模型计算表面间的相对胜率排位。
实验得出了一个极具颠覆性的结果：各表面的优先权高低，与提示词的物理排布深度完全脱钩。
在胜率排名中，系统提示词（SP）、项目文件（PF）以及用户指令（UI）三者的平均胜率排名完全打平，并列居于第一梯队（平均排名得分均为 2.22）。而排在后方的工具描述（TD）（排名 3.78）和技能描述（SD）（排名 4.56）则明显处于下风。
处于上下文最末端的用户指令，在对抗中根本没有展现出绝对压制力，它仅仅与最前方的系统提示词以及工作区中的 CLAUDE.md 打成平手。这一发现对实际开发智能体的系统架构师提出了明确的警示：不要指望用户在对话框里临时打补丁式的叮嘱，能够天然覆盖底层项目规范或系统级 Prompt 的设定；模型在处理分布式上下文约束时，其内生权威机制远比简单的线性上下文距离复杂得多。
重新审视 Agent 评测与落地的底层逻辑
Harness-IF 的提出，把大模型指令遵循的研究范式从单纯的“自然语言对话测试”推向了“多层系统工程级验证”。
对于当下的代码智能体评估而言，这项工作证明了单一的任务通过率（Pass@1）是远远不够的。一个在 SWE-bench 上跑分亮眼的智能体，完全可能在企业代码库里肆意破坏提交规范、违反安全工具的使用限制，甚至因为先验偏见而拒不执行特定的架构规范。如果不引入类似于 AP-Acc 的先验剥离技术，整个评测生态就会陷入一种“模型靠着大语料预训练自带的习惯混及格，开发者却误以为它真正具备高可靠遵循能力”的假象之中。
同时，错误特征主要集中于漏做（Shortfall）而非做多（Overstep）的实验事实，也指明了智能体运行时监控（Harness Verifier）的建设重心。针对企业级代码助理，未来的校验拦截网不应把算力全花在过滤非法输出上，而应构建更积极的遗漏检测机制，在智能体结束轮次前，显式比对项目文件与系统提示词中的必选动作项。
只有当指令遵循的标尺真正下沉到可感知的执行轨迹与抗先验的硬核约束中，代码智能体才能从看似无所不能的“概率玩具”，蜕变为工业级开发流中严谨可靠的工程伙伴。