给大模型打分这件事过去一两年大家其实已经玩得很熟了一堆选择题、推理题、写作题跑完刷个准确率榜单一发模型好坏似乎就盖棺定论了。可等你真正把AI Agent也就是智能体放进生产环境让它去操作业务系统、调API、查库存、写代码再拿同一套“判卷”思路去评判它你会发现处处失灵。这正是“智能体评测”这个领域最近一年突然热闹起来的原因。给AI“聪明”判卷重点早已不是看它“答得对不对”而是要看它能不能在真实任务链里稳定地“办得成事”。这篇文章不是学术论文而是我在工业界搭建智能体评测体系时沉淀下来的一套全景式架构思路。从评测对象分析、指标体系设计、任务库搭建到执行引擎、判定器、回归门禁全链路都会过一遍。适合正在做Agent应用落地、搭AI测试平台、或者为团队设计研发质量门禁的架构师和测试负责人参考。如果你刚入门智能体开发也能靠这套框架建立“怎么判断Agent好不好”的底层认知。1. 为什么“判卷”这件事在智能体这里彻底失灵了1.1 从“答得对”到“办得成”评测对象发生根本变化传统大模型评测本质上是考“知识量”和“推理力”。你给模型一个 prompt它返回一段文字评测系统根据参考答案算相似度、算命中率、算逻辑得分。被测对象的边界非常清晰就是一个静态的模型推理过程。但智能体不一样。一个完整的Agent系统至少包含大模型底座、工具调用层、任务规划器、记忆状态管理以及和外部环境之间的交互协议。底层模型可能还是那个Transformer架构或者MoE架构但评测对象已经变成了一个会“感知-决策-行动-反馈”的动态系统。举个例子一个售后客服Agent接收到“帮我把收货地址改成公司”的指令后它要先解析语义判断需要调用哪个工具确认参数执行修改再回复用户确认。整个过程里模型只是其中的一部分工具是否可用、参数是否合理、多步流程是否有回退机制都会影响最终结果。所以智能体评测的核心对象从“模型”变成了“模型工具策略环境”的组合体。它更像是在给一支球队打分而不是给某个球员打分。如果你还抱着传统LLM评测的思路只对最后的模型输出做文本比对就一定会漏掉大量关键问题。1.2 智能体评测难在哪过程、耦合、不确定性的三重挑战我做了几年评测体系最大的感受是智能体评测比传统模型评测难在三个地方。第一过程不可控。同一个任务一个Agent可能走三步完成另一个Agent可能绕了十步还在原地打转。传统模型评测只看“最终答案”答案对了就是满分但智能体评测必须同时关注“行动轨迹”。轨迹里藏着很多问题工具调用顺序是否合理、有没有做无效查询、失败之后会不会自己纠正、会不会把中间步骤的错误信息当成最终结论输出。这些信息在最终结果里往往看不出来。第二环境强耦合。Agent测试没法完全脱离环境。工具服务的状态、数据库里的数据、上游接口的返回值都会直接影响评测结果。同一个Agent上午测和下午测可能分数都不一样因为环境变了。这给评测的稳定性和可复现性带来了很大麻烦。第三结果有主观性。很多任务并没有唯一正确答案。比如“帮我写一份季度复盘报告”一千个Agent能写出一千种版本。你怎么定义“写得好”靠关键词匹配肯定不行靠模型判定又需要非常细致的 rubrics。这种非标准答案的任务需要一个能兼容主观性和业务目标的多层次评价体系。1.3 一个直观例子同样是“改地址”任务为什么传统方式会漏报问题说个具体场景。我们在测一个售后客服Agent时设计了一个任务用户要求把订单收货地址从“北京市朝阳区某小区”改成“北京市海淀区某园区”同时强调收货人不变。传统测试方案会在最后比对模型回复只要Agent回复“已为您修改收货地址”并且最终地址字段正确就算通过。结果真的测出了问题。这个Agent确实调用了修改地址工具也确实返回了成功信息但仔细检查调用日志才发现它把“收货人”和“详细地址”两个参数的位置传反了。系统层面没有任何报错它自己以为任务完成了用户如果没仔细看可能过两天收到快递才发现收件人变成了那个园区名。这就是结果正确但过程错误的典型例子。最终输出看起来完全正常但内部动作是错的。这也是为什么我坚持认为智能体评测必须同时保留结果指标和过程指标绝不能只盯最后那一段回复。2. 指标体系怎么搭既看结果也要盯过程2.1 结果层与过程层两组核心指标对照既然评测对象变成了一个动态系统指标体系就必须分层设计。我在工业落地时通常把指标分为两层结果层和过程层。结果层回答“任务办成了没有”过程层回答“任务是怎么被办成的”。层级指标名称核心口径适用场景结果层任务完成率目标达成且满足用户约束的任务占比所有任务类型的底线指标结果层完成质量分对非标任务做多维度打分完整性、准确性、友好度内容生成、方案制定类任务结果层用户满意度代理从回复情绪、确认动作、二次反馈等推断用户满意度客服、助手类场景过程层子目标达成率复杂任务拆分为若干子目标后的平均达成比例多步骤、长链路任务过程层路径效率最优步骤数 / 实际步骤数有明确最优解的流程类任务过程层工具调用错误率参数错误、调用失败、调用对象错误次数 / 总调用次数强工具型Agent过程层无效操作次数与任务目标无关的检索、查询、跳转次数所有Agent过程层平均往返轮数完成单个任务所需的用户-Agent交互次数多轮对话型任务结果指标很好理解重点说一下过程指标。子目标达成率是为了解决“大任务只完成了前半段”的情况。比如“先查库存再创建订单最后发通知”这个链路Agent如果只完成了前两步任务完成率会认为失败但子目标达成率是66.7%能更精确地告诉研发团队“卡在最后一步”。路径效率则是用来发现“走弯路”的问题比如同样一个查天气任务最优解是直接调用天气API但有些Agent会先去网页搜索一遍再调API步骤翻倍虽然结果对但成本和延迟都上去了。实际使用中这两层指标要一起看。只看结果层容易漏掉过程劣化只看过程层容易过度优化路径而忽略用户体验。只有两层联动才能完整描述一个Agent的真实水平。2.2 容易被玩坏的三个指标完成率、路径效率、工具调用错误率先说完成率。任务完成率的计算口径是评测体系里最容易被撕扯的地方。如果把“任务完成”定义成二值的成功就是1失败就是0实现简单但失真严重。更合理的做法是引入“部分成功权重”。比如一个任务包含三个必要步骤Agent完成了两步但最后一步失败完成度可能是0.7而不是0。这个权重怎么定需要在任务定义阶段就写清楚而且最好是让业务方参与打分不要让评测团队自己拍脑袋。再说路径效率。路径效率的定义是“最优步骤数 / 实际步骤数”看起来简单但“最优步骤数”怎么来有两个常用方案一是由人工专家预先定义标准路径二是用一组已知的高质量Agent样本跑出基准步骤数。实际开发中两种方案都有坑。人工定义容易跟真实Agent的能力脱节——你设计的“最优”Agent根本走不出来。用基准Agent跑又可能因为Agent本身不够优而把标准拉低。我的做法是定期从线上Top表现Agent的轨迹中提取分位值用P90的步骤数作为“当前阶段的最优参考”再结合人工抽检修正。这样标准是动态的不会因为一次模型大面积升级就彻底失效。最后是工具调用错误率。这个指标最容易误报。我遇到过最典型的场景是Agent因为上游工具短暂超时连续重试了八次八次全部算作“工具调用错误”错误率直接飙到80%。但实际上只有第一次是真正的问题其余七次是合理的重试。所以在统计工具调用错误率时必须做错误归因和错误合并。同一次失败在短时间内连续触发应该合并成一次错误。同时要把错误分成三类参数错误、执行错误、策略错误。参数错误是Agent理解错了参数规则执行错误是工具本身不可用策略错误是不该调工具却调了。三类错误对应的修复动作完全不同混在一起统计会让研发团队无从下手。2.3 评测成本也要进入指标别忘了算账工业级评测体系跟学术评测还有一个很不一样的地方成本。学术评测只关心分数工业评测必须关心每一次跑分花了多少资源。成本指标通常记三样Token消耗、工具调用次数、总耗时。Token消耗决定了大模型推理成本工具调用次数决定了外部服务成本和出错面总耗时则直接关联用户体验和评测管线的吞吐效率。我之前见过一个Agent任务完成率确实比另一个版本高了5个百分点但Token消耗涨了40%。放到线上这意味着每一笔交易都在赔钱。如果评测体系只奖励“更高的完成率”团队就会倾向于在prompt里堆砌各种冗长分析模型变“聪明”的同时也变“贵”了。所以在我的指标清单里一直保留一个“成本效率分”公式很简单结果层得分 / 归一化成本。这个指标不参与最终总分但是会作为雷达图里的一个观察维度展示出来。它最大的作用是约束约束优化方向不能只往“无脑堆推理”的方向走必须同时考虑经济性。另外评测本身也有成本任务库越跑越大几千上万条用例如果全部每天跑开销很可观。所以还需要配合分层执行策略下文的流水线章节会详细讲。3. 评测任务库设计别让题目自己“漏气”3.1 从L1到L4分层任务库怎么搭任务库是整个评测体系的“题库”题库出得不好后面一切指标都是空中楼阁。我搭任务库时习惯分成四个层级跟游戏关卡一样逐级递进。L1是基础能力层考察Agent的指令遵循、单次工具调用、参数解析能力。任务比如“调用天气查询工具返回上海今天的温度”。这一层主要做冒烟测试确保Agent的核心功能没有坏掉。L2是流程串联层考察多工具、多步骤编排能力。任务比如“查一下订单A的物流状态如果已经签收就自动给用户发一条确认短信”。这一层开始出现条件分支Agent需要根据中间结果决定后续动作。L3是决策判断层考察冲突信息处理、优先级排序、不确定性决策。任务比如“用户要求改收件地址到新城市但订单已经开始配送了请给出处理方案并执行可执行的部分”。这一层没有标准操作路径Agent需要自己权衡。L4是长程复杂层考察跨多轮、带环境反馈、需要自我纠错的任务。任务比如“帮用户规划一次包含机票、酒店、景点门票的周末旅行预算5000元以内在用户对方案提出三次调整后输出最终行程”。这种任务跑起来很慢成本很高所以L4用例数量通常最少但权重最高。分层的好处是当Agent某个版本效果回退时你能很快定位是基础能力崩了还是复杂决策崩了不用大海捞针。我建议L1和L2用例数量多一些成本低、跑得快适合做日常回归L3和L4用例数量可以少但必须精适合做发布前的全量验证。3.2 真场景与伪任务决定评测有没有说服力任务库设计时最大的坑是“伪任务”。所谓伪任务是指那种在测试环境里能跑通但一放到真实场景就完全没有参考价值的题目。我举一个例子。设计一个“帮用户查询本月话费账单”的任务如果测试环境里给的是一张非常规整、字段命名友好、数据量极小的模拟表Agent很容易就能查对。但真实生产环境里的账单表可能有几十个字段表名是缩写字段注释缺失还有各种历史数据脏值。Agent在测试环境里PASS上线后大概率还是抓瞎。这就是典型的“伪任务”偏差任务环境和真实场景相差太远评测结果对线上没有指导意义。解决伪任务问题我的原则是“三真一实”真实业务场景、真实工具接口、真实数据样本再加上实际用户话术。当然现实中很难做到百分之百真实数据脱敏、接口模拟总是难免。那就退而求其次凡是模拟环境必须做“失真度评估”。比如数据字段的覆盖率、接口返回格式和线上版本的差异度、异常分支的相似度。失真度高的任务要么重做要么在结论里降权处理防止评测结果被“水题”撑起来。这里还牵扯到一个趋势就是工具协议标准化。现在越来越多的Agent框架支持Model Context Protocol这类标准化协议工具的定义方式和返回格式逐渐统一。这对评测任务库的设计实际上是利好的工具侧越标准你就能把更多精力放在任务逻辑设计上而不是花时间适配各种奇奇怪怪的接口格式。3.3 评测数据防泄漏的底线设计任务库还有一个容易被忽略但极其致命的问题数据泄漏。我见过一个团队评测任务是从某个公开Benchmark上扒下来的。结果模型训练时已经见过这些题目了评测分数自然高得离谱但上线以后效果一塌糊涂。这种情况在智能体评测里更隐蔽因为任务不仅仅是文本还包含工具定义、环境状态、甚至目标路径。这些内容如果泄露到基座模型的训练语料里你根本察觉不到。我的经验是三条纪律。第一任务库要严格分级公开任务集可以做外部对比但不能作为唯一上线依据。第二自建任务集要设置“保活期”定期轮换同一批任务不能无限期使用至少要留20%-30%的“新鲜题目”只用于发布前的最终评估。第三敏感任务要脱敏反转。比如内部系统里的真实操作案例字段名、用户名、公司名全部替换成虚构数据避免Agent只是“记住了某个用户的习惯”而不是真的学会了任务处理。数据泄漏问题没有完美解法但有了这三条底线至少能保证评测结果不会因为“背题”而失真太多。4. 工业级评测流水线从用例装载到报告的工程实现4.1 评测执行引擎的四个核心模块调度、沙箱、轨迹留痕、重试有了任务库接下来就要把整套评测跑起来。工业级评测执行引擎通常包含四个核心模块调度器、沙箱环境、轨迹记录器、重试与超时控制。调度器解决的是“怎么把评测任务高效跑完”的问题。几千条用例如果一条一条串行跑时间上完全不可接受。所以要支持多Agent并发评测而且并发策略要可控。比如L1任务可以开50路并发L4任务可能只能开5路因为复杂任务的资源消耗和外部副作用都更大。调度器还需要做优先级管理比如发布门禁触发的回归评测必须插队执行不能被困在例行评测任务后面。沙箱环境是智能体评测的安全底线。Agent在执行任务时会调用真实工具可能修改数据库、发送消息、创建订单。评测环境必须把这些副作用隔离在沙箱里比如用独立的测试账号、模拟支付网关、只读数据库副本、可控的外部API Mock。我见得太多次因为环境没隔离好Agent在评测时真的给真实用户发了短信、扣了钱的案例。评测可以大胆但环境必须保守。轨迹记录器负责全量留痕。智能体每一次思考、每一次工具调用、工具返回结果、用户模拟器给出的反馈都要按时间线完整记录下来。这不仅是评测判定的依据更是问题定位的核心资产。没有轨迹的评测结果就像一份没有过程分的高考作文你只知道它写得差却说不出差在哪。重试与超时控制则是为了应对真实世界的不稳定。工具调用可能超时第三方接口可能抖动大模型推理偶尔也会抽风。我的做法是给每次评测任务设置重试次数和超时时间超时算一次失败但重试两次后仍然失败才真正判定为“执行失败”。同时保留原始失败上下文避免把偶发性的基础设施故障误判成Agent能力缺陷。4.2 判定器不是简单调一个LLM评测任务跑完之后谁来“判卷”最朴素的想法是调一个大模型来打分。但做过的人都知道直接用LLM当评判者稳定性堪忧。同一个回答今天打90分明天可能打70分换个模型版本分数体系又会飘。工业级评测的判定器必须做三级结构。第一级是规则校验器负责硬性条件的检查。比如结果里是否包含指定字段、工具调用参数是否符合Schema、是否在限定步骤内完成。规则校验的结果是确定的不能有模糊地带。第二级是模型判定器负责软性质量的评估。比如最终方案是否合理、是否考虑了用户隐含需求、语言是否自然。模型判定器可以是基于LLM的自定义打分器Prompt要写得非常细致评分维度要拆开每个维度给锚点示例让打分标准尽量稳定。第三级是人工抽检。无论前两级多完善都需要定期抽样确认判定器和真实预期之间的吻合度。还有一个细节容易被忽略模型判定器必须锁版本。你用来判定的模型一旦版本升级打分风格可能漂移导致这次评测和上次评测之间的分数差异根本不是Agent的变化而是判定模型自己变了。所以我会把判定模型的版本号一起记录到评测报告里同时定期用一套固定的基准样本集回归判定模型本身确保它没有“叛变”。下面是一个我常用的评测用例定义结构字段设计可以用于任务库管理{ task_id: CS-0042, level: L3, description: 用户要求修改收货地址到新城市但订单已进入配送流程, initial_state: { order_status: shipping, current_address: 北京市朝阳区某小区, target_address: 上海市浦东新区某园区 }, tools_available: [query_order, modify_address, cancel_order, notify_user], success_criteria: [ 订单地址未被实际修改, 已向用户说明当前状态, 给出了替代方案 ], rule_checks: [modify_address调用返回值不为success, notify_user调用次数1], model_eval_rubrics: { 方案合理性: [0, 5], 用户沟通友好度: [0, 5], 风险说明完整性: [0, 3] }, mock_data: prepared_db_snapshot_042 }这个结构看起来简单但设计时要想清楚rule_checks必须能覆盖所有“绝对不允许发生”的底线行为model_eval_rubrics的分数权重则代表业务方对每个维度的重视程度。权重不要总是平均分配否则评测报告会变成一个四平八稳但缺乏指导意义的分数。4.3 评测报告与回归门禁让评测变成开发流程的一环评测体系的终点不是产出一堆分数而是推动决策。一张合格的评测报告至少要包含四块内容总分与维度分数、典型成功与失败案例、错误聚类分析、与上一次评测的差异对比。总分和维度分数是给管理层看的案例和错误聚类是给研发团队看的。最怕的是报告里只有总分研发看到一个80分根本不知道怎么下手改。反过来如果报告里能直接给出“72%的错误集中在tool参数解析阶段其中地址类任务占了一半”研发就能快速定位到是工具Schema描述不够清晰还是Agent的指令遵循能力有缺口。这种错误聚类分析看起来简单但价值极高。更关键的是让评测嵌入开发流程形成门禁机制。我在实践中的做法是Agent的任何Prompt改动、工具配置改动、模型版本升级都必须先跑一轮评测通过门槛后才能发布。门槛不设置固定分数线而是设置“相对回归阈值”。举个例子基线版本的综合得分假设是75分新版本的得分允许波动但不能比基线低超过3分且核心过程指标如工具调用错误率、无效操作次数不能恶化超过5%。这种方式既给了优化空间又防止了质量滑坡。门禁机制的实现还要考虑执行策略。不是每次提交都全量跑全套用例那太耗时太烧钱。我的方案是分级执行日常提交只跑L1L2快速集大约百条用例控制在半个小时左右每周跑一次L1-L3全量集发布前才跑包含L4的完整集。分布式调度在这里作用很大评测任务天然适合并行分发把任务切碎丢到多个执行节点上整个评测管线的吞吐量能提升一个量级。5. 那些年我们踩过的坑常见问题与排查实录5.1 五个高频翻车现场速查表问题现象可能原因排查手段同一个用例两次执行结果完全不一样环境状态未隔离或模型采样随机性过大固定随机种子、重置沙箱快照、多次运行取分布任务完成率上升但线上用户投诉反而增多评测判定规则偏向最终结果忽略了过程质量问题引入过程指标、抽检轨迹、增加人工复核工具调用错误率突然飙升但Agent代码没有变动上游工具接口协议升级或Schema描述不一致检查工具版本节点、对比工具Schema变更记录评测报告显示分数波动大无法判断新版本好坏任务集太小或评测用例和判定器版本未锁定扩充任务集、锁定判定模型版本Agent出现“答非所问”却判定为成功规则校验器只检查了字段存在没校验字段合理性增加字段取值校验、引入模型判定器二次确认这几个坑几乎每个做Agent评测的团队都会踩一遍。其中第二个现象最值得警惕。完成率上升但用户体验下降听起来矛盾但在评测指标设计不合理时非常常见。本质上是因为任务完成率只看“目标是否达成”没有看“目标是如何达成的”。Agent可能用了一种取巧的方式达成了目标但给用户留下了不好的体验甚至留下了隐患。这类问题只有把过程指标和轨迹抽检结合起来才能及时发现。5.2 一次真实的评测翻车复盘Agent“变聪明了反而变懒了”之前我们优化过一个售前咨询Agent目标是让它的回答更精炼、更高效。Prompt里加了一句“尽量用最少的步骤完成用户请求不要过度调用工具”。改完之后跑评测结果很有意思任务完成率从76%涨到了81%但工具调用错误率没变用户满意度代理指标却出现了下滑。后来我打开轨迹记录立刻发现了问题。Agent确实变“懒”了很多需要查实时库存的场景它不再调用库存查询工具而是直接根据记忆里的常见信息给出一个模糊回答。比如用户问“这款手机有货吗”之前Agent会查一下库存再回复现在直接回答“这款手机通常是有货的您可以下单试试”。结果就是任务在评测数据里看起来很顺利回复也确实简短高效但放在真实场景里这种回答是致命的用户下单后发现没货体验极差。这个问题最核心的原因就是优化方向只盯住了“完成任务”和“减少步骤”没有守住“信息准确性”这条底线。还好评测体系里保留了工具调用次数和实际查证行为的分析我们才能快速定位到是策略层面出了问题而不是模型本身的指令遵循能力变差了。复盘后我们把Prompt改回“先查证再回答但合并中间的多余环节”同时增加了一个红线规则涉及实时信息时必须调用工具校验否则判失败。这个案例给我的启发是评测指标的设计会直接塑造Agent的行为模式。你鼓励什么、惩罚什么Agent就会朝着那个方向进化。评测体系的本质其实是价值观的落地。5.3 给“判卷”判卷人工抽查与判定器校准是最后一道闸自动评测再怎么成熟人工抽检这一步也不能省。我的经验是每次全量评测结果出来后至少抽5%-10%的案例做人工复核。复核的重点不是看Agent做得好不好而是看“判定器判得对不对”。具体操作上我会让测试同学拿到同样的轨迹记录先自己打一个分再跟判定器的分数做对比。如果两者的吻合度低于90%就说明判定器本身出问题了需要检查是评分规则模糊、判定模型版本漂移还是新的任务类型没有覆盖到。特别要小心一种情况评测任务库本身在扩展新增的任务类型如果跟旧任务的评分标准冲突判定器会不知道怎么处理。我遇到过最典型的一次新增了一批“允许用户拒绝Agent方案并重新提出需求”的用例但旧评分规则里对“未直接执行用户指令”一律扣分导致这批用例的评分全部偏低设定了人工抽检才发现是规则没有跟上任务形态的变化。人工抽检相当于给评测体系装了最后一道闸门。它不一定能发现所有问题但至少能拦住那些系统性偏差确保评测结果始终保持可信。没有这道闸门自动化水平越高翻车风险反而越大因为你可能连自己错在哪都不知道。我个人在实际操作中还有一个习惯就是把每批评测的人工抽检结果整理成一份“判定器校准日志”。日志里记录这次发现了什么偏差、修了什么规则、模型判定器有没有需要微调的地方。这些校准记录积累久了就是一套别处找不到的评测经验库比任何文档都有说服力。如果你准备开始搭智能体评测体系我建议先把“评判规则”和“被测对象”这两件事对齐清楚再动手写调度器。判卷标准要是错了后续跑得再快、再自动化也是在错误的方向上狂奔。 
长河君 · 2026/9/14 16:20:55 · 阅读 1.2k AI Agent评测体系全解析：从结果指标到过程指标的工业级架构
给大模型打分这件事过去一两年大家其实已经玩得很熟了一堆选择题、推理题、写作题跑完刷个准确率榜单一发模型好坏似乎就盖棺定论了。可等你真正把AI Agent也就是智能体放进生产环境让它去操作业务系统、调API、查库存、写代码再拿同一套“判卷”思路去评判它你会发现处处失灵。这正是“智能体评测”这个领域最近一年突然热闹起来的原因。给AI“聪明”判卷重点早已不是看它“答得对不对”而是要看它能不能在真实任务链里稳定地“办得成事”。这篇文章不是学术论文而是我在工业界搭建智能体评测体系时沉淀下来的一套全景式架构思路。从评测对象分析、指标体系设计、任务库搭建到执行引擎、判定器、回归门禁全链路都会过一遍。适合正在做Agent应用落地、搭AI测试平台、或者为团队设计研发质量门禁的架构师和测试负责人参考。如果你刚入门智能体开发也能靠这套框架建立“怎么判断Agent好不好”的底层认知。1. 为什么“判卷”这件事在智能体这里彻底失灵了1.1 从“答得对”到“办得成”评测对象发生根本变化传统大模型评测本质上是考“知识量”和“推理力”。你给模型一个 prompt它返回一段文字评测系统根据参考答案算相似度、算命中率、算逻辑得分。被测对象的边界非常清晰就是一个静态的模型推理过程。但智能体不一样。一个完整的Agent系统至少包含大模型底座、工具调用层、任务规划器、记忆状态管理以及和外部环境之间的交互协议。底层模型可能还是那个Transformer架构或者MoE架构但评测对象已经变成了一个会“感知-决策-行动-反馈”的动态系统。举个例子一个售后客服Agent接收到“帮我把收货地址改成公司”的指令后它要先解析语义判断需要调用哪个工具确认参数执行修改再回复用户确认。整个过程里模型只是其中的一部分工具是否可用、参数是否合理、多步流程是否有回退机制都会影响最终结果。所以智能体评测的核心对象从“模型”变成了“模型工具策略环境”的组合体。它更像是在给一支球队打分而不是给某个球员打分。如果你还抱着传统LLM评测的思路只对最后的模型输出做文本比对就一定会漏掉大量关键问题。1.2 智能体评测难在哪过程、耦合、不确定性的三重挑战我做了几年评测体系最大的感受是智能体评测比传统模型评测难在三个地方。第一过程不可控。同一个任务一个Agent可能走三步完成另一个Agent可能绕了十步还在原地打转。传统模型评测只看“最终答案”答案对了就是满分但智能体评测必须同时关注“行动轨迹”。轨迹里藏着很多问题工具调用顺序是否合理、有没有做无效查询、失败之后会不会自己纠正、会不会把中间步骤的错误信息当成最终结论输出。这些信息在最终结果里往往看不出来。第二环境强耦合。Agent测试没法完全脱离环境。工具服务的状态、数据库里的数据、上游接口的返回值都会直接影响评测结果。同一个Agent上午测和下午测可能分数都不一样因为环境变了。这给评测的稳定性和可复现性带来了很大麻烦。第三结果有主观性。很多任务并没有唯一正确答案。比如“帮我写一份季度复盘报告”一千个Agent能写出一千种版本。你怎么定义“写得好”靠关键词匹配肯定不行靠模型判定又需要非常细致的 rubrics。这种非标准答案的任务需要一个能兼容主观性和业务目标的多层次评价体系。1.3 一个直观例子同样是“改地址”任务为什么传统方式会漏报问题说个具体场景。我们在测一个售后客服Agent时设计了一个任务用户要求把订单收货地址从“北京市朝阳区某小区”改成“北京市海淀区某园区”同时强调收货人不变。传统测试方案会在最后比对模型回复只要Agent回复“已为您修改收货地址”并且最终地址字段正确就算通过。结果真的测出了问题。这个Agent确实调用了修改地址工具也确实返回了成功信息但仔细检查调用日志才发现它把“收货人”和“详细地址”两个参数的位置传反了。系统层面没有任何报错它自己以为任务完成了用户如果没仔细看可能过两天收到快递才发现收件人变成了那个园区名。这就是结果正确但过程错误的典型例子。最终输出看起来完全正常但内部动作是错的。这也是为什么我坚持认为智能体评测必须同时保留结果指标和过程指标绝不能只盯最后那一段回复。2. 指标体系怎么搭既看结果也要盯过程2.1 结果层与过程层两组核心指标对照既然评测对象变成了一个动态系统指标体系就必须分层设计。我在工业落地时通常把指标分为两层结果层和过程层。结果层回答“任务办成了没有”过程层回答“任务是怎么被办成的”。层级指标名称核心口径适用场景结果层任务完成率目标达成且满足用户约束的任务占比所有任务类型的底线指标结果层完成质量分对非标任务做多维度打分完整性、准确性、友好度内容生成、方案制定类任务结果层用户满意度代理从回复情绪、确认动作、二次反馈等推断用户满意度客服、助手类场景过程层子目标达成率复杂任务拆分为若干子目标后的平均达成比例多步骤、长链路任务过程层路径效率最优步骤数 / 实际步骤数有明确最优解的流程类任务过程层工具调用错误率参数错误、调用失败、调用对象错误次数 / 总调用次数强工具型Agent过程层无效操作次数与任务目标无关的检索、查询、跳转次数所有Agent过程层平均往返轮数完成单个任务所需的用户-Agent交互次数多轮对话型任务结果指标很好理解重点说一下过程指标。子目标达成率是为了解决“大任务只完成了前半段”的情况。比如“先查库存再创建订单最后发通知”这个链路Agent如果只完成了前两步任务完成率会认为失败但子目标达成率是66.7%能更精确地告诉研发团队“卡在最后一步”。路径效率则是用来发现“走弯路”的问题比如同样一个查天气任务最优解是直接调用天气API但有些Agent会先去网页搜索一遍再调API步骤翻倍虽然结果对但成本和延迟都上去了。实际使用中这两层指标要一起看。只看结果层容易漏掉过程劣化只看过程层容易过度优化路径而忽略用户体验。只有两层联动才能完整描述一个Agent的真实水平。2.2 容易被玩坏的三个指标完成率、路径效率、工具调用错误率先说完成率。任务完成率的计算口径是评测体系里最容易被撕扯的地方。如果把“任务完成”定义成二值的成功就是1失败就是0实现简单但失真严重。更合理的做法是引入“部分成功权重”。比如一个任务包含三个必要步骤Agent完成了两步但最后一步失败完成度可能是0.7而不是0。这个权重怎么定需要在任务定义阶段就写清楚而且最好是让业务方参与打分不要让评测团队自己拍脑袋。再说路径效率。路径效率的定义是“最优步骤数 / 实际步骤数”看起来简单但“最优步骤数”怎么来有两个常用方案一是由人工专家预先定义标准路径二是用一组已知的高质量Agent样本跑出基准步骤数。实际开发中两种方案都有坑。人工定义容易跟真实Agent的能力脱节——你设计的“最优”Agent根本走不出来。用基准Agent跑又可能因为Agent本身不够优而把标准拉低。我的做法是定期从线上Top表现Agent的轨迹中提取分位值用P90的步骤数作为“当前阶段的最优参考”再结合人工抽检修正。这样标准是动态的不会因为一次模型大面积升级就彻底失效。最后是工具调用错误率。这个指标最容易误报。我遇到过最典型的场景是Agent因为上游工具短暂超时连续重试了八次八次全部算作“工具调用错误”错误率直接飙到80%。但实际上只有第一次是真正的问题其余七次是合理的重试。所以在统计工具调用错误率时必须做错误归因和错误合并。同一次失败在短时间内连续触发应该合并成一次错误。同时要把错误分成三类参数错误、执行错误、策略错误。参数错误是Agent理解错了参数规则执行错误是工具本身不可用策略错误是不该调工具却调了。三类错误对应的修复动作完全不同混在一起统计会让研发团队无从下手。2.3 评测成本也要进入指标别忘了算账工业级评测体系跟学术评测还有一个很不一样的地方成本。学术评测只关心分数工业评测必须关心每一次跑分花了多少资源。成本指标通常记三样Token消耗、工具调用次数、总耗时。Token消耗决定了大模型推理成本工具调用次数决定了外部服务成本和出错面总耗时则直接关联用户体验和评测管线的吞吐效率。我之前见过一个Agent任务完成率确实比另一个版本高了5个百分点但Token消耗涨了40%。放到线上这意味着每一笔交易都在赔钱。如果评测体系只奖励“更高的完成率”团队就会倾向于在prompt里堆砌各种冗长分析模型变“聪明”的同时也变“贵”了。所以在我的指标清单里一直保留一个“成本效率分”公式很简单结果层得分 / 归一化成本。这个指标不参与最终总分但是会作为雷达图里的一个观察维度展示出来。它最大的作用是约束约束优化方向不能只往“无脑堆推理”的方向走必须同时考虑经济性。另外评测本身也有成本任务库越跑越大几千上万条用例如果全部每天跑开销很可观。所以还需要配合分层执行策略下文的流水线章节会详细讲。3. 评测任务库设计别让题目自己“漏气”3.1 从L1到L4分层任务库怎么搭任务库是整个评测体系的“题库”题库出得不好后面一切指标都是空中楼阁。我搭任务库时习惯分成四个层级跟游戏关卡一样逐级递进。L1是基础能力层考察Agent的指令遵循、单次工具调用、参数解析能力。任务比如“调用天气查询工具返回上海今天的温度”。这一层主要做冒烟测试确保Agent的核心功能没有坏掉。L2是流程串联层考察多工具、多步骤编排能力。任务比如“查一下订单A的物流状态如果已经签收就自动给用户发一条确认短信”。这一层开始出现条件分支Agent需要根据中间结果决定后续动作。L3是决策判断层考察冲突信息处理、优先级排序、不确定性决策。任务比如“用户要求改收件地址到新城市但订单已经开始配送了请给出处理方案并执行可执行的部分”。这一层没有标准操作路径Agent需要自己权衡。L4是长程复杂层考察跨多轮、带环境反馈、需要自我纠错的任务。任务比如“帮用户规划一次包含机票、酒店、景点门票的周末旅行预算5000元以内在用户对方案提出三次调整后输出最终行程”。这种任务跑起来很慢成本很高所以L4用例数量通常最少但权重最高。分层的好处是当Agent某个版本效果回退时你能很快定位是基础能力崩了还是复杂决策崩了不用大海捞针。我建议L1和L2用例数量多一些成本低、跑得快适合做日常回归L3和L4用例数量可以少但必须精适合做发布前的全量验证。3.2 真场景与伪任务决定评测有没有说服力任务库设计时最大的坑是“伪任务”。所谓伪任务是指那种在测试环境里能跑通但一放到真实场景就完全没有参考价值的题目。我举一个例子。设计一个“帮用户查询本月话费账单”的任务如果测试环境里给的是一张非常规整、字段命名友好、数据量极小的模拟表Agent很容易就能查对。但真实生产环境里的账单表可能有几十个字段表名是缩写字段注释缺失还有各种历史数据脏值。Agent在测试环境里PASS上线后大概率还是抓瞎。这就是典型的“伪任务”偏差任务环境和真实场景相差太远评测结果对线上没有指导意义。解决伪任务问题我的原则是“三真一实”真实业务场景、真实工具接口、真实数据样本再加上实际用户话术。当然现实中很难做到百分之百真实数据脱敏、接口模拟总是难免。那就退而求其次凡是模拟环境必须做“失真度评估”。比如数据字段的覆盖率、接口返回格式和线上版本的差异度、异常分支的相似度。失真度高的任务要么重做要么在结论里降权处理防止评测结果被“水题”撑起来。这里还牵扯到一个趋势就是工具协议标准化。现在越来越多的Agent框架支持Model Context Protocol这类标准化协议工具的定义方式和返回格式逐渐统一。这对评测任务库的设计实际上是利好的工具侧越标准你就能把更多精力放在任务逻辑设计上而不是花时间适配各种奇奇怪怪的接口格式。3.3 评测数据防泄漏的底线设计任务库还有一个容易被忽略但极其致命的问题数据泄漏。我见过一个团队评测任务是从某个公开Benchmark上扒下来的。结果模型训练时已经见过这些题目了评测分数自然高得离谱但上线以后效果一塌糊涂。这种情况在智能体评测里更隐蔽因为任务不仅仅是文本还包含工具定义、环境状态、甚至目标路径。这些内容如果泄露到基座模型的训练语料里你根本察觉不到。我的经验是三条纪律。第一任务库要严格分级公开任务集可以做外部对比但不能作为唯一上线依据。第二自建任务集要设置“保活期”定期轮换同一批任务不能无限期使用至少要留20%-30%的“新鲜题目”只用于发布前的最终评估。第三敏感任务要脱敏反转。比如内部系统里的真实操作案例字段名、用户名、公司名全部替换成虚构数据避免Agent只是“记住了某个用户的习惯”而不是真的学会了任务处理。数据泄漏问题没有完美解法但有了这三条底线至少能保证评测结果不会因为“背题”而失真太多。4. 工业级评测流水线从用例装载到报告的工程实现4.1 评测执行引擎的四个核心模块调度、沙箱、轨迹留痕、重试有了任务库接下来就要把整套评测跑起来。工业级评测执行引擎通常包含四个核心模块调度器、沙箱环境、轨迹记录器、重试与超时控制。调度器解决的是“怎么把评测任务高效跑完”的问题。几千条用例如果一条一条串行跑时间上完全不可接受。所以要支持多Agent并发评测而且并发策略要可控。比如L1任务可以开50路并发L4任务可能只能开5路因为复杂任务的资源消耗和外部副作用都更大。调度器还需要做优先级管理比如发布门禁触发的回归评测必须插队执行不能被困在例行评测任务后面。沙箱环境是智能体评测的安全底线。Agent在执行任务时会调用真实工具可能修改数据库、发送消息、创建订单。评测环境必须把这些副作用隔离在沙箱里比如用独立的测试账号、模拟支付网关、只读数据库副本、可控的外部API Mock。我见得太多次因为环境没隔离好Agent在评测时真的给真实用户发了短信、扣了钱的案例。评测可以大胆但环境必须保守。轨迹记录器负责全量留痕。智能体每一次思考、每一次工具调用、工具返回结果、用户模拟器给出的反馈都要按时间线完整记录下来。这不仅是评测判定的依据更是问题定位的核心资产。没有轨迹的评测结果就像一份没有过程分的高考作文你只知道它写得差却说不出差在哪。重试与超时控制则是为了应对真实世界的不稳定。工具调用可能超时第三方接口可能抖动大模型推理偶尔也会抽风。我的做法是给每次评测任务设置重试次数和超时时间超时算一次失败但重试两次后仍然失败才真正判定为“执行失败”。同时保留原始失败上下文避免把偶发性的基础设施故障误判成Agent能力缺陷。4.2 判定器不是简单调一个LLM评测任务跑完之后谁来“判卷”最朴素的想法是调一个大模型来打分。但做过的人都知道直接用LLM当评判者稳定性堪忧。同一个回答今天打90分明天可能打70分换个模型版本分数体系又会飘。工业级评测的判定器必须做三级结构。第一级是规则校验器负责硬性条件的检查。比如结果里是否包含指定字段、工具调用参数是否符合Schema、是否在限定步骤内完成。规则校验的结果是确定的不能有模糊地带。第二级是模型判定器负责软性质量的评估。比如最终方案是否合理、是否考虑了用户隐含需求、语言是否自然。模型判定器可以是基于LLM的自定义打分器Prompt要写得非常细致评分维度要拆开每个维度给锚点示例让打分标准尽量稳定。第三级是人工抽检。无论前两级多完善都需要定期抽样确认判定器和真实预期之间的吻合度。还有一个细节容易被忽略模型判定器必须锁版本。你用来判定的模型一旦版本升级打分风格可能漂移导致这次评测和上次评测之间的分数差异根本不是Agent的变化而是判定模型自己变了。所以我会把判定模型的版本号一起记录到评测报告里同时定期用一套固定的基准样本集回归判定模型本身确保它没有“叛变”。下面是一个我常用的评测用例定义结构字段设计可以用于任务库管理{ task_id: CS-0042, level: L3, description: 用户要求修改收货地址到新城市但订单已进入配送流程, initial_state: { order_status: shipping, current_address: 北京市朝阳区某小区, target_address: 上海市浦东新区某园区 }, tools_available: [query_order, modify_address, cancel_order, notify_user], success_criteria: [ 订单地址未被实际修改, 已向用户说明当前状态, 给出了替代方案 ], rule_checks: [modify_address调用返回值不为success, notify_user调用次数1], model_eval_rubrics: { 方案合理性: [0, 5], 用户沟通友好度: [0, 5], 风险说明完整性: [0, 3] }, mock_data: prepared_db_snapshot_042 }这个结构看起来简单但设计时要想清楚rule_checks必须能覆盖所有“绝对不允许发生”的底线行为model_eval_rubrics的分数权重则代表业务方对每个维度的重视程度。权重不要总是平均分配否则评测报告会变成一个四平八稳但缺乏指导意义的分数。4.3 评测报告与回归门禁让评测变成开发流程的一环评测体系的终点不是产出一堆分数而是推动决策。一张合格的评测报告至少要包含四块内容总分与维度分数、典型成功与失败案例、错误聚类分析、与上一次评测的差异对比。总分和维度分数是给管理层看的案例和错误聚类是给研发团队看的。最怕的是报告里只有总分研发看到一个80分根本不知道怎么下手改。反过来如果报告里能直接给出“72%的错误集中在tool参数解析阶段其中地址类任务占了一半”研发就能快速定位到是工具Schema描述不够清晰还是Agent的指令遵循能力有缺口。这种错误聚类分析看起来简单但价值极高。更关键的是让评测嵌入开发流程形成门禁机制。我在实践中的做法是Agent的任何Prompt改动、工具配置改动、模型版本升级都必须先跑一轮评测通过门槛后才能发布。门槛不设置固定分数线而是设置“相对回归阈值”。举个例子基线版本的综合得分假设是75分新版本的得分允许波动但不能比基线低超过3分且核心过程指标如工具调用错误率、无效操作次数不能恶化超过5%。这种方式既给了优化空间又防止了质量滑坡。门禁机制的实现还要考虑执行策略。不是每次提交都全量跑全套用例那太耗时太烧钱。我的方案是分级执行日常提交只跑L1L2快速集大约百条用例控制在半个小时左右每周跑一次L1-L3全量集发布前才跑包含L4的完整集。分布式调度在这里作用很大评测任务天然适合并行分发把任务切碎丢到多个执行节点上整个评测管线的吞吐量能提升一个量级。5. 那些年我们踩过的坑常见问题与排查实录5.1 五个高频翻车现场速查表问题现象可能原因排查手段同一个用例两次执行结果完全不一样环境状态未隔离或模型采样随机性过大固定随机种子、重置沙箱快照、多次运行取分布任务完成率上升但线上用户投诉反而增多评测判定规则偏向最终结果忽略了过程质量问题引入过程指标、抽检轨迹、增加人工复核工具调用错误率突然飙升但Agent代码没有变动上游工具接口协议升级或Schema描述不一致检查工具版本节点、对比工具Schema变更记录评测报告显示分数波动大无法判断新版本好坏任务集太小或评测用例和判定器版本未锁定扩充任务集、锁定判定模型版本Agent出现“答非所问”却判定为成功规则校验器只检查了字段存在没校验字段合理性增加字段取值校验、引入模型判定器二次确认这几个坑几乎每个做Agent评测的团队都会踩一遍。其中第二个现象最值得警惕。完成率上升但用户体验下降听起来矛盾但在评测指标设计不合理时非常常见。本质上是因为任务完成率只看“目标是否达成”没有看“目标是如何达成的”。Agent可能用了一种取巧的方式达成了目标但给用户留下了不好的体验甚至留下了隐患。这类问题只有把过程指标和轨迹抽检结合起来才能及时发现。5.2 一次真实的评测翻车复盘Agent“变聪明了反而变懒了”之前我们优化过一个售前咨询Agent目标是让它的回答更精炼、更高效。Prompt里加了一句“尽量用最少的步骤完成用户请求不要过度调用工具”。改完之后跑评测结果很有意思任务完成率从76%涨到了81%但工具调用错误率没变用户满意度代理指标却出现了下滑。后来我打开轨迹记录立刻发现了问题。Agent确实变“懒”了很多需要查实时库存的场景它不再调用库存查询工具而是直接根据记忆里的常见信息给出一个模糊回答。比如用户问“这款手机有货吗”之前Agent会查一下库存再回复现在直接回答“这款手机通常是有货的您可以下单试试”。结果就是任务在评测数据里看起来很顺利回复也确实简短高效但放在真实场景里这种回答是致命的用户下单后发现没货体验极差。这个问题最核心的原因就是优化方向只盯住了“完成任务”和“减少步骤”没有守住“信息准确性”这条底线。还好评测体系里保留了工具调用次数和实际查证行为的分析我们才能快速定位到是策略层面出了问题而不是模型本身的指令遵循能力变差了。复盘后我们把Prompt改回“先查证再回答但合并中间的多余环节”同时增加了一个红线规则涉及实时信息时必须调用工具校验否则判失败。这个案例给我的启发是评测指标的设计会直接塑造Agent的行为模式。你鼓励什么、惩罚什么Agent就会朝着那个方向进化。评测体系的本质其实是价值观的落地。5.3 给“判卷”判卷人工抽查与判定器校准是最后一道闸自动评测再怎么成熟人工抽检这一步也不能省。我的经验是每次全量评测结果出来后至少抽5%-10%的案例做人工复核。复核的重点不是看Agent做得好不好而是看“判定器判得对不对”。具体操作上我会让测试同学拿到同样的轨迹记录先自己打一个分再跟判定器的分数做对比。如果两者的吻合度低于90%就说明判定器本身出问题了需要检查是评分规则模糊、判定模型版本漂移还是新的任务类型没有覆盖到。特别要小心一种情况评测任务库本身在扩展新增的任务类型如果跟旧任务的评分标准冲突判定器会不知道怎么处理。我遇到过最典型的一次新增了一批“允许用户拒绝Agent方案并重新提出需求”的用例但旧评分规则里对“未直接执行用户指令”一律扣分导致这批用例的评分全部偏低设定了人工抽检才发现是规则没有跟上任务形态的变化。人工抽检相当于给评测体系装了最后一道闸门。它不一定能发现所有问题但至少能拦住那些系统性偏差确保评测结果始终保持可信。没有这道闸门自动化水平越高翻车风险反而越大因为你可能连自己错在哪都不知道。我个人在实际操作中还有一个习惯就是把每批评测的人工抽检结果整理成一份“判定器校准日志”。日志里记录这次发现了什么偏差、修了什么规则、模型判定器有没有需要微调的地方。这些校准记录积累久了就是一套别处找不到的评测经验库比任何文档都有说服力。如果你准备开始搭智能体评测体系我建议先把“评判规则”和“被测对象”这两件事对齐清楚再动手写调度器。判卷标准要是错了后续跑得再快、再自动化也是在错误的方向上狂奔。