许多 AI 编程基准主要检查代码是否通过测试。来自佐治亚理工的研究者提出 RigorBench，进一步评价智能体如何规划、验证和纠错。在使用同一底层模型的 100 个任务中，Agent-Skills、Superpowers 两种智能体运行框架的过程得分与基线相近；要求前置规划的 Agent-Rigor 过程得分相对高约 33%，结果质量得分则从 0.64 升至 0.83。作者将其定位为探索性研究，这组比较仍需独立复现。
现有结果评分较少反映代码开发过程
论文首先对现有 AI 编码基准做了系统梳理：HumanEval、MBPP、SWE-bench、BigCodeBench、LiveCodeBench、DevBench、ProjDevBench、Terminal-Bench、AgentBench。作者认为，这些基准主要衡量产出，没有纳入其关注的工程过程指标。
作者用了一个直白的类比：Agent A 读了错误日志、提出假设、写针对性修复、补了回归测试并验证通过。Agent B 连续尝试了五种 patch，每次都跑测试看结果，最终撞上一个能通过的——但不知道为什么会通过，也没加任何测试。只按最终测试结果评分时，两者可能得分相同，但 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 在各步骤之间，代码库能否保持编译通过？已有测试是否由通过变为失败？每次提交是否围绕单一逻辑变更，并写明提交说明？
测试断言密度（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.83 对 0.64，相对增幅约 30%。这是结果质量综合得分，包含测试通过、功能完整性和回归情况，不能直接视为通过任务的百分比。但论文同时坦承：在单一 harness 内部，过程得分与单次任务结果之间的相关性不显著（Agent-Rigor 内部 r=0.12，Baseline 内部 r=0.05）。因此，框架间的得分差异不能直接证明过程纪律导致了结果改善，也不能预测每项任务是否因此获益。
规划增加了前期工作，总 token 消耗仍低约 12%
虽然 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 也频繁「过度自信」——模型仍倾向继续执行，未能可靠识别任务无法完成。
作者兼任框架开发者，样本和 AI 评分也有限制
论文列出了多项限制，其中两条直接影响结果解读：
利益冲突：两位作者同时是 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 尝试把人类软件工程中的过程要求——从 Humphrey 的 PSP 到 CMMI 所关注的实践——转化为 AI 编程智能体可比较的指标。这为最终代码测试提供了补充。
Claude Mythos Preview 在 SWE-bench Verified 上的报告成绩已达 93.9%。较高的测试通过率仍不能说明开发过程是否可靠：同样达到 90% 的 agent，通过反复试错完成任务，还是经过规划、验证和逐步修改，可能留下不同的维护风险。
论文和基准已完全开源，包括 100 个任务、评分标准和轨迹分析工具。研究者计划扩展到 100+任务、覆盖数据科学和移动开发等领域，并探索将过程纪律指标作为 RLHF 训练信号的可能性；如何防止模型只迎合过程评分，同样需要验证。
