1. 为什么“好不好用”这件事智能体比传统模型难评得多聊智能体评测之前先说一个我自己的切身体会两年前我评测过一个客服问答模型指标很单纯——准确率、召回率、F1跑完测试集就能交差。但到了智能体时代这套玩法基本失灵了。智能体不是一个静态的模型它是一套“感知—决策—行动”的闭环系统你问它一个问题它可能要调工具、翻文档、写代码、执行操作甚至要跟用户来回多轮对话。评测一个智能体本质上是评测一个系统而不是评测一个函数。这也是为什么“超体”评测体系第一次出现在我们团队内部时大家的第一反应不是兴奋而是头疼。头疼的点有三个第一环境耦合问题。智能体的表现高度依赖它所处的环境——API动不动、数据库里有没有数据、工具返回快不快都直接影响结果。同一个智能体在模拟环境里能考90分接进生产环境可能只有60分。第二任务开放性。传统模型评测是标准答案对照智能体的任务往往没有唯一解。比如“帮用户规划一条周末旅行路线”你没法用一个字符串匹配来判断好坏需要考虑合理性和用户偏好。第三过程与结果分离。有些智能体结果对了但过程乱七八糟——比如反复调同一个接口、问了用户三次相同的问题、绕了五个来回才拿到答案。这类问题在传统评测里根本不会被捕捉到但在真实场景里非常致命。这三个难点不是我编出来的是整个行业在做智能体落地时都会撞上的墙。市面上现在有不少评测工具有的偏重单轮问答的准确性有的偏重Agent轨迹回放但真正把“能力—任务—体验”串成一个完整体系的少之又少。超体评测体系的出发点就是想解决这个断层不只看最终答案也不只看单点能力而是把智能体当作一个完整系统来度量。这篇文章我会把超体评测体系的整体设计、基准构建方法、实操流程和踩坑经验全部摊开讲适合正在做智能体开发、平台选型、或者准备搭内部评测体系的团队参考。不需要你有多深的算法背景只要你在跟智能体打交道这里面讲的东西就能直接用。2. 超体评测体系的分层设计从能力原子到体验价值2.1 为什么不能只用一个综合分很多团队搭评测体系第一反应是搞一个综合评分。我在项目初期也走过这条路——把智能体的表现折算成一个百分制分数看起来简洁用起来想死。因为综合分掩盖了太多信息。一个智能体可能代码生成能力很强但多轮对话老是打断用户也可能任务完成率很高但每轮都要用户重复确认。这些差异全部揉进一个数字里你根本不知道该优化哪一块。超体评测体系的核心思路是分层。我们参考了认知能力评估的逻辑把智能体的评测拆成三个层次每层回答不同的问题能力原子层智能体“会不会”——单个技能的掌握程度。比如工具调用是否合规、检索是否命中、代码是否能跑、上下文是否记得住。任务闭环层智能体“能不能”——完成一个完整任务的成功率、效率和质量。比如“从订单系统拉取数据生成周报”这个端到端流程能不能顺利走完。体验价值层智能体“好不好用”——用户视角的体验和实际价值。比如响应是否自然、操作是否符合预期、是否真正帮用户省了时间。三层各看各的最后再按权重合成形成一套“超体评分卡”。这样拆的好处是当你发现综合分掉了能立刻定位是底层能力崩了还是任务闭环断了还是体验出了问题。2.2 能力原子层把智能体拆成可考的单项技能能力原子层的评测最接近传统的模型评测但又不完全一样。我们把它拆成六项核心能力理解能力、检索能力、工具调用能力、代码执行能力、多轮记忆能力、规划决策能力。每一项都是智能体运行的基本功。以工具调用能力为例我们设计了三档难度来考基础档给出明确指令智能体能不能选对工具并填对参数。比如“调用天气API查询北京明天的温度”正确动作是调用get_weather并传入city北京。进阶档指令不完整智能体能不能通过追问或推断补齐参数。比如“明天出门要不要带伞”正确动作是推断出需要天气信息主动调用工具再结合降雨概率给结论。高难档工具报错或返回异常智能体能不能处理。比如API限流、返回空数据智能体是停下来报错还是换一个工具重试这是工程化能力的分水岭。这里有一个很关键的设计原则能力原子层的题目要“纯”。意思是每道题尽量只考察一项能力避免能力之间的互相干扰。比如考规划能力我们就不要在旁边埋工具调用的坑考记忆能力就不要让任务本身有太多理解歧义。如果题目不纯最后分数低了你也分不清是哪个环节弱。能力原子层的评测结果主要用来指导模型和框架层面的优化。如果发现工具调用普遍拉胯问题可能出在模型本身对工具描述的遵循度也可能出在Framework把工具参数组装错了。这时候要结合错误日志进一步定位评测体系只负责告诉你“哪弱”不负责告诉你“为什么弱”定位是后面的事。2.3 任务闭环层以端到端的成功率论英雄能力原子层考的是“基本功”任务闭环层考的是“完整活”。一个智能体就算单项能力都及格串起来也可能一塌糊涂。任务闭环层的设计逻辑很朴素把真实业务场景里的完整任务抽出来做成标准化任务集让智能体从头到尾跑一遍看能不能在合理的时间内给出可用的结果。任务闭环层的评测指标我建议至少覆盖这四类指标定义备注任务完成率完成的任务数 / 总任务数核心指标但要注意“完成”的判定标准平均完成时长从收到任务到产出终态的时间反映效率过长说明路径规划有问题工具调用次数完成任务过程中调用工具的频次过多可能说明试错成本高人工干预率需要人工介入的任务占比这个指标最能反映真实可用性拿我们做过的“智能客服工单处理”评测来说任务集里有一条经典题目用户投诉“上周买的键盘有一个键不灵敏想退换”。这条任务表面上很简单但实际跑起来智能体需要先理解用户诉求然后查订单、确认是否符合退换政策、生成退换申请、通知用户。每一步都有坑订单系统里可能查不到记录退换政策里可能有限制条件用户可能还要追问“那邮费谁出”。只有跑完整个流程并把结果正确反馈给用户我们才判定这个任务“完成”。中途掉一环哪怕最后回复了一句“抱歉无法处理”也不算。这类任务还有一个特点场景化程度高。题库里的任务不是凭空想出来的而是从真实业务日志里抽出来的。我们当时的方法是拉取过去三个月的客服对话记录把重复出现的问题聚类去重再挑出高频高价值的场景改写成标准化评测任务。这样做出来的基准才真正跟业务对齐而不是模型在实验室里自嗨。2.4 体验价值层用户觉得好用才算真的好这一层是最容易被技术团队忽略的但恰恰是最能左右智能体生死的一层。一个任务完成率高达95%的智能体可能因为每次回复都像机器人念稿用户用一次就跑了反过来一个偶尔出错但沟通很自然的智能体用户容忍度反而更高。这就是体验价值层的意义——衡量“人”感受到的质量。体验价值层我们主要看五个维度自然度、主动性、简洁性、稳定性和可控性。自然度指对话是否像真人有没有生硬的模板感。主动性指智能体会不会在用户表达不清时主动追问在信息不足时主动澄清。简洁性指回复是否啰嗦有没有把一句话能说清的事情扩展成三段。稳定性指同样的任务重复跑十次表现是否波动剧烈。可控性指用户能不能通过自然语言纠正智能体的行为。比如用户说“不要每次都给我发长文要短一点”智能体下一次是不是真的变短了。体验层的评测不能全用自动化需要结合人工评价和LLM辅助打分。我们当时的做法是每一条任务跑完先把对话轨迹交给一个独立的评审模型打分再由人工抽检打分结果。人工评分表要尽量细化不要一个笼统的“好不好”而是针对上面五个维度各打一个1到5分。原因很简单笼统的评分没法指导改进只有细化到维度你才知道要在哪里调prompt、哪里改策略。3. 基准构建方法论从任务采集到评分函数3.1 基准集是评测体系的心脏别用拍脑袋的内容超体评测体系里最重的活儿还不是定指标而是建基准集Benchmark。基准集就是这个体系的“考题库”题库出得好不好直接决定评测结果有没有参考价值。我见过不少团队评测体系搭得花里胡哨基准集却只有几十条拍脑袋编出来的题目最后测出来的分数只能用来发PPT对实际优化毫无帮助。基准集构建我按四步走第一步场景采集。从真实业务里挖需求。最靠谱的来源有三个历史对话日志、产品需求文档、一线运营同学的反馈。我跟团队做过一次统计我们基准集里80%的题目都改自真实用户问题剩下20%是根据业务扩展方向预设的“未来场景”。真实题目的价值在于它天然带着真实用户的表达习惯——问法不标准、信息有缺失、需求有多层——这些恰恰是编造的题目很难模拟出来的。第二步难度分级。每道题按“信息完整度、操作复杂度、异常出现概率”三个维度打分归入L1到L3三档。L1是信息完整、单步操作即可完成的任务L2是信息部分缺失、需要多步规划L3是信息冲突、需要纠错或需要综合判断。分级的意义在于你可以分别看智能体在简单和困难场景下的表现差距。如果一个智能体L1满分、L3只有20%说明它只是个“听话的机器人”算不上一名合格的数字员工。第三步答案与判定规则设计。这也是基准构建里最容易翻车的一步。传统评测有标准答案对就是对错就是错智能体任务做不到。你要给每道题配置判定规则明确什么情况算“完成”、什么情况算“部分完成”、什么情况算“失败”。我建议判定规则包含三个维度终态结果对不对、过程关键节点有没有都走到、有没有违反硬性约束比如不能瞎编数据、不能重复要用户信息。第四步动态更新机制。基准集不是建好就一劳永逸的。业务变了、模型强了、用户问法进化了基准集就得跟着更新。我们每季度做一次基准集审计删掉已经过时的题目、补充新出现的业务场景、上调被模型普遍攻克的难题。这套机制的重要性不亚于基准集本身不然测来测去都是老题分数好看但说服力越来越弱。3.2 评分函数设计如何把多维度结果合并成一个可比较的分数基准集建好了接下来就是怎么算分的问题。我们内部管这一步叫“评分函数设计”它决定了评测结果是“一个看得懂的分数”还是“一堆看不懂的数字”。评分函数的设计原则是分层计算逐层加权各层不互相污染。具体到超体评测体系里三层分数的合成方式如下能力原子层按能力项先各算各的得分率再按业务优先级加权。比如一个客服智能体工具调用和检索能力权重高代码能力权重低反过来一个数据分析智能体代码能力权重就拉高。任务闭环层每条任务按判定规则产出三态结果——成功、部分成功、失败然后折算成分数。成功计1分部分成功计0.5分失败计0分。再加两个惩罚项超时扣分和过多工具调用次数扣分。这一步是平均数最后得到任务闭环层的得分率。体验价值层五个维度各取人工/模型打分的均值再做一次加权合计。最后三层分数按**能力20%、任务50%、体验30%**的权重合成一个超体综合分。为什么任务闭环层占最大权重因为它是智能体真实价值的直接度量能力再强、体验再好任务跑不通一切都是零。能力层权重反而压低到20%因为能力再强也只是“潜力”要转化成闭环成果才有意义。需要提醒的是权重比例不是固定的要结合你的业务目标调整。如果你们做的是偏交互型的智能体体验层的权重可以上调到40%如果是后台自动化执行型智能体体验层甚至可以压到10%把更多权重让给任务闭环层。比例设计的原则就一句话权重反映的是你的业务对每一层价值的真实需求。3.3 评分前先问自己完成的标准到底是什么这是整个基准构建里最容易被低估的问题。我见过太多团队题目出好了答案也标了但到了判分环节两个人对同一道题的判定结果可能完全不一样因为他们对“完成”的理解不同。有人觉得智能体给出了最终答复就算完成有人觉得必须用户确认满意才算完成标准不统一评测结果就没有一致性。我们现在的做法是给每条任务写一份判定卡卡片里写清楚三个东西完成定义、关键过程节点、扣分规则。以“生成销售周报”任务为例判定卡会写完成定义输出了结构化周报包含销售数据汇总和趋势分析且数据与源系统一致。关键过程节点成功连接数据源、成功执行数据查询、成功生成结构化报告。三个节点缺一个不能算成功。扣分规则报告中数据源引用错误扣20分报告结构不完整扣10分查询过程重试超过3次扣5分。判定卡的作用是让整个评测团队“对齐语言”所有人在同一把尺子下工作。这个过程很繁琐尤其当任务集规模上百条的时候写判定卡本身就是一个不小的工作量。但它带来的收益是巨大的——你的评测结果在时间维度上可比这个月跟上个月测同一个任务如果智能体没有变分数就应该是稳定的不会因为换了一个评审人员就忽高忽低。4. 实操过程实录用一个客服智能体的跑分案例讲清楚4.1 从搭建测试环境到执行评测任务集理论讲完了我拿一个实际跑过的案例把整个评测流程串一遍。我们当时评测的对象是一个电商客服智能体核心功能是处理售后咨询和退换货请求。评测目标很明确判断这个智能体能不能从测试环境平稳走到生产环境。第一步是搭建隔离的评测环境。这一步看起来不起眼但有坑。智能体评测对环境稳定性的要求极高你不想让评测结果被网络抖动、第三方API限流这些外部因素干扰。我们的做法是把所有外部依赖全部mock掉——订单系统用本地mock数据支付系统用模拟接口物流信息用静态快照。这样跑出来的结果才能纯粹反映智能体本身的能力而不是反映外部系统的波动。等评测通过以后再开一条生产环境的小流量评测通道用真实系统再跑一轮验证。第二步是准备评测任务集。我们从历史客服会话里抽了200条真实问题按超体体系的规则改写成评测任务。200条任务的分布是这样的L1难度100条L2难度60条L3难度40条。覆盖的场景包括普通退换货、发票申请、物流查询、商品咨询、复杂投诉等十几个类目。每条任务都配好了判定卡约定了完成定义和扣分规则。第三步是执行评测。我们用一套自动化脚本批量触发任务把每轮对话的完整轨迹都记录下来。一个细节评测脚本要记录过程数据而不只是终态数据。包括每一轮的输入输出、调用了哪些工具、工具返回了什么、往返耗时多久。这些过程数据是后面做失败分析的原材料只有终态结果的话出了问题根本没法排查。200条任务跑完大概用了两个多小时。这个速度现在看不算快但当时我们为了保证效果每条任务之间还加了随机间隔避免触发限流。如果你想跑得更快可以把并发调高但前提是评测环境要能扛住并发压力否则自损八百。4.2 关键参数任务条数、并发度、评测次数怎么定跑分过程中的几个关键参数我直接给一组我们验证过的参考值任务条数单次评测不要低于100条。太少的话统计意义不大一条任务的成败就能波动好几个百分点的分数。常规评测建议跑200~500条做发布前的完整验收时我会跑到800条以上。并发度单线程跑最稳但时间成本高。我们用的并发度是8在隔离环境里没出现过互相干扰的问题。并发度也别调得太高智能体如果共享了某个资源并发高了可能产生排队效应影响耗时类指标。重复次数同一套任务集至少跑3次取均值。原因后面细说——LLM有随机性单次分数不能代表真实水平。3次是底线如果3次的极差超过5个百分点说明系统稳定性有问题这时候要加测到5次而不是直接取一个均值糊弄过去。还有一个容易被忽略的参数超时上限。我们给每条任务设了180秒的超时上限超过直接判失败。这个值看你任务的复杂度简单的单轮查询60秒就够复杂的多轮规划类任务可以放到300秒。超时上限的作用是防止某个任务卡死把整个评测流程拖崩。4.3 评测结果分析三层分数解读一个智能体的真实状态跑完分数出来我拿一组当时的真实数据给大家做个解读示范。那版智能体的超体综合分是72.5分。分层看能力原子层得分率81%任务闭环层67.5%体验价值层74.2%。如果不分层你只会看到“72.5分还不错”但这组分数的潜台词其实是另一回事。能力原子层81%说明基本功不算差。但往下钻到每一项发现工具调用能力得分率只有65%其他能力都在85%以上。说明这个智能体在“选对并填对工具”这件事上存在明显短板这是模型本身的遵循度问题也可能是工具描述写得不够清楚。任务闭环层67.5%直接拖了后腿。再往细分L1任务完成率85%L2是45%L3是12%。这个梯度一出结论已经很清楚了——这个智能体只能处理简单场景一遇到信息缺失、需要多步规划或者异常处理的场景就崩远远达不到生产标准。体验价值层的74.2%也有问题。看对话轨迹发现智能体在遇到不确定的情况时倾向于反复道歉一句“抱歉我暂时无法处理”用了七八种说法用户体感非常机械。这个在自动化指标上看不出来但看轨迹就一目了然。基于这三层分析优化方向和优先级其实已经浮出水面先修工具调用能力再补L2场景的规划能力最后调对话策略。没有分层评测这三个优先级你是排不出来的。排不出优先级团队就会陷入东一榔头西一棒子的优化循环这是评测体系带给团队的最大价值——让优化动作有明确靶心。上面这个案例讲的是评测“怎么做”但我还想特别强调一点评测框架不是死的要随着模型能力升级同步迭代。我们团队每个季度都会做一次基准集“难度审计”把那些已经被智能体普遍攻克的L2题目升级为L3把新冒出的真实业务场景补充进来把智能体已经形成条件反射的旧套路题目淘汰掉。这个动作看起来工作量不大但它决定了你的评测体系始终是“衡量天花板”的尺子而不是“贴地板”的装饰。5. 常见问题与排查技巧实录5.1 分数漂移问题同一个智能体分数怎么总是忽高忽低这是我在智能体评测中遇到最频繁的问题。同一个智能体同一个任务集上午跑是75分下午跑变成了70分晚上再跑又变成73分。第一次碰见的时候我还以为评测脚本出了bug查了半天最后发现是智能体本身有随机性。这个问题的根源在于LLM的采样随机性。解码时的温度参数只要不是0同一个Prompt就可能产出不同的回复进而导致整条任务走向不同。深入排查还会发现另一个来源上游工具返回的波动。外呼API响应快慢、检索结果排序变化、数据库中数据变动都会影响智能体的决策路径。解决方案分三层评测层同一任务集跑3次取均值单次结果永远不要作为决策依据。配置层评测用的智能体温度参数固定下来不要每次用不同配置跑。环境层尽量用mock数据来隔离外部波动。如果必须用真实环境选择业务低峰期并固定评测窗口时段我一般选夜里的固定两小时。这三层都做到分数漂移基本能控制在2个百分点以内。如果还在漂大概率是任务集里某些题目的判定规则写得不够清晰评审员的判断出现了分歧这时要回头补判定卡。5.2 LLM-as-Judge的偏差问题让模型给模型打分靠谱吗体验价值层我们引入了LLM辅助打分用独立的评审模型给对话轨迹打自然度和主动性评分。这个方法效率高但有一个我不能不提的坑审评模型的偏好偏差。我们踩到过一次很典型的偏差评审模型对“礼貌用语多”的回复给了更高的自然度分数即使这些礼貌用语让回复变得冗长真人评审给分反而更低。还有一次评审模型青睐带Markdown格式的回复认为“结构清晰”但真实用户反馈这些格式在客服场景里反而显得突兀。校准方法是双管齐下一是人工抽检比例不能低于20%用人工给模型打分的结果做对齐校验二是要建一套偏差检测规则定期统计评审模型与人工的评分差异差异大的维度要调整评审的Prompt甚至直接修正评分逻辑。LLM-as-Judge可用但不能无脑全信它必须被放在一个人工审核的闭环里。5.3 任务集污染题做多了分数会虚高还有一个隐蔽的坑叫任务集污染。智能体如果反复调用同一个评测任务集它可能会“记住”题目的套路。具体表现是任务刚开始智能体就已经预测到下一步要做什么不需要推理就给出了“正确答案”。这种虚高的分数对模型能力的评估只有副作用你会被表面的高分欺骗误以为系统已经达标实际换一套任务立刻现原形。应对思路有两个一是动态化评测任务不是每次都跑完全一样的题目而是从一个大的题目池里随机抽样保证每次评测的题目组合有差异二是定期轮换基准集把评测过的题目和使用过的任务集归档过一段时间再换一批新题。如果你发现某个任务的完成率“莫名其妙”从60%涨到了90%先别急着高兴检查一下是不是这个题目已经被跑过太多遍。5.4 长尾场景的缺失基准做得很全但最大的坑在基准之外最后一个想分享的踩坑经验是长尾场景覆盖。很多基准集的构建逻辑是“有多少数据采多少样”但真实业务里的规律是20%的场景贡献了80%的流量剩下80%的长尾场景很少出现但非常考验智能体的应对能力。举一个我们真实遇到的例子。客服智能体的基准集覆盖了“订单不匹配、商品缺货、物流停滞”等各种长尾问题自认为做得足够全。结果上线一个月后反馈最多的问题竟然是“用户要求用别人的订单号查询自己的物流”——这个需求极简单但基准集里完全没覆盖。智能体每次碰到都处理不好因为它的判断规则没有涉及这种跨界查询的场景。这件事之后我们再建基准集会刻意检查长尾覆盖度。方法很简单拿一份全量历史用户问题做词频聚类把频次低但语义独特的问题单独拎出来看覆盖情况。这种“冷门但真实”的题目比热门考点的价值高得多因为热门考点智能体天天见早就熟了冷门题才是真正的分水岭。6. 评测体系不是一次性工程要跟着智能体一起进化写到这里我个人最想强调的一点是评测体系本身也是一个需要持续维护的产品千万别当成一次性工程。我见过太多团队花大力气搭好一套评测基准上线跑了几轮就开始躺平等到半年后突然发现分数注水、指标失真又重新返工。这个成本远比一开始就建立维护机制要高。根据我们的经验维护评测体系至少需要三个固定动作按月做分数趋势分析看有没有指标出现偏离预期的波动按季度做基准集审计淘汰过时题目、补充新场景每次版本发布前做评测回归把新版本和旧版本在相同基准上对比确保优化没有引入新的回退。最后再分享一个小技巧。我们内部每个评测任务集都设了一个“置信度”标签根据题目的来源标注高、中、低三档。来源是真实用户会话且经过多人标注的题目置信度最高由产品经理编造的未来场景题置信度中等。做版本对比时我们优先看置信度高的题目的分数变化这样得出的结论更有说服力不会被少数几道“臆想题”的成绩带偏方向。智能体的评测没有银弹超体评测体系也只是我们在实践里趟出来的一套相对可用的方法。但有一点我可以确定在智能体快速迭代的当下把“怎么衡量好不好用”这件事想清楚和把智能体本身做出来同样重要。评测不是开发的反义词它是开发的一部分——没有那根衡量标尺所有优化都是盲目的。 
长河君 · 2026/10/27 3:17:36 · 阅读 1.2k 智能体评测体系怎么搭？超体分层评测方法论详解
1. 为什么“好不好用”这件事智能体比传统模型难评得多聊智能体评测之前先说一个我自己的切身体会两年前我评测过一个客服问答模型指标很单纯——准确率、召回率、F1跑完测试集就能交差。但到了智能体时代这套玩法基本失灵了。智能体不是一个静态的模型它是一套“感知—决策—行动”的闭环系统你问它一个问题它可能要调工具、翻文档、写代码、执行操作甚至要跟用户来回多轮对话。评测一个智能体本质上是评测一个系统而不是评测一个函数。这也是为什么“超体”评测体系第一次出现在我们团队内部时大家的第一反应不是兴奋而是头疼。头疼的点有三个第一环境耦合问题。智能体的表现高度依赖它所处的环境——API动不动、数据库里有没有数据、工具返回快不快都直接影响结果。同一个智能体在模拟环境里能考90分接进生产环境可能只有60分。第二任务开放性。传统模型评测是标准答案对照智能体的任务往往没有唯一解。比如“帮用户规划一条周末旅行路线”你没法用一个字符串匹配来判断好坏需要考虑合理性和用户偏好。第三过程与结果分离。有些智能体结果对了但过程乱七八糟——比如反复调同一个接口、问了用户三次相同的问题、绕了五个来回才拿到答案。这类问题在传统评测里根本不会被捕捉到但在真实场景里非常致命。这三个难点不是我编出来的是整个行业在做智能体落地时都会撞上的墙。市面上现在有不少评测工具有的偏重单轮问答的准确性有的偏重Agent轨迹回放但真正把“能力—任务—体验”串成一个完整体系的少之又少。超体评测体系的出发点就是想解决这个断层不只看最终答案也不只看单点能力而是把智能体当作一个完整系统来度量。这篇文章我会把超体评测体系的整体设计、基准构建方法、实操流程和踩坑经验全部摊开讲适合正在做智能体开发、平台选型、或者准备搭内部评测体系的团队参考。不需要你有多深的算法背景只要你在跟智能体打交道这里面讲的东西就能直接用。2. 超体评测体系的分层设计从能力原子到体验价值2.1 为什么不能只用一个综合分很多团队搭评测体系第一反应是搞一个综合评分。我在项目初期也走过这条路——把智能体的表现折算成一个百分制分数看起来简洁用起来想死。因为综合分掩盖了太多信息。一个智能体可能代码生成能力很强但多轮对话老是打断用户也可能任务完成率很高但每轮都要用户重复确认。这些差异全部揉进一个数字里你根本不知道该优化哪一块。超体评测体系的核心思路是分层。我们参考了认知能力评估的逻辑把智能体的评测拆成三个层次每层回答不同的问题能力原子层智能体“会不会”——单个技能的掌握程度。比如工具调用是否合规、检索是否命中、代码是否能跑、上下文是否记得住。任务闭环层智能体“能不能”——完成一个完整任务的成功率、效率和质量。比如“从订单系统拉取数据生成周报”这个端到端流程能不能顺利走完。体验价值层智能体“好不好用”——用户视角的体验和实际价值。比如响应是否自然、操作是否符合预期、是否真正帮用户省了时间。三层各看各的最后再按权重合成形成一套“超体评分卡”。这样拆的好处是当你发现综合分掉了能立刻定位是底层能力崩了还是任务闭环断了还是体验出了问题。2.2 能力原子层把智能体拆成可考的单项技能能力原子层的评测最接近传统的模型评测但又不完全一样。我们把它拆成六项核心能力理解能力、检索能力、工具调用能力、代码执行能力、多轮记忆能力、规划决策能力。每一项都是智能体运行的基本功。以工具调用能力为例我们设计了三档难度来考基础档给出明确指令智能体能不能选对工具并填对参数。比如“调用天气API查询北京明天的温度”正确动作是调用get_weather并传入city北京。进阶档指令不完整智能体能不能通过追问或推断补齐参数。比如“明天出门要不要带伞”正确动作是推断出需要天气信息主动调用工具再结合降雨概率给结论。高难档工具报错或返回异常智能体能不能处理。比如API限流、返回空数据智能体是停下来报错还是换一个工具重试这是工程化能力的分水岭。这里有一个很关键的设计原则能力原子层的题目要“纯”。意思是每道题尽量只考察一项能力避免能力之间的互相干扰。比如考规划能力我们就不要在旁边埋工具调用的坑考记忆能力就不要让任务本身有太多理解歧义。如果题目不纯最后分数低了你也分不清是哪个环节弱。能力原子层的评测结果主要用来指导模型和框架层面的优化。如果发现工具调用普遍拉胯问题可能出在模型本身对工具描述的遵循度也可能出在Framework把工具参数组装错了。这时候要结合错误日志进一步定位评测体系只负责告诉你“哪弱”不负责告诉你“为什么弱”定位是后面的事。2.3 任务闭环层以端到端的成功率论英雄能力原子层考的是“基本功”任务闭环层考的是“完整活”。一个智能体就算单项能力都及格串起来也可能一塌糊涂。任务闭环层的设计逻辑很朴素把真实业务场景里的完整任务抽出来做成标准化任务集让智能体从头到尾跑一遍看能不能在合理的时间内给出可用的结果。任务闭环层的评测指标我建议至少覆盖这四类指标定义备注任务完成率完成的任务数 / 总任务数核心指标但要注意“完成”的判定标准平均完成时长从收到任务到产出终态的时间反映效率过长说明路径规划有问题工具调用次数完成任务过程中调用工具的频次过多可能说明试错成本高人工干预率需要人工介入的任务占比这个指标最能反映真实可用性拿我们做过的“智能客服工单处理”评测来说任务集里有一条经典题目用户投诉“上周买的键盘有一个键不灵敏想退换”。这条任务表面上很简单但实际跑起来智能体需要先理解用户诉求然后查订单、确认是否符合退换政策、生成退换申请、通知用户。每一步都有坑订单系统里可能查不到记录退换政策里可能有限制条件用户可能还要追问“那邮费谁出”。只有跑完整个流程并把结果正确反馈给用户我们才判定这个任务“完成”。中途掉一环哪怕最后回复了一句“抱歉无法处理”也不算。这类任务还有一个特点场景化程度高。题库里的任务不是凭空想出来的而是从真实业务日志里抽出来的。我们当时的方法是拉取过去三个月的客服对话记录把重复出现的问题聚类去重再挑出高频高价值的场景改写成标准化评测任务。这样做出来的基准才真正跟业务对齐而不是模型在实验室里自嗨。2.4 体验价值层用户觉得好用才算真的好这一层是最容易被技术团队忽略的但恰恰是最能左右智能体生死的一层。一个任务完成率高达95%的智能体可能因为每次回复都像机器人念稿用户用一次就跑了反过来一个偶尔出错但沟通很自然的智能体用户容忍度反而更高。这就是体验价值层的意义——衡量“人”感受到的质量。体验价值层我们主要看五个维度自然度、主动性、简洁性、稳定性和可控性。自然度指对话是否像真人有没有生硬的模板感。主动性指智能体会不会在用户表达不清时主动追问在信息不足时主动澄清。简洁性指回复是否啰嗦有没有把一句话能说清的事情扩展成三段。稳定性指同样的任务重复跑十次表现是否波动剧烈。可控性指用户能不能通过自然语言纠正智能体的行为。比如用户说“不要每次都给我发长文要短一点”智能体下一次是不是真的变短了。体验层的评测不能全用自动化需要结合人工评价和LLM辅助打分。我们当时的做法是每一条任务跑完先把对话轨迹交给一个独立的评审模型打分再由人工抽检打分结果。人工评分表要尽量细化不要一个笼统的“好不好”而是针对上面五个维度各打一个1到5分。原因很简单笼统的评分没法指导改进只有细化到维度你才知道要在哪里调prompt、哪里改策略。3. 基准构建方法论从任务采集到评分函数3.1 基准集是评测体系的心脏别用拍脑袋的内容超体评测体系里最重的活儿还不是定指标而是建基准集Benchmark。基准集就是这个体系的“考题库”题库出得好不好直接决定评测结果有没有参考价值。我见过不少团队评测体系搭得花里胡哨基准集却只有几十条拍脑袋编出来的题目最后测出来的分数只能用来发PPT对实际优化毫无帮助。基准集构建我按四步走第一步场景采集。从真实业务里挖需求。最靠谱的来源有三个历史对话日志、产品需求文档、一线运营同学的反馈。我跟团队做过一次统计我们基准集里80%的题目都改自真实用户问题剩下20%是根据业务扩展方向预设的“未来场景”。真实题目的价值在于它天然带着真实用户的表达习惯——问法不标准、信息有缺失、需求有多层——这些恰恰是编造的题目很难模拟出来的。第二步难度分级。每道题按“信息完整度、操作复杂度、异常出现概率”三个维度打分归入L1到L3三档。L1是信息完整、单步操作即可完成的任务L2是信息部分缺失、需要多步规划L3是信息冲突、需要纠错或需要综合判断。分级的意义在于你可以分别看智能体在简单和困难场景下的表现差距。如果一个智能体L1满分、L3只有20%说明它只是个“听话的机器人”算不上一名合格的数字员工。第三步答案与判定规则设计。这也是基准构建里最容易翻车的一步。传统评测有标准答案对就是对错就是错智能体任务做不到。你要给每道题配置判定规则明确什么情况算“完成”、什么情况算“部分完成”、什么情况算“失败”。我建议判定规则包含三个维度终态结果对不对、过程关键节点有没有都走到、有没有违反硬性约束比如不能瞎编数据、不能重复要用户信息。第四步动态更新机制。基准集不是建好就一劳永逸的。业务变了、模型强了、用户问法进化了基准集就得跟着更新。我们每季度做一次基准集审计删掉已经过时的题目、补充新出现的业务场景、上调被模型普遍攻克的难题。这套机制的重要性不亚于基准集本身不然测来测去都是老题分数好看但说服力越来越弱。3.2 评分函数设计如何把多维度结果合并成一个可比较的分数基准集建好了接下来就是怎么算分的问题。我们内部管这一步叫“评分函数设计”它决定了评测结果是“一个看得懂的分数”还是“一堆看不懂的数字”。评分函数的设计原则是分层计算逐层加权各层不互相污染。具体到超体评测体系里三层分数的合成方式如下能力原子层按能力项先各算各的得分率再按业务优先级加权。比如一个客服智能体工具调用和检索能力权重高代码能力权重低反过来一个数据分析智能体代码能力权重就拉高。任务闭环层每条任务按判定规则产出三态结果——成功、部分成功、失败然后折算成分数。成功计1分部分成功计0.5分失败计0分。再加两个惩罚项超时扣分和过多工具调用次数扣分。这一步是平均数最后得到任务闭环层的得分率。体验价值层五个维度各取人工/模型打分的均值再做一次加权合计。最后三层分数按**能力20%、任务50%、体验30%**的权重合成一个超体综合分。为什么任务闭环层占最大权重因为它是智能体真实价值的直接度量能力再强、体验再好任务跑不通一切都是零。能力层权重反而压低到20%因为能力再强也只是“潜力”要转化成闭环成果才有意义。需要提醒的是权重比例不是固定的要结合你的业务目标调整。如果你们做的是偏交互型的智能体体验层的权重可以上调到40%如果是后台自动化执行型智能体体验层甚至可以压到10%把更多权重让给任务闭环层。比例设计的原则就一句话权重反映的是你的业务对每一层价值的真实需求。3.3 评分前先问自己完成的标准到底是什么这是整个基准构建里最容易被低估的问题。我见过太多团队题目出好了答案也标了但到了判分环节两个人对同一道题的判定结果可能完全不一样因为他们对“完成”的理解不同。有人觉得智能体给出了最终答复就算完成有人觉得必须用户确认满意才算完成标准不统一评测结果就没有一致性。我们现在的做法是给每条任务写一份判定卡卡片里写清楚三个东西完成定义、关键过程节点、扣分规则。以“生成销售周报”任务为例判定卡会写完成定义输出了结构化周报包含销售数据汇总和趋势分析且数据与源系统一致。关键过程节点成功连接数据源、成功执行数据查询、成功生成结构化报告。三个节点缺一个不能算成功。扣分规则报告中数据源引用错误扣20分报告结构不完整扣10分查询过程重试超过3次扣5分。判定卡的作用是让整个评测团队“对齐语言”所有人在同一把尺子下工作。这个过程很繁琐尤其当任务集规模上百条的时候写判定卡本身就是一个不小的工作量。但它带来的收益是巨大的——你的评测结果在时间维度上可比这个月跟上个月测同一个任务如果智能体没有变分数就应该是稳定的不会因为换了一个评审人员就忽高忽低。4. 实操过程实录用一个客服智能体的跑分案例讲清楚4.1 从搭建测试环境到执行评测任务集理论讲完了我拿一个实际跑过的案例把整个评测流程串一遍。我们当时评测的对象是一个电商客服智能体核心功能是处理售后咨询和退换货请求。评测目标很明确判断这个智能体能不能从测试环境平稳走到生产环境。第一步是搭建隔离的评测环境。这一步看起来不起眼但有坑。智能体评测对环境稳定性的要求极高你不想让评测结果被网络抖动、第三方API限流这些外部因素干扰。我们的做法是把所有外部依赖全部mock掉——订单系统用本地mock数据支付系统用模拟接口物流信息用静态快照。这样跑出来的结果才能纯粹反映智能体本身的能力而不是反映外部系统的波动。等评测通过以后再开一条生产环境的小流量评测通道用真实系统再跑一轮验证。第二步是准备评测任务集。我们从历史客服会话里抽了200条真实问题按超体体系的规则改写成评测任务。200条任务的分布是这样的L1难度100条L2难度60条L3难度40条。覆盖的场景包括普通退换货、发票申请、物流查询、商品咨询、复杂投诉等十几个类目。每条任务都配好了判定卡约定了完成定义和扣分规则。第三步是执行评测。我们用一套自动化脚本批量触发任务把每轮对话的完整轨迹都记录下来。一个细节评测脚本要记录过程数据而不只是终态数据。包括每一轮的输入输出、调用了哪些工具、工具返回了什么、往返耗时多久。这些过程数据是后面做失败分析的原材料只有终态结果的话出了问题根本没法排查。200条任务跑完大概用了两个多小时。这个速度现在看不算快但当时我们为了保证效果每条任务之间还加了随机间隔避免触发限流。如果你想跑得更快可以把并发调高但前提是评测环境要能扛住并发压力否则自损八百。4.2 关键参数任务条数、并发度、评测次数怎么定跑分过程中的几个关键参数我直接给一组我们验证过的参考值任务条数单次评测不要低于100条。太少的话统计意义不大一条任务的成败就能波动好几个百分点的分数。常规评测建议跑200~500条做发布前的完整验收时我会跑到800条以上。并发度单线程跑最稳但时间成本高。我们用的并发度是8在隔离环境里没出现过互相干扰的问题。并发度也别调得太高智能体如果共享了某个资源并发高了可能产生排队效应影响耗时类指标。重复次数同一套任务集至少跑3次取均值。原因后面细说——LLM有随机性单次分数不能代表真实水平。3次是底线如果3次的极差超过5个百分点说明系统稳定性有问题这时候要加测到5次而不是直接取一个均值糊弄过去。还有一个容易被忽略的参数超时上限。我们给每条任务设了180秒的超时上限超过直接判失败。这个值看你任务的复杂度简单的单轮查询60秒就够复杂的多轮规划类任务可以放到300秒。超时上限的作用是防止某个任务卡死把整个评测流程拖崩。4.3 评测结果分析三层分数解读一个智能体的真实状态跑完分数出来我拿一组当时的真实数据给大家做个解读示范。那版智能体的超体综合分是72.5分。分层看能力原子层得分率81%任务闭环层67.5%体验价值层74.2%。如果不分层你只会看到“72.5分还不错”但这组分数的潜台词其实是另一回事。能力原子层81%说明基本功不算差。但往下钻到每一项发现工具调用能力得分率只有65%其他能力都在85%以上。说明这个智能体在“选对并填对工具”这件事上存在明显短板这是模型本身的遵循度问题也可能是工具描述写得不够清楚。任务闭环层67.5%直接拖了后腿。再往细分L1任务完成率85%L2是45%L3是12%。这个梯度一出结论已经很清楚了——这个智能体只能处理简单场景一遇到信息缺失、需要多步规划或者异常处理的场景就崩远远达不到生产标准。体验价值层的74.2%也有问题。看对话轨迹发现智能体在遇到不确定的情况时倾向于反复道歉一句“抱歉我暂时无法处理”用了七八种说法用户体感非常机械。这个在自动化指标上看不出来但看轨迹就一目了然。基于这三层分析优化方向和优先级其实已经浮出水面先修工具调用能力再补L2场景的规划能力最后调对话策略。没有分层评测这三个优先级你是排不出来的。排不出优先级团队就会陷入东一榔头西一棒子的优化循环这是评测体系带给团队的最大价值——让优化动作有明确靶心。上面这个案例讲的是评测“怎么做”但我还想特别强调一点评测框架不是死的要随着模型能力升级同步迭代。我们团队每个季度都会做一次基准集“难度审计”把那些已经被智能体普遍攻克的L2题目升级为L3把新冒出的真实业务场景补充进来把智能体已经形成条件反射的旧套路题目淘汰掉。这个动作看起来工作量不大但它决定了你的评测体系始终是“衡量天花板”的尺子而不是“贴地板”的装饰。5. 常见问题与排查技巧实录5.1 分数漂移问题同一个智能体分数怎么总是忽高忽低这是我在智能体评测中遇到最频繁的问题。同一个智能体同一个任务集上午跑是75分下午跑变成了70分晚上再跑又变成73分。第一次碰见的时候我还以为评测脚本出了bug查了半天最后发现是智能体本身有随机性。这个问题的根源在于LLM的采样随机性。解码时的温度参数只要不是0同一个Prompt就可能产出不同的回复进而导致整条任务走向不同。深入排查还会发现另一个来源上游工具返回的波动。外呼API响应快慢、检索结果排序变化、数据库中数据变动都会影响智能体的决策路径。解决方案分三层评测层同一任务集跑3次取均值单次结果永远不要作为决策依据。配置层评测用的智能体温度参数固定下来不要每次用不同配置跑。环境层尽量用mock数据来隔离外部波动。如果必须用真实环境选择业务低峰期并固定评测窗口时段我一般选夜里的固定两小时。这三层都做到分数漂移基本能控制在2个百分点以内。如果还在漂大概率是任务集里某些题目的判定规则写得不够清晰评审员的判断出现了分歧这时要回头补判定卡。5.2 LLM-as-Judge的偏差问题让模型给模型打分靠谱吗体验价值层我们引入了LLM辅助打分用独立的评审模型给对话轨迹打自然度和主动性评分。这个方法效率高但有一个我不能不提的坑审评模型的偏好偏差。我们踩到过一次很典型的偏差评审模型对“礼貌用语多”的回复给了更高的自然度分数即使这些礼貌用语让回复变得冗长真人评审给分反而更低。还有一次评审模型青睐带Markdown格式的回复认为“结构清晰”但真实用户反馈这些格式在客服场景里反而显得突兀。校准方法是双管齐下一是人工抽检比例不能低于20%用人工给模型打分的结果做对齐校验二是要建一套偏差检测规则定期统计评审模型与人工的评分差异差异大的维度要调整评审的Prompt甚至直接修正评分逻辑。LLM-as-Judge可用但不能无脑全信它必须被放在一个人工审核的闭环里。5.3 任务集污染题做多了分数会虚高还有一个隐蔽的坑叫任务集污染。智能体如果反复调用同一个评测任务集它可能会“记住”题目的套路。具体表现是任务刚开始智能体就已经预测到下一步要做什么不需要推理就给出了“正确答案”。这种虚高的分数对模型能力的评估只有副作用你会被表面的高分欺骗误以为系统已经达标实际换一套任务立刻现原形。应对思路有两个一是动态化评测任务不是每次都跑完全一样的题目而是从一个大的题目池里随机抽样保证每次评测的题目组合有差异二是定期轮换基准集把评测过的题目和使用过的任务集归档过一段时间再换一批新题。如果你发现某个任务的完成率“莫名其妙”从60%涨到了90%先别急着高兴检查一下是不是这个题目已经被跑过太多遍。5.4 长尾场景的缺失基准做得很全但最大的坑在基准之外最后一个想分享的踩坑经验是长尾场景覆盖。很多基准集的构建逻辑是“有多少数据采多少样”但真实业务里的规律是20%的场景贡献了80%的流量剩下80%的长尾场景很少出现但非常考验智能体的应对能力。举一个我们真实遇到的例子。客服智能体的基准集覆盖了“订单不匹配、商品缺货、物流停滞”等各种长尾问题自认为做得足够全。结果上线一个月后反馈最多的问题竟然是“用户要求用别人的订单号查询自己的物流”——这个需求极简单但基准集里完全没覆盖。智能体每次碰到都处理不好因为它的判断规则没有涉及这种跨界查询的场景。这件事之后我们再建基准集会刻意检查长尾覆盖度。方法很简单拿一份全量历史用户问题做词频聚类把频次低但语义独特的问题单独拎出来看覆盖情况。这种“冷门但真实”的题目比热门考点的价值高得多因为热门考点智能体天天见早就熟了冷门题才是真正的分水岭。6. 评测体系不是一次性工程要跟着智能体一起进化写到这里我个人最想强调的一点是评测体系本身也是一个需要持续维护的产品千万别当成一次性工程。我见过太多团队花大力气搭好一套评测基准上线跑了几轮就开始躺平等到半年后突然发现分数注水、指标失真又重新返工。这个成本远比一开始就建立维护机制要高。根据我们的经验维护评测体系至少需要三个固定动作按月做分数趋势分析看有没有指标出现偏离预期的波动按季度做基准集审计淘汰过时题目、补充新场景每次版本发布前做评测回归把新版本和旧版本在相同基准上对比确保优化没有引入新的回退。最后再分享一个小技巧。我们内部每个评测任务集都设了一个“置信度”标签根据题目的来源标注高、中、低三档。来源是真实用户会话且经过多人标注的题目置信度最高由产品经理编造的未来场景题置信度中等。做版本对比时我们优先看置信度高的题目的分数变化这样得出的结论更有说服力不会被少数几道“臆想题”的成绩带偏方向。智能体的评测没有银弹超体评测体系也只是我们在实践里趟出来的一套相对可用的方法。但有一点我可以确定在智能体快速迭代的当下把“怎么衡量好不好用”这件事想清楚和把智能体本身做出来同样重要。评测不是开发的反义词它是开发的一部分——没有那根衡量标尺所有优化都是盲目的。