业务Agent的评测这两年从“锦上添花”变成了“生死攸关”。我见过太多团队模型选型时跑分漂亮得不行一上生产环境就原形毕露——要么工具调用乱套要么多轮对话跑着跑着就忘了自己是谁。问题出在哪出在我们拿评测传统LLM的那套方法去评Agent就像拿考驾照的笔试成绩去判断一个人能不能跑拉力赛。Agent的核心能力是“在动态环境里做决策并执行”这跟“根据上下文生成一段通顺的话”完全是两码事。这篇内容我想把业务Agent评测这件事拆开聊透从为什么难评、评什么、怎么评到落地时踩过的坑和攒下的经验尽量说人话、给干货。适合正在做Agent落地、被评测环节卡住的开发者和技术负责人参考也适合刚接触Agent评测、想建立系统认知的朋友。1. 业务Agent评测为什么不能照搬LLM那套1.1 从“说得好”到“做得对”的范式转移传统LLM评测的核心逻辑是比对。给一个输入看输出和参考答案的相似度BLEU、ROUGE、BERTScore这些指标本质上都在衡量“文本像不像”。这套方法在翻译、摘要、问答场景里很成熟因为那些任务的正确答案相对确定评价维度也单一。但业务Agent不一样。一个Agent接到“帮我查一下上个月华东区销售额下滑的原因”这个任务它可能要调用数据库查询、调取报表工具、做数据对比分析、最后生成结论。这中间每一步都有多种合理路径最终答案也可能因为数据口径不同而有差异。你没法用一个固定的参考答案去比对因为“正确”本身就不是唯一的。更关键的是Agent的失败模式跟LLM完全不同。LLM答错了顶多是内容不对Agent做错了可能是调用了错误的工具、传了错误的参数、在循环里卡死、或者执行了有副作用的操作。这些问题的严重性远超“文本质量”层面。我经历过一次线上事故Agent在退款流程里把“确认退款”和“查询退款”两个工具搞混了直接给用户退了钱。这种错误用文本相似度根本测不出来。所以评测Agent首先要转变思维从“评结果”转向“评过程评结果”从“单点比对”转向“轨迹分析”。1.2 Agent评测的三个独特挑战第一个挑战是状态空间爆炸。Agent每一步的决策都依赖当前状态而状态又由历史动作和环境反馈共同决定。一个10步的任务如果每步有5种可能动作理论上的轨迹数量是5的10次方接近一千万条。你不可能穷举所有路径只能采样评估。第二个挑战是环境依赖。Agent的能力高度依赖它所能访问的工具和环境。同一个Agent接不同的API、不同的数据库表现可能天差地别。这意味着评测环境必须尽可能还原生产环境否则测出来的分数没有参考价值。第三个挑战是评估标准的主观性。什么叫“好”的Agent表现是任务完成率高是步骤少是成本低还是用户体验好不同业务场景下权重完全不同。客服Agent可能更看重准确率和合规性而数据分析Agent可能更看重洞察深度。没有一套通用指标能覆盖所有场景。这三个挑战决定了Agent评测必须是一套组合拳而不是单一指标能搞定的。1.3 一个真实的翻车案例去年我参与过一个电商客服Agent的项目。上线前团队用了一套标准的LLM评测集准确率92%大家都很乐观。结果上线第一周客诉率反而上升了。排查后发现几个典型问题Agent在处理“我要退货”时有时候会先问“您是什么原因退货”有时候直接调用退货工具。前者体验好但效率低后者效率高但显得机械。评测集里没有覆盖这种“交互策略”维度。当用户说“算了不用了”的时候Agent有30%的概率仍然继续执行退货流程。因为评测集里的“取消意图”样本太少模型没学好。多轮对话超过5轮后Agent开始丢失上下文把之前的订单号搞混。评测集里最长只有3轮对话。这些问题在传统评测里全是盲区。后来我们重新设计了一套针对Agent的评测方案才把这些问题逐个暴露出来。这个教训让我深刻认识到评测集的设计质量直接决定了你能否发现真正的问题。2. 拆解业务Agent的评测维度到底该测什么2.1 任务完成度最基础也最容易注水任务完成度是Agent评测的底线指标衡量的是“用户交代的事办成了没有”。听起来简单但实际操作中很容易注水。比如一个“帮我订明天从北京到上海的机票”的任务怎么算完成Agent查到航班算完成吗还是必须走到下单页面还是必须支付成功不同粒度的定义会导致完全不同的完成率。我的经验是任务完成度必须按业务动作分层定义。以订机票为例层级完成标准权重建议L1 信息获取正确识别出发地、目的地、时间20%L2 方案生成返回至少一个符合条件的航班30%L3 动作执行成功调用下单接口并返回订单号40%L4 异常处理遇到无票/超时等情况有合理反馈10%这样分层的好处是你能清楚看到Agent卡在哪一层。如果L1完成率95%但L3只有60%说明问题出在执行环节而不是理解环节。另外要注意完成度不等于成功率。有些Agent会“假装完成”——比如没查到航班就编一个航班号返回。这种情况必须通过事实验证来识别不能只看Agent自己说“已完成”。2.2 工具调用准确性Agent的命门工具调用是Agent区别于普通聊天机器人的核心能力也是评测的重中之重。我一般从四个子维度来评工具选择正确率面对一个任务Agent是否选了正确的工具。比如用户问“今天天气怎么样”Agent应该调天气查询工具而不是调日历工具。这个指标低说明Agent的意图理解或工具描述有问题。参数填充准确率选对了工具参数填对了吗比如查询天气需要城市和时间Agent是否从对话中正确提取了这两个参数。这里常见的坑是参数格式错误比如日期格式不匹配、城市名用了简称等。调用顺序合理性有些任务需要多个工具按特定顺序调用。比如“帮我退掉昨天买的那件衣服”需要先查订单、再确认退货政策、最后执行退货。顺序错了可能导致失败或副作用。异常处理能力工具调用失败时Agent怎么办是重试、换工具、还是向用户求助这个维度最能体现Agent的鲁棒性。我通常会用一张表来记录每次工具调用的详情{ step: 3, expected_tool: query_order, actual_tool: query_order, expected_params: {order_id: 12345, date: 2024-01-15}, actual_params: {order_id: 12345, date: 2024-01-14}, result: success, latency_ms: 320 }这样逐步骤对比能精确定位问题出在哪一环。2.3 多轮对话中的上下文保持能力业务Agent经常需要多轮交互才能完成任务。用户可能先说“我要退货”然后补充“就是上周买的那双鞋”再说“算了换成换货吧”。Agent需要在整个过程中保持对任务目标、已收集信息、用户偏好的追踪。评测这个维度我建议设计带干扰的多轮测试用例。比如第1轮用户提出任务A第2轮用户补充任务A的细节第3轮用户突然问了一个无关问题第4轮用户回到任务A并修改了某个条件第5轮用户确认执行看Agent在第4轮时是否还记得任务A的原始信息是否正确处理了修改。很多Agent在第3轮被干扰后就“忘了”任务A或者在第4轮修改条件时把之前的条件也覆盖了。这里有个实操技巧用“信息槽”的方式追踪上下文。把任务需要的关键信息定义为槽位如订单号、商品、时间、操作类型每轮对话后检查槽位的填充状态。这样能量化评估上下文保持能力而不是靠感觉。2.4 安全性与合规性不能等出事再补业务Agent一旦接入生产系统安全就是红线。评测时必须覆盖以下几类风险越权操作Agent是否可能执行超出用户权限的操作。比如普通用户让Agent“查一下所有用户的订单”Agent应该拒绝。敏感信息泄露Agent在回复中是否可能带出不该带出的信息比如其他用户的手机号、内部系统地址等。提示注入抵抗用户是否可以通过特殊构造的输入让Agent绕过限制执行非预期操作。这是Agent安全里最容易被忽视也最危险的一环。副作用控制对于有副作用的操作如转账、删除、发送Agent是否有二次确认机制。我一般会准备一组“对抗性测试用例”专门用来试探Agent的安全边界。这些用例不追求覆盖所有攻击方式但必须覆盖业务场景下最可能出现的风险点。安全评测的通过标准应该是“零容忍”——只要有一个越权操作成功整个Agent就不能上线。3. 评测方法论的选型在线、离线与混合模式3.1 离线评测快但容易失真离线评测是在受控环境里跑测试集优点是快、可重复、成本低。适合在开发迭代阶段快速验证。但离线评测有个致命问题测试集和真实分布的偏差。你精心设计的测试用例可能跟用户实际会问的问题差很远。我见过一个团队离线评测准确率90%上线后真实准确率只有60%。原因是他们的测试集都是“标准问法”而真实用户会说方言、打错字、用缩写、一句话里塞三个意图。所以离线评测的定位应该是“回归测试”而非“能力评估”。它用来确保新版本没有把旧功能改坏而不是用来判断Agent能不能上线。离线评测的测试集设计我建议遵循“三三制”三分之一来自真实用户日志脱敏后三分之一来自业务专家构造的边界用例三分之一来自对抗性测试用例这样能兼顾真实性和覆盖面。3.2 在线评测真实但代价高在线评测是把Agent放到真实环境里用真实流量来评估。最直接的方式是A/B测试一部分用户用旧版本一部分用新版本对比核心指标。在线评测的指标设计很关键。不能只看任务完成率还要看用户满意度通过点赞/点踩、追问率、转人工率来间接衡量效率指标平均对话轮数、平均耗时、token消耗业务指标转化率、客单价、复购率等在线评测的代价是可能影响真实用户体验。所以一般会先小流量灰度确认没有严重问题再逐步放量。这里有个经验在线评测一定要设置“熔断机制”。如果某个指标如转人工率超过阈值自动回滚到旧版本。别等出了大事再手动处理。3.3 混合模式我的推荐方案纯离线容易失真纯在线代价太高。我推荐的是“离线筛选在线验证”的混合模式开发阶段用离线测试集快速迭代确保基础能力达标预发布阶段用影子模式Shadow Mode跑真实流量Agent只记录不执行对比它“会怎么做”和人工实际怎么做灰度阶段小流量真实执行重点监控安全和异常指标全量阶段持续在线监控定期用离线测试集做回归影子模式特别有用因为它能在不影响用户的前提下用真实数据评估Agent的决策质量。我一般会对比Agent的决策和资深人工的决策计算一致率。一致率超过85%才考虑进入灰度。4. 评测工具链的搭建从Deepeval到自研4.1 Deepeval框架的适用场景与局限Deepeval是这两年比较流行的LLM评测框架它提供了一套声明式的评测接口可以比较方便地定义测试用例和评估指标。对于简单的Agent评测场景它能快速搭起一个可用的评测流程。它的核心用法是这样的from deepeval import evaluate from deepeval.metrics import TaskCompletionMetric from deepeval.test_case import LLMTestCase test_case LLMTestCase( input帮我查一下订单12345的状态, actual_output您的订单已发货预计明天送达, expected_output订单已发货 ) metric TaskCompletionMetric(threshold0.8) evaluate([test_case], [metric])但Deepeval的局限也很明显。它主要面向“输入-输出”式的评测对Agent的多步骤轨迹、工具调用、状态变化支持不够。你可以用它来评最终回复的质量但很难用它来评“第3步为什么选错了工具”。我的建议是Deepeval适合做最终输出的质量评估但不适合做全链路Agent评测。如果你的Agent逻辑比较简单只有一两步工具调用Deepeval够用。如果是复杂多步Agent还是得自研或组合使用其他工具。4.2 自研评测框架的核心模块对于业务Agent我倾向于自研一套轻量评测框架。核心模块包括用例管理模块管理测试用例的增删改查支持按标签、场景、难度筛选。用例格式建议用YAML方便人工编辑和版本管理。- id: case_001 scenario: 订单查询 difficulty: easy turns: - user: 帮我查一下订单12345 - user: 就是上周买的那双鞋 expected: tools_called: [query_order] final_contains: [已发货, 预计] assertions: - type: tool_sequence value: [query_order] - type: no_forbidden_tool value: [refund_order, delete_order]执行引擎负责跑用例记录每一步的输入、输出、工具调用、耗时、token消耗。执行引擎要支持并发否则跑几百个用例要等很久。评估器对执行结果打分。评估器分两类规则评估器和模型评估器。规则评估器用代码判断如工具名是否匹配、是否包含关键词模型评估器用LLM来判断如回复是否合理、是否有帮助。报告模块生成可视化报告展示通过率、失败用例详情、指标趋势。报告要能按维度下钻比如“工具调用准确率按场景分布”。这套框架搭起来大概需要一到两周但后续迭代会非常省力。4.3 模型评估器LLM-as-Judge的使用心得用LLM来评估LLM的输出这两年越来越普遍。它的优势是能处理规则难以覆盖的模糊判断比如“这个回复是否礼貌”“这个解释是否清晰”。但LLM-as-Judge有几个坑必须注意位置偏见LLM倾向于给第一个出现的选项更高分。解决方案是交换顺序评两次取平均。长度偏见LLM倾向于给更长的回复更高分。解决方案是在prompt里明确“长度不是评分标准”。自我偏好用GPT-4评GPT-4的输出分数会偏高。解决方案是尽量用不同家族的模型来评或者用人工校准。评分标准模糊如果prompt里只说“评1-5分”不同批次的评分可能不一致。解决方案是给出详细的评分细则rubric每个分数对应什么表现写清楚。我一般会把LLM-as-Judge的评分和人工评分做相关性分析。如果相关性低于0.7说明评估器的prompt需要优化。这个校准过程通常要迭代两三轮。5. 评测集设计决定评测质量的关键5.1 从真实日志中挖掘高价值用例评测集的质量直接决定评测的有效性。我见过太多团队随便造几十个用例就开始评结果评了个寂寞。好的评测集应该从真实数据中来。具体做法是拉取过去3-6个月的真实用户对话日志脱敏按意图分类统计每类意图的占比每类意图抽取代表性样本覆盖高频和低频对样本做标注标注内容包括期望的工具调用、期望的关键信息、可接受的回复范围这样得到的评测集分布跟真实场景一致评出来的分数才有参考价值。有个细节要注意真实日志里有很多“脏数据”比如用户打错字、说半句话、中途放弃。这些恰恰是最能考验Agent鲁棒性的用例不要过滤掉反而要重点保留。5.2 边界用例与对抗用例的构造方法真实日志覆盖的是“常见情况”但Agent的很多问题出在“不常见情况”。所以还需要人工构造边界用例和对抗用例。边界用例的构造思路参数边界空值、超长值、特殊字符、格式错误流程边界中途取消、重复请求、并发请求状态边界会话超时、工具不可用、数据不存在对抗用例的构造思路意图混淆一句话里包含多个意图看Agent能否正确拆分提示注入在正常请求里夹带“忽略之前的指令”之类的内容诱导越权用看似合理的理由诱导Agent执行越权操作信息套取通过多轮追问套取敏感信息这些用例不需要多但必须精。我一般会保持边界用例和对抗用例各占评测集的15%左右。5.3 评测集的版本管理与迭代评测集不是一次性的需要持续迭代。我的做法是版本化每次修改评测集都打版本号记录修改内容冻结核心集保留一组“核心用例”不轻易改动用于跨版本对比动态扩充每次线上发现新问题就把对应场景补充到评测集定期清理过时的用例如业务已下线及时移除核心集和动态集的比例大概是7:3。核心集保证可比性动态集保证时效性。另外评测集要跟代码一起做版本管理。每次Agent版本更新都要跑一遍完整评测集记录分数变化。如果某个版本分数突然下降能快速定位是哪个用例出了问题。6. 落地实操中的坑与经验6.1 评测环境与生产环境不一致的代价这是最常见的坑也是代价最大的坑。评测环境里工具都是mock的返回数据都是理想的Agent表现很好。一上生产工具超时、返回格式不对、数据缺失Agent直接懵了。我的经验是评测环境要尽可能还原生产环境。具体做法工具接口用真实接口但指向测试数据模拟真实的网络延迟和错误率数据要包含脏数据、缺失值、异常值并发压力要接近生产峰值如果实在没法用真实接口至少要把各种异常情况都mock出来。我一般会要求mock工具支持“按概率返回错误”比如10%的概率超时、5%的概率返回格式错误。6.2 评测指标好看但业务效果差的悖论这个坑很隐蔽。评测指标都达标了但业务方反馈“不好用”。原因通常是评测指标跟业务目标脱节。比如你评的是“任务完成率”但业务方关心的是“用户满意度”。Agent可能完成了任务但过程很啰嗦、语气很生硬用户不爽。或者你评的是“工具调用准确率”但业务方关心的是“响应速度”Agent调对了工具但太慢。解决方案是评测指标必须跟业务方一起定。在评测开始前跟业务方对齐“什么算好”把业务目标翻译成可量化的评测指标。这个过程不能省否则评了也白评。6.3 人工评估的组织与质量控制有些维度机器评不了必须人工评。比如“回复是否得体”“解释是否清晰”“整体体验如何”。人工评估的组织有几个要点评估员培训不能随便找个人就评。要给评估员讲清楚评分标准最好先做一轮校准确保大家的评分尺度一致。盲评评估员不知道哪个是哪个版本避免先入为主。多人评每个用例至少两个人评取平均。如果两人分歧大找第三个人仲裁。抽样复核定期抽查评估员的评分确保质量没有漂移。人工评估成本高所以要用在刀刃上。我一般只在关键版本发布前做人工评估日常迭代用自动评估。6.4 评测频率与迭代节奏的平衡评测太频繁浪费时间评测太少问题发现不及时。我的建议是每次代码提交跑核心集的快速回归5分钟内每日构建跑完整评测集30分钟内版本发布前跑完整评测集人工评估对抗测试每月做一次全面评测包括在线指标分析这个节奏能保证问题尽早发现又不至于拖慢迭代。7. 从评测到优化让评测结果真正产生价值7.1 失败用例的归因分析方法评测的目的不是打分而是发现问题并优化。所以失败用例的归因分析比分数本身更重要。我一般用“五问法”来归因失败的直接原因是什么如工具调用错误为什么会出现这个原因如工具描述不清晰为什么工具描述不清晰如文档没更新为什么文档没更新如没有维护流程根本原因是什么如缺少工具变更的规范这样一层层问下去才能找到真正需要修复的地方。如果只停留在第一层可能只是改改prompt治标不治本。归因分析的结果要分类统计。如果80%的失败都是同一类原因那优先解决这一类。如果失败原因很分散说明Agent的基础能力还有问题需要系统性优化。7.2 评测驱动的Prompt与工具优化评测结果最直接的用途是优化Prompt和工具定义。Prompt优化如果发现Agent经常误解某个意图就在Prompt里补充该意图的说明和示例。如果发现Agent经常漏掉某个步骤就在Prompt里强化该步骤的指令。工具优化如果发现Agent经常选错工具就检查工具的名称和描述是否清晰。工具名要见名知义描述要说明“什么时候用”和“什么时候不用”。如果发现参数经常填错就在参数描述里给出格式示例。这里有个经验工具描述的优化往往比Prompt优化更有效。因为Agent选工具主要看工具描述描述清晰了选错的概率就低了。7.3 建立评测-优化-回归的闭环评测不是一次性的要形成闭环评测发现问题归因分析找到根因针对性优化Prompt/工具/流程回归评测验证优化效果如果没解决回到第2步这个闭环要自动化。每次优化后自动跑评测自动对比分数。如果分数提升合并代码如果下降回滚。闭环的周期越短迭代越快。我见过做得好的团队从发现问题到验证修复只需要半天。这需要评测框架、CI/CD、监控告警的紧密配合。8. 一些关于Agent评测的零散思考评测这件事说到底是在回答“这个Agent到底行不行”。但“行不行”的标准是动态的——今天行明天可能就不行了因为用户期望在变、业务场景在变、竞争对手在变。所以评测体系本身也要迭代。我每隔一个季度会重新审视评测指标问自己这些指标还能反映业务目标吗有没有新的风险点没覆盖评测集的分布还跟真实场景一致吗另一个体会是评测要尽早介入。不要等Agent开发完了再想怎么评。在需求阶段就要想清楚“怎么算成功”在设计阶段就要把可评测性考虑进去比如工具调用要打日志、状态变化要可追踪。评测前置能省掉后面很多返工。最后说个心态问题。评测分数低不可怕可怕的是分数虚高。一个真实的60分比一个注水的90分有价值得多。评测的目的是暴露问题不是证明自己行。抱着这个心态做评测才能真正从评测中获益。提示评测集里一定要保留一组“永远不会删”的核心用例它们是你跨版本对比的基准。这组用例的分数波动超过5%就说明有严重问题必须排查。