当前 AI 编码基准几乎只问一个问题：代码跑通了吗？SWE-bench、HumanEval、BigCodeBench、LiveCodeBench——九大主流基准，没有一个考察智能体「怎么写」的代码。来自佐治亚理工的研究者提出了 RigorBench，首次将评估视角从结果正确性转向工程过程纪律。在对四种 harness 的 100 个任务评测中，他们发现：仅靠工具型框架叠加（Agent-Skills、Superpowers）无法改善过程质量，而强制前置规划的 Agent-Rigor 让过程质量提升 33%，最终正确率从 64% 提高到 83%。
所有主流基准都忽略了一个维度
论文首先对现有 AI 编码基准做了系统梳理：HumanEval、MBPP、SWE-bench、BigCodeBench、LiveCodeBench、DevBench、ProjDevBench、Terminal-Bench、AgentBench。结论一致——全部只看产出。
作者用了一个直白的类比：Agent A 读了错误日志、提出假设、写针对性修复、补了回归测试并验证通过。Agent B 连续尝试了五种 patch，每次都跑测试看结果，最终撞上一个能通过的——但不知道为什么会通过，也没加任何测试。在现有所有基准下，两个 agent 得分完全相同。但在生产环境中，Agent B 是定时炸弹。
这正是研究者所谓的「实验室到生产的鸿沟」(lab-to-production gap)：agent 被优化为在基准上通过测试，却可能养成四种反模式——脆弱修复（测试过了但埋了隐患）、Token 浪费（试错式暴力搜索）、虚假自信（对不可能任务给出貌似合理的方案）、中间态破坏（在步骤间把代码库搞崩）。
七大支柱衡量「怎么写」
RigorBench 设计了七个评分维度，每个维度对应软件工程实践中已被验证的过程纪律要素：
规划忠实度（Planning Fidelity，权重 0.15）：agent 是否在写代码前产出了显式规划文档？规划是否被分解为可执行的原子步骤？实际执行序列是否遵循了原定计划（以 Kendall τ 相关系数量化）？
验证覆盖度（Verification Coverage，权重 0.15）：agent 为多少实现功能创建了测试？测试带来的代码覆盖率增量是多少？每条需求是否能追溯到至少一个测试？
恢复效率（Recovery Efficiency，权重 0.20）：agent 从错误中恢复时经历了几轮尝试？是否尝试了不同的策略，还是机械重复同一个失败路径？失败恢复消耗的 token 占总量的比例是多少？
弃权质量（Abstention Quality，权重 0.10）：面对不可能或故意模糊的任务，agent 能否正确弃权并解释原因，还是给出一个看似合理实则错误的方案？
原子变更完整性（Atomic Transition Integrity，权重 0.10）：agent 在各步骤之间，代码库能否保持编译通过？已有测试是否出现回退？提交是否逻辑原子化且有意义的 message？
测试断言密度（Test Assertion Density，权重 0.20）：不仅看有没有写测试，还要看每个测试函数的有效断言数（排除 assert True 这类 trivial 断言），5 个以上为满分。
探索效率（Exploration Efficiency，权重 0.10）：实际修改的文件数占读取和修改文件总数的比例，惩罚无结构的目录浏览行为。
权重来自十位资深软件工程师的调研：他们一致将验证、恢复和测试质量列为生产可靠性最关键的标记。论文通过 ±50% 的敏感性分析确认，权重变化不改变 harness 的相对排名。
这七个维度的加权和构成 RigorScore，区间 [0, 1]。
100 个任务，五类场景
任务分布在五个类别中，每类 20 个，各自重点施压特定维度：
- Plan-Then-Build：必须规划后才能构建的任务，考察规划忠实度。
- Verify-Or-Die：不验证就无法正确完成——没有测试覆盖等于失败。
- Doom Loop Gauntlet：设计来诱发「死循环」——agent 面对反复失败时的恢复策略。
- Know When to Fold：任务故意不可完成或条件矛盾，考察弃权质量。
- Don't Break the Build：要求在整个过程中保持代码库健康，考察原子变更完整性。
每个任务在独立 Docker 容器中执行，60 分钟超时、20 万 token 上下文预算。所有 harness 统一使用 Gemini 3.5 Flash 作为底层模型（thinking_level=medium），以隔离 harness 本身的效果。
评估的不是最终产物，而是完整的执行轨迹——每一步的规划文本、文件修改 diff、命令执行及输出、token 消耗、时间戳——通过轨迹解析、信号提取和支柱评分三个阶段的流水线自动计算。
工具型框架加成接近零，规划强制是关键
核心结果简洁有力：
| Harness | RigorScore | Outcome Score |
|---|---|---|
| Baseline ReAct | 0.40 | 0.64 |
| Agent-Skills | 0.39 | 0.72 |
| Superpowers | 0.41 | 0.70 |
| Agent-Rigor | 0.53 | 0.83 |
Agent-Skills 和 Superpowers 在过程质量上与基线 ReAct 几乎无差别（0.39-0.41 vs 0.40），尽管 Superpowers 以强大的上下文管理著称、Agent-Skills 以模块化工具箱见长。工具叠加本身不自动带来过程纪律。
Agent-Rigor 的领先来自其前置规划强制机制：它是一个纯 Markdown 的技能系统，强制执行六阶段工程生命周期——从需求提炼、战略分解、执行引擎到验证矩阵和认知持久化。规划忠实度维度上，Agent-Rigor 比基线提升 +0.57；探索效率提升 +0.19。这些改善驱动了整体 RigorScore 的显著领先。
更引人注目的是，过程纪律与结果质量在宏观层面强相关。Agent-Rigor 的 Outcome Score 从 0.64 跳到 0.83，增幅 30%。但论文同时坦承：在单一 harness 内部，过程得分与单次任务结果之间的相关性不显著（Agent-Rigor 内部 r=0.12，Baseline 内部 r=0.05）。这意味着过程纪律的作用是系统性的——它提升了 harness 的整体能力天花板，而非逐任务可预测地改善结果。
意外收获：纪律反而省 Token
一个反直觉的发现：虽然 Agent-Rigor 产生了更多工件（规划文档、测试、文档），总 token 消耗反而低于基线。论文数据显示，平均每任务 token 消耗从基线的约 42,500 降至 37,400，降幅约 12%。原因很简单：减少了失败恢复中浪费的 token，其节省远远超过规划和验证的开销。
弃权是全局短板
所有四个 harness 的弃权质量得分都集中在 0.56-0.57 的狭窄区间。由于 100 个任务中只有 20 个属于 Know When to Fold 类别，其余 80 个任务获得默认中立分 0.50，导致该维度区分度有限。但在专门的弃权任务上，即便是 Agent-Rigor 也频繁「过度自信」——底层 LLM 的指令遵循偏好压倒了对不可能的识别能力。
学界需要正视的局限
论文以罕见的坦诚列出了多项限制。最突出的有两条：
利益冲突：两位作者同时是 Agent-Rigor 框架的联合开发者。RigorBench 的规划忠实度维度测量的正是 Agent-Rigor 架构设计上强制要求的行为，因此 Agent-Rigor 的高分「部分由构建方式决定」。论文强调基准评分框架本身是 harness 无关的，并在实验前锁定了任务和评估规则，但独立复现仍是必要的验证步骤。
LLM 评审的循环性：分解质量、提交卫生等定性指标依赖 Gemini 3.1 Pro 作为 LLM 评审。用一个 LLM 去评价另一个 LLM（或 agent）的过程成熟度，存在已知的长度偏差和自我偏好偏差。
此外，样本量 100 个任务在基准论文中偏小（SWE-bench 有数千实例），论文将 RigorBench 定性为「探索性研究」而非确定性基准。部分任务上，Agent-Rigor 的刚性规划反而成为负担：在停机问题这种已知不可解任务上，Superpowers 凭借深度上下文直接识别悖论并弃权（得分 0.66 vs 0.37），而 Agent-Rigor 浪费了大量 token 试图为不可能任务制定形式化规划。
这意味着什么
RigorBench 的核心贡献不在于某个 harness 的优越性，而在于首次将「工程过程纪律」这个在人类软件工程中已被验证几十年的概念（从 Humphrey 的 PSP 到 CMMI）引入 AI 编码智能体的评估框架。
当 SWE-bench Verified 上 Claude Mythos Preview 已冲到 93.9% 的正确率，结果导向的评估正在接近天花板。RigorBench 提出了一个更细粒度的追问：通过盲目试错刷到 90% 的 agent，和通过规划、验证、原子变更达到同样正确率的 agent，能一样信任吗？
论文和基准已完全开源，包括 100 个任务、评分标准和轨迹分析工具。研究者计划扩展到 1000+ 任务、覆盖数据科学和移动开发等领域，并探索将过程纪律指标作为 RLHF 训练信号的可能性。
