1. 从“跑分”到“判卷”智能体评测的终局思维做智能体评测这件事我前前后后折腾了快两年。从最早拿几个公开榜单刷分到后来自己搭评测流水线再到最近半年反复被一个问题困扰——评测做完之后呢分数出来了报告生成了然后呢模型该幻觉还是幻觉工具调用该出错还是出错多轮对话该跑偏还是跑偏。评测像是一场考试考完试学生该怎样还怎样那这场考试的意义到底在哪这个系列写到终章我想把最后一层窗户纸捅破评测的终局不是排名是治理。评测即治理这不是一句口号而是我踩了无数坑之后得出的结论。所谓治理就是让评测结果能够反向约束智能体的行为边界、驱动迭代方向、定义上线标准。没有治理能力的评测本质上就是自娱自乐。这篇文章面向的是已经在做智能体开发、或者正准备搭建评测体系的从业者。不管你是用 Coze、Dify 这类平台搭应用还是基于 Agno、Hermes 这类框架做深度定制只要你关心“我的智能体到底行不行、怎么让它更行”这篇内容都值得你花时间看完。我会从评测体系的设计思路讲起拆解核心指标的定义逻辑然后给出可落地的实操方案最后分享我在实际项目中遇到的典型问题和排查技巧。核心关键词先摆出来智能体、评测、治理、LLM。这四个词贯穿全文也是我理解这个领域的四个锚点。智能体是对象评测是手段治理是目的LLM 是底座。四者之间的关系不是线性的而是一个闭环——评测驱动治理治理反过来定义评测标准LLM 的能力边界决定了这个闭环能转多快。2. 评测体系到底该怎么设计从指标定义到场景覆盖2.1 为什么通用榜单救不了你的智能体我见过太多团队一上来就问“有没有什么榜单能直接测我的智能体”答案是有但基本没用。Open LLM Leaderboard 这类公开榜单测的是基座模型在标准化任务上的表现MMLU、GSM8K、HumanEval 这些数据集确实能反映模型的通用能力但它们和你的业务场景之间隔着十万八千里。举个例子你做一个电商客服智能体核心能力是理解用户意图、查询订单状态、处理退换货流程。公开榜单不会测你的智能体能不能正确调用订单查询接口不会测它在用户情绪激动时会不会说错话更不会测它在多轮对话中会不会丢失上下文。这些才是真正决定用户体验的东西。所以我的第一个建议是通用榜单只看趋势业务评测必须自建。自建评测体系的第一步不是找数据集而是定义你的智能体到底要做什么、做到什么程度算合格。这个定义过程本身就是治理的起点。2.2 三层评测指标体系能力、安全、体验我把智能体评测指标分成三层从下到上依次是能力层、安全层、体验层。这个分层逻辑参考了 OWASP Top 10 for LLM Applications 的思路但做了更适合智能体场景的调整。能力层是最基础的衡量智能体能不能完成任务。核心指标包括任务完成率、工具调用准确率、多轮对话一致性。任务完成率好理解就是给定一个任务描述智能体最终有没有交付正确结果。工具调用准确率衡量的是智能体在选择工具、构造参数、解析返回值这三个环节的正确性。多轮对话一致性则关注智能体在长对话中是否会出现上下文遗忘、前后矛盾的问题。安全层衡量的是智能体会不会闯祸。这里的安全不只是内容安全还包括操作安全。内容安全指智能体是否会产生有害、偏见、误导性输出操作安全指智能体在执行工具调用时是否会越权、是否会触发危险操作。比如一个数据库查询智能体如果用户输入“帮我删掉所有订单”它应该拒绝执行而不是真的去调删除接口。体验层是最容易被忽略但实际影响最大的。同样完成一个任务智能体的回复是生硬还是自然是冗长还是简洁是主动确认还是擅自行动这些都会直接影响用户满意度。体验层的指标比较主观我通常用人工评分加用户反馈来量化。指标层级核心指标评测方式治理动作能力层任务完成率、工具调用准确率、多轮一致性自动化脚本人工抽检低于阈值触发迭代安全层有害输出率、越权操作率、拒答准确率红队测试规则引擎触发即阻断上线体验层回复自然度、信息密度、主动确认率人工评分用户反馈持续优化提示词2.3 场景覆盖的“冰山模型”评测场景的设计有个经典误区只测水面上的部分。什么叫水面上的部分就是那些正常的、典型的、预期内的用户输入。但真正导致线上事故的往往是水面下的部分——边界情况、对抗输入、异常流程。我习惯用“冰山模型”来设计评测场景。水面以上是正常场景占评测集的 60% 左右水面以下是边界场景和对抗场景各占 20%。边界场景包括空输入、超长输入、特殊字符、多语言混杂等对抗场景包括提示词注入、角色扮演诱导、逻辑陷阱等。提示对抗场景的评测集需要定期更新。我一般每两周补充一批新的对抗样本来源包括线上真实 badcase、安全社区披露的新攻击手法、以及团队内部的红队演练结果。3. 核心指标拆解从“召回率 91.3%”说起3.1 召回率、准确率、F1 在智能体场景下的重新定义前阵子看到华为云码道检视修复智能体的数据召回率 91.3%这个数字在企业级代码质量保障场景下确实不错。但我想借这个案例说明一个问题智能体场景下的召回率和传统机器学习里的召回率含义已经不一样了。传统召回率 正确检索到的相关文档数 / 所有相关文档总数。但在智能体场景下“检索”这个动作可能发生在多个环节知识库检索、工具选择、参数构造、结果解析。每个环节都有自己的召回率。华为云那个 91.3% 的召回率我推测是针对代码缺陷检视这个具体任务的——在所有真实缺陷中智能体成功检视出 91.3%。这就引出一个关键问题你测的到底是哪个环节的召回率如果智能体在知识库检索环节召回率很高但在工具选择环节召回率很低最终任务完成率依然上不去。所以我在实际项目中会把召回率拆解到每个环节分别监控。环节召回率定义典型阈值低于阈值的治理动作知识库检索相关文档被检索到的比例≥85%优化索引策略、补充知识工具选择正确工具被选中的比例≥90%优化工具描述、增加示例参数构造参数正确的比例≥95%增加参数校验、优化提示词结果解析正确解析返回值的比例≥98%增加解析容错、规范返回格式3.2 工具调用准确率智能体评测的“七寸”如果只能选一个指标来衡量智能体的核心能力我会选工具调用准确率。原因很简单智能体和聊天机器人的本质区别就在于能不能调工具。LLM 本身只能生成文本只有通过工具调用才能与外部世界交互才能完成真实任务。工具调用准确率的计算方式我一般这样定义工具调用准确率 正确调用次数 / 总调用次数“正确调用”需要同时满足三个条件选对了工具、传对了参数、正确处理了返回值。三个条件缺一不可。我见过太多案例工具选对了但参数传错或者参数传对了但返回值解析出错最终任务失败。实测下来工具调用准确率低于 85% 的智能体基本不具备上线条件。85% 到 95% 之间需要配合人工兜底。95% 以上才能考虑全自动化运行。这个阈值不是拍脑袋定的是根据多个项目的线上数据反推出来的。3.3 多轮对话一致性最容易被低估的指标多轮对话一致性是我在早期项目中最容易忽略的指标直到有一次线上事故才引起重视。那是一个订票智能体用户在第一轮说了“我要订明天北京到上海的机票”智能体确认了。第二轮用户说“改成后天”智能体正确修改了日期。第三轮用户说“还是原来那个时间吧”智能体却把日期改回了明天但出发地变成了上海——它把“原来那个时间”理解成了“原来那个行程”。这个问题本质上是大模型在长上下文中的注意力衰减。LLM 的 token 机制决定了它对早期信息的记忆会随着对话轮次增加而减弱。三个关键点key 是“我是谁”query 是“我在找什么”value 是“我能提供什么”。在多轮对话中如果 key 和 query 的匹配出现偏差value 就会取错。治理多轮对话一致性的手段主要有三个一是控制对话轮次上限超过一定轮次强制摘要压缩二是关键信息显式回显每轮确认时把核心参数列出来三是引入外部状态管理把对话状态从 LLM 上下文中剥离出来用结构化数据存储。4. 评测即治理让评测结果真正驱动迭代4.1 从“评测报告”到“治理工单”大部分团队的评测流程是这样的跑评测集 → 生成报告 → 开会讨论 → 排期优化。这个流程的问题在于评测和治理之间是断开的。报告里的问题能不能被修复、什么时候修复、修复到什么程度全靠人的自觉。我的做法是把评测结果直接转化成治理工单。每个未通过的评测用例自动生成一条工单工单里包含问题描述、复现步骤、期望行为、实际行为、严重等级、建议修复方向。工单直接进入研发迭代流程和普通 bug 一样被跟踪。这样做的好处是评测不再是“参考”而是“约束”。评测不通过的智能体版本不允许上线。这就把评测从建议权变成了否决权治理能力自然就上来了。4.2 阈值治理用数据定义“合格线”治理的核心是定义边界。什么能做什么不能做做到什么程度算合格这些都需要用数据来定义而不是拍脑袋。我通常用“三线法”来定义阈值红线绝对不能突破的底线。比如安全层的越权操作率必须为 0一旦触发直接阻断上线。黄线需要关注但可以容忍的警戒线。比如工具调用准确率低于 90% 触发预警需要给出改进计划。绿线期望达到的目标线。比如任务完成率高于 95% 才算优秀。这三条线不是固定不变的而是随着智能体迭代逐步提高。第一版可能红线是 80%第二版提到 85%第三版提到 90%。这种渐进式治理比一步到位更现实也更容易落地。4.3 持续评测把“考试”变成“体检”传统评测是“考试模式”——开发完了测一次通过了就上线。但智能体是活的用户输入在变、外部工具在变、LLM 本身也在更新。一次考试通过不代表永远合格。我推崇的是“体检模式”——持续评测定期体检。具体做法是每天跑一次核心评测集每周跑一次全量评测集每月做一次对抗评测。核心评测集控制在 100 条以内保证快速反馈全量评测集 500 到 1000 条覆盖所有场景对抗评测集持续更新保持攻击面覆盖。注意持续评测的前提是评测集的质量。我见过太多团队的评测集半年不更新里面全是过时的场景和已经修复的问题。评测集本身也需要治理定期清理无效用例、补充新场景、调整难度分布。5. 实操落地从零搭建一套可治理的评测流水线5.1 工具选型不要重复造轮子搭建评测流水线第一步是选工具。我的原则是能用开源就用开源能复用就不自研。评测框架这块LangSmith、LangFuse、Weights Biases 都可以考虑。如果团队已经在用 Dify 或 Coze 做智能体开发它们自带的评测功能可以先跑起来不够用再扩展。自研的部分主要集中在评测集管理和治理工单系统。评测集管理需要支持用例的增删改查、版本管理、难度标注、场景分类。治理工单系统需要和现有的研发流程打通最好能直接对接 Jira、飞书项目或类似的工具。工具类型推荐方案适用场景注意事项评测框架LangFuse、LangSmith通用评测流水线注意数据隐私和成本平台自带Dify 评测、Coze 评测平台内智能体灵活性有限适合起步自研Python pytest 自定义断言深度定制需求维护成本高谨慎评估工单系统Jira、飞书项目治理闭环需要和评测系统打通5.2 评测集构建从 0 到 1 的实操步骤评测集构建是整个流水线中最耗时但也最重要的环节。我的实操步骤是这样的第一步收集种子用例。来源包括产品需求文档中的典型场景、线上真实用户对话、竞品分析中发现的场景、团队头脑风暴的边界情况。种子用例不需要多50 到 100 条即可。第二步分类和标注。按能力层、安全层、体验层分类每类下面再按场景细分。每条用例标注输入、期望输出、评测方式自动/人工、严重等级。第三步扩充和平衡。种子用例往往分布不均需要有针对性地扩充。比如安全层用例太少就专门设计一批对抗样本。最终评测集的分布应该和线上真实分布大致匹配。第四步验证和迭代。评测集本身也需要验证——用已知正确和已知错误的智能体版本跑一遍看评测集能不能区分出来。如果区分不出来说明用例设计有问题需要调整。5.3 自动化评测脚本的核心逻辑自动化评测脚本的核心是“断言”。每条评测用例都需要一个或多个断言来判断是否通过。断言的类型包括精确匹配输出必须等于期望值。适用于工具调用参数、结构化输出等场景。包含匹配输出必须包含某些关键词。适用于自然语言回复的粗粒度检查。语义匹配用 LLM 判断输出是否和期望语义一致。适用于开放式回复。规则匹配用正则表达式或自定义规则判断。适用于格式检查、敏感词过滤等。# 示例工具调用评测的断言逻辑 def assert_tool_call(response, expected_tool, expected_params): # 检查工具名是否正确 assert response.tool_name expected_tool, \ f工具选择错误期望 {expected_tool}实际 {response.tool_name} # 检查参数是否包含期望的键值对 for key, value in expected_params.items(): assert key in response.params, f缺少参数{key} assert response.params[key] value, \ f参数错误{key} 期望 {value}实际 {response.params[key]} return True语义匹配的断言我一般用 GPT-4 或 DeepSeek 来做裁判但要注意成本和一致性。我的做法是先用规则匹配过滤掉明显错误的再用语义匹配做精细判断。语义匹配的提示词需要精心设计明确评分标准和输出格式。5.4 治理闭环的最后一公里从报告到行动评测报告生成之后最关键的一步是推动行动。我的经验是报告要短工单要细跟踪要紧。报告只放核心结论哪些指标达标了哪些没达标没达标的原因是什么建议的修复方向是什么。不要放太多细节细节放在工单里。工单要具体到可执行问题描述、复现步骤、期望行为、实际行为、严重等级、建议修复方向、负责人、截止日期。每条工单都要有明确的验收标准。跟踪要形成节奏每天站会过一遍新增工单每周复盘一次修复进度每月评估一次治理效果。治理效果的核心指标是“评测通过率”和“线上事故率”的同步变化。如果评测通过率上去了但线上事故率没下来说明评测集和真实场景脱节了需要调整评测集。6. 常见问题与排查技巧实录6.1 评测结果波动大同一版本跑两次结果不一样这是最常见的问题原因通常有三个LLM 本身的随机性、评测环境的不稳定、评测脚本的 bug。LLM 随机性可以通过设置 temperature0 来降低但无法完全消除。我的做法是核心评测跑三次取平均值如果三次结果差异超过 5%说明这个用例本身不稳定需要检查是不是提示词太模糊或者期望输出太开放。评测环境不稳定包括网络延迟、工具接口超时、数据库连接失败等。这些外部依赖需要在评测脚本里做好 mock 或重试机制。评测脚本的 bug 往往出在断言逻辑上。比如语义匹配的提示词不够明确导致 LLM 裁判的判断标准不一致。解决方法是固定裁判模型的版本和参数并且定期用人工标注的数据校准裁判的准确性。6.2 评测通过率很高但线上还是出问题这个问题我遇到过不止一次根本原因是评测集和真实场景的分布不一致。评测集里的用例都是精心设计的输入规范、意图明确、边界清晰。但线上用户的输入是随机的、模糊的、甚至带有对抗性的。解决办法是持续把线上 badcase 回流到评测集。我一般每周从线上日志里抽取一批失败案例人工标注后期望行为补充到评测集里。这样评测集就能逐步逼近真实分布。另一个原因是评测指标和业务指标脱节。比如评测关注的是任务完成率但业务关注的是用户满意度。任务完成了但用户不满意的情况很常见——智能体把任务做完了但过程中反复确认、回复冗长、语气生硬。所以体验层的评测不能省。6.3 工具调用准确率上不去怎么排查工具调用准确率低排查思路是从上到下、从粗到细。先看工具选择环节。如果工具选错了检查工具描述是否清晰、工具数量是否过多、是否有功能重叠的工具。我一般建议单个智能体的工具数量控制在 10 个以内超过 10 个就需要分组或引入路由机制。再看参数构造环节。如果工具选对了但参数错了检查参数定义是否明确、是否有示例、是否做了类型校验。参数名要语义化参数描述要包含格式要求和示例值。最后看返回值解析环节。如果参数对了但结果解析错了检查返回值的格式是否规范、是否有异常情况的处理、解析逻辑是否健壮。我一般要求所有工具返回值都遵循统一的 JSON 格式包含 code、message、data 三个字段。问题现象可能原因排查方法解决方案工具选错描述不清、工具过多检查工具描述和数量优化描述、分组路由参数传错定义模糊、缺少示例检查参数定义增加示例、类型校验解析出错格式不规范、异常未处理检查返回值格式统一格式、增加容错多轮丢失上下文过长、注意力衰减检查对话轮次摘要压缩、状态外置6.4 安全层评测怎么做才有效安全层评测最容易流于形式。我见过一些团队的安全评测就是跑一遍敏感词库过了就算安全。这远远不够。有效的安全评测需要覆盖三类风险内容风险、操作风险、诱导风险。内容风险包括有害输出、偏见输出、误导性输出操作风险包括越权操作、危险操作、未授权操作诱导风险包括提示词注入、角色扮演绕过、逻辑陷阱。红队测试是安全评测的核心手段。我一般组织 2 到 3 人的红队专门设计对抗样本尝试突破智能体的安全边界。红队测试的结果直接进入治理工单高危问题触发红线阻断。提示安全评测的用例不要放在公开的评测集里单独管理限制访问权限。避免评测集本身成为攻击者的参考资料。6.5 评测成本太高怎么优化评测成本主要来自两个方面LLM 调用成本和人工标注成本。LLM 调用成本可以通过分级评测来优化。核心评测集用最好的模型全量评测集用性价比高的模型对抗评测集用规则引擎加少量 LLM 调用。另外语义匹配的裁判模型可以缓存结果相同输入直接复用。人工标注成本可以通过主动学习来优化。先用自动化评测跑一遍只把不确定的用例挑出来人工标注。这样人工标注量可以减少 70% 以上。还有一个技巧是复用评测结果。同一个智能体版本能力层评测通过后安全层和体验层的评测可以并行跑不需要串行等待。7. 全系列收官的几点个人体会这个系列从第一篇写到终章中间隔了差不多半年。半年里智能体这个领域变化很快新的框架、新的平台、新的评测方法层出不穷。但有些东西是不变的评测的目的是治理治理的目的是让智能体真正可用、可靠、可控。我个人的体会是评测这件事不能交给测试团队单独做必须是开发、产品、测试三方共建。开发定义技术指标产品定义业务指标测试负责执行和反馈。三方对齐了评测才有效。另外评测体系不要追求大而全先跑起来再迭代。我见过太多团队花三个月设计了一套完美的评测方案结果一行代码没跑。先用最小可行评测集跑起来哪怕只有 20 条用例也比没有强。最后分享一个我最近在用的技巧把评测结果做成看板挂在团队每天都能看到的地方。通过率、红线触发次数、工单修复率这三个数字每天更新。数据可视化带来的行为改变比任何流程规范都有效。