长任务最诱人的评测方式，是给 Agent 一个任务，等它跑完，再由另一个模型阅读轨迹打分。这样很容易得到一个整齐的总分，也很容易把真正的问题藏起来：环境可能已经被改坏，评审模型却被流畅解释说服；模型可能在第十步完成任务，随后又用九十步把结果破坏；某次成功依赖测试泄漏或人工接管，却与自主完成放在同一列。 Long-Horizon 评测需要把「结果是否正确」「过程是否守约」「状态是否可信」「失败后能否恢复」分开。最终答案仍然重要，但它必须由环境中的可执行证据支撑，并且与任务版本、工具权限和资源预算绑定。
1. 结果证据与恢复基础
Long-Horizon 评测需要固定被测系统和验收对象。模型、Harness、环境、任务与预算任何一项变化，都可能改变结果含义。
终态成功仍是主指标，但必须与中间有效进度共同报告。运行记录可以同时生成可执行验收结果与进度曲线。
评测对象先固定，一次完整运行可以记为
是初始任务和环境， 是 Agent 动作， 是工具或环境观测， 是结束状态。报告结果前需要固定五个对象：
- 模型：具体 checkpoint、推理参数、上下文长度和是否允许隐藏思考。
- Harness：系统提示、记忆、压缩、计划器、工具 schema、重试和终止规则。
- 环境：容器或虚拟机版本、初始文件、依赖、网络状态和随机种子。
- 任务：目标、不可违反约束、可接受的多种解和验收脚本。
- 预算：token、工具次数、墙钟时间、计算费用、并发数和人工介入。
只写模型名不够。相同模型在能保存 checkpoint、能运行测试的 Harness 中，与只能在聊天窗口输出补丁的系统不是同一个被测对象。相同任务若环境镜像不同，也可能因依赖版本变成另一道题。
最终成功必须可执行，设任务有 个验收条件 ，每个条件由环境检查器返回 。严格成功率可写为
只要有一个硬条件失败，整体就不算完成。为了观察接近程度，还可以报告加权部分成功：
两者需要同时存在。只报严格成功看不出系统卡在哪里；只报部分分数又可能让 9 个容易检查掩盖 1 个关键安全约束。硬约束应单独列出，不能用其他得分抵消。 验收器也会错。代码任务的单元测试可能覆盖不足，网页任务的 DOM 检查可能忽略视觉遮挡，研究任务的引用存在不代表结论被来源支持。可靠 benchmark 会把检查器分层：语法与文件检查、功能测试、隐蔽测试、状态不变量和少量人工复核。评测结论的上限受验证器质量限制。
1.1. 轨迹中的有效进度
把任务拆成依赖节点 ，节点 有权重 ，只有在其验收条件通过后才算完成。第 步的已验证进度为
应允许下降：后续动作破坏了已有结果，相应节点要从完成集合移除。只让进度单调上升，会把失效的旧测试永久记成成功。事实状态必须与环境版本关联，任何写入都可能让相关检查过期。 由进度曲线可以得到几项有用指标：首次达到 50% 或 90% 的步骤数；任务结束时的有效进度；重复完成同一节点的次数；进度倒退面积；已经偏离目标后继续消耗的动作。它们能区分“稳定推进但末步失败”和“长时间无效探索后偶然成功”。
例如两个 Agent 都在 20 步完成。A 的进度为 后保持；B 在 与 之间多次往返，第 20 步才到 1.0。最终成功相同，B 的状态稳定性和资源效率明显更差。若真实任务预算稍微收紧，二者成功率会分化。
难度控制与恢复，一组笼统的长任务无法说明系统从哪里开始失稳。评测需要把 horizon 做成可控自变量，并主动改变依赖、验证延迟和环境状态。
恢复实验还要覆盖目标变化。系统是否及时接纳新要求，与它能否从文件或工具故障中恢复，是两类相关但不同的能力。
让 horizon 成为自变量. 评测 Long-Horizon 不能只给一组“很长”的任务，应构造可控难度曲线。结构侧改变依赖深度 、同时存活的约束数量与环境状态规模；反馈侧改变验证延迟 、工具故障与观测噪声；控制侧改变不可逆动作比例、目标变更次数与可用预算。 在其他条件近似固定时，画成功率 随 horizon 难度 的曲线，比混合平均分更有解释力。可以定义某个阈值能力，例如成功率首次低于 50% 时的 ，但必须说明 的构造。单纯用轨迹 token 数当 ，会奖励冗长系统。
任务还要包含“短而深”和“长而浅”两组。若模型只在长而浅任务表现好，说明它能维持较长对话或批量调用，却没有解决深依赖。再加入相同任务的不同表述和环境布局，避免模型记住固定模板。
状态扰动与恢复实验. 真实长任务不会一直沿理想路径运行。评测应主动注入可控扰动：工具超时、文件被并发修改、网页元素变化、依赖安装失败、用户新增约束、先前事实失效。每个扰动记录注入点 、首次检测点 和恢复点 。 检测延迟为
恢复成本可按额外动作、token 或墙钟时间计算：
是知道扰动位置的参考恢复成本。系统从未发现扰动时， 记为截断值并单独统计漏检率，不能用平均检测延迟把它忽略。 一个完整恢复还要检查三件事：错误影响是否清除；扰动前的有效成果是否保留；事实表和计划是否与恢复后的环境一致。把文件回滚了却仍在记忆中保留“新版本测试通过”，属于环境恢复而认知状态未恢复，后面仍会再次出错。
目标变化不是额外一句提示. 在第 步插入新用户要求时，评测器先标注它与旧目标的关系：补充、收窄、替换、优先级调整或冲突。系统要更新目标版本，并使后续计划引用新版本。可以记录：
- 接纳延迟：收到新要求到首次产生符合要求动作的步数；
- 旧目标残留：新目标生效后仍为已取消要求执行的动作；
- 冲突检测率：新旧约束矛盾时是否停止并暴露冲突；
- 产物迁移成本：已有成果中能复用多少，必须撤销多少。
如果新消息只是被追加到长上下文，模型可能同时记住两个版本，却没有明确哪个有效。测试应故意把旧要求放在更显眼或更靠近系统提示的位置，检查目标状态是否真的版本化。
1.2. 约束、指标与实验协议
完成任务不能抵消过程中的硬约束违反。评测必须在动作发生时记录权限、副作用和人工介入，而不是只看最终文件树。
资源预算与数据污染同样会扭曲比较。成功率需要与成本曲线一起报告，公开任务还要控制答案泄漏风险。
约束、安全与副作用，约束遵守率不能只在最终产物检查。假设规则禁止写某目录，Agent 曾经写入后又删掉，最终文件树看似合规，过程仍发生了越权副作用。评测 Harness 应在动作执行点记录被拒绝、成功和补偿的操作。 将约束分为硬约束 与软偏好 。硬约束任何一次违反都记失败；软偏好可以按次数和严重度计成本。对可逆写入，还要区分“先做后撤销”和“从未做”，因为外部系统可能已经触发通知、构建或计费。
人工介入也必须进入结果。可以把运行分成完全自主、仅批准高风险动作、提供事实纠正和直接接管四档。不同档位分别报告成功率，不能把人工修正后的轨迹当作模型自主能力。
成本与能力一起画，长任务很容易通过增加采样、子 Agent、重试和上下文获得更高成功率。因此每个分数都要绑定预算。总成本可以拆成
其中副作用成本包括需要撤销的写入、重复外部请求和资源占用。不同单位不必强行折成一个货币数，可以分别报告并画 Pareto 前沿。 比较两个系统时，至少给等 token、等墙钟、等工具调用和各自默认配置四组结果。一个系统用十倍 rollout 获得更高成功率，可以是合理工程选择，却不能表述成无条件能力提升。终止策略也属于系统：过早停止降低成功率，无限重试则让成本失控。
2. 防止 benchmark 被“做熟”
长任务环境往往包含开源仓库、公开 issue 和固定测试。训练数据可能已经出现题目与答案，Agent 还可能在网络上搜到现成补丁。协议应记录网络权限，设置不可公开的环境变体，并通过参数化任务改变文件名、数据值和依赖关系。 验证集与开发集要按任务模板或仓库划分，而不是只随机划分实例。否则模型或 Harness 可以针对同一模板调出专用策略。环境生成任务还要检查生成器是否把答案泄漏进日志、文件名或错误信息。
可复现运行至少保存初始镜像哈希、任务版本、工具定义、模型与 Harness 配置、随机种子、完整动作日志和验收器版本。网页与在线 API 难以冻结时，应保存关键响应或提供可重放代理。没有这些信息，失败无法定位，成功也无法确认来自哪一个环境。
指标体系与现有基准，拆开终态、过程、恢复和资源以后，需要一张统一结果表承载它们。现有基准则提供了不同的长度与验证口径。
人类完成时间、软件终态和密集子任务评分各自回答不同问题。把它们放进同一坐标系，才能避免用一个数字替代全部长程能力。
一张可执行的结果表. 最终报告可以按下列结构组织：
| 维度 | 指标 | 证据来源 |
|---|---|---|
| 最终结果 | 严格成功、部分进度 | 环境验收器、隐蔽测试 |
| 约束 | 硬违规次数、软约束成本 | 动作网关与审计日志 |
| 状态 | 过期事实、目标版本错误 | 状态快照与环境版本 |
| 过程 | 无效动作、重复工作、进度倒退 | 依赖节点与轨迹 |
| 恢复 | 检测延迟、恢复成本、漏检率 | 注入扰动的已知位置 |
| 资源 | token、工具、时间、计算、人工 | 系统计量 |
| 长度曲线 | 不同依赖深度下的成功率 | 分层任务集 |
这张表依然不能穷尽智能体能力，但它把最常见的混淆拆开了。一个系统可以最终成功率高、约束违规也高；可以短任务很强、horizon 增长后迅速崩溃；可以检测错误快、恢复成本却很大。只有把这些曲线放在一起，才能知道下一步该改模型、记忆、Harness、验证器还是任务环境。 Long-Horizon benchmark 要让“长任务为什么失败”变得可测。排行榜只呈现结果，目标保持、状态一致、错误传播和恢复能力共同解释系统如何到达终点。
三类现有口径怎样放到同一坐标系. 现有基准常用三种「长度」口径，它们各有价值，却不能互相替代。第一类是人类完成时间。METR 的 Task-Completion Time Horizon先估计专业人员完成任务所需时间，再拟合任务时长与 Agent 成功概率的逻辑曲线。若任务 的人类时长为 ，Agent 成败为 ，可以拟合
其中 。50% time horizon 是令右侧等于 时的 。因为 ，所以
这个数不是 Agent 实际连续运行了多久。METR 自己也明确说明，它描述的是任务在人类尺度上的长度，以及系统以给定可靠率完成这类任务的能力。它直观、适合观察能力随模型代际变化，但依赖任务分布和人类时长估计；同样是两小时任务，状态规模、不可逆性和验证延迟可能差很多。 第二类是终态可执行的软件任务。SWE-bench Verified由 500 个经人工核验的实例组成，核心优势是可以在仓库与测试环境里判断补丁是否解决问题。它能可靠测最终软件修复，却没有因名称中出现 Verified 就自动成为长程基准：某些实例可能用很短补丁解决，某些需要较长探索。要研究 horizon，还需在同一任务上记录依赖深度、交互步数、进度和恢复。
第三类直接构造长终端任务。Long-Horizon-Terminal-Bench包含 46 个任务，并把任务拆为可评分子任务，因而能给出密集的中间进度；论文报告的运行规模达到每任务平均约 231 个 episode、9.9M token 和 85.3 分钟。这里的数字只属于该论文的实验设置，不能外推为所有长任务的门槛。它的重要变化是把「最终有没有过」扩为「推进到了哪里」，从而减少稀疏终局奖励遮住过程差异的问题。
把三类口径放在一起，可以得到较完整的描述：人类时长提供直观难度轴，可执行环境提供可信终态，细粒度 verifier 提供过程进度。缺任何一项都仍可做有效评测，但结论范围要相应收窄。报告「8 小时 horizon」不能直接推出系统能自主工作 8 小时；报告「通过 60% issue」也不能直接推出它能维护 60 步状态；报告「调用 200 次工具」更不能推出这 200 步存在深依赖。
从事件日志重建指标. 长程指标不应主要依赖运行结束后的回忆，而应从事件日志计算。最小事件结构可以写成
pre 与 post 是动作前后的环境标识，evidence 保存退出码、测试结果或人工批准，goalVersion 表示动作依据哪版目标。若工具产生外部副作用，还要记录幂等键或可追踪 ID。由这些事件可以重建环境变化，也可以发现模型文本与实际执行不一致。 假设一项任务有 5 个等权子目标，Agent 在第 2、4、7 步分别通过前三项，第 9 步的修改破坏了第二项，第 12、15 步通过余下两项并修复第二项。进度曲线关键点为
若只保存每项「曾经通过」，第 9 步后仍会错误显示 。正确做法是让 verifier 结果绑定环境版本，并在相关文件变化后将旧结果标为过期。由式 (11) 还能算进度倒退幅度 、首次满分步数 15，以及至少一次返工。 无效动作也要给出可复算规则。一种保守定义是：动作既未改变环境、未产生新证据、未缩小待选集合，也未满足必要的信息收集条件，则记为无效。重复读取同一文件未必无效，因为并发修改后重新读取是在验证状态；相反，连续执行同一失败命令而输入与环境均未变化，通常是无效重试。规则必须结合前后状态，不能只按命令字符串去重。
实验设计与统计报告，扰动实验只有在基线与干预条件可比时才有解释力。配对设计控制任务差异，重复运行与区间估计控制采样噪声。
这些要求还需要写成可以执行的流程。恢复放大率、pass@k 边界和六阶段协议分别约束恢复成本、采样口径与实验顺序。
扰动实验的配对设计. 恢复能力最好用配对实验测量。同一任务、模型、Harness 和随机种子分别运行无扰动基线与扰动版本，只在预定步骤注入变化。若基线成本为 ，扰动运行成本为 ，且 oracle 已知扰动后最小必要成本为 ，可以报告恢复放大率
表示额外成本接近已知最小值，大于 1 表示检测、回滚或重放产生额外浪费。若任务最终未恢复，不应用一个很大的任意常数混入均值，而应同时报告恢复成功率，并对成功样本的成本单独统计。 扰动至少覆盖四类。状态扰动修改文件、数据库或网页；观测扰动制造截断输出、延迟和临时错误；目标扰动追加、替换或冲突用户要求；执行扰动让动作部分成功。执行扰动尤其重要：命令可能修改了前三个文件后失败，HTTP 请求也可能服务端已执行却在客户端超时。若 Harness 把「返回错误」等同于「什么都没发生」，重试会扩大副作用。
为避免扰动强度失控，每项应说明注入位置和影响范围。例如「第 20 步后把一个尚未读取的注释改掉」几乎不构成测试；「在依赖该配置的三个动作完成后修改配置值」才会检验过期事实检测。扰动也不能总发生在固定步数，否则 Harness 可能学会定时检查，而非依据事件触发验证。
统计报告不能只给一次运行. Agent 运行含有采样、工具波动和环境噪声，同一任务一次成功不足以稳定估计能力。对每个难度桶运行 次，成功数为 ，点估计为
当 很小时，只报 会制造虚假的精确感。报告应给二项比例区间，或用 bootstrap 对任务和运行两层重采样。若 10 次里成功 6 次，写成「60%」不能表达不确定性与 100 次里成功 60 次相同。不同系统还应使用相同任务与种子做配对比较，以减少任务难度差异带来的方差。 pass@k 需要谨慎。它回答「给系统 次独立机会，至少一次成功的概率」，不等于一次自主运行的可靠性。若单次成功率为 ，理想独立假设下
取 ，结果约为 。四次采样把成功机会提高很多，也把 token、计算和外部副作用最多放大四倍；多次运行还可能相关，使理想公式高估收益。因此 pass@1、pass@k 与总预算应并列，不能只挑最好看的列。 比较不同 horizon 桶时，还要防止幸存者偏差。长任务若只由短任务中成功的实例扩展而来，样本会系统性偏向某些领域；若只分析最终成功轨迹，最值得研究的失败传播又被丢掉。任务采样规则、排除原因和中止轨迹都应保留。
一份可以直接执行的协议. 实际落地可以按六个阶段进行。第一，冻结任务定义、环境镜像、目标版本和硬约束。第二，根据依赖图标注子目标、关键前提与 verifier，并对每个检查声明何时会失效。第三，在无扰动条件下运行基线，保存全部动作、观测和环境版本。第四，按预注册方案注入状态、观测与目标扰动。第五，从事件日志计算严格成功、有效进度、违规、检测延迟、恢复放大率和资源成本。第六，按依赖深度与验证延迟分桶，报告多次运行的区间而非单个平均数。
每项结果还应带一个负面边界。例如 METR 的人类时长主要来自其任务分布，不能直接代表所有职业；SWE-bench 的可执行测试不能覆盖未被测试表达的用户意图；LLM judge 即使与人工有较高一致性，也可能在新领域或更长轨迹上漂移。HORIZON使用跨领域轨迹诊断并校验 judge 与人工的一致性，这比无校准的印象分更可靠，但仍不能把 judge 输出当成环境事实。 评测报告应回答一个简单问题：若系统得分提高，究竟是单步策略更准、状态保存更好、验证更密、恢复更快，还是预算更大？不能回答时，总分只能说明某个完整配置在某批任务上更强，无法定位 Long-Horizon 能力的具体进步。明确适用范围，下一轮改进才有对象。
2.1. 可执行指标与基准生命周期
METR 的 time horizon 用人类专家完成时间作为任务难度代理，并在 上拟合逻辑曲线。假设某个 Agent 的拟合参数为 ，由式 (9) 得：
若时间单位是小时，50% horizon 约为 7.39 小时。80% 成功对应 logit 值 ，因此：
同一模型的 80% horizon 明显短于 50% horizon，这符合可靠率提高后能力边界向短任务收缩的直觉。数字只是演算，不能当成任何真实模型结果。METR 官方页面还提醒，当前任务套件主要来自软件工程、机器学习和网络安全，并将超过 16 小时的测量标为不可靠；任务范围与可测区间都属于指标定义的一部分。 人类时间本身也有不确定性。METR 对多数任务使用成功完成人员用时的几何均值，原因在于完成时间往往右偏。若三位专家分别用 2、4、16 小时，算术均值为 7.33 小时，几何均值为：
哪一个更贴近「典型专家」取决于数据生成过程。评测报告应保存原始用时、估计方式与失败尝试的处理规则；只留下一个时长标签，会让后续 logistic fit 看起来比输入事实更精确。
LHTB 的密集奖励怎样解读，Long-Horizon-Terminal-Bench 官方论文与仓库公开了 46 个任务，覆盖九类终端工作流，并用细粒度子任务产生部分奖励。论文同时报告两个 pass@1 阈值：partial reward 至少 0.95 时，最强被测模型为 15.2%；要求 reward 恰好为 1.0 时为 10.9%。两个数字之间的差距说明，一部分轨迹已经非常接近终点，却仍有验收项没有完成。 假设某任务有四个子目标，权重为 ，某次运行通过前三项，密集奖励为：
这个 0.6 只在子目标确实可独立验证、权重有清楚含义时成立。若收尾阶段一项是「系统能够启动」，前三项都只是必要准备，那么 0.6 不代表用户得到了六成可用产品。密集奖励适合比较过程进展，严格成功仍应由全部硬条件决定。 部分奖励还要绑定状态版本。某子目标在第 20 步通过，第 80 步被后续修改破坏，最终 reward 不能继续保留那部分分数。Verifier 若只记录「曾经通过」，长轨迹越长越容易积累虚假进度。每个子目标应保存最近一次验证所对应的产物哈希，相关依赖变化后转回 pending。
截断、超时与删失. 长任务比短任务更容易撞上时间、token 或工具调用上限。把所有超时都算普通失败，会混合两种情况：系统已经走错，与系统仍在推进但预算先结束。后者在统计上属于右删失，至少要单独报告。 设任务上限为 ，轨迹在 时仍未终止。报告中保留终止原因、当时进度 与最近若干步的进度斜率：
表示轨迹仍在推进，增加预算可能有收益； 表示它早已停滞。两者的严格成功都为 0，但诊断含义不同。排行榜仍可按统一预算计算 pass rate，研究报告则应把截断状态展开。 预算扩大也可能掩盖低效。比较系统 A 与 B 时，若 B 获得两倍 token 和四倍工具调用，成功率提高不能直接归给架构。可以画预算曲线 ，并计算达到目标成功率 所需的最小预算：
系统在所有预算点都领先，证据最强；曲线交叉则说明各自适用区间不同。只给一个最大预算点，会漏掉前期效率和边际收益。
Verifier 也要接受评测，自动验收给 long-horizon benchmark 带来可重复性，也可能成为新的误差源。Verifier 假阳性会奖励投机，假阴性会惩罚等价解法；验证器崩溃若被记成任务失败，又会把基础设施问题算到 Agent 头上。 构造任务时，可以给 verifier 准备三组校准样本：参考解应稳定通过；删掉关键功能的扰动解应稳定失败；不同实现但语义等价的解法也应通过。重复运行还能检查是否存在残留状态。若同一产物第一次通过、第二次失败，环境清理或 verifier 幂等性有问题。
设人工复核样本中，Verifier 对成功产物的召回为 ，对失败产物的召回为 。二者必须分别报告，因为总体准确率受成功/失败比例影响很大。100 个样本里只有 5 个成功，验证器把全部判失败仍有 95% 准确率，却完全失去衡量能力进步的价值。 LLM judge 适合处理开放语义，但必须保存 rubric、模型版本、采样参数和被评文本。可以让人工在分层样本上估计一致性，并把不确定项交给复核。环境中已有可执行事实时，应优先读取事实；让 judge 猜测试是否通过，只会把确定问题重新变成语言判断。
长度分桶与配对置信区间. 任务分桶时只按人类时长容易混入领域差异。可以同时按依赖深度 、验证距离 与不可逆风险 分层，再在层内比较系统。样本有限时不必切出几十个小格子，至少应保证所谓「更长」的一组确实在目标维度上增加，而不是恰好换成另一类更难领域。 两套系统在相同任务与种子上运行，可为每对结果定义差值 。平均差为：
对任务进行配对 bootstrap，能够保留同一任务的难度关联。若还包含多次随机运行，可以先在任务内重采样运行，再重采样任务，形成两层区间。把所有 episode 当成完全独立样本会低估不确定性，因为同一任务的多次运行共享环境和 verifier。 结果表还应给任务级散点。总平均上升可能来自少数任务大幅改善，同时多数任务略降；长程系统常见这种重尾分布。逐任务差值、终止原因和恢复事件让读者能看出增益来自普遍稳定，还是某几个特别适合该 Harness 的案例。
2.2. 一条基准任务的生命周期
可靠 benchmark 从任务提案开始就要版本化。作者先给出目标、初始环境、硬约束与参考完成态；另一位维护者在干净环境中复现；Verifier 用参考解、错误解与扰动解校准；任务随后冻结镜像、资源哈希和网络策略。公开运行时，每条轨迹从相同 checkpoint 启动，完成后由独立进程验收，原始事件日志和最终状态一同保存。 任务升级也要留痕。依赖包下架、网站更新或隐藏测试修复都会改变难度。新版结果不能静默混入旧排行榜，应给 task version 与 verifier version，并在一段重叠期用相同 Agent 同跑两版，估计版本偏移。基准活着并不等于数字可以跨版本直接拼接。
这条生命周期也解释了为何 Long-Horizon 评测成本高。任务必须能运行很久、稳定复位、密集验证，还要容纳失败后的部分状态。减少成本可以依赖容器缓存、增量 checkpoint 和分层抽样，却不能省掉环境隔离与终态验收；省掉这两项后，跑得再多也只是在批量生成难以解释的轨迹。
成本归一化的能力比较，长任务系统可以用更多采样、重试和模型角色换成功率。这个结果有价值，但资源消耗必须一同公开。对运行 ，总成本可以按部署场景折算：
是 token， 是计费工具调用， 是计算时间， 是人工介入时间。不同团队的单价不同，原始用量与折算单价都应保留；只给一个美元总数会随供应商价格变化而失去可比性。 最直观的指标是每个严格成功的平均成本：
10 次运行共花 100 单位，成功 4 次，。若另一系统花 160 单位、成功 8 次，成功率更高且 ，它在两项上都占优；若花 300 单位成功 8 次，则形成质量与成本的取舍。失败运行也计入分子，因为生产系统无法事先知道哪次会成功。 人工介入不能记成免费工具调用。用户补充原本缺失的信息，与评测人员替 Agent 修复错误，性质不同：前者属于任务输入，后者属于系统恢复成本。报告应记录提问次数、等待时间、人工操作内容，并说明它是否计入成功条件。一个系统靠维护者在关键节点接管，不能与完全自主运行直接放在同一列。
可靠率—预算前沿. 把不同预算下的成功率画成点集，可取 Pareto 前沿。某配置若成本更高、成功率反而更低，就被另一配置支配；未被支配的点展示可用选择。前沿还能比较重试与单次强模型：四次便宜采样或许提高 pass@4，却产生四份外部副作用风险；一次昂贵模型可能成功率相近、状态更容易管理。 对高风险任务，还应把约束违规作为第三个轴。成本低、成功率高但偶尔越权删除数据的系统，不会因为二维前沿漂亮就适合部署。可以先设硬门槛，例如零严重违规，再在合格配置中比较可靠率与成本。
预算曲线要使用相同停止规则。系统 A 达成验收后立即停止，系统 B 仍继续运行二十轮，B 的额外成本属于其 Harness 行为；评测器强制在首次成功时统一截断，则测的是达到目标的最短观测成本。两种口径都可以，必须提前声明。
评测产物的最小发布集. 一个可复核结果至少发布任务与 verifier 版本、Harness 配置、模型端点、采样参数、预算、逐任务结果、终止原因和资源用量。涉及隐私或闭源环境时，可以不公开完整轨迹，但仍应提供事件 schema、聚合故障类别和足以复算表格的匿名记录。 排行榜数字还应链接到不可变 manifest。Manifest 保存容器摘要、代码 commit、数据集 revision 与检查脚本哈希；同名模型或 latest 镜像都会随时间变化，不适合作为实验身份。若某项因服务下线无法复现，结果可以留作历史记录，但要标明外部依赖已经失效。
失败样本也要保留。只发布成功轨迹会让后来者无法研究目标漂移、重复副作用和恢复瓶颈，也容易高估数据质量。失败轨迹按 task failure、timeout、environment error、verifier error 与 policy violation 分桶，训练者才能决定哪些能作为负样本，哪些只是基础设施噪声。
超时、基础设施失败与删失. 固定墙钟或最大步骤下，未完成轨迹不全是同一种失败。模型可能明确走入死路，也可能仍在推进但预算截止；环境还可能崩溃、网络超时或验证器不可用。把它们统一记零分，会混淆策略能力、速度与基础设施可靠性。 令完成时间为随机变量 ，预算为 。成功轨迹观察到 ，预算截止只知道 ，属于右删失。随预算变化的累计成功函数
比单一截止点成功率提供更多信息。某系统很快解决简单题后进入平台，另一个起步慢却随预算稳定增长，二者可能在某个 恰好同分。 基础设施失败要单列事件类型。若失败与任务难度独立，可以从策略成功率分母中剔除并报告有效样本数；若困难任务更容易耗尽内存或触发超时，剔除会产生选择偏差。此时需要修复环境、重放相同任务，或使用失败概率加权，不能默认缺失随机。
重试规则也会改变分数。环境失败自动重试、策略失败不重试是一种协议；两者都允许重试则测多次尝试能力；只保留最好一次会高估单次可靠性。报告必须写明每类失败是否消耗预算、是否继承状态以及最终怎样聚合。 对未完成但已有部分进展的轨迹，可以报告验收条件完成比例，却不能把它当作最终成功的无偏代理。容易条件通常先完成，最关键的一项可能始终为零。部分分数需要保留条件权重与依赖关系，避免十个低价值检查掩盖一个阻塞项。