评测集建在流沙上，越努力陷越深。这篇把评测集当代码基础设施来治理：可复现性试金石、oracle 校验评分器（定盘星）、防自污染五招与保密集体温计、入库六勾清单。藏书中最系统的数据治理篇。
先修：a33（自建评测集）。评测集已有一定规模、开始依赖它做决策的团队。第一个动作：给所有 oracle 重跑一遍，看哪些老题已经悄悄坏了。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
同一 Agent 反复跑：好题/Agent 飘的失败有规律、原因同类可解释；题目飘的失败无规律、自相矛盾（同一条正确轨迹这次判过下次判挂）。结果异常不稳，先修题别调 Agent。
证明任务可解；校验评分器（必须被判满分）；维护评测集活性（环境/上游变了导致老题无解时，定期重跑 oracle 会报警）。
比较开发集与保密集的分数差：天天看的开发集 92 分、从没见过的保密集只有 70 分，这个巨大分差就是过拟合/污染的强烈信号。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
上一讲你学会了从零建评测集、让它滚动生长。但这里埋着一个危险：如果任务本身质量不行——有歧义、不可解、答案是错的、能被作弊、或者被污染——那你的评测集建得越大、跑得越勤，你就错得越自信。
一套有问题的评测集，会持续给你错误的信号：它可能让一个其实变差的版本"分数变高"，于是你高高兴兴上线；也可能让一个真正的改进"分数不动"，于是你把好东西改回去了。评测一旦建在流沙上，你越努力，陷得越深。
所以这一讲我们做"评测数据治理"——把评测集当成代码和数据基础设施来管，守住三道质量关：任务质量、Oracle 参考解、防污染。
好基准的三条标准：明确性、可解性、完整性（防作弊）。这一讲讲怎么把它们落地检验。其中最该死磕的，是一个容易被忽略的硬指标——可复现性。
判断任务质量，有个特别实用的试金石：拿同一个 Agent，把这个任务反复跑很多遍，结果稳不稳定？
这里要小心一个陷阱。Agent 本身就不确定，结果有波动是正常的。但你要区分两种"飘"：
当一个任务的结果异常不稳定时，先怀疑题目，而不是 Agent。很多人一看到分数飘就去调 Agent，其实是在为一道烂题打补丁。
举个退款的例子。一个坏任务："测试退款功能。"——这根本没法判定：退哪个订单？什么算成功？于是不同 trial 的"成功"判得乱七八糟。改成好任务："订单 #1234（状态 paid、未发货）发起退款；成功 = 退款接口返回成功且订单状态变为 refunded。"——判定唯一、结果就稳了。模糊是题目飘的头号来源。
用数据看一眼就懂。同一个 Agent，分别在"好题"和"飘题"上各跑 10 次：
| 好题（判定唯一） | 飘题（判定模糊） | |
|---|---|---|
| 10 次结果 | 通过 8、失败 2，且失败原因同类 | 通过 5、失败 5，失败五花八门、毫无规律 |
| 你能下的判断 | "约 80% 水平"，可信 | 分不清几分——这是题目在飘 |
好题的失败是有规律、可解释的；飘题的失败是无规律、自相矛盾的（甚至同一条正确轨迹这次判过、下次判挂）。看到后者，别急着调 Agent，回去修题。
别等结果飘了才发现。三个主动的体检手段：
每收一个新任务，过一遍这张清单：判定唯一（什么算成功写清楚了吗、会不会有歧义）？可解（有 oracle 证明它真能被解出来吗）？防作弊（有没有一行投机取巧就能骗过判定的捷径）？环境稳定（每次跑的初始状态一致、能复位吗）？结果可复现（同一 Agent 反复跑，排除 Agent 自身波动后分数稳定吗）？
还有一种最坑的坏题——标准答案是错的。可能是当初标注就标错了，也可能是业务规则变了、老答案过期了。它的危害极大：Agent 明明答对，却被判错，于是你以为 Agent 退步了，跑去"修"一个本来正确的行为，越修越坏。
怎么防？靠 oracle 和定期人工抽检。一个特别值得警觉的信号是：当某道题"Agent 一直过不了、可你看轨迹又觉得它没做错"时，第一反应不该是怀疑 Agent，而是去查这题的 ground truth 还对不对。
Oracle（参考解），就是为每个任务配的一条"已知正确"的处理方式——可以是标准答案，也可以是一条完整的、正确解决该任务的轨迹。Terminal-Bench、SWE-bench 这些好基准都把它当标配。它有三个作用：
作用一：证明任务可解。一道连人工写的标准解都通不过的题，是坏题。oracle 是任务"可解性"的证据。
作用二（最关键）：校验你的评分器。这是很多人没意识到的——评分器本身也会错。你写的代码断言可能漏了一种情况，你的 LLM 裁判可能判得偏。怎么知道评分器对不对？把 oracle 喂给评分器，它必须判满分。如果一条标准正确的解，被你的评分器判成了失败，那——不是 Agent 的问题，是你评分器的 bug。
举个退款的例子。退款-006 的 oracle 是一条"先追问订单号、确认后正确退款"的轨迹。你把它喂进评分器：如果评分器给它打了低分，说明你的评分逻辑有问题（比如它错误地要求"必须一次性完成、不准多轮追问"）。没有 oracle，你永远分不清是 Agent 烂还是评分器烂。
具体怎么做，三步：① 为任务写一条标准正确的轨迹（oracle）；② 把它当成"一次 Agent 试验"喂给你的评分器；③ 看评分器给不给满分——给，评分器初步可信；不给，先去修评分器，别动 Agent。养成一个习惯：每写一个新评分器，先拿 oracle 过一遍再上线用。
作用三：维护评测集的"活性"。你的环境、工具、API 会变。某天上游改了个字段，可能让一道老题悄悄变得无解——但因为 Agent 失败看起来"正常"，你根本不会发现。对策：定期重跑所有 oracle。哪天某个 oracle 突然通不过了，就是在报警："这道题或它的环境坏了，快修。" 这是检验"评测集还活着"的最低成本手段。
最后一关，也是最隐蔽的一关：数据污染（contamination）。污染的意思是：评测的题目或答案，以某种方式"提前泄漏"给了模型，于是它不是"做对了"，而是"背过了"。分数虚高，把你骗得以为 Agent 很强。污染分两类：
第一类，训练污染（公开题被背过）。公开基准的题目大概率已经进了模型的训练语料。所以一个模型在公开榜上的高分，可能有水分——它见过原题。这就是为什么 GAIA 把 300 道测试题答案保密、SWE-bench 不断出新题。对你的启示：越是公开、越是老的基准，分数越要打折看。
第二类，自污染（你自己泄漏的）。这个更常见、也更冤——是团队自己造成的：
结果就是 Agent 在你的评测集上分数漂亮，一到真实流量就现原形——因为它学的是"应付这几道题"，不是"解决这类问题"。
我见过一个很典型的场景：团队对着固定的 50 道评测题反复调 prompt，三周后评测分从 70 涨到 92，皆大欢喜上线——结果线上投诉不降反升。复盘才发现，那 92 分是"专门为这 50 道题调出来的"，prompt 里甚至塞进了和评测题高度相似的例子。评测集一旦变成了训练集，分数就成了自欺。
防污染的几个实操办法：
怎么"测出"污染？一个简单好用的体温计：比较开发集和保密集的分数差。如果你的 Agent 在天天看的开发集上 92 分、在从没见过的保密集上只有 70 分，这个巨大的分差就是过拟合/污染的强烈信号——它擅长的是"应付见过的题"，不是"解决这类问题"。健康的情况下，两个集合的分数应该接近。把这个"分差"当成一个常态监控的指标，污染一冒头你就能发现。
一句话：评测集的价值，建立在"模型没见过它"之上。一旦它泄漏，就报废了。
三关之外，最后给一个治理总纲——像管代码一样管你的评测集：
落到最小可执行的程度，给"往评测集加一道题"配一张提交清单（像 code review 一样过）：判定标准写清楚了（结果目标 + 过程目标）？配了 oracle，且 oracle 能被评分器判满分？做过"作弊体检"，确认没有捷径能骗过判定？跑过 dummy Agent，确认它会失败？打了标签（维度 / 难度 / 是否回归集 / 来源）？确认这道题（及答案）没有泄漏进任何 prompt 或训练数据？六个勾全打上，这道题才够格进库。
怎么知道评测集开始腐烂了？盯这几个征兆，出现任何一条就回来做一次治理：oracle 开始莫名通不过（环境变了）、分数好得反常（污染或判定变松）、好几个月没加过新题（停止生长）、所有题都挤在同一个维度（覆盖偏）、有人为了报告好看删过难题。