做智能体开发和评测做了大半年，我越来越确认一个判断：传统大模型的跑分，和智能体“好不好用”之间，隔着一条巨大的鸿沟。很多团队把基座模型的benchmark分数当成自家智能体的底气，结果一上线，用户根本不买账。原因很简单：智能体是“行动单位”，不是“问答器”。它要在真实环境里自己理解需求、拆解计划、调用工具、处理中间错误，把整条业务闭环走完。你没法用一个选择题数据集，回答“它到底能不能把一笔售后订单处理好”这种问题。
这篇文章是“超体”系列的第6篇，专门聊评测体系与基准构建。所谓“超体”，指的是把模型、编排逻辑、工具封装、容错机制当成一个整体来评测——不是测单点能力，而是测这个“增强后的智能体”在真实任务里的综合表现。我会把过去半年多在智能体评测上验证有效的方法论、指标口径、任务集构造流程，以及踩过的各种坑，一次性讲透。如果你正在用Coze、Dify这类平台搭智能体，或者用Python框架（LangGraph、AutoGen等）从零写agent，又或者只是想把现有智能体的能力摸个底，这篇文章大概率能帮你少走两个月的弯路。
1. 为什么大模型跑分衡量不了智能体
1.1 评测对象变了：从“答得对”到“做得成”
传统LLM评测，比如MMLU、GSM8K、HumanEval，检验的是“单次回答的质量”：给模型一个问题，它输出一段文本，和标准答案比对。评测单元是回合，评测对象是输出内容。
智能体不一样。智能体的评测单元是任务，评测对象是行为序列。一个任务从用户query开始，智能体可能要经历意图理解、规划、多次工具调用、中间结果解析、错误恢复、结果汇总、最终回复，中间任何一步都可能出错，而且错误会滚雪球式积累。更麻烦的是，智能体的输出会改变外部状态——调用了下单API，订单状态就变了；写入了数据库，数据就变了。这让“答案比对”变成了“状态验证”。
我常用一个类比：大模型跑分是考笔试，智能体评测是考带薪实习。笔试考知识储备，实习考的是真实环境里能不能把事办成。很多模型笔试很厉害，实习一塌糊涂，因为实习要面对环境噪音、工具异常、目标模糊、中途变更，这些恰恰是笔试里没有的。
1.2 跑分和上线成绩之间的断崖
我实测过一个典型案例：有个基座模型MMLU接近90分，在Agent任务集上表现明显弱于另一个跑分低5分的模型。原因是它文本推理能力强，但工具调用格式不稳定，偶尔输出多余字段，导致下游JSON解析失败。这种问题在纯文本评测里完全暴露不出来。
类似的差异还有几类：
- 文本能力强，但工具参数容易传错。
- 单轮对话强，多轮上下文维护差，做着做着忘了用户要什么。
- 规划表面可以，但失败后不会根据环境反馈调整策略。
- 输出格式偶尔“出轨”，在严格校验的环境里直接判死。
所以我把智能体评测的第一原则定为：永远用“任务成败”说话，而不是用“文本相似度”说话。指标必须来自任务最终结果，过程文本只是辅助诊断信号。
1.3 智能体评测最容易踩的三个误区
做评测体系设计时，团队里最容易出现三种问题。
第一，把“能对话”当“能用”。智能体流利跑完对话流程，很多人就觉得效果不错。但对话只是外壳，真正要验证的是它有没有在对话过程中调用正确工具、拿到正确数据、执行有效操作。聊天体验好不等于任务完成得好。
第二，只测成功路径，不测失败路径。初版评测集往往都是正常用户的正常请求，但智能体真正翻车的地方，往往在模糊指令、信息缺失、工具报错、权限不足、重复请求这些“脏”场景。评测集不加入这些，等于考试不考压轴题。
第三，用单一数字评价一个行动系统。智能体是多目标的：成功、效率、成本、稳定、安全，这些目标常常互相冲突。成功率高的可能更慢更贵，快的可能牺牲安全。用一个综合分评价，很难定位是哪一块拖了后腿。评测体系必须多维拆解，综合分只是仪表盘，定位问题时一定要看分维度数据。
2. 「超体」评测体系的三层结构：能力、行为、系统
2.1 能力层：传统评测还有用，但要有选择地用
能力层测的是智能体依赖的基础模型能力：语言理解、逻辑推理、指令跟随、数学计算、编程、多模态理解。这部分可以沿用传统评测集，但不能全量跑。我一般从实际业务出发抽取相关能力项。
比如做企业客服智能体，重点测四样：意图分类在千级细分类目下的准确率；槽位抽取对订单号、地址、日期等关键信息的正确识别；多轮复盘能力，用户中途改口能不能正确更新状态；情绪与门槛判断，什么时候该转人工。
能力层的价值在于排障归因。当行为层分数突然下滑，你要先判断是底层模型能力退化，还是上层流程设计有bug。有分层数据，排查效率会高很多。能力层评测用标准化静态数据集即可，跑分成本也低。
2.2 行为层：智能体独有的评测核心区
行为层是“超体”体系里最核心也最花功夫的部分，测的是智能体在任务执行过程中的行为质量。不管底层用ReAct还是Plan-and-Execute范式，评测关心的都是行为结果。我把它拆成五个子维度：
- 任务完成度：任务目标是否达成、达成程度如何。
- 工具调用正确性：调没调对工具、参数传没传对、次数是否合理。
- 路径效率：完成任务用了几步、有没有做无用功。
- 容错恢复：遇到工具报错、环境异常、信息冲突时，能不能自动修正并继续。
- 目标保持：多轮交互中会不会偏离用户原始目标，被无关信息带跑。
容错恢复是我认为最容易被忽略、最影响上线体验的维度。真实环境里工具接口时刻在返回异常：服务超时、字段为空、权限不足、下游数据还没同步。智能体如果只会把所有错误原样抛给用户，体验会非常差。好的智能体能对错误分类，可重试的自动重试，可规避的换条路径，无法处理的保留上下文转人工。比如查询接口超时，好的agent会走重试策略，而不是直接告诉用户“系统繁忙，请稍后再试”。
行为层的评测必须用可执行的任务环境，不能只给文本。评测时要记录完整轨迹，包括每一次LLM输出、工具请求、工具响应、状态变化。有了轨迹才能做归因分析——这也是平台型智能体难做细粒度行为评测的原因，后面会展开。
2.3 系统层：测“能不能长期稳定运行”
系统层回答的问题是：生产环境里，这个智能体靠不靠谱。
重点看几个组指标。稳定性：同一个任务跑20遍，成功率方差大不大。LLM天然有随机性，好的工程实践能把关键路径的成功率压得很稳，方差大往往说明温度设置、prompt结构或重试逻辑有问题。延迟分布：不看平均延迟，看P95/P99。智能体应用最怕偶发巨慢，一次工具链超时可能毁掉整个会话体验。成本承受力：每个任务消耗多少token、调用多少次LLM API。很多demo跑得通，一算账发现一个任务烧掉几毛甚至几块钱，ROI直接为负。安全合规：有没有越权调用工具、有没有输出敏感信息、有没有循环失控，每轮动作都要有行为审计日志。
系统层评测通常结合压测和生产流量回放来做。最终产出是一张健康仪表盘，和单点能力、单任务行为分开看。三层数据互补，缺一层都容易误判。
| 层级 | 核心问题 | 典型评测内容 | 闭环对象 |
|---|---|---|---|
| 能力层 | 底子行不行 | 意图分类、槽位抽取、推理、指令跟随 | 基础模型、prompt模板 |
| 行为层 | 事办没办成 | 任务完成度、工具调用、容错恢复 | Agent编排、工具封装、上下文管理 |
| 系统层 | 能不能上线 | 稳定性、延迟、成本、安全审计 | 重试机制、并发架构、监控策略 |
这张表帮我整顿过很多内部讨论。凡是“智能体效果差”的反馈，先分到某一层再对症下药，比笼统地调prompt有效得多。
3. 基准构建流程：从任务集设计到gold轨迹标注
说完了测什么，来看基准怎么建。我建议不要一开始就追求大而全，而是围绕业务场景做一个高质量小集，跑通流程再扩充。
3.1 任务集的三种来源
第一，真实用户请求采样。优先级最高。从生产日志按比例抽样，覆盖高频请求、异常请求、投诉类请求。真实请求里包含天然的“脏”：口语化、信息缺漏、语义歧义、情绪激烈，合成数据很难完全模拟。
第二，可控合成生成。真实请求太稀缺或涉密时，让模型按模板生成任务，生成后再人工审核。关键是模板要覆盖边界情况：空参数、超长文本、冲突信息、隐含目标。合成任务也是补齐长尾分布的主要手段。
第三，标准环境基准任务。做通用型智能体可以直接借鉴开源基准环境，比如WebArena（网页操作）、SWE-bench（代码修复）、τ-bench这类。环境搭建有学习成本，但很多场景能复用Gym风格的任务定义和判定逻辑。
3.2 任务的结构化定义
无论来源是哪种，每条评测任务我都要求写成结构化条目，至少包含：task_id唯一标识；场景描述（初始环境状态、已有上下文、用户身份）；用户query完整输入；可用工具/接口列表；期望结果的判定标准；难度等级；参考轨迹或备注（提示裁判用，但不能暴露给被测agent）。
举个客服场景的“困难”级例子：
任务ID: CS-2024-023 场景：用户在订单详情页发起咨询，订单号ORD-8821，物流状态为“运输中”，此时用户已申请过一次退款。 用户query：“我的快递好几天没动了，不想等了，能退了吗？会不会扣我钱？” 可用工具：查询订单、查询物流、查询退款规则、发起退款申请、转人工。 期望结果：正确判断用户诉求是取消订单并退款，核实退款规则后给出准确答复；若触发平台限制，要明确说明原因，不得给出错误承诺。 难度：困难。
把任务写成结构化条目，是为了让每条评测指标都能落到具体字段上。期望结果的描述尤其重要，它直接决定自动判定的可行性。
3.3 难度分层与质量审核
任务集建好后的第一件事不是评测，是清洗。我会用双人标注交叉审核每条任务：任务自洽吗？期望结果唯一吗？工具列表够吗？有没有可能出现多种合理路径却被判失败？
清洗之后做难度分层。分层维度包括：所需步骤数、信息完整度、是否需要多源信息整合、是否包含异常路径。分层不是装点门面，而是评测报告必须有的切片维度——按难度看成功率，比看一个总体成功率有意义得多。
我吃过一个教训：第一版评测集偏简单，80%任务3步以内搞定，三个不同版本的智能体成功率都在85%以上，完全拉不开差距。后来加入困难任务和极端任务，比如工具连续两次报错后还能不能恢复，分数差异才显现。没有难度梯度，评测体系对“好一点”和“差一点”的区分度就是零。
3.4 评测集规模：多少条才够用
很多人问评测集建多少条。我的实操经验是：
- 快速冒烟集：30-50条，覆盖各难度层级，每次迭代后快速跑。
- 完整评测集：200-500条，按业务场景加权抽样，版本发布前全量验证。
- 长尾专项集：每个场景50-100条，如极端容错、安全、多语言，按需建设。
500条听起来不多，但加上期望结果标注、轨迹人工审核抽样、环境mock搭建，工作量不小。而且评测集是“活”的，要持续补充生产case回流。我建议按季度做一次评测集修订，淘汰过时流程，增补新业务case，防止评测集和企业业务脱节。
4. 关键指标的计算口径：什么样的数字才算“好用”
评测体系烂，大多烂在指标定义不清。“成功率”听着简单，但“成功”怎么定义不提前讲清楚，后面全是扯皮。这一节把常用指标和口径逐个说清。
4.1 任务成功率的三种判定方式
成功率有三种判定方式。二值判定，任务目标完全达成=1，否则=0，简单清晰但太严苛，80%完成度的复杂任务和完全跑偏的任务都算0，区分度差。子目标加权，把复杂任务拆成多个子目标，比如“查清订单状态”20%、“确认退款规则”30%、“给出可执行方案”40%、“语气合规”10%，按完成比例给分，对复杂任务友好，但要精细设计子目标。结果分级评分，0-5分每档有明确行为描述，0=完全错误、1=答非所问、2=部分正确但关键动作遗漏、3=基本完成但有瑕疵、4=完美完成，适合人工或LLM judge。
我的建议：正式评测用二值判定做硬指标，保证口径无争议；子目标加权和分级评分做软指标，用于分析差距和指导优化。只报一个成功率，掩盖的信息太多。
4.2 部分得分与质量分级
重对话场景我尤其推荐引入质量分级。很多任务没有绝对的对错，用户满意度来自“关键动作到位+表达得体”。
分级时，关键动作比表达更重要。我见过智能体语气极其礼貌，但关键信息一个没给，这种只能算低分；表达略微生硬但把问题解决了，反而该给高分。所以评分rubric里要显式写明“关键动作权重高于表达风格”，否则LLM judge容易被礼貌话术带偏。
实际的rubric可以长这样：
| 维度 | 权重 | 评分说明 |
|---|---|---|
| 关键动作完成 | 60% | 是否完成查单、退款校验等核心动作 |
| 信息准确性 | 20% | 给出的金额、时效、政策是否无误 |
| 表达质量 | 10% | 语气、结构化程度、可读性 |
| 转人工衔接 | 10% | 需要转人工时能否顺畅传递上下文 |
4.3 路径效率与工具调用准确率
成功完成任务不代表路径合理。两个agent都完成任务，一个2步搞定，一个绕8步，中间调了3次无用接口。后者在生产里意味着更长响应时间、更高成本、更高出错概率。
路径效率我常用两个指标。归一化步数：实际步数/参考轨迹步数，比值接近1最好，显著大于1说明冗余。工具调用准确率：从轨迹里统计对最终结果有正向贡献的调用占比。agent调了10次工具，只有3次有用，工具调用准确率就是30%，即便最终成功，也是“笨成功”。
还有一个指标容易被忽略：无效重复动作。连续三次调用同一个查询接口，参数完全一样，前两次失败第三次成功。这在重试机制设计差的agent里很常见，浪费成本增加延迟，应该把“无效重试占比”单独拉出来看。
4.4 成本、延迟与稳定性指标
评测报告除了结果分，我会固定输出一组“体检项”：
- 每任务中位成本：LLM调用费用加工具调用平摊费用。
- 每任务耗时可接受度：目标场景容忍上限内完成的比例。
- 成功率在P95/P99尾部场景的表现。
- 会话轮次失控率：单任务交互超过N轮仍未结束的比例。
- 工具调用异常率：错误码、超时、非预期格式的次数。
这些指标里我最看重“成本/成功率联合曲线”。有的agent把成功率从80%提到90%，成本翻了三倍，不一定划算。评测体系必须让这种权衡显性化，而不是只看漂亮成功率。
4.5 综合评分怎么加权
综合评分适合管理层横向对比，我推荐用分维度加权而不是线性总分。分维度数据的价值在定位，综合总分的价值在速览。我个人的加权习惯：任务成功率30%，关键场景容错恢复20%，路径效率20%，成本合理性15%，安全合规15%。
权重随业务变化，不需要教条。记住一个原则：综合分只是速览，永远伴随分维度明细表，避免平均分掩盖短板。
5. 评测实战里的三大坑：伪高分、判官偏见、环境不隔离
评测体系建好容易，建得“可信”很难，坑基本集中在三个方向。
5.1 伪高分陷阱：任务泄漏与“背题”效应
第一个坑是任务泄漏。智能体基座模型如果训练语料里含评测任务相似数据，它可能靠“背答案”得分，而不是靠推理能力。防范方法：评测任务集不公开，不同步到公共分支；任务用模板化参数，每次评测生成不同实例；严格区分评测任务数据和训练微调数据，评测数据不进任何训练流程；用复述检测抽查agent回答和gold轨迹是否高度雷同。
还有一个隐蔽的伪高分来源：任务本身存在捷径。比如评测环境里某个工具固定返回“成功”，agent调用它就完成任务，不需要真正做事。所以期望结果的check必须依赖真实环境状态，不能是固定假响应。
5.2 LLM-as-Judge的偏见与校准
用LLM当裁判是Agent评测的主流手段。因为智能体的过程质量很难穷举规则判定，让强模型给轨迹打分最省人力。但Judge有系统性偏见，我实际遇到的几类：长度偏见，更喜欢长回答，哪怕多出来的内容没价值；礼貌偏见，喜欢客气话术；自证偏见，对自己模型家族的输出打分偏高；环境信息错觉，把环境描述里提到的内容当成agent实际执行的动作。
校准方法：抽100条样本人工标好分，让LLM Judge打分，计算一致率。我的标准是至少85%，不一致的样本要分析是rubric不清楚还是judge系统偏好。rubric要迭代打磨，比换模型更有用。每个批次的Judge调用要固定模型版本、温度设0，否则评分波动会混入评测噪声。
5.3 测试环境隔离与可复现性
智能体评测最容易被低估的是环境。如果测试环境和真实服务耦合，一次下游系统的数据变更就能让评测结果重跑后对不上——评测不仅要测agent，还要保证测试本身可复现。
我的做法是尽量mock化：外部工具API统一走mock服务，初始状态可重置。mock服务要注入真实分布的错误模式，比如5%超时、3%空响应，否则评测环境比生产“善良”太多，容错能力测不出来，上线才翻车。
可复现性还有个细节：随机种子控制。LLM随机性没法完全消除，所以每个任务固定跑N次，通常3-5次，报告成功率分布，而不是单次结果。只跑一次就给结论，偶然因素太多。
6. 平台搭建的智能体与Python框架搭建的智能体，评测思路完全不同
被问得最多的问题是：Coze、Dify这类平台搭的智能体，和用Python框架写的智能体，到底有什么不一样？构建方式不同，评测的关注点和操作方式本质上也不同。
6.1 平台型智能体：黑盒反馈为主，重点验体验闭环
用Coze、Dify这类低代码平台搭智能体，速度极快，三两天能出能对话的demo，但评测有限制：平台大多不提供细粒度的内部轨迹日志，很难看到每次LLM调用的完整输入输出，更难对某一步做单元化断言。
所以平台型智能体的评测重点放在端到端体验闭环：跑完整用户旅程，咨询-操作-完成，确认每个环节都工作；重点测多轮体验，能不能准确记住前文、会不会频繁重申无关信息；统计完成任务所需对话轮数，这几乎是平台型agent最有效的效率指标；接好真实业务API后务必做一轮生产环境烟雾测试，因为平台mock环境和真实环境的差异常比想象中大。
平台可视化节点逻辑让编排很直观，但也意味着决策逻辑是黑盒。黑盒测评要多用行为观察法，少做内部归因——你很难通过平台日志快速定位是哪个prompt节点崩了。
6.2 代码型智能体：细粒度监控，评测能钻到轨迹级
用Python框架（LangGraph、AutoGen、自研编排引擎）写智能体，构建成本更高，但评测灵活度高得多。你拥有全部代码和日志，可以在每个节点插桩：记录每次LLM输出、工具请求、工具响应、状态变更；对单个节点做单元测试，比如单独验证意图分类器在某类query上的准确率；对整条链路做集成测试，注入mock工具错误，观察agent是否走容错分支；对节点间数据流做断言，检查上下文是否被正确传递。
代码型agent评测的核心优势是“细”，但“细”带来维护负担。很多团队写了几十个单元测试，每次改动都要修测试，评测流程比agent本身还复杂。我的建议是分两层：CI冒烟层，快速，30条任务10分钟跑完；周期回归层，静态和动态组合，多跑几轮。别让评测体系变成负担，否则没人维护照样失效。
6.3 双轨评测的体会
我自己维护过平台型和代码型两套智能体，评测上最大的区别一句话总结：平台型评测看“能不能用”，代码型评测看“能不能控”。
| 对比项 | 平台型（Coze/Dify） | 代码型（LangGraph/AutoGen） |
|---|---|---|
| 内部轨迹可见性 | 低，黑盒 | 高，可插桩 |
| 单元级断言 | 难 | 容易 |
| 端到端体验 | 是主要验证手段 | 也需要但非唯一 |
| 异常注入 | 受限 | 灵活可控 |
| 维护成本 | 较低 | 较高，需分层设计 |
如果你用平台，多把精力花在客服体验、导流逻辑、人工兜底这些外部行为上；如果你写代码，多花时间在轨迹审计、异常注入、状态一致性这些内部机制上。搞清楚自己手里是哪一类，评测方案才不会跑偏。
7. 从评测到落地：一次客服智能体的复盘
7.1 一次分数下跌的定位过程
最后用真实案例讲评测结果怎么帮助迭代。我们有个售后客服智能体，v0.8版本迭代后期，完整评测集分数从82%掉到78%。直觉以为是模型变差，但分层一看，能力层分数完全没变，行为层的“容错恢复”掉了12个百分点。
查轨迹发现，新增的“退款查询”工具在部分场景返回非标准JSON，错误码放在顶层字段而不是嵌套字段，新版本agent没做异常解析兜底，直接崩溃，连累后续步骤全部失败。问题根因不是模型能力，而是工具异常处理分支缺失。修复后分数回到84%，同时给我们提了醒：每次新增工具、修改工具响应结构，都必须跑一遍容错专项评测集。
7.2 评测体系带来的排障提速
这次复盘给我最大的启发是：评测体系的价值不只是打分，更是把模糊的“效果变差了”翻译成具体的“哪个环节挂了”。有了分层指标、轨迹日志、可控的评测环境，定位时间能从几天压缩到几小时。这也是我愿意持续投入维护评测体系的根本原因。
最后再分享一个小经验：评测体系不是一次性交作业，它会随着你的业务演进变得过时。务必要留出固定的季度修订时间，把真实生产回流的新case补进去，把过时任务清出去。一个“活”的评测体系，比一个漂亮但沉睡的基准有价值得多。
