智能体评测体系怎么搭？超体分层评测方法论详解

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. 评测体系不是一次性工程，要跟着智能体一起进化

写到这里，我个人最想强调的一点是：评测体系本身也是一个需要持续维护的产品，千万别当成一次性工程。我见过太多团队，花大力气搭好一套评测基准，上线跑了几轮，就开始躺平，等到半年后突然发现分数注水、指标失真，又重新返工。这个成本远比一开始就建立维护机制要高。

根据我们的经验，维护评测体系至少需要三个固定动作：按月做分数趋势分析，看有没有指标出现偏离预期的波动；按季度做基准集审计，淘汰过时题目、补充新场景；每次版本发布前做评测回归，把新版本和旧版本在相同基准上对比，确保优化没有引入新的回退。

最后再分享一个小技巧。我们内部每个评测任务集都设了一个“置信度”标签，根据题目的来源标注高、中、低三档。来源是真实用户会话且经过多人标注的题目，置信度最高；由产品经理编造的未来场景题，置信度中等。做版本对比时，我们优先看置信度高的题目的分数变化，这样得出的结论更有说服力，不会被少数几道“臆想题”的成绩带偏方向。

智能体的评测没有银弹，超体评测体系也只是我们在实践里趟出来的一套相对可用的方法。但有一点我可以确定：在智能体快速迭代的当下，把“怎么衡量好不好用”这件事想清楚，和把智能体本身做出来同样重要。评测不是开发的反义词，它是开发的一部分——没有那根衡量标尺，所有优化都是盲目的。