Appearance
怎样建立可重复的 E2E Eval：Dataset 与 Deterministic Grader
前置：恢复逻辑如何防回归：Replay / Resume Tests 与 Golden Trace
核心问题：怎样设计一套不是“100 个随便 Prompt”的 E2E Dataset，并用 deterministic grader 判断真实任务是否完成？
同一代码任务完整经历 planner→tools→patch→tests，最终看测试和 diff，并记录总 token/时长。加入常见任务、长尾、需要拒绝、权限不足、工具失败、长 context 等分层样本，并单独报告各 slice。
Mental Model
E2E Eval 保留完整 Harness 路径，但 grader 应尽量把可确定的软件事实和开放语义质量拆开；Dataset 决定它测到的到底是不是实际关心的任务分布。
End-to-End Evaluation
E2E Eval 用真实或代表性输入跑完整 Harness，回答的是：用户最终任务有没有被正确完成，而且代价是否可接受。
它可以同时记录 success、latency、cost、安全约束和最终 artifact，但定位能力有限。若 E2E success 从 90% 掉到 78%，还需要 component eval / trace 判断到底是 Retrieval、Planner、Tool 还是 Context 退化。
所以 E2E Eval 更像总体验收，不应该替代分组件诊断。
Eval Dataset Design
Eval Dataset 决定了最终分数代表什么。只收“系统本来就很会做”的简单题，分数再高也不能说明生产质量。
一个 Harness dataset 应覆盖真实任务分布中的不同维度，例如：
text
任务类型 / 难度
需要的 Tool 数量
是否需要 Retrieval
长 Context / noisy Context
错误 Tool observation
权限/approval 场景
需要恢复的长 Run还要保留固定 regression set，避免每次发布都换题导致分数不可比较。线上失败案例可以不断补进 challenge set，但不要直接把测试集变成训练/提示调优材料后还继续用同一分数宣称提升。
Deterministic Grader
文件是否存在、JSON schema、DB state、调用次数、trajectory constraint 等可程序判断的，应优先 deterministic grader。
它便宜、稳定且可解释。
Eval Dataset 不是“随便攒 100 个 Prompt”
一个 Harness 回归集应该覆盖真实任务分布和关键 failure surface。例如 Coding Agent 可以分层：
text
30% 定位/解释问题
25% 单文件修复
20% 跨文件修改
10% tool failure / timeout
10% approval / permission boundary
5% long-running resume每个 case 不一定只有一个标准答案。可以同时保存：输入、fixture/workspace version、允许/禁止的 tool、确定性验收脚本、必要 rubric、expected artifacts。
数据集还要区分开发集和 holdout regression set。反复根据同一批失败样本改 Prompt 后再在原集合上报高分，很容易过拟合；重要版本应该在未用于日常调参的集合上确认没有退化。
Failure Modes
用 Model-as-Judge 评可确定断言的软件事实
症状： Tool 调用次数、schema 合法性等也交给 judge。
为什么危险： 测试变慢、昂贵并引入随机性。
处理： 确定性行为用代码 grader/assertion；语义质量才用有 rubric 的 judge。
如何验证
| Case | 断言 |
|---|---|
| 用 Model-as-Judge 评可确定断言的软件事实 | 同一 deterministic failure 多次运行必须 100% 同一程序断言。 |
自测
- 一套 E2E Eval 如果每次 grader 标准都变，分数还能比较吗？Dataset 与 deterministic grader 应怎样版本化？
- 只收集 happy path 样本会让哪类 Harness 问题在评测里完全不可见？