OpenAI旧Evals进入退役倒计时这件事让我马上想到的居然是上周的一次评审会。我朋友所在的团队兴冲冲打开OpenAI在线Evaluations传了200条用例点了运行评测按钮界面弹回一个92分。他们拿这个分数去说服客户结果Agent一接入真实的报销审批流程头两天就翻了车工具调用漏参数、多轮对话状态错乱、遇到权限边界直接死循环。分数很漂亮实战一团糟。这不是个案我这两年帮团队搭Agent测试体系见得太多了。所以我想把这件事掰开说清楚。旧Evals退役不只是一个框架下线的新闻它逼着所有做Agent测评的人回答一个根本问题你评测的目的是让仪表盘好看还是让Agent在真实任务里真的能用如果你准备跟着官方引导从此把Agent测评押在平台的一个按钮上我劝你先看完这篇再决定。1. 旧Evals退役这件事要分三个层面看1.1 旧Evals本质是LLM文本能力的记分牌openai/evals是OpenAI开源的评估框架最早是评估GPT-4这类模型能力用的。它的工作方式很朴素你在YAML里定义一个eval给模型喂一批输入用规则或者用另一个模型对着参考答案打分最后汇总成一个能力分数。很多人拿它做Agent评测但它最初的设计假设其实很简单——一句文本进去一句文本出来打个分。这样说不是贬低它。当年没有Evals大家评估模型就是肉眼抽几条样本Evals至少把评测集评分器这两个概念做成了工程化的东西。直到今天我身边还有团队用它跑每周的模型回归。后来把评测能力整合进平台旧Evals进入维护和退役流程这其实是早晚的事因为OpenAI的主线已经很清晰把评估这种能力也产品化做成托管服务。1.2 官方迁移的方向是托管服务随着评估能力整合进平台OpenAI开始引导用户使用在线Evaluations上传数据集、绑定模型、点运行然后看一个结果页。这是典型的产品化路径对很多团队确实省事——不用自己维护runner不用折腾环境界面还好看。我认可这个方向尤其是那些资源有限、又需要快速拿到模型能力基线的小团队平台按钮是能救命的。但省事的另一面是失控。平台按钮背后数据集是怎么组织的、运行环境是什么样的、打分模型是什么版本、超时和重试怎么处理这些细节对用户基本不可见。对于单轮纯文本评测这些细节没那么致命对Agent评测这些细节恰恰是命门。1.3 这次迁移真正改变的是裁判权旧Evals时代你掌握框架的全部源码可以自定义eval class、改runner、接入私有数据源甚至用本地模型当裁判。迁移到平台按钮之后裁判、场地、评分标准都成了托管服务。这本身没有错但Agent评测最需要的恰恰是自定义裁判——把Agent全部评测压在平台按钮上等于把最有技术含量的部分交了出去。我不否认平台Evaluations在某些场景的价值但趋势已经很明显以后凡是点一下按钮就出分的评测会越来越适合标准化场景越来越不适合复杂Agent场景。这也是我看到旧Evals退役倒计时公告时第一反应不是赶紧迁移数据而是我们的自建评测得加快速度的原因。2. 平台上一个按钮测出来的高分为什么和真实Agent表现对不上2.1 你要测的不再是一句话的质量而是一整段轨迹旧Evals和平台Evaluations的默认评测单元是问题-答案给模型一个输入拿到一个输出跟参考答案比。Agent完全不是这个结构它是一轮又一轮的感知-决策-行动每一步都可能改变外部状态每一步的输出又会变成下一步的输入。我见过太多团队拿平台按钮测Agent然后得到一堆90分。问题在于Agent的失败很少发生在最终那句话上而是发生在中间步骤第3轮应该调日历API却调了搜索API、创建工单时漏了必填字段、第5轮已经忘了第1轮用户说过邮件必须抄送给主管。平台评测的核心比较对象是最终文本Agent的命门在完整的行动轨迹。你拿一个测作文的打分器去测一整场比赛分数自然失真。2.2 平台评测里三个看不见的变量数据、裁判、环境第一数据集。你传上去的用例是静态的版本管理、去重、难度分析这些工作平台帮不了你。更重要的平台默认评测集是OpenAI自己组织的通用能力题你的Agent业务场景它不知道也不会替你维护。第二裁判模型。模型给模型打分天生有系统性偏见。同一个最终回复换个打分模型或者换一个版本分数能差出15到20分。平台把打分模型版本封装在按钮后面你看不到、也锁定不了。自建评测至少要锁死一个评分模型的版本才能保证曲线可对比。第三执行环境。平台跑评测用的sandbox和你生产环境的工具真实行为差得很远。它们的mock工具返回的数据很干净没有真实API的校验逻辑、没有权限边界、没有延迟。这种环境下测出来的Agent一进生产环境就被教做人。2.3 一个典型的虚高案例错在参数边界我举一个上周刚复现过的场景。一条用例是帮我订明天上午北京到上海的航班。Agent正确查到了航班调了booking.create由于平台mock工具不校验参数agent漏传了passenger_id但平台只看最后回复文本已为你订好XX航班给了满分。拿到真实系统里booking.create因为缺passenger_id直接返回400。如果Agent没有在同一轮里自我纠正这个任务就是失败的。同一份Prompt宽松文本比对下能跑出95分真实工具调用加参数校验下只剩55分。分数的差距本质就是评测环境真实度的差距。2.4 一个抽象分数解决不了迭代问题平台按钮最后给你一个综合分这个分数最大的问题是不可解释你不知道失败case卡在哪一层是规划错了、工具选错了、参数没填对还是记忆丢了。没有细粒度失败归因就没有反馈回路没有反馈回路你改Prompt只能是玄学。我做Agent评测最看重的一件事是每条失败case都能被回放到某一步具体的trace位置。平台按钮无法支撑这种debug粒度所以分数再好看也只是给管理层看的仪表盘。3. 自建Agent评测体系从测模型转向测任务3.1 你的评测对象已经迁移了一个残酷的现实当你做Agent的时候你已经不是在评测一个模型而是在评测一个系统。模型只是其中的一个组件组件之外还有工具选择逻辑、外部API、状态管理、上下文记忆、错误恢复策略。系统的评测方式自然不能沿用单模型文本打分的范式。我建议所有做Agent评测的人先记住一句话你是来测任务有没有达成、过程有没有出错、成本有没有失控的不是来给模型文本打分的。想清楚这一点你就不会再纠结平台按钮够不够好这种问题因为方向已经完全不同了。3.2 harness和agent别把两者混为一谈在自建评测体系里先要分清楚两个角色。Agent是决策者。它读入目标、观察环境状态、规划下一步行动然后调用工具或者回复用户。Harness是它的运行环境我更愿意叫它测试执行器——它模拟外部世界提供Agent可调用的工具接口管理工具返回值、错误、状态同时记录完整的运行轨迹。类比一下Agent是司机harness是驾校的模拟驾驶舱路况、车辆反馈、考官记录都来自这个舱。没有harness的Agent评测等于把一个司机丢在没有车的考场你只能通过他的嘴来判断开车水平那当然会失真。我踩过的坑是一开始为了省事直接把harness里的工具返回值全写成成功Agent从来不处理失败路径一接真实API就崩。现在我会刻意在harness里注入随机失败、字段缺失、权限不足这些情况这才像真实世界。3.3 四根支柱缺一不可自建Agent评测体系我拆成四个部分任何一个环节瘸了整个体系都白搭。第一个是数据集。Agent用例不是问题-答案对而是任务工具期望轨迹结果约束的结构化定义。我一般分三层维护黄金集覆盖核心业务场景回归集沉淀历史Bug对抗集放边界和恶意输入。每层都要标注好可接受的成功判据不能只有一个模糊的应该成功。第二个是执行器也就是harness。它要能做到三件事按Agent的工具Schema提供mock或沙箱工具、维护一个状态容器比如当前登录用户、待办清单以及严格控制超时和最大步数。没有最大步数限制你的一次评测可能因为Agent死循环烧掉大量Token。我在自建时默认把最大步数压到12轮超时直接判失败宁可误伤不可失控。第三个是评分器。记住一句话能用程序断言的地方绝不依赖模型打分。任务是否达成、关键参数是否合法、工具是否被正确调用这些都写成代码断言可重现、无漂移。模型打分只用于那些模糊维度最终回复是否自然、是否让用户有掌控感、策略选择是否合理。第四个是追踪器。Langfuse这类可观测性工具在Agent评测里的角色常常被低估。评测不是跑完拿个分数就结束的你要能点开每一条trace看到每一步的LLM调用、工具入参出参、状态变化。没有追踪的评测分数等于一个无法debug的报错。现在很多团队问我Langfuse怎么用于评测我的答案很简单把评测跑当作一条特殊trace记录失败case直接回放评分结果直接打在trace上。3.4 一个最小可跑的评测闭环长什么样我给出一个极简的流程骨架你可以直接抄回去改准备阶段把任务用例加载进harness注入对应的seed数据。执行阶段启动Agent跑任务harness收集完整轨迹包括每一步LLM请求、工具调用和状态变化。断言阶段程序化检查结果断言比如任务是否做到、关键约束是否满足、最终回复是否包含必要信息。质量阶段对结果抽样做模型评分评估回复质量和过程中的策略质量。记录阶段把轨迹、断言结果、评分写回追踪器同时汇总成指标报表。回流阶段失败的case自动或人工转回数据集修完Prompt后重跑回归。这个闭环看着简单但很多团队只会做到执行和断言然后跑完出分、分低改Prompt、再跑——没有记录和回流评测就永远是一锤子买卖。4. 迁移旧Evals时的实操清单保住你手里最值钱的资产4.1 最值钱的不是框架是那堆YAML用例旧Evals的评测资产生命周期很长团队可能攒了上百条YAML eval。框架退役不重要重要的是这些用例里沉淀的业务语义。迁移第一步先把eval registry解析出来导成JSON逐条过一遍。我见过有人直接把YAML拖进平台Evaluations的上传框——能导入但本质上只是把用例文本搬运了语义完全没带过去。你的用例应该被重新当作评测资产来处理而不是当成一堆待上传的数据包。老框架可以下线用例里的业务逻辑和边界条件是团队真金白银堆出来的。4.2 把文本对照用例改造成任务用例旧Evals的用例结构很简单input加ideal用来比文本。Agent任务用例需要的信息多得多要有目标、可用工具清单、环境种子数据、结果断言和过程约束。举个例子旧结构是这样的input: 帮我约明天下午三点的会议 ideal: 好的已为你预约明天下午三点的会议如果直接当成Agent用例它测的是回复像不像而不是会议到底约没约成。我给改造后的结构大概是这样的task_id: schedule_meeting goal: 约明天下午三点的会议 available_tools: [calendar_create, contact_lookup] seed_data: user_email: aliceexample.com participants: [bobexample.com] success_criteria: - calendar_create被调用且参会人字段完整 - 开始时间与用户预期一致 - 最终回复包含会议确认信息关键就是把判断标准从文本相似度换成工具副作用加结果断言。改造过程很枯燥但这一步不做后面所有指标都建立在沙子上。4.3 模型评判的Prompt值得保留但裁判服务要自己搭旧Evals里model-graded的评分Prompt写得质量不错这些是可以直接提取出来的文字资产。但我不建议继续依赖平台侧的裁判因为平台裁判模型版本、采样参数、评判逻辑都是黑盒。自建裁判服务至少有四个好处打分模型版本锁定、温度设为0、多次采样取中位数抵消随机性、完全掌控评分成本。迁移期间新旧两套评分并行跑两周看趋势曲线是否一致一致再切换。别搞突然迁移评测体系的连续性一旦断了你很难说清Agent变好到底是你的改进生效了还是评分规则变了。4.4 成本与并发的账不比功能简单Agent评测是吃Token大户。一次任务平均几十轮LLM调用100条用例跑一轮就是几千次调用。成本估算公式其实很简单平均步数乘用例数乘单步Token乘模型单价。很多团队算完就劝退了但成本是可以压下来的。省钱的配置有几个限制最大步数比如超过12轮强制终止并判失败工具调用设置超时和一个总的Token预算评分维度不是每个case都需要模型打分抽样打分加程序断言已经能覆盖大部分需求。我在这里花的钱远比我一开始预想得少。并发也是同一个问题。平台侧有默认限流大批量跑回归很容易触发429。自建时我会把并发压到5到10个任务同时跑出错了容易定位也不至于把预算瞬间烧光。很多团队问AI Agent怎么扛并发评测场景其实就是并发的绝佳练手场harness本身是异步的任务之间状态必须隔离这跟生产环境Agent的并发模型是一回事。4.5 哪些用例值得迁移哪些就算了不是所有旧Evals用例都要进自建体系。我自己的判断标准很简单如果这个用例只看回答文本对不对那留给平台按钮或者换掉都没问题如果这个用例涉及过程是否合理、任务是否真的达成那就必须进自建评测。举个区分摘要质量、文本分类、情绪识别这类属于第一类工具调用、多轮任务、状态依赖、权限边界这类属于第二类。前者在平台跑挺舒服后者往平台一放分数越好越危险。提示判断一条用例归属就问一个问题——这条用例失败时我能不能从文本上一眼看出为什么看不出来说明它已经超出纯文本评测的范畴了。5. Agent评测的指标设计多维度打分才能暴露真实问题5.1 任务成功率只是及格线很多团队汇报Agent效果就报一个指标任务成功率85%。这个数有没有用有用但它远远不够。一个Agent完全可能85%任务都成功了但成功的方式是绕远路多调3倍工具、多烧2倍Token、多花5倍时间。指标的意义不是让你汇报而是帮你定位问题。单看成功率你永远不知道瓶颈在规划、工具、记忆还是成本。所以我会把指标拆开让每个维度都能对应一类可干预的改进方向。5.2 指标拆开来看才有指导性我习惯把一个Agent评测run拆成若干层指标下面这个表基本就是我每次评测必出的维度。层面指标说明结果层任务成功率最终目标是否达成结果层约束满足率必填字段、权限边界等硬性约束是否全通过过程层工具选择正确率每一步是否选择了最合适的工具过程层无效调用率是否存在没必要的工具调用或重复调用过程层错误恢复成功率工具第一次失败后Agent能否自我纠正过程层平均轮次完成任务需要多少轮交互资源层平均Token消耗单任务的成本度量稳定性层同任务多次一致性非确定性提示下结果是否可靠结果层的数字决定能不能用过程层的数字决定好不好用资源层的数字决定用不用得起。这三类指标放在一起才能完整描述一个Agent的真实状态。我见过不少全能但没用的Agent就是只看了结果层。5.3 失败回流机制评测集必须是活水评测数据集最忌讳闭门造车。上线一个月的Agent真实用户会遇到你完全没预想过的输入平台按钮的静态数据集永远追不上这些场景。我的做法是在生产端做一个事件采集凡是用户投诉、系统报警、任务失败的事件进入待转评测集的队列由工程师筛选后变成一条新的Agent用例。反过来评测失败的case也要定期人工Review观察是不是评测集本身设计错了——是agent的问题还是断言写得太严还是环境mock失真。这个循环一旦转起来评测体系才真正变成工程质量的一部分。5.4 别忘了Agent记忆和状态一致性多轮Agent和大语言模型的一个核心区别就是它要有记忆。旧Evals完全没测这个维度平台按钮默认也没测。但Agent实际运行中记忆错误占到失败原因的相当比例。我会专门构造记忆评测用例第一轮告诉Agent我的会议偏好是30分钟第三轮让它安排会议看它是否还记得中途插入与之前矛盾的信息看它是否会被带偏连续对话20轮之后看它是否出现自相矛盾的结论。这些case不贵但能暴露Agent在生产环境中非常致命的一类问题。记忆评测做得好很多线上客户说Agent像个傻子的投诉都能提前拦下来。5.5 评测结果要能翻译给协作方自建多维指标还有一个额外收益——它可以解释。给产品经理或者客户汇报时你不需要秀一个抽象平台分数你可以直接说任务成功率92%其中工具调用错误占比7%、记忆丢失占比3%、成本超支占比2%然后拉一条失败case的trace逐条讲解。这种可解释性才是自建评测体系在协作里的真正价值。平台按钮做不到。一个说不上为什么失败、也不知道该改哪里的分数对协作的贡献基本为零。最后说点个人感受。旧Evals退役这个新闻本身不惊悚惊悚的是很多人收到通知后的第一反应是那把数据拖到平台按钮上吧。我能理解托管服务省心但Agent这东西评测的复杂度和它本身的复杂度是成正比的。凡是涉及工具调用、多轮状态、业务结果的Agent能力我现在的原则已经固定了一律自建评测纯文本生成质量才考虑平台。建评测体系确实费时间——设计harness、维护数据集、盯失败回流每一项都要投入——但换来的东西也很实在当你对Agent做任何一点改动时你能快速回答它是不是真的变好了而不是盯着一个漂亮的平台分数假装安心。这比什么都重要。