OpenAI旧Evals进入退役倒计时：Agent测评别再押在一个平台按钮上
真正会丢的不是一个界面
很多团队说“我们做过几十条 Agent Eval”，实际资产只存在某个平台的网页按钮里：案例是谁写的、标准答案是什么、评分器怎么判、失败时调用了哪些工具，全靠系统内部保存。平台一迁，留下的可能只是一张总分截图。
OpenAI 已公布旧 Evals 的只读与关闭时间。无论是否使用该平台，这都是一个提醒：评测能力不能依赖某个页面还在。
四类资产必须独立保存
① Evaluation Dataset：用户请求、上下文、期望业务事实；② Grader/断言：通过条件、禁止行为、阈值；③ Trace：工具调用、参数、模型与版本；④ CI报告：哪次变更造成了什么回归。
把它们存成可版本管理的 JSON、代码和可查询日志，换平台时只需要换执行器，不需要从零再猜业务规则。
迁移前先跑一次双写校验
选择20条高风险样本：退款、权限、空结果、工具超时。旧系统和新执行器同时跑，逐条比较不是只比较总分，而是比较失败分类和 Trace。若新平台只会打“失败”，却无法指出参数越权或调用顺序错，就不是等价迁移。
双写时建议把每条样本拆成三列：业务结论、行为证据、诊断标签。比如“退款未执行”是业务结论；“先调用 cancel 再调用 refund”是行为证据；“调用顺序错误”才是诊断标签。三列分开后，团队能判断是评分器变了，还是 Agent 真变了。只比较 82 分和 84 分，排查没有起点。
迁移清单也要有人负责：谁维护坏案例、谁审批新增评分规则、谁在模型或 Tool Schema 变更时触发回归。它不是平台管理员的杂活，而是 AI 测试开发的质量资产管理。新同学接手时，能在仓库里找到版本化数据集和报告，比收到一张历史仪表盘截图有用得多。
结论
评测平台是工具，不是资产。测试工程师应该拥有自己的坏案例、断言和证据链，这样任何平台退役都不会带走团队的质量记忆。
