长程评测最诱人的数字是成功率，也最容易让人误判。一次运行通过了终态测试，无法说明中间有没有反复破坏再修复、Harness 是否替模型补全了关键动作，也无法说明系统遇到状态漂移后还能不能回来。反过来，一次失败可能已经完成大部分可验证工作，只是在收尾步骤碰到外部服务故障。若评测只留下一个比特，这些差别都会消失。
评测协议因此要同时保存终态和事件轨迹。终态回答任务是否完成，事件轨迹回答它怎样走到那里。每个事件至少绑定动作来源、目标版本、环境版本、前置状态哈希、观测、验证结果和耗时。这样才能从日志重建有效进度、无效动作、首次偏离位置、恢复次数和重复副作用。指标不必堆得很多，但必须能对应定义中的依赖、延迟、传播与恢复。
1. 基准先证明自己测到了什么
一个任务被命名为 Long-Horizon，不代表它真的含有长程依赖。把提示重复一百遍主要测检索耐久；把本可并行的子题串起来主要增加运行时间。合格任务需要让早期决策改变后期条件，并且最终验证器能检查这些条件是否持续成立。任务构造与基准生命周期从构念效度出发，讨论人类完成时间、可执行软件终态、密集子任务评分各自覆盖什么，以及公开题库被反复调参以后怎样维护新鲜度。
验证器本身也要被测。若它只检查文件是否存在，Agent 可以交一个空文件；若同一环境没有复位，后一条轨迹可能借用前一条留下的状态。参考解、故意破坏的解、无动作对照和扰动测试共同给出验证器的假阳性与假阴性边界。只有这些边界明确，成功率才有稳定含义。
2. 用干预解释改进来自哪里
长程系统由模型、上下文管理、状态存储、规划器、工具层和验证器共同组成。总分上涨以后，需要通过配对任务、冻结预算和单组件消融判断增益来自哪里。增加 checkpoint 若真改善恢复，应看到重复副作用和丢失工作量下降；增加规划器若真改善关键路径，应看到无效动作或回退深度变化。只给最终分数，无法排除额外计算和提示泄漏。
故障注入与结果归因把目标更新、工具超时、进程重启、环境漂移等事件按确定位置注入轨迹，再用配对统计比较恢复。它还讨论成本—质量前沿、删失、重尾任务和置信区间。两篇共同建立评估次序：先确认任务包含长程结构，再确认验证器可信，随后比较系统；看到改进后继续追问，是哪个组件改变了哪一个中间量。
3. 最小可复现实验
最小实验不需要先造一个持续数周的任务。选择一批具有明确依赖链的可执行任务，为每题固定初态和验证器，各运行若干随机种子。对照组使用基础 Agent，实验组只替换一个组件。随后在相同位置注入一次可恢复故障，记录最终成功、故障前有效进度、恢复后重复工作、额外 token 与墙钟时间。任务级配对差值比两组总均值更有解释力，因为同一任务的难度被抵消。若实验组只靠更多重试获得成功，成本曲线会暴露它；若恢复机制确实有效，受扰动任务的丢失工作量应下降，而未扰动任务不应凭空大涨。