面对一批 AlphaEval 失败样本，最忌讳的动作是先改 Agent 的提示词或逻辑。更稳妥的顺序是：先按错误类型分组看集中度，再打开单条失败用例的执行轨迹定位失败步骤，然后复跑区分偶发与必现，最后检查评测环境侧的依赖与配额。只有前三层都排除掉环境因素，剩下的才值得归因到模型或 Agent 逻辑。这个顺序的价值在于：它能让改动落点有依据，而不是凭第一眼印象去调参。

处理 AlphaEval 失败样本时，建议按“分组统计 → 单条轨迹 → 复跑验证 → 环境排查 → 写回标签”的顺序归因。分组用于看集中度，轨迹用于定位失败步骤，复跑用于区分偶发与必现，环境排查用于剔除机器、限流、外部服务造成的假失败。只有复跑稳定且环境项核对通过后，才把问题归到模型或 Agent 逻辑。边界是：归因结论依赖日志字段完整度和复跑条件一致性，字段缺失时应先补日志而非下结论。

先把失败样本按错误类型分组

逐条肉眼翻失败用例，容易在前几条就形成错误印象。建议先做一次机械分组，看失败是否集中在少数几类。分组维度通常取三个：异常类型（超时、连接错误、解析失败、断言不通过等）、耗时区间（正常区间、明显偏长、接近超时阈值）、工具返回码（成功、业务错误、网关错误、限流）。

分组后要看的不是“哪类最多”这么简单，而是看结果表里的几个信号：某一类是否占了绝大多数；耗时偏长的样本是否和超时类高度重合；工具返回码非成功的样本是否集中在同一个外部服务上。如果失败高度集中在工具返回码和耗时区间上，第一嫌疑在环境侧；如果异常类型分散但都指向同一个 Agent 决策步骤，才更像模型逻辑问题。

分组结果表示例（字段按你的日志实际列名替换）

error_type        count   p50_latency_ms   max_latency_ms   tool_status_dist
Timeout           38      11800            30000            timeout:38
AssertFailed      12      900              2100             ok:12
ParseError         7      1400             2600             ok:5, bad_payload:2
RateLimited        5      600              800              http_429:5

这张表的用途是决定下一步先查哪一层。构造分组脚本时，从评测结果文件里读原始记录，按上述维度聚合即可，不需要引入额外系统。验证方式是随机抽几条失败记录，确认它们被分到了预期分组里。

打开单条失败用例的执行轨迹

分组只能告诉你哪类多，定位失败发生在哪一步必须看轨迹。建议从失败最多的那一类里挑一到三条，打开完整执行轨迹，按字段逐项核对，不要只看最后一条错误信息。

• 原始输入：确认送进 Agent 的输入是否就是用例设计的输入，有没有被截断、转义或拼接错误。
• 工具调用参数：模型生成的参数是否合法，是否出现了空参数、类型不符、字段缺失。
• 工具返回：工具实际返回了什么，是业务错误、空结果，还是超时或连接失败。
• 耗时：每个步骤的耗时分布，失败步骤之前是否已有步骤接近超时阈值。
• 异常信息：异常是抛在工具调用层、解析层还是断言层，堆栈是否指向同一个位置。

核对时的判断规则可以保守一点：如果工具返回本身是错误码或超时，先把这条记为环境侧可疑，不要急着改 Agent；如果工具返回正常但 Agent 下一步给出的参数或断言明显偏离预期，才记为模型侧可疑。轨迹字段不全时，先补日志字段再下结论，不要在缺字段的情况下猜。

复跑失败样本，看是否稳定复现

单次失败不能说明问题。把分组里各类失败样本各抽若干条，用与原始跑分相同的配置复跑。复跑方式建议保留原始输入、原始工具配置和原始超时设置，只改变执行次数，这样才能判断是偶发还是必现。

复现次数的选择要看失败类型：超时和限流类建议多跑几次，因为这类失败本身受负载影响；解析失败和断言失败可以少跑几次，但至少要覆盖到能观察出规律。判定为稳定复现的标准建议是：在同一配置下多次复跑中每次都失败，且失败位置和异常信息一致；只要出现成功与失败交替，就先按偶发处理，不要归因到模型逻辑。

复跑记录表字段建议

case_id  run_index  result  error_type  failed_step  latency_ms  备注
case-001 1          fail    Timeout     tool_call    30000       与首跑一致
case-001 2          pass    -           -            4200        偶发倾向

复跑结果要落到表里，别只记在脑子里。稳定复现的样本进入模型侧排查队列，偶发样本先挂起，等环境侧排查完再回看。

检查评测环境侧的依赖与配额

很多“模型失败”其实是跑批环境没准备好。建议在归因前把下面几项核对一遍，全部通过再谈模型问题。

• 依赖版本：评测框架、工具依赖、运行时版本是否与上次正常跑分一致，是否有隐式升级。
• 超时设置：单步超时、整体超时、外部调用超时是否被调小，是否存在多层超时互相覆盖。
• 并发上限：跑批并发是否超过工具或外部服务的承受能力，是否触发了限流。
• 外部调用返回码：网关错误、限流码、连接重置是否在失败样本中集中出现。

核对方式以可观察证据为准：对比配置文件差异、查看服务端返回码分布、查看跑批机器的资源占用。如果发现超时被调小或并发超限，修正后重跑同一批失败样本，观察失败是否消失。这一步的目的不是优化性能，而是排除假失败，避免把环境问题误记成模型缺陷。

把确认过的归因写回样本标签

归因做完如果不写回，下一轮跑分还要重复同样的排查。建议在样本记录上增加归因标签，取值约定保持少而稳定，例如：model_error、env_timeout、env_rate_limit、env_dependency、flaky、unknown。标签要写在评测结果记录里，与用例 ID 绑定，而不是写在临时表格里。

标签写回示例（字段名按你的结果结构替换）

{
  "case_id": "case-001",
  "result": "fail",
  "error_type": "Timeout",
  "failed_step": "tool_call",
  "attribution": "env_timeout",
  "reproducible": false,
  "checked_by": "manual"
}

写回后，下一轮跑分可以直接按 attribution 过滤：先看 env_ 开头的标签是否仍然存在，再看 model_error 的样本是否集中在同一类任务上。这样每一轮的排查都从上一轮的结论出发，而不是每次从零开始翻失败列表。归因结论不确定时保留 unknown，比强行归到模型侧更安全。