做 Agent 评测这件事我踩过最深的一个坑是拿评测大模型的老思路硬套 Agent。以前做 LLM 评测整理一批输入输出对写脚本离线跑一遍把文本和参考答案比对一下交付就完了。可 Agent 一旦跑起来就是多轮推理加行动要查数据库、调外部接口、改配置、做状态变更中间任何一环出错最终结果都可能和预期差出十万八千里。大概从两年前开始我陆续帮着几个业务团队搭过不同形态的 Agent 自动化评测体系。越搭越明白端到端的 Agent Evaluation 并不是写几个评测脚本那么简单它是一整套围绕任务设计、环境模拟、结果观测、指标定义和数据迭代搭建起来的工程系统。这篇文章把我在实操中怎么拆解 Agent 自动化评测、怎么搭端到端评测体系、以及踩过的那些坑完整记录下来。正在为“Agent 怎么做自动化评测”发愁的同学可以重点看测评集已经跑起来但结果总是被业务方挑战的人也能从这里找到一些排查思路。1. Agent 评测为什么不能直接套用 LLM 评测的方案1.1 传统 LLM 评测的本质是一次性答卷过去做大模型评测最常见的形式就是准备一批输入输出对让模型生成一次答案然后和参考答案对比。不管是基于规则的比对、算 BLEU/ROUGE还是用评判模型打分本质上都是在给“一份答卷”评分。一张卷子一锤定音交完就完事。这套模式对文本生成、摘要、分类、问答这些场景没问题它考验的是模型在给定输入下的“一次性推理能力”。但放到 Agent 上情况就完全变了。Agent 的产出不是一个最终文本而是一连串行动序列。比如一个客服 Agent 处理退款申请读邮件、查订单系统、判断是否符合退款政策、调用退款接口、给用户写回复。每一步都有取舍下一步往往依赖上一步的结果。如果只看最后那句“我已经为您办理退款”你根本不知道它是不是真的把退款接口调成功了。所以把 Agent 评测简单当成“给最终回复打分”是最大的误解也是很多评测体系做出来没人信的直接原因。1.2 Agent 评测的差异从“考背诵”变成“考办事”我经常给团队里的同学打个比方LLM 评测像是考背诵Agent 评测更像考办事。考办事有个特点过程和结果同等重要。办事的人要打开浏览器搜索资料、要拨打电话核实信息、要填写表单提交申请这些动作都有对错。更有意思的是办事过程中还会遇到突发情况——电话没人接、系统报错、用户改主意这时能否恢复过来、继续把事办成才是真正要测的能力。落到 Agent 上这几点和 LLM 评测完全不同环境交互。Agent 必须真实或近似真实地和外部环境交互评测需要模拟环境并观察状态变化。多步决策。每一步都可能错错误会累积中间一步错了后面再多步都可能白费。工具调用正确性。不仅要看是否调用了工具还要看参数对不对、调用时机对不对、返回值有没有被正确解析。故障恢复。工具抛异常时Agent 是继续乱撞还是冷静处理这直接影响任务成功率。这四个差异决定了评测设计必须同时关注“最终效果”和“完成过程”只看一头都不行。1.3 端到端评测要分三个层级去看既然 Agent 评测和 LLM 评测完全不是一回事那评测体系也不能只有一层。我给自己搭评测体系定了一个三层结构每个层级解决不同问题第一层是单元能力评测。单独验证 Agent 里头某个能力模块比如工具调用参数生成是否正确、某个 prompt 分支是否稳定。这一层跑得快适合开发阶段频繁自测。第二层是流程链路评测。把 Agent 放进 mock 环境里给定初始状态跑完一个完整任务但环境里的外部依赖都用可控的桩替代。这是主力既能端到端观察又能控制变量。第三层才是真正贴近线上的端到端评测。在尽量接近生产的环境里跑外部服务用沙箱或测试账号数据用脱敏后的真实数据。这一层最真实、也最贵适合发布前做全量回归。很多团队一上来就想直接做第三层发现又贵又不稳定做了几天就跑不下去了。实际踩下来还是得从第二层起步先把可控性做扎实再往真实环境逼近。这也是这篇文章主推的思路。2. 端到端评测体系怎么设计任务、指标和过程观测2.1 评测任务集定义把业务需求翻译成可执行任务构建端到端评测体系第一步不是选框架也不是写脚本而是定义评测任务集。评测任务集不是随便列一些用户问题就完事每个任务必须包含以下要素初始状态任务开始前系统处于什么状态比如订单待支付、客户资料缺失、库存不足。用户请求用户自然表达的一句话或一段话尽量模拟真实语气。可用工具与权限Agent 在当前任务里能调用什么调不了什么。预期最终状态任务成功后系统状态应该变成什么样这是最核心的验收标准。参考轨迹可选一名熟练操作者大概会按什么顺序调用哪些工具不一定要求 Agent 完全一致但可以作为过程评分参考。难度标签单步任务、多步任务、异常恢复任务、长程任务方便后续按难度拆分分析。拿客服场景举例初始状态是“订单 A100 状态为已发货用户发起退款请求”用户请求是“我要退掉刚收到的这个商品”预期最终状态是“该订单进入退款审核流程且原支付渠道生成了退款申请记录”。只要最终状态不对不管 Agent 回复得多么客气这个用例都算失败。任务集定义得越细后面所有分析才越有抓手。否则出了问题连是 Agent 的问题还是任务描述不清晰都分不清。2.2 结果层指标任务完成率、完成质量和失败分布结果层是所有指标里最核心的一层它回答的问题是Agent 到底把活干成没有。我实际在用的指标组合是这样任务完成率是最直观的指标也就是预期终态断言全部通过的用例占总用例的比例。这个指标必须字节级明确比如“订单状态字段变成 cancelled且取消原因字段等于用户申请原因”不能写“大体上完成”。部分完成率也很关键。有些任务 Agent 做了一半比如查到了订单信息但退款环节没执行。我倾向于给这类任务单独记一个“部分完成”标签而不是简单归入失败。部分完成率高说明 Agent 的信息理解、工具选择能力还行但关键动作的执行策略存在问题。失败类型分布是我后来才补上的但价值极高。每跑完一轮评测把失败用例按原因归类统计是调用参数错误、信息缺失、政策误判、还是中途放弃。这个分布能直接指向下一步优化方向比单一通过率有用得多。另外对于有“参考答案”的任务我会引入一个质量分由大模型或规则对最终产出质量做五档评价。但对这个打分我始终保持谨慎它只能作为辅助不能替代状态断言。2.3 过程层指标步数、工具使用和错误恢复结果层只能告诉你成没成功不能告诉你为什么成功或失败。所以必须有过程观测。我最常看的过程指标有这几个平均步数。完成同一个任务Agent 用了 5 步和用了 25 步差距很大。步数过长往往意味着无效探索和反复试错。步数暴涨通常对应评测结果恶化即使最终通过率还没掉也值得警惕。工具调用序列。把每条用例的轨迹拉出来看 Agent 调了哪些工具、顺序是什么、有没有重复调用。如果在取消订单任务里Agent 先调了五次查询接口才发起取消请求说明工具选择效率有明显问题。错误恢复次数。统计 Agent 遇到工具异常后能自行修正并继续完成的占比。这是衡量 Agent“办事能力”很重要的维度。真实业务里总有接口抖动恢复能力决定了系统能否长期稳定运行。无效循环检测。如果 Agent 在同一个工具、同一个参数上反复调用超过三次基本可以认定它陷入了死循环这类用例必须单独标记。过程层指标跑在一起本质上是把 Agent 的“行为轨迹”转成可量化数据这样才能把每个失败都定位到具体环节。2.4 成本与稳定性指标Agent 评测本身是有成本的每一轮评测都是真实的模型调用。长期跑下来不看成本是不行的。我常记录的指标包括单任务平均 token 消耗、工具调用总次数、单任务平均耗时、API 请求失败率。这些指标不直接反映能力但直接决定评测能不能持续。如果某个版本平均 token 消耗暴涨了 50%即使通过率没变也得看是不是 Agent 开始产生大量低效重试了。有时候我也会把“成本/通过率”看成一个综合效率指标。通过率差不多的情况下成本更低的实现方案明显更优。这也是评测体系能在技术选型和 prompt 优化里发挥价值的地方。3. 从零搭建 Agent 自动化评测环境的实操步骤3.1 评测环境三件套运行时、沙箱和工具桩到现在为止指标定义都有了下一步就要让评测真的跑起来。实际操作里评测环境我从来不用生产环境而是自建一套隔离环境包含三个部分。第一是 Agent 运行时。就是被测 Agent 本身包括它的模型、prompt、工具注册表、记忆模块。评测时要能通过参数切换模型、切换 prompt 版本方便做对比实验。第二是沙箱环境。任何可能有副作用的操作都要在沙箱里完成。最简单的方式是用 Docker 起一个独立容器容器里跑一个模拟业务系统比如模拟订单库、模拟支付网关。Agent 在沙箱里的任何操作都不会影响真实数据评测完可以随手重置环境。第三是工具桩。核心思想是把外部依赖全部换成可控的模拟服务。比如真实支付接口在网络抖动和幂等性上不可控但评测需要稳定可复现所以我会启动一个本地 HTTP 服务模拟支付接口返回码、响应延迟、异常路径全部由测试脚本指定。工具桩最妙的地方在于可以“注入故障”。想让 Agent 遇到支付超时直接让桩服务返回超时想看空结果的场景就让查询接口返回空列表。这种可控性在真实环境里是根本做不到的。3.2 评测用例在代码里怎么落地环境搭好之后评测用例本身最好用代码表达这样才能集成 CI、做回归。下面是我在项目里常见的一个用例骨架字段用了伪代码思路可以直接落地# 评测用例骨架示例 async def test_cancel_order_success(agent_factory, sandbox): # 1. 准备初始业务状态 sandbox.db.create_order(order_idA100, statusactive) # 2. 构造用户请求 request 我要取消昨天下的那个订单单号是A100 # 3. 运行被测 Agent result await agent_factory(requestrequest).run() # 4. 重点:校验环境最终状态,而不是只看agent回复文本 assert sandbox.db.get_order(A100).status cancelled # 5. 辅助校验过程:检查轨迹里是否出现了预期工具调用 assert any(tool.name cancel_order for tool in result.trajectory)这段代码里的核心思想是“用环境状态断言代替文本断言”。Agent 的回复文本千变万化直接解析文本既脆弱又容易误判。状态断言是稳定的、可精确验证的这才是端到端评测该有的姿势。实际用例会比这个复杂比如要处理超时、并发、依赖初始化。但骨架思路就是三步准备初始状态、跑 Agent、断言最终状态。永远不要试图在评测脚本里逐字解析 Agent 回复里的客套话。3.3 用现成框架还是自建 harness我的取舍标准市面上已经有一些评测框架比如 LangSmith、LangFuse以及各家模型服务商自带的评测工具也常有人问我是直接用还是自己写。我的个人经验是评测 harness 和 Agent 框架的关系应该是解耦的。评测 harness 的职责是加载评测集、初始化环境、运行 Agent、收集结果、执行断言、产报告。Agent 本身是 harness 的“被测物体”两者之间只暴露标准接口。如果评测框架和 Agent 框架绑得过死一旦 Agent 换架构评测体系也跟着推倒重来。所以我的取舍标准很直接如果你还在快速迭代阶段Agent 的结构都可能变那先用简单的自定义 harness保持轻量别急着上大而全的框架。如果你的 Agent 框架稳定了并且现有评测工具支持无侵入式接入可以考虑引入现成框架省去维护成本。不管选哪种评测脚本里尽量不要出现 Agent 框架特有的内部 API最好只通过一个 run() 方法交互。我自己长期用的是 pytest 加一层自定义 runner评测集是纯数据文件。Agent 换过两次底座评测体系基本没伤筋动骨这就是解耦的好处。3.4 并发评测和成本控制的具体办法评测集一旦变多几百条用例顺序跑可能要跑一个晚上所以并发是必然选择。但并发也会带来成本失控这两者必须一起设计。我的做法是先给每类任务定一个并发上限。日常冒烟评测并发 8全量回归并发 32 左右具体看模型服务端的限流策略。跑之前先估计总 token 消耗如果超出预算按任务难度分层抽样优先跑高价值用例。另外两个习惯也值得养成一是用评测结果缓存。同一个任务集、同一个 Agent 版本、同一次运行之间如果评测输入没变化可以复用上次的缓存结果避免重复消耗。特别是开发调 prompt 时只跑受影响的子集就够了。二是对失败用例做“二次确认”。第一次跑失败的用例我会自动重跑一次区分偶发失败和确定失败。这一步常被忽略但能帮你过滤大量因为外部抖动产生的虚假失败。4. 评测集怎么构建才经得起业务考验4.1 从真实业务日志里挖评测任务评测集不能靠拍脑袋写。评测集构建的第一原则是尽可能从真实业务场景里来。真实场景的数据才有足够的“野性”那些用户千奇百怪的表达方式才是 Agent 每天要面对的真实压力。我的操作路径是这样的第一步拉历史业务日志筛出用户真实请求比如客服会话里用户提出的退款、改签、查询需求。第二步按意图聚类。把表达不同但意图相同的请求归到一组比如“我要退钱”“这个商品我不想要了”“怎么申请退款”都归到“退款申请”这个意图下。第三步为每组请求补全任务要素初始状态、预期最终状态、期望工具序列。从日志里挖出来的任务最大的价值是它带着真实噪声。用户不会按教科书说话会省略信息、会有错别字、会一次提多个需求。这些在人工构造里很难模拟到位。不过我提醒一句真实日志只解决“像不像真实用户”的问题不等于覆盖了所有关键路径。因此还需要人工补齐边界和异常场景。4.2 人工构造和难度分级的思路补齐人工用例时我一般按这几类去写极简表达用户给的信息特别少看 Agent 会不会主动追问。信息冗余一句话里塞五六个意图看 Agent 能不能拆解和排序。权限受限用户想执行某个操作但没有权限看 Agent 是否及时告知并引导替代方案。工具异常外部服务返回超时、错误码、空结果看 Agent 如何恢复。状态冲突比如订单已经取消了用户又要求取消看 Agent 正确理解新状态并避免重复操作。写完之后按难度分级。我习惯分成 P0 到 P3 四级P0 是最核心的主流程任何发布都必须通过P1 是常见变体P2 是边界和异常P3 是长程复杂任务。分级的目的是让回归策略有弹性小改动跑 P0 P1大改动再扩大到全量。4.3 评测标签体系与数据质量维护评测集不是静态资产它要随着业务演进持续更新。为了让更新有序我坚持给每条用例打标签。标签至少包括业务领域订单、售后、营销、能力类型信息查询、状态变更、多步骤协调、难度级别P0-P3、意图聚类 ID、失败模式用于分析时回填。有了标签分析结果时可以快速切片。比如想知道“售后场景 P2 级别的通过率是不是下降了”一条查询就能出来。没有标签的评测集跑完只能看个总通过率什么都定位不了。评测集本身也会“坏”。有些用例写的时候预期状态和后来业务调整不一致有些用例描述本身有歧义。所以我每轮全量回归后都会扫一遍长期失败的用例。如果同一个用例连续两周失败并且 Agent 改动和它无关大概率是用例本身有问题我宁可先把它标记为“待审核”也不让它继续污染通过率数字。5. Agent 评测踩坑实录假通过、不稳定和超时排查5.1 同一个用例第一次过、第二次挂怎么判断Agent 评测最让人头疼的就是同一个用例这次跑通过下次跑就失败看起来毫无规律。第一次遇到这种情况我花了好几天排查代码和环境最后发现根因在一部分随机性上——模型采样本身就不是确定性的。现在的处理办法是双管齐下第一在评测配置里固定 temperature、top_p 等采样参数能固定 seed 的尽量固定。这能降低一部分随机波动但坦白说不能完全消除尤其是明显基于某个前沿模型的 Agent。第二用“多次运行取多数”的策略。关键用例默认跑 3 次至少 2 次通过才算通过。这样做单条用例成本上去了但稳定性大幅提升。全量集跑一次花的时间多了可结果更有说服力。另外还要区分两类失败偶发失败和趋势性失败。偶发失败是同一用例多次运行有概率通过也有概率挂掉通常不是代码问题。趋势性失败是某个模型版本或 prompt 修改后通过率持续下降这类必须当回归处理。建立这种区分能帮你少折腾很多无谓的排查。5.2 “假通过”的识别与防御假通过是评测体系里最隐蔽的问题。表面上看用例跑通了实际上 Agent 根本就没完成任务。我遇到过最典型的情况Agent 在工具执行失败后没有重试也没继续处理只是回复用户“非常抱歉系统暂时无法处理您的请求请稍后再试”。从回复文本上看它既礼貌又合理但环境状态根本没变。如果用文本匹配来验收这个用例大概率会被判通过。防御手段只有一个就是在评测脚本里强制做“环境状态断言”。如果订单状态没有变成 cancelled不管 Agent 回复得多诚恳一律判失败。另一个假通过场景是工具桩返回了假数据。比如模拟查询接口里预制了所有订单状态为“已取消”那 Agent 无论怎么查都是已取消最终断言当然能过。所以每次跑评测前工具的初始数据都要由测试用例显式重置不能依赖上一次运行留下的状态。5.3 超时、卡死和工具异常的处理套路Agent 测评跑久了一定会遇到超时和卡死不提前处理的话会拖垮整个评测流程。我目前的标准配置是整个任务设置最大时长我常用 10 分钟超过就直接终止并标记“超时失败”。单个工具调用设置超时我常用 20 秒。超时的工具返回一个标准错误给 Agent观察它能不能恢复。设置最大步数一般 40 步。超过 40 步仍然没完成基本可以认定是低效循环直接断掉。循环检测也很有用。同一工具、同一参数调用超过三次评测脚本可以给 Agent 发一个系统提示或者直接终止。工具异常不光是超时还有返回格式异常、内容为空的边界情况。评测时要有意把这些情况注入到工具桩里。真实系统里接口不会永远是理想状态Agent 有没有预案靠评测见分晓。5.4 把评测挂进 CI 前要想清楚这几件事很多团队做到一定程度就想把评测塞进 CI每次提交代码都跑全量。我的建议是别急着全量先做分层。我把评测拆成两层。第一层是冒烟评测十几条 P0 用例覆盖主流程跑完只要几分钟。任何变更包括 prompt 调整、工具改动、模型切换都要跑冒烟。第二层是全量评测几百条用例在夜间跑或发布前跑。全量过了才允许上线。另外 CI 里跑评测要注意缓存。如果评测集没变化、Agent 版本没变化同样的用例不应该在每次 CI 里重复消耗 token。配合结果缓存能把 CI 成本压到一个合理范围。还有一点不能忽视评测频率别太高。真没必要每次 push 都跑几百条用例。按变更范围动态选择评测子集改 prompt 就只跑 prompt 敏感用例改工具才跑工具相关用例这是控制预算最有效的手段。5.5 问题排查快速判定清单把最常见的现象、可能原因和优先动作列成一张表排查时直接对表操作效率会高很多现象可能原因优先动作用例首次通过、二次失败模型采样随机、外部服务抖动固定采样参数多次运行取多数区分偶发与趋势失败通过率高但上线后表现差评测集与真实分布偏差大环境断言漏回真实日志补任务补强环境状态断言Agent 反复调用同一个工具工具参数生成错误、缺少终止条件检查轨迹中的参数增加循环检测某个用例一直超时工具桩响应慢、Agent 陷入死循环增加单工具超时减少困惑路径观察轨迹并发一高就大量失败API 限流、资源竞争降低并发增加重试策略检查评测资源独立部署连续多轮通过率骤降模型版本升级、prompt 变更对比历史轨迹差异回滚变更定位回归这张表我打印出来贴在工位旁边每次评测出问题都对一遍省了很多重复排查的时间。6. 如果重来一遍我会最先做哪两件事6.1 把真实业务日志转评测集这件事提前做最开始搭评测时我的评测集大多靠团队“想出来”后来又花了大功夫去业务日志里挖真实请求。两者之间差别极大真实的用词、真实的情绪、真实的省略都会影响评测效果。如果重来一遍我会在第一天就安排人去拉日志、聚类意图、建初版评测集。这是让评测体系有生命力的关键也是最难后期补的功课。6.2 把环境状态校验写进每条用例第二个会提前做的是环境状态断言。我在早期很多用例里只校验 Agent 的回复文本导致漏掉一批“假通过”的垃圾结果。现在每条用例的第一条断言都是“业务环境状态是否符合预期”文本判断只作为辅助。环境状态断言看起来简单但需要业务方深度参与定义“什么才算真正完成”。这个过程本身就是和业务对齐预期的过程价值远超技术本身。最后再分享一个心得评测体系的价值不在跑出多漂亮的数字而在每次数字波动时能帮团队快速定位到具体问题、具体用例、具体轨迹。别追求一百分先把“可解释”做到六十分这套体系在团队里就自然站得住脚了。