为什么 Coding Agent 评测需要 trace 和 replay

01核心判断CORE JUDGMENT

评测一个 coding agent，最终对外呈现的往往是一个数字：通过率、解题数、排名。但数字本身没有质地——比如同样一句"通过率提升五个点"，可能是真实的能力进步，也可能是环境泄漏、测试投机或统计噪声。区分这两者的唯一办法，是数字背后的每一次运行都能被打开检查。

所以评测系统的第一要求不是"算得快"，而是"留得全"：任务定义、环境边界、执行轨迹（trace）、产物和验证结果，五样都要保留。这五样齐了，任何一个可疑的结果都可以被回放（replay）审查；缺了任何一样，评测报告就从证据退化成声称。

这个判断对内对外同样成立：对外，它决定评测结果能不能说服别人；对内，它决定团队能不能从失败样例里学到东西——不能回放的失败，等于白白失败了一次。

第一种说谎方式是环境泄漏：答案藏在环境里——测试文件可读、历史提交可查、题目和训练数据重叠——agent 找到了答案，但不是通过解决问题。分数是真的，能力是假的。

第二种是测试投机：agent 修改测试让它通过、hardcode 期望输出、绕过而不是修复问题。验证器只检查了"测试绿了"，没检查"问题解决了"。这类通过在 trace 里一眼可见，在汇总数字里完全隐形。

第三种更隐蔽：不稳定。比如同一任务重跑十次，只通过三次，报告里写"能解决"。没有留下运行记录的评测，读者无法知道这个"能"字的含金量。三种说谎方式共同指向一个结论：没有 trace 的通过率，只能反映评测者的诚实程度，不能反映系统的真实能力。

任务定义锁定"考了什么"：输入、目标、判分标准，避免事后用宽松解释救数字。环境边界锁定"给了什么条件"：能访问什么文件和网络、起始状态是什么，这是判断有没有泄漏的依据。

trace 锁定"怎么做的"：每一步的命令、工具调用、中间输出。它能区分真实解决和投机取巧，也能让失败样例变成可分析的材料。产物锁定"做出了什么"：最终的 diff、文件、报告，可以独立于运行环境被检查。验证结果锁定"凭什么算对"：跑了哪些检查、什么版本、通过和失败的完整清单。

五要素之间的关系和证据链一样是互相制约的：验证结果要能对上产物，产物要能在 trace 里找到来历，trace 要落在环境边界内，一切都要回到任务定义。链条断在哪里，评测的可信度就降级到哪里。

保留是为了回放。replay 的最低要求是：给定同一个任务，能用记录的环境和版本重跑一次，得到可比的结果。这要求记录不只覆盖 agent 的行为，还覆盖评测本身的配置——模型版本、工具版本、环境镜像、判分脚本，任何一个变了，数字就不可比。

回放不需要覆盖每一次运行，它是抽查手段：从通过样例里随机抽几个，确认通过是真的；从失败样例里挑几个，看失败在哪一步。能经受随机抽查的评测，汇总数字才值得引用——这和审计的逻辑完全一致。

做不到完整 replay 也有务实的降级：至少保证 trace 完整可读、产物可独立验证、版本被记录。可审查是底线，可复现是目标；两者都没有的评测，只是自动化了的主观印象。

如果要把几百个任务、每个跑几十分钟的评测批次运行起来，就会发现评测系统自己就是一个长任务系统：要排队、要隔离、要处理超时和部分失败、要存产物、要报进度。N-009 讨论的那套结构——任务状态机、失败处理、产物存储——在这里全部适用。

这不是巧合，而是同构：评测系统消耗真实算力、产出需要被信任的结果，所以它和生成系统面对同一组工程问题。区别只在产物——一个产出资产，一个产出"这个数字可以被相信"。

所以搭评测系统的团队可以直接复用长任务系统的检查清单，再加上评测特有的一条：判分环节自己也要被审计。裁判的可信度，决定比分的可信度。