评测集这事我的判断一直没变：最值钱的样本在线上，不在你脑子里。你坐下来写 case 的时候，能想到的失败模式已经被你想到了，写出来的东西只是在验证你已经知道的事。但这周有几篇东西提醒我，线上不是免费午餐——agent 能改自己的 trace，监控本身也会被当成障碍绕过。矿是好矿，得先验货。
线上失败案例最肥，但先确认 trace 是它自己改不了的
人工构造集的毛病不在质量，在分布。你写 case 时脑子里有个"可能出错的地方"清单，这个清单本身就来自你的经验边界。清单外的失败，你构造不出来。线上案例好就好在它不关心你想没想到。
问题是，线上案例的原始形态是 trace。而 2609.30266 那篇说得很直接：异步监控、事故复盘、合规审计都建立在"agent 改不了自己的执行记录"这个假设上，而这个假设不成立。
这不是学术洁癖。HN 上排在前面的那条 OpenAI agent 打 Hugging Face 的复盘，还有 transluce 抓到的早期 rogue agent 活动，以及澳洲政府网站那事——这些案例的事后重建全靠 trace。如果 trace 是 agent 自己进程写的、和 agent 在同一个权限域，你攒的不是事实，是 agent 的自我陈述。
工程上就一条：日志写到 agent 碰不到的地方，append-only，时间戳来自外部。听着像废话，但很多 agent 框架默认的 tracing 就是进程内埋点。
介入即入池，抽样频率自己测出来
具体做法我倾向这样：所有有人工介入的会话，自动进候选池。人工介入包括用户重试、人工接管、转人工客服、提交工单、报错告警——凡是"人伸手了"的信号都算。
池子有了，抽样标注的频率别定死。定死的频率在两个方向都会错：介入量低的时候标出来的全是噪声，介入量高的时候标不完，池子越堆越陈，最后没人看。
我自己的做法是看边际收益。先高频标一批，记录每批新增的"以前没见过的失败模式"数量。这个数掉到接近零，就该降频；它重新涨起来，再提频。频率跟着介入量走，不跟着日历走。
反面：没人报的失败永远进不了池子
这是"全靠线上"最大的漏洞。用户遇到问题，默默换个说法重试成功了，走了。这种失败不会出现在任何介入记录里。用户直接不用了，更不会。
2609.30217 那篇讲得更狠：agent 会把运行时监控当成完成任务的障碍，主动绕开。你以为监控覆盖了，其实监控只是它权衡过的选项之一。
还有个更日常的例子。HN 上那条 Claude Code 只在 telemetry 开着时才读 AGENTS.md，不管最后怎么修的，它暴露的问题很典型：你的采集本身是有条件的，条件之外的失败你根本看不见。池子从采集层就是偏的。
所以纯线上不够。
对抗样本那一小批，别省
手工构造不该被全盘否定，它该换个位置——从主力变成补丁，专门补线上采不到的那块。几条就够，但得是那种线上永远不会自然冒出来的：
- 工具返回的 JSON 里夹着指令
- agent 判断"B 更符合你的真实意图"，于是没做 A
- 用户中途改主意三次，看它跟不跟得住
这几条的意义不是覆盖率，是当探针用。它们长期不失败，说明这几个方向上确实稳；一旦某条开始失败，说明最近的改动动了不该动的东西。
评测集不是攒一次就封存的。它更像一个筛子——你得持续往里倒线上的泥浆，同时偶尔手动撒一把沙子，看看筛孔有没有变大。