1. 智能体评测是什么为什么突然这么“卷”过去一年AI圈子里最热的关键词已经从单纯的“大模型”悄悄转移到了“AI Agent”智能体。身边不少团队都在做智能体有的是客服机器人有的是代码助手有的是内部知识库问答Agent。模型底座差不多Prompt写得也不差可一旦上了真实业务表现就千差万别。有人归结为“模型玄学”但我更愿意说问题多半出在评测环节太弱。智能体评测简单说就是给AI的“聪明程度”打分判卷。它和传统软件测试完全是两码事——传统测试断言“返回值是不是等于预期”智能体评测要判断“这个多轮对话是否解决问题”“这个工具调用是否合理”“这个推理过程是否让人信服”。没有一套靠谱的评测体系你连“模型升级后到底是变好了还是变坏了”都说不清楚。我去年带团队做过一个工业级智能体评测平台的项目踩了不少坑也沉淀下来一整套从指标设计、任务构造、自动化执行到结果分析的方法论。这篇文章不聊泛泛的概念把整个架构掰开揉碎讲清楚怎么搭评测体系、怎么定指标、怎么写评测用例、怎么做自动化判分、怎么定位模型退化。适合正在做Agent应用、或者准备让AI在业务里担更重角色的人参考。这里说的“工业级”不是实验室里跑几百个Question看个准确率。工业级意味着每天几千个评测任务自动跑、测试集覆盖真实业务分布、判分规则可以追溯到单条用例、能监控线上Agent的badcase回流并且整个体系对研发和业务双方都透明可解释。聊清楚这套东西比背十个评测框架都有用。2. 评测体系整体架构从目标拆解到分层设计2.1 先想清楚你评测的是“模型”还是“智能体”这是第一个容易搞混的地方。纯大模型评测比如MMLU、C-Eval这类评测的是模型本身的“知识”和“推理”能力输入一条query输出一个答案比较标准答案。但智能体评测的对象是“模型Prompt工具记忆编排策略”的整个系统。举一个真实例子。我们有一个客服智能体底层换了一个推理能力更强的大模型结果线上满意度反而降了。查下来发现新模型确实更聪明但它在不需要调用查询工具时开始主动调用导致响应变慢而且它偶尔会过度推理用户问“订单退了吗”它能答出一大段物流链路分析用户反而不耐烦。所以评测的时候如果只测单轮问答根本发现不了这类问题。所以智能体评测体系架构里的第一件事是把评测对象拆开底座的模型能力、中间的编排逻辑、外围的工具与插件、整体的用户体验每一层都要有对应的评测视角。工业级评测体系本质上是一个“多维观测台”而不是一把单一尺子。2.2 工业级评测体系的四层架构拆解我习惯把整套架构分成四层每一层都有明确输入和输出指标层Metrics Layer定义“什么样算好”。包括任务完成度、工具调用准确率、多轮协作效率、安全合规率等。指标必须可量化、可拆解、可追溯。数据层Data Layer管理评测数据集。包括离线测试集、线上badcase回流池、对抗性样本库、人工标注答案库。执行层Execution Layer负责批量跑评测任务、模拟用户行为、调度Agent完成多轮交互、记录执行轨迹。分析层Analysis Layer把原始执行结果加工成可读报告输出得分、趋势、badcase归因、模型对比结论。四层之间通过统一的数据结构串联。我们内部定义了一套“评测事件”标准格式包含session_id、timestamp、user_query、agent_action、thought、observation、final_answer、tool_calls等字段。这套数据结构是整个体系的底座后续做分析、可视化、自动化告警都靠它。用生活化类比来说这套体系就像一个驾校考场指标层是考试大纲倒库、侧方停车、文明驾驶数据层是题库和考试路线执行层是监考人员和考试车辆分析层是成绩单和错题分析。四层缺一不可。2.3 离线评测与线上评测两条腿必须同时走评测体系里最容易犯的错是只做离线评测。离线评测解决的是“版本能不能发”线上评测解决的是“真实用户认不认”。工业级体系必须同时打通这两条链路离线评测主要用固定测试集每次新版本模型或新Prompt上线前强制运行。保证回归不倒退给研发一个“门禁”信号。线上评测通过流量染色、影子模式或A/B实验让一部分真实请求走新Agent逻辑然后采集用户反馈点赞/点踩、转人工率、会话长度等持续监控。在我们的实践里两条链路用同一套指标体系但判定标准不同。离线偏严格比如任务成功率要大于等于上一版本线上偏动态比如转人工率下降3%算显著改善。这样既守住了下限又留出了迭代空间。3. 评测体系的“判卷标准”指标怎么定才科学3.1 四大核心维度完成度、效率、安全、体验很多团队做评测指标列了一堆什么“准确率”“召回率”“BLEU值”都往上堆最后根本不知道怎么加权也没法指导优化。我建议收敛到四个核心维度维度典型指标评价重点任务完成度端到端成功率、目标达成率用户要的事办没办成效率轮次、耗时、工具调用次数是否用最少代价解决问题安全合规违规内容率、敏感操作拦截率能不能守住底线体验质量用户满意度、转人工率、答案可读性用户主观感受好坏这四个维度在不同业务场景里权重不同。代码辅助Agent更看任务完成度和效率安全要求不那么多客服Agent对安全合规和体验要求就很高内部知识库Agent则四项都要看。指标的另一个要求是“可归因”。如果得分下降了必须能定位到是哪个环节出的问题。所以除了顶层的得分我们还会记录大量过程指标比如“首次响应时长”“工具调用失败率”“上下文token消耗量”。这些过程指标是定位问题的重要抓手。3.2 指标计算别想当然要带“过程性”和“容错性”评分体系最忌讳一刀切。比如判定“工具调用正确”如果Agent先调错了工具、后来又调对了最终结果正确那这条到底算对还是算错我们当时的做法是把判定拆成两层结果正确性和过程正确性。结果正确是“用户问题解决了吗”过程正确是“Agent走的路是不是最优的”。最终得分 结果分 × 0.7 过程分 × 0.3权重可以根据业务调。这就避免了一个经典尴尬——过程一团糟但结果碰巧对了的人拿走了和逻辑清晰的Agent一样的满分。举例。问Agent“帮我查下北京明天天气顺便定个明早9点的闹钟”。一个Agent先查天气、再定闹钟工具调用干净利落得满分另一个Agent先试着定闹钟、定错了时间、取消重定、最后又查天气虽然最终两件事都完成了但过程分就会很低。这个过程分在工业环境里很重要因为用户能感知到的“笨拙”往往就体现在过程上。3.3 多轮对话任务的评分策略里程碑式打分单轮问答的评测相对成熟多轮任务就难多了。用户的真实目标可能被分散在多次对话里中间还有大量打断和纠偏。我们用了“里程碑式评分”来解决。做法是把一个复杂任务拆解为多个里程碑节点每个节点单独判定。以订机票任务为例可拆为“获取出行需求”“搜索航班”“确认机票信息”“完成支付引导”四个里程碑。每个里程碑有独立的判定条件和权重。Agent只要达成了某个里程碑就能拿对应分数。最终总分是里程碑得分的加权和。这套方法的优势在于哪怕对话中途用户突然改需求这是真实场景里的高频情况Agent如果能平滑切换到新目标之前完成的有效步骤不会被归零。评测系统只关心每一步该做的有没有做到不要求Agent走一条预设的完美轨迹。对比一下“整条对话全部完美匹配才给分”的做法这套机制对真实场景的适配度明显更高。4. 评测数据从哪来测试集构建是真正的护城河4.1 测试集不是越多越好关键是分布对齐很多团队迷信“测试集越大越准”一口气攒了十万条评测数据结果跑一次评测要十几个小时迭代一次模型根本等不起。工业环境的诉求是“又快又准又有代表性”。我建议控制总规模在20005000条左右但严格要求分布对齐真实业务。什么叫对齐分布如果你的线上请求60%是“订单查询”20%是“退换货”10%是“价格咨询”10%是“人工投诉”那测试集里的比例也应该大致如此。这里面有个细节线上分布是动态的所以至少每个月要从线上日志里重新采样一轮刷新测试集。我们的做法是把线上请求按意图聚类每个类别按比例抽取再经过人工检查去重、去噪声圈定出一套“黄金测试集”。黄金测试集不动用于验收每次版本发布另配一套“动态测试集”每周从线上badcase中抽取增量数据用于发现新问题。4.2 生产资料真实日志、人工构造、对抗样本一个都不能少测试集的数据来源我大概分成三类真实线上日志这是最宝贵的素材。但需要注意脱敏和清洗把用户手机号、地址等私隐信息一律替换。此外很多线上日志的“标准答案”是缺失的需要人工或LLM辅助标注。人工构造由业务专家和产品经理编写。覆盖典型场景、边界场景、异常输入。很多“用户说一半话”的场景只能靠人工构造才能覆盖到。对抗样本与恶意输入包括prompt注入、越狱攻击、敏感话题、超长上下文等。这一块在工业级体系里绝对不能省。上线后出了安全问题代价通常比想象中大得多。三类数据建议按“6:3:1”的比例混入测试集。60%真实日志保证贴近业务30%人工构造覆盖长尾边界10%对抗样本守住安全底线。4.3 标准答案与标注质量谁来判这个卷有了题还得有“标准答案”。单轮问答类任务的标准答案好写多位标注员打分取一致性即可。多轮和工具调用类任务就要费劲得多。我们当时搭了一套“预标注人工抽检一致性校验”的流程先用强模型比如架构更高级的模型生成一轮预标注答案包括结果判定和过程判定。人工标注员只做复核和修正而不是从零开始写。这能节省大量人力。系统定期抽检计算标注一致性。如果两位标注员对同一批数据的评分差异较大说明判定规则有歧义需要返工修订规则。这里有个实操心得标准答案不用写“完美答案”只要写“可接受的最低标准”。比如用户问“你们有什么手机套餐”标准答案只需要包含“有几种价格档位”的核心信息点就不算错。要是拿写文案的标准去要求Agent评测结果会失真——那叫好答案不叫及格答案。5. 自动化评测执行怎么让千个Agent“考生”同时开考5.1 评测执行引擎的核心设计评测执行引擎是整套体系的“考场”。它的任务包括加载测试集、初始化Agent会话、驱动Agent与模拟用户交互、记录全链路日志、调用评分模块打分、汇总结果。我们起初也是一个个用例手动跑后来被逼着做了自动化。核心抽象是“模拟用户Simulated User”模式。每条测试用例除了标准答案还额外定义了“用户行为脚本”首轮说什么、什么情况下追问、什么情况下打断、什么情况下提供额外信息。执行引擎按脚本与Agent交互完整跑完一轮再进入下一条用例。一个被低估的细节是执行引擎必须严格控制时间。Agent模型推理慢一条多轮用例可能要跑几分钟。几千条用例并发跑的时候要设计好任务队列、超时控制、失败重试。我们曾因为上游模型API偶发超时导致评测任务成批失败后来加了指数退避重试机制才稳住。并发调度方面我们用的是异步任务队列按“测试集分组”为单位派发任务。每组跑完后自动汇总结果。这样单个用例失败不会拖垮整场评测模型服务抖动时重跑成本也停留在小组级别。5.2 自动判分器的技术选型规则、模型、混合三种路线判分是评测体系里“争议最多”的环节。按技术路线分有三类规则判定写正则、关键词、逻辑判断适合答案格式很固定的场景。比如“是否生成了订单号”“是否包含退款金额”。优点是稳定、可解释缺点是只能覆盖简单场景。LLM判定用大模型当裁判输入评测用例、Agent回答、标准答案让大模型输出得分和理由。优点是灵活、能处理开放性问题缺点是有不确定性、成本高而且需要防“偏袒”问题——同一个裁判模型可能对同系列的Agent更友好。混合判定先规则过滤命中不了的再用LLM判定。这是工业环境的常见折中方案。我强烈建议从混合模式起步。规则能兜住逻辑强约束的场景LLM负责开放主观评价双方搭配。另外LLM判分时最好让它“先给理由再给分”而不是直接甩一个分。这样人审时能看到推理过程定位问题快得多。5.3 一次评测任务怎么组织从配置到报告的完整流程具体跑一次评测流程大概是配置评测计划选择测试集、指定Agent版本模型、Prompt、工具集的组合、选择评分模板。前置校验检查Agent配置有没有明显错误比如工具API地址失效避免无效跑批。执行评测评测引擎按需并发执行用例实时写入执行日志。自动判分先跑规则判定未命中的走LLM判分。结果汇总与报告生成得分分布、维度雷达图、badcase列表、与基线的对比差异。报告自动推送到相关研发群。告警与门禁如果关键指标跌破阈值评测系统直接拦截发布流程。整套流程需要一个比较清晰的中间存储。我们选了关系型数据库存任务元数据和分析结果、对象存储存原始会话日志。这样的好处是结果可追溯每条用例跑了什么都能查到原始记录这在出线上事故时能快速对账。6. 从评分到归因评测报告怎么指导迭代6.1 Badcase归因三板斧轨迹回溯、步骤定位、群像聚类评测的目标不是打分而是找到问题在哪、然后改掉它。我们内部有一套“Badcase归因三板斧”轨迹回溯把Agent的完整思考过程、每个工具调用的输入输出、每一轮用户反馈全部展开。就像看考试答题卡看它哪一步开始跑偏。步骤定位把失败环节标记到具体模块。是意图识别错了、工具参数填错了、还是答案生成阶段幻觉了不同环节的修复方式完全不同。群像聚类单条badcase不好归纳规律但两百条badcase聚成几类规律就出来了。比如“工具调用参数为null”这类问题多半是Prompt里没有要求解析用户输入中的可选字段“引用文档不存在的内容”则可能是指纹检索召回不足。我们每周固定做一次badcase研判会。把评测系统自动聚类出的Top5问题拉出来逐个确认根因、指定负责人、设定下个迭代的评测目标。这个机制是整个评测体系能持续产生价值的保障——不是晒成绩单而是形成“发现-定位-修复-回归”的闭环。6.2 模型版本对比别只看涨跌要看“收益-代价”曲线评测报告里最常见的就是“V2比V1涨了三个点”。但工业级决策没那么简单。我建议每份报告都附上能力维度的详细对比以及代价指标。举个例子。有次我们升级模型底座任务完成率从82%涨到85%看着很亮眼。但细看发现单次会话的平均耗时涨了40%Token消耗涨了35%。对C端客服场景来说用户等不起成本也扛不住。最后这个版本没有上线而是回去做了推理加速和Prompt裁剪。所以我在报告模板里固定放两个板块收益指标和代价指标。收益指标是任务完成率、体验分等代价指标是延迟、成本、失败率。决策者必须同时看这两块评出来的“最优版本”才是在真实业务里成立的最优解。6.3 评测体系上线后的运营节奏周更、月析、季度复盘体系建完不是终点运转起来才是。我们跑顺之后的运营节奏是每日线上监控Agent的关键指标异常自动告警。比如单日转人工率突然飙升马上拉日志分析是不是新发的Prompt有问题。每周跑一次动态测试集输出周报召开badcase研判会沉淀新样本进入测试集。每月全量回归黄金测试集评估模型和Agent整体趋势校准标注规则。每季度和业务方一起复核指标体系该加的维度加、该砍的指标砍。比如业务上线了新的营销玩法评测体系里就要新增对应的任务类型。这套节奏听起来简单真正难的是坚持。很多团队开始热情高涨跑了一个月就慢慢松了最后评测体系沦为摆设。我的经验是一定要把评测结果和发布门禁绑定——没有评测报告代码合不进主干评测不过线版本不给上线。只有变成硬约束体系才能活下来。7. 工业级评测体系落地案例客服智能体和代码辅助Agent7.1 案例一客服智能体从“不会聊”到“聊得好”我们最先落地的场景是电商客服智能体。早期评判它好不好完全看人工抽检满意度效率低又滞后。评测体系建起来之后我们把线上会话按意图分类抽取了十几类高频场景建测试集每类场景都标注了“目标状态”和“红线行为”。跑了几轮就发现了有价值的问题。比如“订单取消”场景Agent明明能通过工具取消订单但它在取得用户确认前就去操作了导致用户说“我只是问问能不能取消你怎么就取消了”。这个在离线评测里是能查出来的——我们给“非授权操作”设了一票否决规则命中直接判负。后来在Prompt里加了“执行敏感操作前必须二次确认”的约束评测通过率明显提升。另一个收获取决于数据回流。系统上线后每天线上用户对Agent回答的“不喜欢”反馈会回流到badcase池经过清洗后自动扩充到动态测试集。三个月时间测试集从最初的2000条涨到5000条覆盖场景翻了一倍。Agent的端到端解决率从71%提升到86%。7.2 案例二代码辅助Agent的评测思路代码类Agent比客服复杂很多难在“答案对错”不好界定。代码能跑不等于符合预期符合预期不等于风格良好。我们对代码Agent的评测用了分层次策略功能正确性跑一个单元测试集看新生成代码能否通过测试。这是硬指标不过关直接判负。接口规范性检查代码是否遵循了项目的接口定义和命名规范。用静态检查工具自动完成。上下文理解度检查生成代码是否用到了对话里提到的约束条件比如“用Python 3.10语法”“别改公共接口签名”。这个可以通过在测试用例里埋“暗号”来验证——一个必要条件藏在对话历史里模型没提到基本就说明没读到。可维护性用LLM裁判打分从变量命名、函数划分、注释质量等维度给出可读性评价。这套体系跑下来最大的收获是把“能跑”和“能交付”这两个层次分开了。团队不再只为“代码能运行”欢呼而是开始为“既跑得通又读得懂”努力。7.3 从0到1搭建评测体系的路径建议如果你现在正在从零起步我给一条务实的路径第一周从线上日志手动挑100条典型case组建一个最小可用测试集。不要追求复杂指标先把“任务是否完成”的二分类题目做出来。第二周定义5个以内的核心指标搭建最简单的批量跑批脚本输出一份粗糙但一致的报告。第一个月补上自动判分能力建立badcase收集机制形成每周跑一次评测并开研判会的习惯。第二个月接入发布门禁让评测结果对研发流程产生约束力。第三个月再逐步补充对抗样本、效率指标、成本观测等高级能力。不用一上来就追求完美架构。评测体系最大的价值在“开始跑起来”数据越滚越多之后体系自然会长出更高级的形态。8. 常见问题与排查技巧实录8.1 评测得分和线上表现对不上怎么办这是所有团队都会撞的问题。离线明明90分线上用户还是骂声一片。我总结了几种最常见的情况和对策现象可能原因排查方向离线分高、线上满意度低测试集和线上分布脱节对比测试集与线上日志的意图分布离线分高、线上任务失败多线上工具接口不稳定离线Mock掉了评测环境接入真实工具的稳定性注入离线分低、线上还行标注标准过于严格复核标准答案看是否要求太高指标波动大测试集样本量不够增加测试集数量或按困难度分层统计一个容易被忽视的问题评测用的“模拟用户”和真实用户行为差异很大。真实用户会输入错别字、会一句话表达多重意图、会不耐烦地连发消息。如果模拟用户太“礼貌”评测环境就会失真。我们后来从线上日志里抽取真实用户行为作为模拟脚本这才让评测结果和线上表现逐渐对齐。8.2 LLM裁判不稳定怎么处理LLM判分最让人头疼的是不稳定同样一条用例上午跑是80分下午跑是60分。我们的应对策略如下多次采样取均值每一条用例跑3次LLM判分取平均分。成本可控稳定性明显提高。规则锁死硬性条件凡是能用规则判定的比如是否包含订单号、是否命中禁用词一律不走LLM。LLM只处理开放、主观的问题。提供“评分锚点”给裁判模型提供几个不同分数段的示例相当于给它看“评分标准范例”。这能明显减少打分漂移。定期校验裁判质量用一批人工打过分的用例定期测试LLM裁判如果偏离度过大就要更换裁判模型或调整Prompt。我最想强调的还是那条不要把所有希望寄托在LLM裁判上。工业级体系的底色是确定性和可解释性规则能兜住的绝不放给模型。8.3 Prompt改了但评测没变化是白改了吗这种情况也很常见。我的第一反应时常是评测用例没触达Prompt变更影响的功能点。比如你优化了Prompt里“商品推荐”的策略描述但测试集里“商品推荐”意图的用例占比只有2%那整体得分当然看不出变化。解决方案是分层看报告不只关注总分还要按意图维度拆分。最好每个关键意图单独输出一份得分这样Prompt改动是否生效一目了然。另一个可能性是LLM判分粒度不够细看不出差异。可以试试把评分卡从“0-100”改成“维度分总体分”的结构让裁判对回答的完整性、相关性、友好度分别打分。这样Prompt优化的信号更容易被捕捉。我在实操中有一个习惯每次改Prompt先单独抽20条和该改动强相关的用例做定向测评快速验证方向是否正确再跑全量回归。这样迭代速度快得多也不会频繁被全量评测结果“平均”掉信号。9. 最后分享点实操体会这套工业级智能体评测体系从0到1搭建用时大概三个月但真正跑顺、被研发和业务都信任又花了整整一个季度。过程中最深的体会是评测体系的核心不是工具和指标而是“持续运转的机制”。你可以用开源框架快速搭一个评测脚本但如果没有稳定的数据回流、没有发布门禁约束、没有每周研判的节奏再好的指标体系也只是个摆设。另一个体会是“越简单越持久”。指标别贪多三五个月后还能坚持看的核心指标才是真正有价值的指标。我们最开始列了三四十项指标后来沉淀下来、每个人每天都会盯的其实就七八项。如果你正在做智能体相关的工作不管团队大小我都建议尽早把评测这件事提上日程。哪怕先手工跑20条用例、用表格记录得分也比没有强。评测体系这东西种一棵树最好的时间是十年前其次是现在。每一次评测数据的积累都是你后续迭代最可靠的底气。