失败请求提前返回，评测报告漏记已经消耗的用量

2026 年 7 月，一次结构化输出消融实验的复跑中暴露了评测链路的记账缺陷：流式硬失败的 case 在结果记录里丢了用量字段。缺陷不影响用户，但成本统计和失败分析都会失真。

现象

复跑的结构化输出模式失败率很高，开发和保留两个数据集的校验失败率都在九成上下，这是实验本来要回答的问题。核对结果时发现了另一个问题：流式硬失败的 case 结果记录里没有用量字段，失败调用发生了，报告里记的却是零 token、零耗时。

排查

报告里先看到的是大量失败 case 的用量字段为零。零 token 有两种可能：请求没跑起来，或者请求跑了、消耗在记录环节被丢掉。同一轮实验里两类都存在：供应商不可用导致的失败，请求根本没发出去，记零是对的；要查的是另一类——流式请求已经开始了，报告里还是零。

区分两类的依据是请求快照。对照三样东西：报错的那条流、请求快照、最终写进报告的 case 记录。请求快照里已经有消耗的 token，case 记录却是零，说明消耗真实发生，丢在从快照抄到 case 记录的这一步。顺着 case 结果的构造路径查，定位到评测运行器的流式硬失败返回分支：这条分支在构造 case 结果时直接返回错误，没有先读请求快照。正常走完的 case 用量记录不受影响，缺陷只在这条提前返回分支上。

根因与修复

根因在评测运行器的返回顺序：流式硬失败的提前返回路径在构造 case 结果时没有先取请求快照，已经消耗的 token 和耗时随错误路径被丢弃。

这个缺陷是这次复跑第一次暴露的。流式请求一旦建立，token 和耗时只累积在请求侧，case 结果里的用量字段是从请求快照抄过来的；硬失败分支跳过了读快照这一步，已经消耗的量就随错误路径被丢掉。请求快照在报错后仍然可取，所以修复把读取提到返回错误之前：先读快照，再返回流式错误，失败 case 就保留了完整用量（提示、缓存、补全、总 token 和耗时）。有一条专门的单测覆盖这个行为。此前用旧行为跑出的三个运行目录作废，不混入后续统计；其中一个目录是发现记账缺陷后中途停掉的，其余跑在修复之前，里面的失败用量都不可信。

验证

修复后的最终复跑，两个数据集的"零 token 失败"都降为零。评测命令、全量测试、合同测试和集成测试均通过。数据集规模为每个数据集 18 个 case、每模式重复 5 次。

这次消融实验还回答了结束约束的问题：更严格的结束约束没有稳定提高质量，还增加了失败和耗时，所以没有切换到强制策略。

这份记录是历史快照，实验运行目录已删除，指标不再重新生成。