PAST-Bench 的归因结论回答的是「在任务集覆盖到的场景里，失败主要落在哪一类因素上」，它并不回答「这个 Agent 整体行不行」。总分是聚合量，归因是分类量；聚合会把没覆盖的场景连同有覆盖的场景一起平均掉，归因不会，但归因的适用范围严格等于样本范围。所以拿到一份归因结果时，判断顺序建议是：先看任务集的覆盖清单，再看每条归因绑定了哪些证据，最后才看总分。

先做覆盖清单，再读归因结论。把任务集按场景类型拆成格子，数清每类样本量，把没有样本的格子显式标出来；每条归因结论用「结论 / 证据来源 / 覆盖场景」三列绑定到具体样本。归因只在其依据的场景类型和样本量内成立，覆盖不到的场景记为待补测项，不能拿来支持「这个 Agent 不行」的整体判断。

把任务集按场景类型列成覆盖清单

第一步不是看结论，而是把任务集拆成格子：先定分类维度，再数每类样本数，最后把没样本的格子标出来。常用维度有任务形态（单轮问答、多步工具调用、长上下文、需要澄清、失败后重试）、外部依赖（无、只读接口、有副作用写操作）、判定方式（精确匹配、状态断言、rubric 打分）。维度两三个正交即可，太多会把格子切碎到无法解释。

# coverage-matrix.yaml
dimensions:
  task_shape: [single_turn, multi_step_tool, long_context, clarify_required]
  deps:       [none, read_only, side_effect]
  verdict:    [exact_match, state_check, rubric]
grids:
  - {task_shape: single_turn,      deps: none,        verdict: exact_match, samples: 12}
  - {task_shape: multi_step_tool,  deps: side_effect, verdict: state_check, samples: 0}
  - {task_shape: clarify_required, deps: none,        verdict: rubric,      samples: 0}
# samples 为 0 的格子即覆盖空白，单独摘成待补测表

验证方式：按上面字段对样本分组计数，把 samples 为 0 的格子挑出来。如果你认为很重要、却没有一条样本的场景，就是归因结论不能覆盖的方向。

给每条归因结论标注证据范围

结论要能追到具体样本。建议一条结论一行，用三列同行记录，不要合并成一段话。

| 结论                 | 证据来源                                   | 覆盖场景                                  |
| 失败集中在工具参数拼装 | run_0421, run_0433, tool_call 参数校验失败   | multi_step_tool / read_only / state_check, N=2 |
| 澄清类任务表现不稳定   | 无对应样本，暂不外推                        | clarify_required, N=0                     |
| 长上下文下漏读约束     | run_0510 等 3 条                           | long_context / none / rubric, N=3         |

证据条目不足时不要空着，也不要写「表现不佳」这类没有主语的判断。用固定标注：样本量低于事先设定的下限就写「证据不足，暂不外推」，覆盖场景列写「N=0，见补测计划第几条」。这样报告里不会出现一条没有归属的结论。

识别结论被过度外推的三种情况

这三种在归因报告里最常见，识别信号都比较直白。

• 类型缺失：结论里出现的场景词，在覆盖清单里对应 samples 为 0。比如结论写「多轮澄清能力弱」，但 clarify_required 一行样本数为 0，这条结论没有支撑它的格子。
• 样本过少：某类场景样本数明显低于其他类，结论却按整类陈述。信号是结论用了「普遍」「总是」「不支持」这类量词，而证据来源只有一两条轨迹。这类最多写成「在现有少量样本中出现过」，不能写成能力判断。
• 判定口径只对单一场景成立：rubric 或断言脚本只在一种任务形态下标定过，换到长上下文或带写操作的场景就会误判。信号是同一结论在两种场景下给出的失败原因互相矛盾，或某场景的失败里大量是判定脚本报错而非任务本身出错。先把「判定失败」和「任务失败」分开统计，再决定这条结论算不算数。

把覆盖空白写成补测计划

空白格不能只标红色，要有下一步动作。补测任务选取建议按两条排序：先补影响判断方向的格子（例如你正准备下「工具调用不行」的结论，就优先补 side_effect 类），再补获取成本低的格子。每个空白格先规划一个最小批次，数量按项目里的统计习惯定，但要写进计划。

# 补测计划模板
- blank_grid: multi_step_tool / side_effect / state_check
  why: 支撑「工具调用能力弱」这条结论，当前 N=0
  tasks_planned: 从现有任务池筛出带写操作的多步任务，人工确认后纳入
  verdict_rule: 沿用同一套 state_check 断言，不因补测放宽判定
  after_run: 更新结论表中该行的 覆盖场景 / N / 是否可外推

判定口径要沿用，不能为了补齐空白临时改标准，否则补测样本和原有样本不可比。补测完成后需要更新：原结论的覆盖场景列、样本量，以及原本标成「证据不足，暂不外推」的条目能否解除标注。

在结论里写清适用边界

下面这段改掉占位符后可以直接放进报告，位置放在归因结论之后、行动建议之前。

本页归因结论基于任务集 {{任务集版本}} 中的 {{N_total}} 条样本得出，
覆盖场景类型为 {{场景列表}}，判定口径为 {{判定方式}}，各类样本量见覆盖清单。
结论仅适用于上述覆盖范围内的场景；
对未覆盖的场景（如 {{空白场景列表}}），本页不做能力判断，记为待补测项，
补测计划见 {{补测计划位置}}。
总分与归因分开看：总分不用于支持本条归因，归因也不用于推断未覆盖场景的表现。

写完这段再回查一遍：报告里每一条带能力判断的句子，是否都对得上覆盖清单里的某个格子。对不上的，要么降级成待补测项，要么删掉。