OpenAI 旧 Evals 平台退役倒计时10 月 31 日转只读Agent 测评团队的迁移清单与 Trace/Grader 新范式解读导语一个按钮消失时什么会跟着消失先做一个思想实验2026 年 11 月 30 日早上一位评测工程师点开收藏夹里的旧 Evals 平台链接页面变成 404。他想复现上周那条失败样本却发现 Case 正文、Grader 定义、历史 Eval Run 的报告视图全部只存在于那个已经关闭的平台上。团队当然可以重新搭一套环境但问题是你要重新搭的不是环境是资产。这正是 OpenAI 旧 Evals 平台退役事件的真正含义。据当前公开的转述OpenAI 官方评测最佳实践页面明确写出旧 Evals 平台将在 2026 年 10 月 31 日对现有用户转为只读并计划于 2026 年 11 月 30 日关闭与此同时官方的 Agent 评测指南仍然强调使用 Trace、Grader、Dataset 和 Eval Run 来持续改进 Agent 质量 [1]。这是本次研究材料中唯一带明确硬截止日期的技术事件因此它不是一则产品下线通知而是 Agent 测评团队的工程事件。需要先做边界声明本文引用的退役日期与新范式术语来自掘金二手转述 [1]该文明确指向 OpenAI 官方评测最佳实践页面与 Agent 评测指南但本次研究材料中未提供这两份官方文档的原始链接。因此所有平台行为、能力边界、导出接口与 API 名称正式迁移前必须以 OpenAI 官方文档原文为准。本文给出的目录结构、manifest 字段、脚本骨架与评测循环均为可移植性建议不代表官方接口也不应被当作官方 SDK 的方法签名使用。一、时间线与影响面10 月 31 日和 11 月 30 日分别意味着什么1.1 两个日期的行为差异转只读与关闭是两种不同性质的截止时间点推断的能力状态对团队的实际约束2026-10-31 之前可读、可写、可导出可以补 Case、修 Grader、整理标签是一切补救动作的最后窗口2026-10-31 起只读推断为可查看、可导出但不可编辑、不可新增想改的字段再也不能改导出仍可能是可行的但不应把希望寄托在只读期2026-11-30计划关闭推断为访问完全终止未落盘的资产等于永久丢失需要说明上表中只读期是否仍允许 API 批量导出“关闭后历史 Run 是否可恢复”“是否有宽限期”在本次研究材料中均无一手证据支持属于必须回源核验的事项。工程上的稳妥做法是把 10 月 31 日当作绝对截止而不是把 11 月 30 日当作截止。只读期应当被当作补救通道而非计划内的工作窗口——如果导出工作卡在 11 月才开始任何权限、速率限制或字段缺失问题都没有回旋余地。1.2 影响面盘点旧平台上通常沉淀着四类资产它们的紧迫度并不相同资产项影响迁移紧迫度说明Case 正文与输入变量高最高这是评测集的本体丢了等于重建Grader 逻辑与 prompt高最高往往是最难恢复的部分写在界面上的判定规则、阈值、prompt可能从未进过版本库metadata标签、版本、负责人、来源中高表面次要实际决定 Dataset 的分层、切片与回归分析能力历史 Eval Run 结果与失败样本高高是曾经出错过的样本的唯一来源也是基线可比性的依据告警、看板、CI 集成中中平台关闭后会失效需要重新对接新入口其中最危险的不是 Case而是Grader 逻辑与历史失败样本。Case 通常还能从需求文档或线上日志里重建而一条精心调过的评分 prompt、一组被人工标注过的边界样本往往只活在平台的表单里。研究材料中提到的 Agent 评测最佳实践同样把 Grader 与 Dataset 并列为核心对象 [1]这不是概念修辞而是在提示判定逻辑本身必须被视为可版本化的工程资产。二、第一步导出与对账10 月 31 日前的硬动作2.1 导出清单在动手之前先明确要带走什么。建议按下表逐项打勾资产项导出内容存放位置验收标准负责人Case输入变量、上下文、期望输出/参考答案datasets/name/v1/cases.jsonl条数与平台侧一致抽样 20 条字段完整评测负责人Grader评分 prompt、代码型判定逻辑、阈值、模型判定配置graders/每个 grader 可独立执行并产出结构化结果Agent 后端metadata标签、版本、来源、负责人、创建时间、难度manifest.yaml 每条 case 内嵌无标签缺失率超过约定阈值评测负责人历史 Run每次 run 的配置、聚合指标、失败样本及其 traceruns/date/至少可回溯最近 N 次基线 run平台工程集成配置CI 触发条件、告警阈值、看板查询仓库内.ci/或文档换后端后可复现同一触发条件平台工程导出字段是否包含 grader 与历史 run、平台是否提供批量导出接口、是否有速率限制本次材料未给出一手说明需在官方文档中逐一确认后再写自动化脚本 [1]。2.2 落盘格式建议用 Git 管理的可移植结构平台会退役Git 不会。建议以每 Case 一条记录 独立 manifest的方式落盘明确标注为自定义可移植格式eval-assets/ ├── datasets/ │ └── refund-agent/ │ ├── manifest.yaml │ └── v1/ │ ├── cases.jsonl │ └── traces/ # 历史失败样本的 trace开放格式 ├── graders/ │ ├── schema_check.py # 确定性检查 │ ├── policy_compliance.yaml # 声明式规则 │ └── quality_judge.prompt.md # 模型判定 prompt ├── runs/ │ └── 2026-10-28-baseline/ │ ├── run.yaml # 运行配置模型、温度、采样次数 │ └── results.jsonl └── tools/ └── reconcile.py # 对账脚本骨架cases.jsonl的一条记录可以这样组织示意非官方 schema{case_id:refund-001,input:{user_goal:申请退款,context:订单已签收 25 天},expected:{outcome:拒绝并给出替代方案},metadata:{tags:[refund,policy-boundary],source:prod-log-2026-09,owner:qa-team,difficulty:hard},graders:[schema_check,policy_compliance,quality_judge]}manifest.yaml负责描述数据集级别的信息dataset:refund-agentversion:v1created_at:2026-10-20source_platform:legacy-evalscase_count:312layers:smoke:[refund-001,refund-014,refund-207]regression:tag:regressionadversarial:tag:policy-boundarygraders:-id:schema_checktype:deterministic-id:policy_compliancetype:deterministic-id:quality_judgetype:modelmodel:待填写baseline_run:runs/2026-10-28-baseline2.3 对账证明导出是完整的导出不等于完成能被对账验证的导出才算完成。最小对账脚本骨架如下示意# tools/reconcile.py —— 骨架示意平台侧计数 API 待官方文档确认后补全importjsonfrompathlibimportPath REQUIRED[case_id,input,expected,metadata,graders]defload_cases(path):return[json.loads(line)forlineinPath(path).read_text().splitlines()ifline.strip()]defreconcile(local_path,platform_totalNone):casesload_cases(local_path)missing[c.get(case_id)forcincasesifany(knotincforkinREQUIRED)]print(f本地条数:{len(cases)})ifplatform_totalisnotNone:assertlen(cases)platform_total,f条数不一致:{len(cases)}!{platform_total}print(f必填字段缺失条数:{len(missing)})returnlen(cases),missingif__name____main__:reconcile(datasets/refund-agent/v1/cases.jsonl,platform_totalNone)验收标准建议至少包含三条条数与平台侧一致必填字段缺失率为零或有明确豁免清单随机抽 20 条在新环境中重跑结果与历史基线的差异可解释。最后一条尤其重要它能在早期暴露导出了文本、丢掉了隐含上下文这类静默错误。三、第二步理解新范式——Trace / Grader / Dataset / Eval Run3.1 四个对象各自解决什么问题Dataset可版本化的输入与期望集合。它解决测什么的问题核心要求是可复现、可切片、可 review。Grader可声明、可复用的判定逻辑。它解决怎么算对的问题要求与数据解耦、可独立执行、可审计。TraceAgent 执行过程的可观测记录包括工具调用序列、参数、返回、中间状态。它解决为什么错的问题。Eval Run一次可复现的执行与结果聚合。它解决这次改动带来了什么变化的问题。官方 Agent 评测指南据转述强调使用 Trace、Grader、Dataset、Eval Run 来改进 Agent 质量 [1]。四个对象合起来构成一个闭环数据集定义问题执行产生轨迹判定器打分运行结果回流数据集。3.2 旧 → 新概念映射旧对象新对象迁移动作可能的信息损失Case / 期望输出Dataset 条目导出 补齐结构化字段隐藏上下文、平台侧的隐式参数评分器 / 人工标注Grader把界面配置改写为可执行代码或声明式规则阈值微调过程、判定 prompt 的版本历史单次评测记录Eval Run导出 run 配置与结果重建基线平台聚合视图中的派生指标无对应Trace新建采集链路这是旧范式最弱的一环需要从零补第三行是关键Trace 在旧范式中往往没有独立地位很多团队只保存最终答案与对错标签。迁移时若只搬结果而不补过程就等于把新范式用成了旧范式。3.3 从结果判定走向过程判定Agent 评测与传统模型评测的最大差异在于最终答案正确不代表过程合规。一个退款 Agent 可能给出了正确结论却在中途越权调用了写接口也可能用大量无效重试勉强凑出结果成本与延迟早已失控。因此判定必须落到 trace 上工具选择是否正确参数是否合法是否出现越权或危险写操作是否陷入循环、重试是否收敛中间结论是否有幻觉成本、延迟、步数是否在预算内。这一点在本次研究的其他材料中也有呼应trpc-agent-go 这类生产级框架把 evaluation 与 OpenTelemetry 可观测性并列作为核心能力 [2]两份 2026 年 Agent 框架对比报告也把 Security 与 Evaluation 作为评分维度 [3][4]。换言之评测与可观测正在收敛为同一件事。一次 Eval Run 的生命周期可以概括为Dataset 选择smoke / 全量 / 对抗集 ↓ Agent 执行逐条产出 Trace ↓ Grader 分层判定确定性 → 模型 → 人工 ↓ Eval Run 聚合结果通过率、成本、延迟、失败分类 ↓ 失败样本与被修正的 Trace 回流 Dataset形成回归集四、第三步把 Agent 评测真正跑起来4.1 先测什么从真实失败出发评测集最容易犯的错是从理想用例出发编写写出一堆 Agent 永远不会遇到的漂亮场景。更有效的路径是反过来从线上失败案例、用户投诉、Trace 中的异常片段出发构建 Dataset把曾经出错的样本永久保留为回归集。这样每一次修复都有对应的证据每一次回归都能被立刻发现。4.2 Grader 分层确定性优先建议采用三层判定越便宜、越确定的规则越靠前确定性检查输出格式、字段完整性、工具调用合法性、策略硬约束例如退款天数不得超过 30 天。这一层应覆盖大部分样本且必须零成本、零歧义。模型判定用于主观质量如语气、完整性、解释的合理性。判定 prompt 本身要进版本库并定期用人工标注样本校准。人工复核兜底用于模型判定不确定、争议样本和安全相关的高风险样本。4.3 失败分类与判定手段失败类型可否用确定性规则捕获建议 GraderTrace 检查点输出格式错误可以schema_check最终输出字段工具选择错误部分可以规则比对期望工具序列工具调用序列参数错误可以参数校验器调用入参循环不收敛可以步数/重复度阈值步数统计、重复调用越权写操作可以策略合规规则写操作调用与审批记录幻觉事实难模型判定 人工复核中间结论与证据链4.4 一个贯穿案例客服 Agent 的多轮退款流程以客服 Agent 多轮退款为例最小评测集可以只有 3 条样本refund-001签收 25 天申请退款期望拒绝并给出替代方案refund-014签收 3 天、商品破损期望同意退款并发起取件refund-207用户反复施压要求突破政策期望坚持政策、不越权改单。对应的 trace 片段示意中refund-207可能出现一次update_order(writeTrue)的调用尝试——这正是结果判定看不出来、过程判定一眼看到的问题。两个 grader 就足以覆盖policy_compliance负责拦截越权写操作quality_judge负责评价拒绝话术的清晰度与共情。一次 run 的结果面板数值为示意不代表真实数据里通过率、越权拦截数、平均步数三个指标放在一起才能说明这次改动究竟让 Agent 变好还是变巧。4.5 评测节奏改动即跑 smoke 集10–30 条高价值样本分钟级反馈合并前跑全量回归集包含历史失败样本周期性跑长时程/多轮/对抗集多轮任务、策略边界、越权诱导安全与对抗集单独留档这类样本不应随普通数据集一起清理。五、反单点依赖让测评资产脱离任何平台按钮这次退役事件最有价值的教训不是记得导出而是测评资产的可移植性应当先于平台功能的丰富度。5.1 三条工程原则数据集进 Git每个 Case、每次修改都可 review、可回滚、可追溯负责人。平台只允许查看而不能比较差异Git 恰好相反。Grader 逻辑可执行、可审计写在界面上的规则是配置写进仓库的规则是代码。判定逻辑必须能脱离平台跑出同样的结果。Trace 可导出为开放格式优先选择可对接 OpenTelemetry 等开放标准的采集方案避免过程数据再次被锁在某个 UI 里。新平台是否提供官方 OTel 对接或批量导出本次材料未给出一手说明需在官方文档确认 [1][2]。5.2 可移植评测资产的最小规范对象必备字段版本化方式Casecase_id、input、expected、metadata、gradersJSONL随数据集版本提交Datasetname、version、case_count、layers、baseline_runmanifest.yamlGraderid、type、输入输出契约、阈值、prompt 引用代码文件或声明式 YAMLTracecase_id、步骤序列、工具调用、成本、时长开放格式文件按 run 归档Eval Runrun_id、配置、模型版本、聚合结果、失败分类run.yaml results.jsonlGrader 的输入输出契约建议固定为输入一份 trace 与一条期望输出{grader_id, pass, score, reason, evidence}。其中evidence指向 trace 中的具体步骤这样失败报告可以直接定位到第 7 步的写操作而不是停留在这条没过。5.3 平台仍然值得用的部分反单点依赖不等于反平台。托管执行、并行调度、报告视图、Trace UI这些能力自建成本很高用平台是合理选择。需要调整的只是入口日常入口应当是代码与 CI而不是网页按钮。CI 触发 smoke run、结果以 artifact 形式留存、失败自动附上 trace 摘要——用通用 CI 概念即可实现不绑定任何厂商。六、倒计时作战表与迁移验收按团队规模可采用两档节奏阶段1–2 人小队专职评测组T-30 至 T-21盘点资产、确定导出范围盘点资产 并行验证新范式概念映射T-20 至 T-14完成 Case 与 metadata 导出导出 Case/Grader/Run建立对账脚本T-13 至 T-7写 Grader、跑通首次新环境 run全量迁移、校准新旧判定差异、接 CIT-6 至 T-1对账、抽样重跑、修补缺字段对抗集与长时程 run、基线对比报告只读期仅用于补救与最终对账仅用于补救与最终对账迁移完成定义DoD全部 Case、Grader、metadata、历史 Run 已落盘对账通过新环境至少跑通 1 次全量 run新旧环境判定结果差异可解释并有校准记录CI 已接入PR 触发 smoke run没有任何评测资产只存在于平台上历史基线指标可比失败样本回流机制已建立值班人知晓回滚路径与紧急联系人。风险登记风险触发条件缓解动作导出字段不全对账发现 metadata 或 grader 缺失立即截图留档 联系官方支持不要等只读期只读期权限受限10-31 后导出接口不可用以 10-31 为绝对截止提前完成全部导出新旧判定不一致抽样重跑结果差异超阈值用同一批样本做双跑比对逐条定位判定规则差异历史 run 无法迁移平台不提供批量导出至少导出聚合指标与失败样本清单作为基线文档留档平台临时变更时间表官方更新公告以官方文档为准本文日期仅为转述 [1]七、常见坑与速查Q元数据导不全怎么办A先按可导出部分落盘并在 manifest 中建立missing_fields清单注明缺失字段、影响范围与补救责任人。不要因为追求完美导出而错过截止。Q历史 Run 没法迁移怎么留档A优先导出三样东西run 配置、聚合指标、失败样本及其 trace。若 trace 也拿不到至少留下失败样本清单与当时的结论文字作为基线文档。QGrader 在新旧环境判定不一致怎么办A这是迁移中最常见的问题通常来自隐式参数温度、模型版本、超时、解析规则差异。用 20–50 条标注样本做双跑比对把差异分类为实现错误或校准差异前者修代码后者记入变更说明。Q只读期还能补 Case 吗A按只读的通常含义推断不能新增或编辑 [1]因此所有补录必须在 10 月 31 日前完成。这一点务必在官方文档确认。Q遇到 X 就做 Y情况动作导出条数对不上立即比对分页/筛选条件暂停清理动作一条 Case 字段为空回源平台截图留档在 JSONL 中保留占位并标注新环境跑不通先跑 1 条最小 Case定位是权限、格式还是依赖问题CI 时间过长缩小 smoke 集长时程任务移到周期性调度官方时间表变更以官方文档为准同步更新团队作战表八、结语把这次退役当作一次测评基建体检平台退役是外部事件暴露的却是内部问题评测资产是否可导出、判定逻辑是否可复现、失败样本是否可回流、历史结果是否可比。这四件事做得好换平台只是改配置做得不好换平台就是重建。长期来看Trace、Grader、Dataset、Eval Run 这套范式的价值在于把评测从一次性的跑分动作变成一条有输入、有过程、有判定、有回流的工程流水线 [1]。生产级 Agent 框架把 evaluation 与可观测性作为一等能力 [2]第三方框架对比也普遍把评测与安全纳入评分维度 [3][4]都说明这个方向已经是共识。真正值得押注的不是某一个平台按钮而是团队自己手里的那份可版本化、可执行、可重放的测评资产。参考资料[1] 《OpenAI 旧 Evals 平台进入退役倒计时Agent 测评别再押在一个平台按钮上》掘金2026-09-30https://juejin.cn/post/7691160156302147584 。该文转述了 OpenAI 官方评测最佳实践页面中的退役时间表2026-10-31 转只读、2026-11-30 计划关闭以及 Agent 评测指南中 Trace / Grader / Dataset / Eval Run 的核心范式本文成稿时未获得官方页面原始链接正式迁移前请以 OpenAI 官方文档为准。[2] trpc-agent-gotrpc-groupGitHubhttps://github.com/trpc-group/trpc-agent-go 。含 graph workflows、A2A、MCP、evaluation 与 OpenTelemetry 可观测能力说明。[3] ai-agent-comparison-2026janvarezGitHubhttps://github.com/janvarez/ai-agent-comparison-2026 。9 个 AI Agent 框架在安全、代码质量、编排、生态等维度的对比分析。[4] agent-framework-comparison-2026hussain-alsaibaiGitHubhttps://github.com/hussain-alsaibai/agent-framework-comparison-2026 。tiny-agent、LangChain、CrewAI、AutoGen 的功能与取舍对比。注OpenAI Agent 评测指南与旧 Evals 平台的官方原始链接在本次研究材料中未提供故未列入链接条目文中涉及的退役日期、只读期能力边界与导出接口能力均属二手转述或待核验事项。