1. 一次官方公告引发的思考旧Evals平台的退役意味着什么最近关注到OpenAI官方对旧Evals平台给出了退役倒计时的信号这个消息在Agent开发圈子里讨论度不低。很多人第一反应是那我之前搭的评测流程怎么办但我看到这个消息时脑子里冒出来的却是另一个问题这两年大家都在做Agent真正能把Agent评测这件事做扎实的团队其实少之又少大部分人的评测体系都押在了某一个平台、某一个按钮上。旧Evals平台是什么它是OpenAI推出的一个评估框架用来定义和运行AI模型的评测任务。开发者可以在上面创建测试用例、配置评估逻辑、跑批量评测最终得到一组这个模型/这版Prompt好还是不好的结论。在GPT类模型能力快速迭代的那段时间Evals几乎是不少团队验证模型效果的默认入口。尤其是在做Prompt调优、模型选型、微调效果对比的时候Evals提供了一个看起来相当标准化的流程写用例、跑评测、看分数、做决策。但我得说句实话——Evals这种平台型的评测思路在单纯的模型能力度量场景下是够用的可一旦放到Agent场景里它的局限性就暴露得非常明显。Agent不是一个纯粹的文本输入输出模型它是一套包含规划、工具调用、记忆读写、多轮交互、环境反馈的复杂系统。拿一个只能对输入-输出做打分的平台去度量Agent的好坏就像用体重秤去量一个人的身高工具没错但用错了地方。这次退役倒计时真正值得大家注意的信号不是OpenAI又下架了一个产品而是它在提醒所有做Agent的团队**评测体系必须自己掌握不能押在任何一个平台的上层按钮上。**平台会迭代、会调整方向、会退役这些都不以你的意志为转移但你自己的评测集、评测流程、评测标准才是能持续用的资产。我在和一些创业团队聊的时候发现不少人搭建评测流程的方式就是等平台出功能平台给了评测工具就用平台的平台没给就随便拿几个测试用例手动跑一跑。这种思路在平台功能稳定的时候确实省力可一旦平台变动整个评测体系就跟着瘫痪了。这次OpenAI旧Evals退役正好是重新审视我们评测体系的一个时机。1.1 退役不是下线搞清楚平台变动的真实含义先纠正一个常见的误解OpenAI旧Evals平台退役倒计时不等于马上就不能用了。从官方发布节奏来看平台进入退役倒计时通常意味着会有一个过渡期、迁移期老功能会逐步收窄新功能不会继续大版本迭代最终在某个时间点彻底停止服务。对已经在用这套体系的团队来说最需要关注的是两个节点数据迁移窗口和替代方案的成熟度。我在以前的项目里经历过好几次类似的平台退役不只是AI领域的还包括CI/CD工具、监控平台、数据管道服务一个最大的教训是**平台给你迁移窗口和你自己能完成迁移是两回事。**官方可能给了三个月、半年但你的老评测流程里往往积累了大量历史用例、标签体系、预期结果、踩坑注释这些东西的迁移成本远比你想的高。很多团队都是拖到最后一个月才开始动结果数据格式不兼容、字段对不上、逻辑要重写搞得焦头烂额。所以看到退役倒计时这类消息第一反应应该是立刻盘一下自己的存量资产我们现在有多少评测用例它们是用什么格式组织的它们对平台的依赖程度有多深有多少逻辑是平台独有的API封装出来的把这些搞清楚了才谈得上迁移或者重建。1.2 Evals曾经解决的痛点标准化评测对Agent开发的价值虽然我一直在说平台型评测的局限但客观来讲旧Evals平台当年确实解决了真实存在的痛点。在它之前评测模型效果的方式有多原始很多团队直接肉眼读生成结果一个人说感觉这版好一点另一个人说我觉得上一版更像人话两个人能争半天。Evals这类工具的价值是把好不好这件事从主观感受变成了可执行的判定逻辑定义好评估标准用代码或模型来打分让评测结果可复现、可对比、可追溯。这个思路放在Agent评测里依然是地基。Agent开发的复杂度远高于纯文本生成如果连哪一版Agent表现更好都说不清楚后续的所有优化都是盲人摸象。**评测体系的价值恰恰在于让每一次改动都有清晰的对照而不是靠感觉做决定。**旧Evals平台退役不代表定义评测标准、跑批量对比、看结果决策这套方法论失效了恰恰相反它更需要被沉淀到自己的工程体系里。2. Agent评测的天生难题为什么按一下按钮从来就不是正解既然要自己掌握评测体系就得先想清楚一个问题Agent评测到底难在哪我自己做Agent开发这几年的体感是它的难度跟传统机器学习评测完全不是一个量级。如果你还是抱着写几个测试用例、跑一遍、看准确率的思路去做Agent评测一定会踩坑。2.1 Agent评测与传统模型评测的本质区别传统模型评测比如文本分类、抽取、生成质量打分有一个非常核心的前提**输入输出都是结构化、可判定的。**输入是一段文本输出是一段文本评测逻辑要么是跟标准答案做相似度比对要么是用规则/模型判断生成结果是否满足要求。这种情况下评测集可以相对固定跑分可以做到比较稳定平台化的评测工具也比较好用。但Agent评测面对的是完全不同的图景。一个Agent任务的典型链路是收到用户目标规划执行步骤决定调用哪些工具解析工具返回结果根据结果调整后续动作多轮迭代直到完成任务或失败退出。这里面每一个环节都可能出错而且错的形态千奇百怪可能是规划逻辑不对选了一个错误工具可能是工具调用参数传错可能是解析结果环节把关键信息丢了也可能是多轮交互中Agent忘了用户目标开始自说自话。在这种系统里你没法用一个最终答案去衡量好坏因为过程质量本身就是结果的一部分。我见过一个Agent最终输出的答案看起来没问题但实际执行过程中访问了不该访问的敏感接口这种情况在传统的输入-输出评测里根本发现不了。所以Agent评测必须覆盖过程维度这已经超出了传统平台型评测能承担的范围。2.2 高随机性与场景爆炸跑分结果的真实含义做过Agent评测的朋友应该都有过这种体验同一个测试用例上午跑是成功的下午跑就失败了而且失败原因还不一样。这就是Agent评测的第二大难题——高随机性。大模型本身的采样机制决定了输出有波动加上Agent执行链路上的工具调用、外部服务响应、环境状态变化随机性被层层放大。你今天跑出来的Agent评测分数明天可能就是另一个数字而且波动可能相当大。场景爆炸则是另一个头疼的问题。用户对Agent的诉求几乎是无边界的哪怕你把业务范围限定得很窄实际操作里也会遇到各种边界情况。一个电商客服Agent可能遇到话术阴阳怪气的用户、问不存在的商品、要求退款但订单状态异常、在对话里夹杂辱骂词汇……这些场景一一枚举出来测试集的大小会迅速膨胀到不可维护的程度。这就导致了一个尴尬局面**评测平台擅长的是跑固定用例但Agent真正需要的是覆盖动态场景。**固定用例跑得再溜也覆盖不了真实世界的千奇百怪。所以那些指望在平台上多配几个测试用例就能把Agent评测搞定的想法从根子上就有问题。这也是我一直强调不要押在一个平台按钮上的一个重要原因——平台给你的是标准化能力而Agent评测需要的是场景化能力后者必须自己建设。2.3 平台按钮的诱惑为什么团队容易把评测外包给平台既然Agent评测这么复杂为什么还是有大量团队选择了平台按钮式的评测方式我觉得核心原因是这符合人性对确定性的追求。想象一下这个场景团队里Agent版本迭代了大家对新版本的优劣有分歧老板问数据怎么说。如果你有一套自己的评测流水线答案是我先跑一组回归用例明天给你报告如果你依赖平台按钮答案是我在平台上跑了评测分数提高5个点。后者在当下一瞬间是无比省心的——平台替你承担了评测集的维护、评估逻辑的编写、过程监控的运维你只需要点击运行和阅读报告。这种省心带来的代价是隐性的你并不清楚平台跑的结果具体是基于哪些用例也不清楚分数变化背后是什么原因更不清楚平台对某个场景的判定逻辑是否合理。等平台一变动、一退役你才发现自己对这些评测结果的理解是多么单薄。**评测是手段不是目的目的是理解你的Agent到底行不行、哪里不行。**如果你把整个评测外包给平台你可能连哪里不行都没法定位因为平台不会为你的业务逻辑提供细粒度的诊断。我在团队里做过一个小的对比实验同样是评估一个客服Agent的应对复杂退款咨询能力我一边用平台自带的模型打分评测一边自己写了5个模拟场景结合执行链路日志做人工判断。结果是平台给的分数是82分看起来不错而5个模拟场景里2个彻底失败、2个部分成功、1个勉强通过。为什么差距这么大因为平台的评测集来自于通用场景和我实际业务的需求严重脱节。这个实验之后我彻底放弃了平台按钮式的评测方式。3. 旧Evals平台能做什么、不能做什么把平台能力放到正确的位置我写这篇文章不是想全盘否定旧Evals这类平台而是想给它一个准确定位**它是评测体系里的一块拼图但不是整个体系。**搞清楚它的边界才能更理智地做评测体系的规划。3.1 Evals类平台真正擅长的事情确定性任务的批量验证旧Evals平台这类框架最适合的评测场景其实是目标明确、输出可验证的任务。比如给一段客服对话判断模型是否正确识别了用户的退款意图给一个商品描述判断模型生成的摘要是否包含价格、规格、售后信息这些关键字段给一道数学题判断模型给出的答案是否与标准答案一致。这些场景的共性在于你可以定义客观的、可复现的判定标准并且用例预期是相对稳定的。这类评测的价值在Prompt调优和模型选型时尤其明显。举个例子我要在两个模型之间做选择比如GPT-4代际对比或者开源模型对比就可以把这批确定性任务批量跑一遍对比它们在几十个用例上的通过率、出错类型、稳定性。这个场景下平台化的批量评测效率确实比自己逐条跑高很多而且结果具备统计分析的基础。所以我的建议是**把Evals类平台当成一个确定性回归测试器用来度量模型的基础能力面而不是用它来度量Agent的复合能力。**前者是它擅长的后者是它做不了的。3.2 边界之外的关键维度真实Agent运行时不可测量的部分那Agent评测里真正重要、但旧Evals这类平台根本测不了的是什么结合我自己踩过的坑至少有这几个维度。第一个是工具调用的正确性。Agent的规划再好最终执行还是要落到具体的工具调用上。工具名称选对了没有参数填对没有返回结果解析对没有异常路径处理好了没有这些问题需要一个能感知Agent外部行为的评测环境而不是仅仅感知模型输出文本的评估框架。第二个是多轮交互的连贯性。一个Agent在真实场景下通常需要好几轮对话才能完成任务期间可能穿插用户的打断、信息的补充、情绪的波动。Agent能不能记住目标、能不能纠正错误、能不能重新规划路径这些只有在多轮上下文中才能判断。而平台型评测往往是单轮输入输出根本构造不出来这种链路。第三个是合规与安全维度。Agent在无人监督或者说弱监督的环境下会不会越权操作、要不要调用危险工具、会不会泄露不该泄露的信息这些维度与其说是变好变坏的评测不如说是合格与不合格的红线检查。平台型评测的模型打分机制对于红线类问题往往是无能为力的因为它的判定粒度太粗了。第四个是成本与效率的权衡。同样一个任务Agent A调用5次工具完成Agent B调用15次工具完成表面结果一样但真实落地时Agent B的成本要高得多。这个过程维度的比较也需要自己搭建评测链路去统计平台是不会替你记录的。3.3 平台依赖的风险当评测平台变动你的Agent评估体系怎么办这次OpenAI旧Evals退役让很多团队猛然意识到一个残酷的事实**他们把太多评测资产押在了一个自己不掌控的平台上了。**测试用例是平台格式的评估逻辑是平台API的历史记录是平台数据库里的迁移的时候才发现自己手里剩下的东西少得可怜。平台依赖最大的风险不是平台跑路这种事概率毕竟不大而是平台迭代方向与你的需求脱节。平台方有它自己的产品规划、优先级排序、资源分配它可能某天决定不再维护某个特性可能改变评分逻辑可能调整接口协议这些变动背后都是基于平台方的战略考量而不是你的业务需求。你把评测体系建立在这种不稳定的地基上本质上是在用一个不可控变量来决定你的Agent迭代质量。我在给团队搭评测体系时定了一个基本纪律**平台可以当工具用但评测的核心资产用例集、评估逻辑、基准报告、诊断流程必须自己掌控。**用例集用标准格式管理评估逻辑写在自己的代码仓库里基准报告按固定流程产出并归档。这样即使某个具体平台退役了我损失的只是一部分执行效率而不是整个评测体系的根基。4. 分散评测体系怎么落地从开源框架到自建流程聊完了为什么不能押在一个平台上接下来的问题自然就是那怎么搭一套自己的评测体系。我在这部分会拆解一个不算复杂、但足够实用的落地路径包含框架选型、最小可用方案、评测集设计三个部分。4.1 开源评测框架的选型对比哪些能直接拿来用在动手自建之前可以先看看已经存在的开源评测工具能省不少重复造轮子的功夫。我按使用场景把这些框架分了一下类框架定位适用场景短板OpenAI Evals开源版评测框架Prompt对比、确定性任务批量跑分对Agent过程维度支持弱LangChain的相关评测组件链路评测基于LangChain的Agent链路调试与LangChain绑定较深换框架需改造RagasRAG系统评测检索增强生成场景的质量评估偏RAG通用Agent覆盖不足DeepEval单元/集成测试式评测面向开发者的模型输出断言Agent环境交互模拟需要自己搭promptfooPrompt与模型评测批跑Prompt、模型横向对比、回归测试对多轮Agent场景支持有限自建评测框架自定义需要细粒度过程控制、跨系统集成的复杂Agent评测开发成本高需维护选型的核心判断标准是**你的Agent评测是在验证模型层还是系统层。**如果主要是验证模型层能力直接在开源评测框架上扩展就行如果重点在系统层工具调用链、多轮交互、权限控制、成本效率那开源框架通常只够做一个底座核心逻辑必须自己写。就我个人经验比较推荐的组合是用promptfoo 或 DeepEval 这类工具做模型输出层的批量回归与断言然后**自己搭一个Agent运行器Runner**来承载真实的工具调用链路评测。前者取代了旧Evals平台提供的基础评测能力后者才是面向Agent系统本身的关键建设。4.2 自建评测的最小可用方案第一版不要追求大而全很多团队一听到自建评测体系第一反应就是要做一个庞大的平台系统这其实是另一个极端。我的建议是第一版务必保持最小可用用最朴素的工程手段跑通评测闭环后面再逐步丰富。一个最小可用的Agent评测方案至少包含这几个部分评测用例集用JSON或YAML这类纯文本格式维护每个用例包含任务描述、前置环境配置、预期行为要点、判分说明。Agent执行器Runner一段脚本负责调用Agent完成指定任务并记录完整执行日志包括每一步的规划、工具调用、返回结果、Token消耗。判分器根据预设判定规则可以是规则判断也可以是模型判定或两者结合对执行结果打分。报告生成器把每次评测的运行结果汇总成结构化报告包含通过率、失败用例明细、错误类型分布。这套方案看起来简单但它的核心价值在于**所有评测资产都在你自己的仓库里用例可维护、结果可复盘、逻辑可扩展。**平台方给你再大的变动都影响不到这套体系的根基。下面是一个很简化的Runner伪代码示例帮你建立基本概念# agent_runner.py - 最小可用的Agent评测执行器 import json from agent import create_agent # 你的Agent入口 def run_single_case(agent, case): 执行一个评测用例返回执行记录与结果摘要 logs [] status failed score 0 try: result agent.execute(case[task], recordlogs) status success if result.satisfied(case[expect]) else failed score evaluate_logs(logs, case[expected_behaviors]) except Exception as e: logs.append({error: str(e)}) return { case_id: case[id], status: status, score: score, logs: logs, token_usage: sum(log.get(tokens, 0) for log in logs), } def run_batch(cases_file: str, output_file: str) - None: with open(cases_file, r) as f: cases json.load(f) agent create_agent() results [run_single_case(agent, case) for case in cases] with open(output_file, w) as f: json.dump({ pass_rate: sum(r[status] success for r in results) / len(results), avg_score: sum(r[score] for r in results) / len(results), details: results, }, f, ensure_asciiFalse, indent2) if __name__ __main__: run_batch(cases.json, report.json)实际的Runner会比这个复杂得多尤其是环境配置和行为记录的部分但主体思路就是这样。第一版先跑通后面再慢慢加并发执行、环境隔离、异常恢复这些高级能力。4.3 评测集设计让用例真正反映你的Agent在实际场景中的表现评测集是整个评测体系的灵魂用例设计得好不好直接决定了评测结果有没有参考价值。这里分享几个我总结的实用原则。第一条原则是从真实日志里提炼用例而不是凭空编造。先把Agent在预生产环境里的数千条真实交互日志拉出来筛选出有代表性的任务轨迹典型的成功路径、典型的失败路径、边界情况、异常输入。把这些轨迹整理成结构化的评测用例比拍脑袋编出来的用例有价值得多。我见过不少团队造了一堆看起来很专业的测试用例结果跟实际业务完全脱节评测分数毫无意义。第二条原则是按能力维度分层组织用例而不是按业务模块组织。比如可以把用例集分成这几层基础能力层单轮指令理解、信息抽取、格式生成。工具调用层正确选工具、正确传参数、正确解析返回结果、异常恢复。多轮交互层目标保持、上下文记忆、纠错能力、用户打断处理。安全合规层拒绝越权操作、敏感信息保护、危险场景规避。每层用不同的判分策略基础能力层可以直接用规则断言多轮交互层可能需要模型辅助判定安全合规层则最好是硬性指标不合格就是不过。第三条原则是给用例标注难度和优先级并建立回归基准。核心业务场景对应的用例是P0级别任何版本发布前必须全量跑过边缘场景是P1级别每周或每旬跑一次探索性场景是P2级别后台静默收集数据即可。这样做的好处是在版本迭代频繁的时候你可以用P0用例快速验证Agent是否出了大问题而不是每次都跑全量用例导致效率低下。5. 从跑分到持续评测让Agent评估体系真正融入研发流程最后的这一步是把评测体系从偶尔跑一次的工具变成持续运转的流程。很多团队有评测工具但没评测流程用例写了一堆却只在发版前想起来跑一次这种割裂会让评测的效力大打折扣。5.1 评测集版本化与回归机制每一次变更都有据可查评测集不是写一次就结束的静态资产它会随着业务发展、Agent能力升级、用户反馈积累而持续演化。所以我建议把评测集当成代码一样做版本管理每个用例的增删改都要有记录每次评测跑分对应哪个版本的评测集要可追溯。实际操作中我在仓库里维护了三个层次的版本信息评测集版本、Agent版本、评测报告版本。任意一个Agent改动提交后CI流程自动拉起评测任务把跑分结果与历史基线做对比差异超过阈值的自动告警。这样Agent迭代的每一步都有客观数据的支撑而不是靠感觉变好了来推动决策。回归机制是这个环节的关键。我见过不少团队评测集越加越多但跑一次全量评测的时间成本越来越不可接受最后只能降低评测频率又回到了发版前跑一次的状态。解法有两个方向一是对用例做优先级分层高频跑P0、低频跑P1/P2二是对评测做抽样策略每次跑全量后随机抽取子集与全量结果做相关性分析建立小样本可以近似全量结果的数学模型用统计方法降低评测开销。后者门槛略高但一旦做成就很值得。5.2 预算与成本控制Agent评测不是无限烧钱的过程Agent评测成本比传统模型评测高一个量级这一点必须有清醒的认知。每跑一个用例Agent可能要调用多次大模型API还要触发工具调用链路的计费。评测集如果有一千条用例跑一遍的Token消耗可能是百万级甚至千万级的这个账单在稳定迭代的团队里会膨胀得非常快。我自己的成本控制经验有这几条**控制Token消耗的核心是限制Agent的无效迭代。**我在评测Runner里强制设置了单用例的最大执行步数和最大Token上限Agent超过阈值直接判定为失败不计入无限循环的Token消耗。这是成本控制的第一道防线也是最有效的一道。**评测集采用动态裁剪策略。**如果连续多次评测中某些用例Agent表现都非常稳定无论是稳定通过还是稳定失败就把它从常规评测集里摘除改为低频抽查。把评测资源集中到容易波动、容易被改动影响的用例上成本效率会高得多。**在预生产环境评测时使用成本更低的模型版本。**如果评测目的是验证Agent的系统链路是否正确工具调用、记忆读写、状态管理可以用相对便宜且稳定的模型来做批量验证只在关键节点用最强的模型。当然这要求评测集的设计能区分系统链路问题和模型能力问题所以要把两种用例分开组织。5.3 评测结果如何驱动上线决策从看分数到看信号最后一个想强调的点是**评测结果不能只看总分要从分数里提炼出可执行的信息。**一个Agent评测跑了80分这个数字本身没有意义有意义的是那20分的失败里藏着什么样的信号。我看评测报告的习惯是第一眼看得不是通过率而是失败用例的错误类型分布。是工具调用参数错误居多还是多轮交互丢失上下文居多还是安全合规场景出现越权这些错误分布的迁移比总分更能反映Agent版本变化的影响。举个例子有一次我们的Agent评测总分没变甚至微涨了一点但深入看错误类型分布发现工具调用错误的比例从30%涨到了50%。这说明虽然表面上Agent的输出质量提升了但它在真实执行层面的稳定性在下滑。如果把评测只停留在总分合格这个层面这个隐患就会被掩盖掉等上线后再暴露就晚了。所以在我的团队里评测报告会分成三个层次呈现准入指标红线类用例必须全部通过不满足则阻塞发布。变化指标各能力维度的通过率、失败类型分布与历史基线的对比。业务指标核心场景的端到端成功率、平均轮数、平均成本。这三个层次从能不能发布到哪些方面在变化再到业务影响多大逐步递进。这样的评测结果才能真正成为Agent迭代决策的依据。回到旧Evals平台退役这件事我的建议一直是**用它可以但别依赖它参考它可以但要有自己的体系。**平台解决的是批量跑的效率问题解决不了理解Agent表现的认知问题。Agent开发的复杂度决定了评测必然是一个持续投入的工程环节把它押在任何一个平台按钮上都是不可持续的。趁这次退役倒计时把评测体系收回自己手里用开源框架辅助、用自建Runner承载、用分层评测集和回归机制让它持续运转——这件事做完Agent迭代的效率和质量提升你很快就能感受到。 
长河君 · 2026/10/25 9:43:34 · 阅读 1.2k OpenAI旧Evals退役倒计时：Agent评测为何必须自建体系
1. 一次官方公告引发的思考旧Evals平台的退役意味着什么最近关注到OpenAI官方对旧Evals平台给出了退役倒计时的信号这个消息在Agent开发圈子里讨论度不低。很多人第一反应是那我之前搭的评测流程怎么办但我看到这个消息时脑子里冒出来的却是另一个问题这两年大家都在做Agent真正能把Agent评测这件事做扎实的团队其实少之又少大部分人的评测体系都押在了某一个平台、某一个按钮上。旧Evals平台是什么它是OpenAI推出的一个评估框架用来定义和运行AI模型的评测任务。开发者可以在上面创建测试用例、配置评估逻辑、跑批量评测最终得到一组这个模型/这版Prompt好还是不好的结论。在GPT类模型能力快速迭代的那段时间Evals几乎是不少团队验证模型效果的默认入口。尤其是在做Prompt调优、模型选型、微调效果对比的时候Evals提供了一个看起来相当标准化的流程写用例、跑评测、看分数、做决策。但我得说句实话——Evals这种平台型的评测思路在单纯的模型能力度量场景下是够用的可一旦放到Agent场景里它的局限性就暴露得非常明显。Agent不是一个纯粹的文本输入输出模型它是一套包含规划、工具调用、记忆读写、多轮交互、环境反馈的复杂系统。拿一个只能对输入-输出做打分的平台去度量Agent的好坏就像用体重秤去量一个人的身高工具没错但用错了地方。这次退役倒计时真正值得大家注意的信号不是OpenAI又下架了一个产品而是它在提醒所有做Agent的团队**评测体系必须自己掌握不能押在任何一个平台的上层按钮上。**平台会迭代、会调整方向、会退役这些都不以你的意志为转移但你自己的评测集、评测流程、评测标准才是能持续用的资产。我在和一些创业团队聊的时候发现不少人搭建评测流程的方式就是等平台出功能平台给了评测工具就用平台的平台没给就随便拿几个测试用例手动跑一跑。这种思路在平台功能稳定的时候确实省力可一旦平台变动整个评测体系就跟着瘫痪了。这次OpenAI旧Evals退役正好是重新审视我们评测体系的一个时机。1.1 退役不是下线搞清楚平台变动的真实含义先纠正一个常见的误解OpenAI旧Evals平台退役倒计时不等于马上就不能用了。从官方发布节奏来看平台进入退役倒计时通常意味着会有一个过渡期、迁移期老功能会逐步收窄新功能不会继续大版本迭代最终在某个时间点彻底停止服务。对已经在用这套体系的团队来说最需要关注的是两个节点数据迁移窗口和替代方案的成熟度。我在以前的项目里经历过好几次类似的平台退役不只是AI领域的还包括CI/CD工具、监控平台、数据管道服务一个最大的教训是**平台给你迁移窗口和你自己能完成迁移是两回事。**官方可能给了三个月、半年但你的老评测流程里往往积累了大量历史用例、标签体系、预期结果、踩坑注释这些东西的迁移成本远比你想的高。很多团队都是拖到最后一个月才开始动结果数据格式不兼容、字段对不上、逻辑要重写搞得焦头烂额。所以看到退役倒计时这类消息第一反应应该是立刻盘一下自己的存量资产我们现在有多少评测用例它们是用什么格式组织的它们对平台的依赖程度有多深有多少逻辑是平台独有的API封装出来的把这些搞清楚了才谈得上迁移或者重建。1.2 Evals曾经解决的痛点标准化评测对Agent开发的价值虽然我一直在说平台型评测的局限但客观来讲旧Evals平台当年确实解决了真实存在的痛点。在它之前评测模型效果的方式有多原始很多团队直接肉眼读生成结果一个人说感觉这版好一点另一个人说我觉得上一版更像人话两个人能争半天。Evals这类工具的价值是把好不好这件事从主观感受变成了可执行的判定逻辑定义好评估标准用代码或模型来打分让评测结果可复现、可对比、可追溯。这个思路放在Agent评测里依然是地基。Agent开发的复杂度远高于纯文本生成如果连哪一版Agent表现更好都说不清楚后续的所有优化都是盲人摸象。**评测体系的价值恰恰在于让每一次改动都有清晰的对照而不是靠感觉做决定。**旧Evals平台退役不代表定义评测标准、跑批量对比、看结果决策这套方法论失效了恰恰相反它更需要被沉淀到自己的工程体系里。2. Agent评测的天生难题为什么按一下按钮从来就不是正解既然要自己掌握评测体系就得先想清楚一个问题Agent评测到底难在哪我自己做Agent开发这几年的体感是它的难度跟传统机器学习评测完全不是一个量级。如果你还是抱着写几个测试用例、跑一遍、看准确率的思路去做Agent评测一定会踩坑。2.1 Agent评测与传统模型评测的本质区别传统模型评测比如文本分类、抽取、生成质量打分有一个非常核心的前提**输入输出都是结构化、可判定的。**输入是一段文本输出是一段文本评测逻辑要么是跟标准答案做相似度比对要么是用规则/模型判断生成结果是否满足要求。这种情况下评测集可以相对固定跑分可以做到比较稳定平台化的评测工具也比较好用。但Agent评测面对的是完全不同的图景。一个Agent任务的典型链路是收到用户目标规划执行步骤决定调用哪些工具解析工具返回结果根据结果调整后续动作多轮迭代直到完成任务或失败退出。这里面每一个环节都可能出错而且错的形态千奇百怪可能是规划逻辑不对选了一个错误工具可能是工具调用参数传错可能是解析结果环节把关键信息丢了也可能是多轮交互中Agent忘了用户目标开始自说自话。在这种系统里你没法用一个最终答案去衡量好坏因为过程质量本身就是结果的一部分。我见过一个Agent最终输出的答案看起来没问题但实际执行过程中访问了不该访问的敏感接口这种情况在传统的输入-输出评测里根本发现不了。所以Agent评测必须覆盖过程维度这已经超出了传统平台型评测能承担的范围。2.2 高随机性与场景爆炸跑分结果的真实含义做过Agent评测的朋友应该都有过这种体验同一个测试用例上午跑是成功的下午跑就失败了而且失败原因还不一样。这就是Agent评测的第二大难题——高随机性。大模型本身的采样机制决定了输出有波动加上Agent执行链路上的工具调用、外部服务响应、环境状态变化随机性被层层放大。你今天跑出来的Agent评测分数明天可能就是另一个数字而且波动可能相当大。场景爆炸则是另一个头疼的问题。用户对Agent的诉求几乎是无边界的哪怕你把业务范围限定得很窄实际操作里也会遇到各种边界情况。一个电商客服Agent可能遇到话术阴阳怪气的用户、问不存在的商品、要求退款但订单状态异常、在对话里夹杂辱骂词汇……这些场景一一枚举出来测试集的大小会迅速膨胀到不可维护的程度。这就导致了一个尴尬局面**评测平台擅长的是跑固定用例但Agent真正需要的是覆盖动态场景。**固定用例跑得再溜也覆盖不了真实世界的千奇百怪。所以那些指望在平台上多配几个测试用例就能把Agent评测搞定的想法从根子上就有问题。这也是我一直强调不要押在一个平台按钮上的一个重要原因——平台给你的是标准化能力而Agent评测需要的是场景化能力后者必须自己建设。2.3 平台按钮的诱惑为什么团队容易把评测外包给平台既然Agent评测这么复杂为什么还是有大量团队选择了平台按钮式的评测方式我觉得核心原因是这符合人性对确定性的追求。想象一下这个场景团队里Agent版本迭代了大家对新版本的优劣有分歧老板问数据怎么说。如果你有一套自己的评测流水线答案是我先跑一组回归用例明天给你报告如果你依赖平台按钮答案是我在平台上跑了评测分数提高5个点。后者在当下一瞬间是无比省心的——平台替你承担了评测集的维护、评估逻辑的编写、过程监控的运维你只需要点击运行和阅读报告。这种省心带来的代价是隐性的你并不清楚平台跑的结果具体是基于哪些用例也不清楚分数变化背后是什么原因更不清楚平台对某个场景的判定逻辑是否合理。等平台一变动、一退役你才发现自己对这些评测结果的理解是多么单薄。**评测是手段不是目的目的是理解你的Agent到底行不行、哪里不行。**如果你把整个评测外包给平台你可能连哪里不行都没法定位因为平台不会为你的业务逻辑提供细粒度的诊断。我在团队里做过一个小的对比实验同样是评估一个客服Agent的应对复杂退款咨询能力我一边用平台自带的模型打分评测一边自己写了5个模拟场景结合执行链路日志做人工判断。结果是平台给的分数是82分看起来不错而5个模拟场景里2个彻底失败、2个部分成功、1个勉强通过。为什么差距这么大因为平台的评测集来自于通用场景和我实际业务的需求严重脱节。这个实验之后我彻底放弃了平台按钮式的评测方式。3. 旧Evals平台能做什么、不能做什么把平台能力放到正确的位置我写这篇文章不是想全盘否定旧Evals这类平台而是想给它一个准确定位**它是评测体系里的一块拼图但不是整个体系。**搞清楚它的边界才能更理智地做评测体系的规划。3.1 Evals类平台真正擅长的事情确定性任务的批量验证旧Evals平台这类框架最适合的评测场景其实是目标明确、输出可验证的任务。比如给一段客服对话判断模型是否正确识别了用户的退款意图给一个商品描述判断模型生成的摘要是否包含价格、规格、售后信息这些关键字段给一道数学题判断模型给出的答案是否与标准答案一致。这些场景的共性在于你可以定义客观的、可复现的判定标准并且用例预期是相对稳定的。这类评测的价值在Prompt调优和模型选型时尤其明显。举个例子我要在两个模型之间做选择比如GPT-4代际对比或者开源模型对比就可以把这批确定性任务批量跑一遍对比它们在几十个用例上的通过率、出错类型、稳定性。这个场景下平台化的批量评测效率确实比自己逐条跑高很多而且结果具备统计分析的基础。所以我的建议是**把Evals类平台当成一个确定性回归测试器用来度量模型的基础能力面而不是用它来度量Agent的复合能力。**前者是它擅长的后者是它做不了的。3.2 边界之外的关键维度真实Agent运行时不可测量的部分那Agent评测里真正重要、但旧Evals这类平台根本测不了的是什么结合我自己踩过的坑至少有这几个维度。第一个是工具调用的正确性。Agent的规划再好最终执行还是要落到具体的工具调用上。工具名称选对了没有参数填对没有返回结果解析对没有异常路径处理好了没有这些问题需要一个能感知Agent外部行为的评测环境而不是仅仅感知模型输出文本的评估框架。第二个是多轮交互的连贯性。一个Agent在真实场景下通常需要好几轮对话才能完成任务期间可能穿插用户的打断、信息的补充、情绪的波动。Agent能不能记住目标、能不能纠正错误、能不能重新规划路径这些只有在多轮上下文中才能判断。而平台型评测往往是单轮输入输出根本构造不出来这种链路。第三个是合规与安全维度。Agent在无人监督或者说弱监督的环境下会不会越权操作、要不要调用危险工具、会不会泄露不该泄露的信息这些维度与其说是变好变坏的评测不如说是合格与不合格的红线检查。平台型评测的模型打分机制对于红线类问题往往是无能为力的因为它的判定粒度太粗了。第四个是成本与效率的权衡。同样一个任务Agent A调用5次工具完成Agent B调用15次工具完成表面结果一样但真实落地时Agent B的成本要高得多。这个过程维度的比较也需要自己搭建评测链路去统计平台是不会替你记录的。3.3 平台依赖的风险当评测平台变动你的Agent评估体系怎么办这次OpenAI旧Evals退役让很多团队猛然意识到一个残酷的事实**他们把太多评测资产押在了一个自己不掌控的平台上了。**测试用例是平台格式的评估逻辑是平台API的历史记录是平台数据库里的迁移的时候才发现自己手里剩下的东西少得可怜。平台依赖最大的风险不是平台跑路这种事概率毕竟不大而是平台迭代方向与你的需求脱节。平台方有它自己的产品规划、优先级排序、资源分配它可能某天决定不再维护某个特性可能改变评分逻辑可能调整接口协议这些变动背后都是基于平台方的战略考量而不是你的业务需求。你把评测体系建立在这种不稳定的地基上本质上是在用一个不可控变量来决定你的Agent迭代质量。我在给团队搭评测体系时定了一个基本纪律**平台可以当工具用但评测的核心资产用例集、评估逻辑、基准报告、诊断流程必须自己掌控。**用例集用标准格式管理评估逻辑写在自己的代码仓库里基准报告按固定流程产出并归档。这样即使某个具体平台退役了我损失的只是一部分执行效率而不是整个评测体系的根基。4. 分散评测体系怎么落地从开源框架到自建流程聊完了为什么不能押在一个平台上接下来的问题自然就是那怎么搭一套自己的评测体系。我在这部分会拆解一个不算复杂、但足够实用的落地路径包含框架选型、最小可用方案、评测集设计三个部分。4.1 开源评测框架的选型对比哪些能直接拿来用在动手自建之前可以先看看已经存在的开源评测工具能省不少重复造轮子的功夫。我按使用场景把这些框架分了一下类框架定位适用场景短板OpenAI Evals开源版评测框架Prompt对比、确定性任务批量跑分对Agent过程维度支持弱LangChain的相关评测组件链路评测基于LangChain的Agent链路调试与LangChain绑定较深换框架需改造RagasRAG系统评测检索增强生成场景的质量评估偏RAG通用Agent覆盖不足DeepEval单元/集成测试式评测面向开发者的模型输出断言Agent环境交互模拟需要自己搭promptfooPrompt与模型评测批跑Prompt、模型横向对比、回归测试对多轮Agent场景支持有限自建评测框架自定义需要细粒度过程控制、跨系统集成的复杂Agent评测开发成本高需维护选型的核心判断标准是**你的Agent评测是在验证模型层还是系统层。**如果主要是验证模型层能力直接在开源评测框架上扩展就行如果重点在系统层工具调用链、多轮交互、权限控制、成本效率那开源框架通常只够做一个底座核心逻辑必须自己写。就我个人经验比较推荐的组合是用promptfoo 或 DeepEval 这类工具做模型输出层的批量回归与断言然后**自己搭一个Agent运行器Runner**来承载真实的工具调用链路评测。前者取代了旧Evals平台提供的基础评测能力后者才是面向Agent系统本身的关键建设。4.2 自建评测的最小可用方案第一版不要追求大而全很多团队一听到自建评测体系第一反应就是要做一个庞大的平台系统这其实是另一个极端。我的建议是第一版务必保持最小可用用最朴素的工程手段跑通评测闭环后面再逐步丰富。一个最小可用的Agent评测方案至少包含这几个部分评测用例集用JSON或YAML这类纯文本格式维护每个用例包含任务描述、前置环境配置、预期行为要点、判分说明。Agent执行器Runner一段脚本负责调用Agent完成指定任务并记录完整执行日志包括每一步的规划、工具调用、返回结果、Token消耗。判分器根据预设判定规则可以是规则判断也可以是模型判定或两者结合对执行结果打分。报告生成器把每次评测的运行结果汇总成结构化报告包含通过率、失败用例明细、错误类型分布。这套方案看起来简单但它的核心价值在于**所有评测资产都在你自己的仓库里用例可维护、结果可复盘、逻辑可扩展。**平台方给你再大的变动都影响不到这套体系的根基。下面是一个很简化的Runner伪代码示例帮你建立基本概念# agent_runner.py - 最小可用的Agent评测执行器 import json from agent import create_agent # 你的Agent入口 def run_single_case(agent, case): 执行一个评测用例返回执行记录与结果摘要 logs [] status failed score 0 try: result agent.execute(case[task], recordlogs) status success if result.satisfied(case[expect]) else failed score evaluate_logs(logs, case[expected_behaviors]) except Exception as e: logs.append({error: str(e)}) return { case_id: case[id], status: status, score: score, logs: logs, token_usage: sum(log.get(tokens, 0) for log in logs), } def run_batch(cases_file: str, output_file: str) - None: with open(cases_file, r) as f: cases json.load(f) agent create_agent() results [run_single_case(agent, case) for case in cases] with open(output_file, w) as f: json.dump({ pass_rate: sum(r[status] success for r in results) / len(results), avg_score: sum(r[score] for r in results) / len(results), details: results, }, f, ensure_asciiFalse, indent2) if __name__ __main__: run_batch(cases.json, report.json)实际的Runner会比这个复杂得多尤其是环境配置和行为记录的部分但主体思路就是这样。第一版先跑通后面再慢慢加并发执行、环境隔离、异常恢复这些高级能力。4.3 评测集设计让用例真正反映你的Agent在实际场景中的表现评测集是整个评测体系的灵魂用例设计得好不好直接决定了评测结果有没有参考价值。这里分享几个我总结的实用原则。第一条原则是从真实日志里提炼用例而不是凭空编造。先把Agent在预生产环境里的数千条真实交互日志拉出来筛选出有代表性的任务轨迹典型的成功路径、典型的失败路径、边界情况、异常输入。把这些轨迹整理成结构化的评测用例比拍脑袋编出来的用例有价值得多。我见过不少团队造了一堆看起来很专业的测试用例结果跟实际业务完全脱节评测分数毫无意义。第二条原则是按能力维度分层组织用例而不是按业务模块组织。比如可以把用例集分成这几层基础能力层单轮指令理解、信息抽取、格式生成。工具调用层正确选工具、正确传参数、正确解析返回结果、异常恢复。多轮交互层目标保持、上下文记忆、纠错能力、用户打断处理。安全合规层拒绝越权操作、敏感信息保护、危险场景规避。每层用不同的判分策略基础能力层可以直接用规则断言多轮交互层可能需要模型辅助判定安全合规层则最好是硬性指标不合格就是不过。第三条原则是给用例标注难度和优先级并建立回归基准。核心业务场景对应的用例是P0级别任何版本发布前必须全量跑过边缘场景是P1级别每周或每旬跑一次探索性场景是P2级别后台静默收集数据即可。这样做的好处是在版本迭代频繁的时候你可以用P0用例快速验证Agent是否出了大问题而不是每次都跑全量用例导致效率低下。5. 从跑分到持续评测让Agent评估体系真正融入研发流程最后的这一步是把评测体系从偶尔跑一次的工具变成持续运转的流程。很多团队有评测工具但没评测流程用例写了一堆却只在发版前想起来跑一次这种割裂会让评测的效力大打折扣。5.1 评测集版本化与回归机制每一次变更都有据可查评测集不是写一次就结束的静态资产它会随着业务发展、Agent能力升级、用户反馈积累而持续演化。所以我建议把评测集当成代码一样做版本管理每个用例的增删改都要有记录每次评测跑分对应哪个版本的评测集要可追溯。实际操作中我在仓库里维护了三个层次的版本信息评测集版本、Agent版本、评测报告版本。任意一个Agent改动提交后CI流程自动拉起评测任务把跑分结果与历史基线做对比差异超过阈值的自动告警。这样Agent迭代的每一步都有客观数据的支撑而不是靠感觉变好了来推动决策。回归机制是这个环节的关键。我见过不少团队评测集越加越多但跑一次全量评测的时间成本越来越不可接受最后只能降低评测频率又回到了发版前跑一次的状态。解法有两个方向一是对用例做优先级分层高频跑P0、低频跑P1/P2二是对评测做抽样策略每次跑全量后随机抽取子集与全量结果做相关性分析建立小样本可以近似全量结果的数学模型用统计方法降低评测开销。后者门槛略高但一旦做成就很值得。5.2 预算与成本控制Agent评测不是无限烧钱的过程Agent评测成本比传统模型评测高一个量级这一点必须有清醒的认知。每跑一个用例Agent可能要调用多次大模型API还要触发工具调用链路的计费。评测集如果有一千条用例跑一遍的Token消耗可能是百万级甚至千万级的这个账单在稳定迭代的团队里会膨胀得非常快。我自己的成本控制经验有这几条**控制Token消耗的核心是限制Agent的无效迭代。**我在评测Runner里强制设置了单用例的最大执行步数和最大Token上限Agent超过阈值直接判定为失败不计入无限循环的Token消耗。这是成本控制的第一道防线也是最有效的一道。**评测集采用动态裁剪策略。**如果连续多次评测中某些用例Agent表现都非常稳定无论是稳定通过还是稳定失败就把它从常规评测集里摘除改为低频抽查。把评测资源集中到容易波动、容易被改动影响的用例上成本效率会高得多。**在预生产环境评测时使用成本更低的模型版本。**如果评测目的是验证Agent的系统链路是否正确工具调用、记忆读写、状态管理可以用相对便宜且稳定的模型来做批量验证只在关键节点用最强的模型。当然这要求评测集的设计能区分系统链路问题和模型能力问题所以要把两种用例分开组织。5.3 评测结果如何驱动上线决策从看分数到看信号最后一个想强调的点是**评测结果不能只看总分要从分数里提炼出可执行的信息。**一个Agent评测跑了80分这个数字本身没有意义有意义的是那20分的失败里藏着什么样的信号。我看评测报告的习惯是第一眼看得不是通过率而是失败用例的错误类型分布。是工具调用参数错误居多还是多轮交互丢失上下文居多还是安全合规场景出现越权这些错误分布的迁移比总分更能反映Agent版本变化的影响。举个例子有一次我们的Agent评测总分没变甚至微涨了一点但深入看错误类型分布发现工具调用错误的比例从30%涨到了50%。这说明虽然表面上Agent的输出质量提升了但它在真实执行层面的稳定性在下滑。如果把评测只停留在总分合格这个层面这个隐患就会被掩盖掉等上线后再暴露就晚了。所以在我的团队里评测报告会分成三个层次呈现准入指标红线类用例必须全部通过不满足则阻塞发布。变化指标各能力维度的通过率、失败类型分布与历史基线的对比。业务指标核心场景的端到端成功率、平均轮数、平均成本。这三个层次从能不能发布到哪些方面在变化再到业务影响多大逐步递进。这样的评测结果才能真正成为Agent迭代决策的依据。回到旧Evals平台退役这件事我的建议一直是**用它可以但别依赖它参考它可以但要有自己的体系。**平台解决的是批量跑的效率问题解决不了理解Agent表现的认知问题。Agent开发的复杂度决定了评测必然是一个持续投入的工程环节把它押在任何一个平台按钮上都是不可持续的。趁这次退役倒计时把评测体系收回自己手里用开源框架辅助、用自建Runner承载、用分层评测集和回归机制让它持续运转——这件事做完Agent迭代的效率和质量提升你很快就能感受到。