Evals退役启示录：Agent评测体系如何摆脱平台依赖自建落地

1. 事件还原Evals退役到底意味着什么1.1 先搞清楚Evals是什么很多人一听到“Evals退役”第一反应是“哦又一个老工具要没了”。但Evals在Agent开发社区里的位置比想象中重要得多。它是OpenAI开源的那套评测工具——你可以用它来定义“一组输入、期望行为、打分逻辑”然后自动跑一遍看模型或应用的表现。放在两年前这几乎是LLM应用做回归测试的“默认选项”。具体来说Evals允许你用Python写评测逻辑比如定义一个Eval类在里面指定输入数据、参考答案、评分函数跑完之后生成一份结果报告。它支持的维度看起来也不花哨准确率、召回率、F1、通过率还有一套基于LLM做裁判的打分模板。对一个刚上手Agent项目的团队来说这往往是第一个接触到的“正规评测工具”。我见过不少项目从Demo阶段到上线前夕整个评测体系就建在Evals上。问题也出在这里。当我们把“测评”两个字等同于“某个平台/某个开源库的一个按钮”时就自动放弃了独立的判断力。Evals提供一个很好的起点但它不是终点尤其当你的Agent开始调用工具、访问数据库、操作第三方API之后这种“单平台一键评测”的做法会越来越不合身。1.2 退役通知背后真正值得关注的信息OpenAI给Evals安排退役时间线这件事本身不复杂。复杂的是它释放出的三个信号。第一个信号LLM应用的评估正在从“基础设施”变成“业务能力”。Evals早期承载的是“模型能力摸底”比如让GPT-4跑一批数学题看正确率多少。但现在的Agent项目需要的是“业务闭环验证”——我要验证的不是“模型会不会解这道题”而是“这个Agent能不能完整处理一次客户投诉”。这种验证一定要基于你自己的数据、场景、SLA而不是某个通用评测集。官方退出一款通用评估工具本质上是承认评估该由应用方自己在业务上下文里去构建。第二个信号生态在快速分化。Evals退役的同一时期Langfuse、LangSmith这类可观测性平台在疯狂迭代OpenTelemetry也把GenAI相关语义规范纳入了标准讨论更别说各种针对Agent轨迹回放、工具调用链路追踪的开源方案了。这些工具解决的问题比“跑一批断言”复杂得多它们追踪每一次工具调用、每一个中间状态、每一段上下文变化。你以为你在选“测评工具”实际上你在选“整个质量观测体系的底座”。第三个信号别把鸡蛋放在同一个篮子里。这句话我在很多技术文章里看到过但在Agent评估这件事上它不是鸡汤而是很现实的架构决策。你依赖一个平台的评测按钮意味着你的发布流程、回归周期、报警机制全部被这个按钮卡住。它一退役你的CI就红你的版本就发不出去。这种单点依赖放到系统设计里会被骂放到评估体系里却常常被忽略。1.3 测评按钮依赖症一个容易被忽视的架构隐患“依赖症”这个词听着夸张实际很普遍。很多团队做Agent评测流程是这样的准备一批Prompt → 粘贴到某个平台的网页端 → 点“Run Eval” → 看分数 → 分数没跌就认为版本OK。这个流程最大的问题不是“贴Prompt”这个动作低效而是评估逻辑和业务完全脱节。我在几个团队里都见过类似的局面。他们的Agent已经接入了内部订单系统能查库存、能改地址、能发起退款但他们的评测集还是那批通用客服问答评测指标还是“LLM判断回复是否得体”。一旦有人改了Prompt里某个工具描述或者调整了Agent的Tool Choice策略普通问答评测根本测不出来。真正的风险场景——比如“用户在下单未支付状态下反复催单Agent会不会误触发重复退款”——完全没有覆盖。退役军人只会让这种隐患暴露得更显性原本靠平台按钮硬撑着现在按钮没了才发现自己连一份像样的评测集都没有。所以与其讨论“Evals何时下线”不如借此机会把Agent测评重新设计一遍。这正好回到一个本质问题Agent测评到底要测什么2. 为什么Agent测评不能押在一个平台上2.1 Agent测评的本质评估一个会行动的实习生要理解Agent测评可以先把它类比成管理一个实习生。你不会只考他“回答问题是否标准”——你更关心他接到一个任务后能不能拆解步骤、判断该用哪个工具、发现问题怎么处理、最后交付的结果是否靠谱。即使过程中偶有波折只要最终任务完成、路径合理、没有越权操作你大概率会认为这个实习生“合格”。Agent测评也是同一个逻辑。LLM层面的评估只看“输入输出对”比如给一段Prompt看Response对不对Agent层面的评估必须看“行动轨迹”——Agent做了什么决策、调用了什么工具、传了什么参数、在哪个环节犹豫或回退、最终是否达成目标。这也是为什么我会反复强调Agent测评绝不是一个“按钮”能搞定的事情它需要对过程负责。这也解释了旧Evals这类单库评测工具为什么越来越吃力它的抽象层级还停留在“一个输入、一个输出、一个分数”而Agent是一个多轮、有状态、会与环境交互的闭环系统。硬要用旧的“输入输出打分”框架去套你会损失大量信息工具调用的顺序错了吗中间状态有没有产生脏数据Agent是第一次就成功了还是绕了五圈才成功这些信息恰恰是评估一个“会行动的实习生”的核心依据。2.2 平台绑定带来的三个致命问题拿“测评按钮依赖症”来说我总结过三个最实际的问题建议每个团队自查一遍。第一评测数据集被平台“格式化”。不同平台有不同模板你需要按它的Prompt格式、数据格式去组织评测用例。这会让数据集沾上平台的味道。之后你想切换到自家方案光数据迁移就要花不小的力气更别说那些平台特有的打分参数。到这一步你已经被无形的绑定套牢了。第二打分标准不透明。很多平台用LLM做裁判内部到底用哪个模型、温度多高、有没有针对某个指标做过调试你是看不到的。当分数异常时你根本无从判断是Agent变差了还是裁判模型的参数浮动。这在发布决策上极其被动你没法在一个“黑盒分数”面前做理性判断。第三评测维度被固定。平台通常只会给你几个预设维度正确率、连贯性、相关性。但Agent项目里你可能要测“工具调用是否在三个回合内收敛”“是否在无权限时明确拒绝”“上下文窗口是否被无效记忆占据”——这些维度平台未必支持甚至可能永远不打算支持。这就是我常说的“平台给的标准答案通常不是你的业务答案”。2.3 多维度指标体系Agent测评到底该测什么既然不能押在别人的按钮上那自建评估应该测什么我按自己的项目经验把Agent评估拆成六个维度每个维度都有明确的关注点。功能正确性任务完成率、关键步骤正确率、输出格式合法率。这是最基础的维度但“正确”的定义必须来自业务方。鲁棒性输入扰动了还能不能继续。用户换个说法、换个标点、网络多延迟500ms、第三方接口返回异常Agent是否还能稳定推进。安全边界是否越权调用工具、是否被Prompt Injection忽悠、是否泄露系统提示词里的敏感信息。很多Agent在演示时很好看一放到沙箱环境被恶意用户试两轮就露馅了。成本效率完成一个任务花了多少Token、调用了多少次工具、绕了多少圈。Agent“能完成”是一回事“用最低成本完成”是另一回事这在生产环境直接转化为账单。稳定一致性同样输入跑五次结果是否波动。LLM的非确定性决定了Agent必然有随机波动但我们需要知道波动的上限在哪里特别是“关键业务动作是否稳定触发”。可观测性每次评测的结果是否能复现、轨迹是否完整、日志是否可回放。如果你的评测跑完连中间轨迹都找不到那这个评测体系本身就没有生存价值。这个六维框架不是某个权威机构定的而是我在多个Agent项目里反复调整后留下的。它不是万能公式但至少能帮你摆脱“只看通过率”的惯性。下一部分我会具体讲怎么一步步把评估体系落地接住Evals退役后留下的空位。3. 自建Agent测评体系的实操方案3.1 用可观测性工具搭起评估地基自建评估体系的第一步不是写一大堆测试用例而是先把“数据地基”打好。你要能看到Agent每一次运行的全过程用户输入、模型输出、工具调用、返回结果、上下文变化、Token消耗。没有这些原始数据后续所有评估都是空中楼阁。具体工具上Langfuse是承接Evals退役场景的一个很自然的选择。它支持追踪LLM调用链、记录Token与成本、做Prompt版本管理还能在追踪数据之上挂评分逻辑。LangSmith也提供类似能力自带数据集管理和离线评测功能。如果你偏好完全开源自控可以走OpenTelemetry的LLM语义约定把Span和Trace标准化再对接Jaeger或Grafana做可视化。我个人的建议是评估体系的底座一定要“贴近你现有的监控基建”而不是另起一个平台。如果你已经有了监控告警和日志系统最好把Agent轨迹也跟着送进去。这样你的评测结果和线上运行数据在同一个坐标系里能直接对比“离线测试为什么和线上表现对不上”。我之前遇到过一个案例Agent离线测试通过率90%上线后关键任务完成率只有60%最后查出来的原因就是测试环境的工具Mock返回数据和真实API差异巨大——这种问题只有当你把测试轨迹和线上轨迹放在同一套可观测体系里做对比时才会快速暴露。3.2 Golden Set回归集的建设方法有了数据底座下一步就是建设回归集。没有回归集就谈不上“版本上线前跑一遍”。很多团队的做法是随手攒几十条测试Prompt但这远远不够——我给一个相对完整的做法。先按业务场景分类建任务卡。假设你做一个电商客服Agent场景可能有订单查询、退换货、优惠券计算、物流催单、客诉安抚。每一个场景下再细分出“正常流程”“边界条件”“异常输入”三种类型。比如订单查询场景正常流程用户提供一个合法订单号Agent正确返回订单状态和物流节点。边界条件订单号为空、订单号格式错误、订单不在该用户名下。异常输入用户用特殊编码或拼接字符串试图注入指令Agent是否不理会并继续话术。每一个任务卡要写明三件事任务目标用户最终要什么、期望行为Agent应该做什么和怎么做、验收标准怎么判定成功。这听起来很啰嗦但没有这些信息后面所有打分都无从谈起。Golden Set的规模以我经验来看不要一上来就追求上千条。先把核心场景覆盖住300条左右就够了但要保证每条来源真实——尽量从真实对话日志里捞再手动清洗。那些“我想当然编出来的测试用例”通常只能测出你想当然的正确率。3.3 离线回测与线上灰度双通道评估体系搭起来之后要跑两条线离线回测和线上灰度。离线回测解决“这个版本能不能发”的问题。每次代码变更或Prompt变更在CI里触发一次离线回归。测试Agent在沙箱环境里使用Mock工具链运行所有外部依赖用预置的返回数据模拟保证结果可对比。这里最重要的是“环境隔离”测试环境永远不该连真实数据库、真实支付接口。你在测试环境里跑出来一个退款操作如果它真把你的测试订单退款了那你可就要为这个Bug买单了。线上灰度解决“这个版本在真实世界行不行”的问题。做法很简单新版本Agent只放流给5%或10%的真实用户同时在所有调用链路上打上版本号把这部分流量与全量流量对比。你主要看两个信号一是关键任务完成率是否下降二是有没有出现风险行为比如越权操作、异常的高成本消耗。灰度观察期至少覆盖一次完整的业务周期我通常跑三到五天有异常立即回滚版本。这两条通道合在一起才构成一个闭环。离线回测的快反馈 线上灰度的真实验证互相弥补不足。只看离线你会被Mock环境的“假阳性通过”欺骗只看线上出了问题你连排查的轨迹都不一定完整。3.4 实测中的评分卡设计示例我这里给一个可以直接参考的评分卡模板。不追求满分也不追求学术严谨但很实用。以“订单退款”任务为例一个标准的评估流程会这样打分目标达成度0到1退款最终是否完成。完成1中途放弃0.5彻底失败0。轨迹合规度0或1Agent是否在用户明确授权之后才发起退款是否先做了订单状态校验。不合法直接记为0。工具调用效率0.5到1调用次数是否在合理范围内。比如正常退款流程5次调用以内算1超过5次但小于8次算0.75超过8次算0.5。用户话术质量LLM裁判打分0到1回复是否清晰、是否准确解释退款到账时间。这一步可以用裁判模型但要固定裁判模型版本。综合得分公式可以自己定我先分享一个简单加权版本总分 0.4 * 目标达成度 0.3 * 轨迹合规度 0.1 * 工具调用效率 0.2 * 用户话术质量把每一次评测的得分记录下来形成分数趋势图。这样当某次Prompt改动让总分下降时你能立刻看出是哪一分项掉了。我之前就撞到过一次改了一个关于“退款时效”的Prompt描述目标达成度没问题但用户话术质量分数掉得很厉害因为Agent开始老实地重复一段很长的免责声明——这种细颗粒度的分析用单一通过率绝对看不出来。3.5 设计评测用例时的一个实验细节最后补充一个实验设计上的细节评测用例的输入不要只准备“一条干净的Prompt”。真实用户说话往往是脏的、乱的、带错别字的甚至一上来就连续发三条消息。这个细节在很多平台里没法模拟但自建体系可以轻松做到为同一任务准备多个输入变体比如“hello我昨天买的东西还没到”和“到货了吗”和一段带错别字的旺旺聊天式输入。输入变体越多Agent的鲁棒性验证就越真实。这其实也回应了题目里那句“Agent测评别再押在一个平台按钮上”自建体系的核心不是“自我掌控的优越感”而是你能控制输入变体、控制评分维度、控制环境隔离最终对Agent的成败原因做到真正可解释。4. 常见问题与排查技巧实录4.1 典型翻车现场自建评估体系过程中最容易翻车的有几个地方我分开说。第一把“测试通过率”当成了“用户满意度”。这是最普遍的问题。你辛辛苦苦搭了评估集分很高结果上线之后用户骂声一片。为什么呢因为你的评估任务定义的是“Agent完成动作”而不是“用户是否满意”。用户满意度包含了响应速度、语气、是否站在用户角度解决问题。我在评分卡里把“用户话术质量”单独拎出来就是吃过这个亏。第二用LLM裁判但没固定裁判模型版本。LLM裁判本身有漂移。你上周用GPT-4o做裁判这周平台悄悄换成了另一个模型版本你的历史分数全量失真然后你还在很严肃地分析“本周分数下滑原因”——花了一整天排查最后发现是裁判换了。所以务必把裁判模型的版本也做成配置项并固定下来。第三数据污染。很多人喜欢直接把公开的Benchmark集拿来做Agent评估。但你的Agent如果本身经过了大量通用知识的微调或Few-shot示例覆盖这些公开测试集的题目可能已经被“背下来了”。这就好比你考驾照前天天练习考试线路最后拿高分但上路还是慌。自建Golden Set的核心价值就在于“脏”和“真实”要尽量从你自己的业务数据里生成而不是沿用公开数据集。第四Mock工具数据过于“干净”。我之前提到的那个“离线测试通过90%、线上60%”的案例就是Mock工具数据过于理想导致的。解决方法是在Mock返回里加入异常分支比如接口超时、返回空数组、返回格式多了一个字段。这些异常分支不需要很多每个工具准备两三条就够但别让测试环境永远顺风顺水。4.2 排查流程速查当你的Agent评测分数突然出现异常按什么顺序排查我整理了一个速查顺序省得你乱麻一样到处找原因。第一步回放Trace。先看轨迹本身到底是Agent根本没理解意图还是理解了但工具调用失败。这一步最优先因为它直接定位问题层级。第二步比对Golden Set版本。确认评测集是否有更新。很多时候分数波动不是模型变差了而是有人加了几条新的高难度用例导致分母变大。第三步检查裁判模型版本与评分配置。前面讲过测试环境一致性要严格保证。第四步检查工具Mock返回。看看外部依赖是否有模拟数据变化边界条件是不是混入了不应该出现的异常或大字段。第五步对比线上灰度指标。如果离线测试还看不出问题就去线上灰度版看真实数据大概率能找到“测试环境没覆盖到的现实”。这套流程没那么高深但很管用。它有两次救过我的项目上线一次是Agent突然“失忆”排查发现是上下文裁剪逻辑把关键订单信息裁掉了另一次是工具调用参数序列化出错用户一句话里有多个实体Agent只传了第一个。这两次如果没按流程排查凭直觉乱改Prompt怕是改到天亮也找不到根因。4.3 关于从平台迁移的实用建议最后给正在做迁移的团队三个建议。一是不要一次性清空旧平台的测试数据。把历史评测结果导出、存档至少保存半年以上。它们的价值不在于“和未来对比”而在于历史记录的完整性——当你需要回溯某次线上事故时旧数据能帮你判断“是从什么时候开始异常的”。二是先搭数据底座再谈评估指标。很多团队一上来就说“我们打算自建评测集”然后直接开写测试用例结果写到一半发现“根本没有日志数据可以捞真实案例”又回头补可观测性。顺序反了必然吃苦。三是把评估体系当作一个内部产品来迭代而不是一次性交付。第一次搭建的评测集大概率不完美但只要你保留了“反思与增补”的机制——每季度从线上挑一些典型案例补进Golden Set每次事故后把复盘用例固化成回归用例——你的评估体系就会越来越值钱。结尾我是从Evals还算年轻的时候就开始用它的说实话它帮我的早期项目建立起了“评测应该存在”这个意识这点我一直是感谢的。但经历了两次Agent线上事故、三次测试环境被Mock数据“欺骗”之后我确实越来越确信一件事Agent评估是一个需要自己动手织网的过程平台按钮只不过是最开始那根线头。旧Evals退役只是提醒我们审视自己的评测体系是否还健在如果没有独立评估能力未来还有无数个“平台退役”等着你。如果你还在靠某个网页端的按钮做Agent发布决策我强烈建议把这件事当作一个专项排进最近的迭代计划里。