读懂 issue
任务结果中的每个 attempt 都保存issues 列表；没有未解决的问题时为 []：
完整的 traceback 和异常链保存在同一 attempt 的
artifacts.execution_diagnostics 中。issue 与分数相互独立：带有 ERROR 或 WARNING 的 attempt 仍可能包含有效的 Benchmark 指标。
attempt 的 status 由其 FATAL 和 ERROR issue 所在的阶段推导：位于 setup、run 或 collect 时为 run_error，位于 evaluate 时为 eval_error，两者都有时为 run_error_or_eval_error。只有 WARNING 的 attempt 保持 completed。用 status 判断 attempt 在哪里失败，用 severity 判断失败有多严重。
失败如何分级
各组件在失败实际发生的位置分级，因此同一种异常在不同位置可能有不同的严重级别。
各 Benchmark 或 Harness 特有的分级见对应的组件页面，例如哪些 Judge 响应视为无效。
Judge 与验证器
依赖 LLM Judge 评分的 Benchmark 在 Judge 失败时无法得到有效观测。Judge 请求失败，或响应不符合约定的输出格式（例如 JSON 无效或缺少评分字段）时记为 FATAL，而不是判为答错。 Benchmark 自有的验证器（例如测试脚本）则不同。奖励缺失或无法解析时，任务按失败或0 计分，并记录 WARNING。可确认的受信验证环境准备失败（例如无法准备评测 Environment）仍为 FATAL。
超时与上限
Harness 接收 agent 执行预算，并把自身超时报告为 ERROR。如果 Harness 在该预算加run_timer_compensation_seconds 内仍未停止，runtime 会终止它并记录 ERROR run_failed。被终止的 Harness 未写完的占位文件不会额外产生 FATAL。
Harness 因轮次或步数上限结束时记录 ERROR harness_max_iterations；无法确认上限类型时记录 harness_limit_reached。无论超时还是达到上限，AgentCompass 都会继续收集输出并评分。
evaluation_timeout_seconds 到期时，runtime 记录 ERROR。部分 Benchmark 为这种情况声明了失败分值，使任务计为失败，而不是缺少观测：
其他 Benchmark 保留缺少观测的状态。这些值只在 runtime 的评测超时到期时使用，不用于其他评测错误或取消。
重试失败的工作
哪些 issue 会重试
max_retries 设置每个逻辑 attempt 的额外执行次数，setup、执行、收集和评测共享这份预算。默认值为 0，即任何失败都不重试：一次瞬时故障（例如 Judge 返回一次 HTTP 503）就会留下最终 FATAL，使该任务失效并导致运行失败。建议设置 max_retries: 2 以容忍瞬时服务故障。
模式搜索每个 issue 的 message 和 code，不搜索 traceback。未填写、null 或空的 retry_pattern_list 只重试 FATAL。
旧版本在模式列表未填写或为
null 时重试所有错误，为空列表时不重试。现在两者都只重试 FATAL。如需重新重试所有 ERROR，请将 retry_pattern_list 设为 [".*"]。--timeout-seconds 时限不会触发重试：runtime 不再启动新的重试，并释放已打开的资源。
重试会重复什么
重试替换当前逻辑 attempt 内的工作，不增加评分样本数，也不会重跑已完成的其他 attempt。
每次重试都会把丢弃的结果写入
attempt-<n>/retries/，详见retry 详情。进度文件会记录 attempt_retry 事件，详见 progress.jsonl。
重试之间的等待
每次 runtime 重试都会先退避等待。retry_min_delay_seconds 默认 5，retry_max_delay_seconds 默认 60；两者须为有限正数，且最大值不小于最小值。退避基准从最小值开始，每次翻倍并在最大值处封顶，默认序列为 5 → 10 → 20 → 40 → 60 → 60 … 秒。实际等待均匀随机取本轮基准的 50%～100%，所以第一次默认等待 2.5～5 秒。整轮重跑和仅评测重试共享同一逻辑 attempt 的序列，新 attempt 或新 run 从最小值重新开始。
等待在必要的资源清理后开始，支持取消，计入整次请求的总时限，不计入运行或评测阶段的超时预算。整轮重跑等待时释放并发额度，仅评测重试沿用当前额度。进度阶段显示为 retry_wait，选定的等待时长记录在重试诊断与事件的 retry_delay_seconds 中。
失败对分数的影响
ERROR 和 WARNING 不影响 Benchmark 的有效观测。runtime 从不用 false 或0 填补缺失的观测；只有 Benchmark 自己会给出失败分值，例如上文的 WARNING 和评测超时情形。
任一逻辑 attempt 在重试后仍有 FATAL 时，整个任务失效。该任务在每个指标序列、类别和派生指标中都计为 invalidated，其观测全部不参与计算。每个序列满足 evaluated + unavailable + invalidated = total，error 单独计数。多次 attempt 如何归约见指标与聚合。
运行失败时
只要至少一个任务以最终 FATAL 结束，整次运行即为失败。AgentCompass 仍会写出全部结果文件：metrics.json将evaluation_failed设为true，所有正式value设为null。reference_value只用未失效的任务计算；没有可评分的任务时也为null。summary.md说明没有正式分数，并把其余数值标为参考值。agentcompass run以非零状态退出。在launch中，该请求标记为failed，其他请求继续运行，编排以partial_failure结束，退出状态为1。- 在 Python SDK 中，
run_evaluation抛出RuntimeError，消息中包含结果路径；launch返回OrchestrationResult，其中该请求标记为failed。
--reuse 重新运行，只重做失败的工作。如果任务只有 ERROR 或 WARNING，运行仍然成功并发布正式数值。
失败后的复用
--reuse 会按当前重试策略处理已保存的结果：
- 没有 FATAL、也没有匹配当前模式的 ERROR 的结果直接复用。
max_retries大于0时，带有可重试 issue 的 attempt 会重新执行，并占用当前预算中的一次重试。历史重试次数只作为记录保留。max_retries: 0时，失败结果原样复用；需要设置重试预算才能重跑。- 在
none或fresh评测模式下，如果只有评测失败，会恢复已保存的 agent 结果，不再重新运行 agent。
查找失败详情
按照排查运行失败中的顺序检查这些文件。