端到端Agent Evaluation：智能体自动化评测体系实战

Agent 项目跑到第三个迭代周期我琢磨最多的问题已经不是怎么写推理逻辑而是怎么把自动化评测跑起来、怎么相信我发出去的版本。一个 prompt 措辞的小改动、一次工具参数定义的调整都可能让 Agent 的行为出现不可预知的漂移——这条链路在这个场景没问题换一个场景就连环出错。靠人工回归点检既慢又不稳定。这半年我们集中做了一件事把 Agent 的评测流程自动化从任务下发、Agent 决策执行、工具调用回环一直到结果判定、指标聚合完整跑通一条端到端的 Agent Evaluation 体系。先说清楚两个词端到端在这里指的是评测链路覆盖 Agent 从接到请求到产出结果的完整闭环不是智驾圈常说的那个端到端模型自动化指的是从任务注入到报告产出中间不需要人碰任何环节。这篇文章适合正在做 Agent 应用或大模型产品评测基建的同学也适合准备把人工回归换成自动化评测的团队我会把架构、任务集、判题策略、日常运转细节和踩过的坑一起写出来。1. 为什么 Agent 评测不能照搬传统问答评测1.1 Agent 的核心差异从一次回答变成一串决策想设计评测体系先得认清评测对象。传统对话式评测或者说传统 NLP 基准测试评测的是一个输入-输出映射给模型一个问题模型吐一个答案然后拿相似度、准确率或者人工评分衡量答案质量。但到了 Agent 场景事情变成了一个动态决策过程。大多数 Agent 应用都在跑 ReAct 式的循环模型先理解用户意图生成计划计划拆成工具调用工具返回结果后模型观察、再决策直到收集够信息生成最终回复。也就是说被测 Agent 输出的不是一串文本而是一串经过多轮推理和行动形成的决策序列中间夹着大量工具调用的中间状态。这带来一个本质变化评测标准从答案对不对扩展成了任务成不成、路径好不好、效率高不高。一个 Agent 就算最终回复正确但过程中反复调用同一个工具、在无关工具上浪费了大量 token这依然是不良行为。反过来Agent 中途绕了弯路最后换了个工具成功搞定任务这同样应该得到认可。传统的问答评测根本没覆盖这两个维度。1.2 传统 NLP 评测指标在 Agent 场景中的三个失效点第一是指标不可比。BLEU、ROUGE 这类指标依赖参考文本和候选文本之间的 n-gram 重叠但 Agent 的输出经常是 JSON、工具调用参数、数据库查询结果甚至一次页面操作。没有天然的参考答案硬套相似度指标结果既没有判别力还会带偏方向。第二是归因困难。单轮问答错了原因相对集中。Agent 任务失败却可能发生在多个环节意图理解错了、任务规划缺步骤、工具参数构造错误、工具返回的数据没被正确解析。如果只拿最终答案和标准答案比对就算判出错了也定位不到具体是哪个环节出的问题。工程上最贵的不是发现错而是定位错。第三是环境耦合。Agent 要调用真实的外部服务下单得下到测试环境查库要连影子库天气接口可能限流支付网关可能不稳定。传统评测假设输入给定输出对比是一个封闭环境Agent 评测却是开放环境环境抖动会被错误地算成 Agent 能力退化。所以结论很直接Agent 评测必须独立设计一套体系而不能拿问答评测的尺子硬量这就是 Agent Evaluation 要解决的真正问题。2. 端到端评测的总体架构五个环节打通一条链路2.1 评测全链路长什么样我们搭的这套体系核心链路可以拆成五个环节任务集管理、执行器、过程数据层、判题器、指标聚合与报告。一条评测请求大致是这样走的评测任务从任务集取出带上元数据和难度标签执行器把任务包装成标准 session调用被测 Agent 的接口启动对话Agent 运行过程中产生的每一次模型输出、工具调用、环境返回都被结构化记录到过程数据层会话结束判题器读取完整过程数据和最终回复按规则或模型裁判给出得分得分汇总到指标层按任务类型、难度、工具维度做分组聚合生成报告和基线对比打个比方这套链路就像餐厅试菜任务集是菜谱执行器是后厨过程数据是后厨监控录像判题器是试菜员指标聚合是记账本。想判断一道菜到底做得怎么样不能光尝最后一口还得看后厨有没有多放盐、有没有烧糊锅、用了多少食材。监控录像的意义就在这。为什么强调端到端因为只单独测 LLM 的规划能力再单独测工具选择准确性两个环节分数都很高合在一起任务却失败了。原因在衔接损耗规划结果没被后续执行正确引用、工具返回超时导致规划作废。端到端评测把整个链路作为一个整体跑完才能捕捉到真实系统在真实链路里的表现。它的定位虽然不是精细化归因但能保证有问题一定被看见。2.2 评测环境隔离别让环境抖动背锅Agent 要跑真实逻辑绕不开外部依赖。我们踩过的坑是第一版评测直接打生产 API 和数据库某天第三方支付接口限流当天任务成功率掉到 61%看起来像 Agent 出了大问题最后查了半天才发现是环境问题。从那以后环境隔离成了硬性要求。我们的做法分四层外部 HTTP 服务优先用录制回放的 mock server。线上把真实请求和响应录制下来评测时按 key 匹配返回。需要覆盖新场景或新数据时再对特定服务开测试环境白名单。数据库用影子库或者每次评测前重建的 Docker 实例避免脏数据残留影响下一轮。第三方账号与配额申请专项评测测试账号独立 quota避免和线上抢资源。模型推理服务被测 Agent 依赖的基础模型服务单独部署一份同版本实例防止线上流量挤占评测推理能力。需要提醒的是隔离不是越干净越好。mock 环境太干净Agent 踩不到现实中的坑比如接口格式变化、某个字段为空评测结果会虚高。成熟的团队通常采用真实服务优先mock 兜底的混合策略核心流程连测试环境真实服务很不稳定或不可重放的服务才 mock。评测只有接上真实世界的粗糙度才有参考价值。实测下来环境隔离这部分花了我们将近三分之一的搭建时间但后面省下的排查时间远超投入。评测体系里每一个假阳性失败都在消耗团队对评测的信任环境问题导致的误报伤的恰恰是评测体系自身的公信力。3. 评测任务集场景覆盖度决定评测体系的天花板3.1 从真实用户日志沉淀任务任务集是评测体系的地基。地基烂了后面跑得再顺也是自欺欺人。我们给自己定的原则是任务集绝不能只是我们觉得用户会问什么必须有相当比例来自真实用户怎么问。具体做法是建一条从生产日志到评测任务集的生产线。第一步把用户会话日志按 session 切好并脱敏第二步给用户意图做聚类看高频意图分布第三步按意图类别做分层抽样保证每个高频场景都有覆盖第四步把样本手工剪裁成标准评测任务包括用户输入、期望结果、允许的工具范围、难度标签。这条生产线跑起来以后评测和真实用户需求的代差会逐渐缩小。抽样要特别注意一个问题日志里八成都是帮我查一下 X这类简单请求如果完全随机抽样任务集会被简单任务淹没。我们后来改成按意图分层加权抽样简单场景抽一部分复杂场景在日志里可能只占 5%但要给它 20% 的权重评测结果才不会显得水分很大。3.2 模板化生成与难度分级光靠真实日志还不够很多边界场景日志里根本不会出现。比如用户让 Agent 调用不存在的工具、工具中途返回错误码这些都需要模板化生成来补。做法很简单设计任务模板加参数槽位批量生成用例。比如帮我在{系统}里查一下{对象}的{属性}参数槽填入不同实体一次生成几十条变体。又如失败恢复类任务先调用{工具A}若失败就改用{工具B}完成{目标}专门测 Agent 的应变能力。难度分级给一个我们实际在用的划分等级特征示例L1单次工具调用结果可确定查询订单物流状态单次 query_order 调用L2多步工具调用链路固定先查余额再交易、先登录再拉列表L3需要规划分支信息不完整根据预算推荐方案并完成下单L4需要纠错、恢复、处理异常工具失败后切换备用方案、主动澄清意图L1/L2 用于回归守门L3/L4 用于能力评估。两拨任务分开看指标不要混在一起算一个成功率。把 L4 和 L1 混成一个数字只会得到一个看着还行的均值什么问题都暴露不了。3.3 黄金标注集钱要花在最值得的地方模板生成和日志沉淀只能保证用例有了不能保证答案有标准。所以必须维护一批黄金标注集golden set。黄金标注集的设计我们分了三个层次。一是可接受的结果范围比如返回订单状态字段值可以是已发货或运输中不能是已取消二是期望的工具调用序列比如应调用 query_order_detail参数 order_id 必须是用户提供的那个订单号三是禁止出现的行为比如不得调用 create_order用户已提供登录态时不得要求重新登录。有人会问黄金标注集成本高不高说实话不低一条复杂用例半小时起步。但我们的经验是不需要全覆盖维护 200 到 500 条精品黄金用例价值远超几千条边角料。因为模型裁判判分时需要锚定样例黄金集就是那把尺子尺子不准判出来的分数也会歪到一边去。4. 自动执行与过程追踪让 Agent 每一步都留痕4.1 执行器的三点设计执行器的角色很简单把评测任务注入被测 Agent控制运行边界把过程数据全部捞出来。但细节上有讲究。第一统一入口。不管被测 Agent 是 Python SDK、HTTP 接口还是内部 RPC执行器外层统一包一层适配器评测框架只和适配器说话。这样换模型、换 Agent 框架不需要重写评测系统。我们至今换过三轮底层框架评测系统本身只动了适配器那几十行代码。第二独立 session。每一条评测用例必须跑在全新的上下文里中途不能复用其它用例的任何 history否则上下文串味评测结果直接作废。我们的执行器每次启动前会强制 reset 会话上下文这条写进代码检查项防止有人图省事复用 session。第三超时与并发控制。每个用例设两个超时总超时和单步超时。总超时防止 Agent 陷入死循环单步超时防止某个工具调用挂死。并发度按被测系统的承受力配别一上来 50 并发把第三方服务打挂。我们一般是先压一轮找 95 分位延迟和吞吐的平衡点再对评测并发放行。4.2 过程事件模型定义回放的最小单元判题要分析过程过程要能回放回放要依赖结构化的事件。我们参考 ReAct 循环的语义把过程记录成统一事件序列每个事件带 trace_id 串起整条会话。事件类型大致分六类user_input、plan、tool_call、tool_result、final_answer、error。每条事件记录时间戳、token 消耗、延迟。这是最原始的过程数据判题器靠它定位问题指标层靠它算成本开发同学靠它复现现场。下面是一条 tool_call 事件落到存储里的样子可以直接感受一下。{ trace_id: eval_20250601_0018, run_id: run_8f3a2c, turn_id: 3, event_type: tool_call, content: { tool_name: query_order, arguments: {order_id: 20250601001} }, latency_ms: 540, cost_tokens: 128, ts: 2025-06-01T10:00:03Z }存储这块我们用 ClickHouse 落明细因为查询维度多、写入量大列式存储更合适。项目早期用 SQLite 也能顶但如果后续要做全量数据下钻分析建议一步到位上列存省得中途迁移。4.3 别把环境错误记在 Agent 头上这是评测系统最容易翻车的细节。Agent 执行过程中很多失败来自外部环境接口 503、数据库连接超时、mock server 没启动、参数里的日期格式不匹配。这些都不是 Agent 的推理和决策问题但如果不在记录阶段区分判题器就会把它们全算成任务失败。我们的处理方案是执行器在收集事件时给 error 事件打来源标签——Agent 内部模型输出了非法格式、工具调用目标工具返回了异常、基础设施网络超时。判题阶段遇到基础设施类错误这轮用例标记为环境异常单独剔除或重试不进成功率分母。重试策略也顺带说一下。环境错误往往是瞬时的重试一次通常就过了但如果同一用例连续重试两次还是环境错误就标记为环境故障执行器继续往下跑别的用例不要让单条用例阻塞整条评测链路。5. 自动判题规则、模型裁判与人工抽检的三层配合5.1 能写死就写死规则判定的边界判题器的第一原则能用确定性规则判的绝不让模型判。什么任务适合规则判定结果可以形式化的任务。比如查询类任务标准答案是一个结构化字段那就直接解析 Agent 最终回复比对字段和值工具调用类任务期望序列是确定的比对事件流里的 tool_call 序列是否符合预期。规则判定的好处是稳定、可审计出问题随时能指出是哪条规则判错了。规则写不出来的场景主要是开放任务和规划合理性。比如根据用户预算推荐一个方案并解释理由什么是好方案没有客观定义这时候才轮到模型裁判出场。5.2 LLM-as-Judge评测模型的可靠性问题与缓解我看到不少团队直接把一个通用大模型作为 judge让它读一遍对话就给分然后发现分数漂移严重。同一个用例今天 8 分明天 5 分把方案 A 和方案 B 的顺序换一下评判结果跟着变。这是 LLM-as-Judge 天然的偏差代码里规避不了只能在评测协议上做约束。实践下来比较有效的做法有四条。第一用评分卡替代自由打分。不要问请对本次任务打分而是把任务拆成多个维度任务完成度、工具使用正确性、过程效率、回复可读性。每个维度单独打分最后加权。维度拆得越细模型的主观空间越小分数稳定性越高。第二给出锚定样例。评分提示词里带上黄金标注集的 1 到 2 条样例写明这类情况给满分这类情况给 3 分这类情况给 0 分把评分空间钉死避免模型凭感觉打分。第三温度设为 0并要求输出理由。要求 judge 为每项分数输出判分依据理由留痕人工复核时有据可查。温度 0 保证同一条输入多次评判结果一致。第四双模型投票。对争议用例让两个不同的模型分别打分不一致再过人工。我们实际跑下来双模型的一致性比单模型高不少但成本贵一倍所以只对规则判不了、且第一次 judge 得分在中位数区间的用例使用没必要全量铺开。具体打分提示词我这里保留了一个适合当模板的版本你是一名 Agent 评测员。下面是一次 Agent 完成用户任务的完整过程记录 请按以下四个维度分别打分每个维度 0-5 分并给出理由。 维度1 任务完成度最终答案是否解决了用户的核心诉求 维度2 工具使用正确性是否存在错误工具、无效参数、重复调用 维度3 过程效率是否用最少的必要步骤完成有无多余往返 维度4 回复可读性最终答案是否清晰、无歧义、格式友好 打分标准 5完全符合要求3部分满足但有明显瑕疵0基本未满足。 请同时参考以下锚定样例 [这里插入黄金样例和对应打分] 输出格式 {task_completion: 分数, tool_correctness: 分数, process_efficiency: 分数, readability: 分数, reason: 每个维度一两句判分依据}5.3 指标聚合别让报告变成一张数字糊墙纸单条用例判完分接下来是把分数聚合到团队能用的层面。聚合格局上切记不要只给一个总成功率一定要能分层下钻。我们报告里的指标分成三层层级指标示例总体层任务成功率、平均任务耗时、平均单任务成本分组层按任务等级L1-L4、按工具域、按意图类别的成功率明细层每条失败用例的失败阶段、失败类型、判题理由分组层是团队每天盯得最多的。比如这次改动影响的是财务域工具那财务域任务成功率从 92% 掉到 78%比总成功率从 90% 掉到 88% 更能说明问题。没有分组层大盘数字往往会掩盖具体领域的退化。顺便说一句报告里每个分组的样本量要带上只有 20 条样本的分组掉 10 个百分点和 2000 条样本掉 10 个百分点含义完全不一样。6. 从搭建到运转评测体系真正活起来的日常节奏6.1 每日跑批与基线对比评测体系如果只在发版前手动跑一次价值会大打折扣。我们的做法是把评测变成日常节奏每天凌晨定时跑全量评测集结果自动和基线版本对比。基线选择上我们固定上一稳定版作为基准每次新版本合并到主干、或者模型配置有变更立刻触发一次对比评测。对比报告需要明确几个信号成功率是否出现超过阈值的下降、哪些分组跌了、哪些用例从过变为不过。日跑批的意义在于出问题当天发现、当天定位而不是等用户投诉了才回头查版本。红线机制也很重要。每个团队应该想清楚自己的核心场景设一两条不允许碰的红线指标。比如我们规定交易链路任务成功率低于 90% 不允许发版。红线不需要多两三个就够多了团队会疲劳最后反而形同虚设。6.2 失败用例的三级分类法每天跑完评测会收到一批失败用例。不分类直接丢给开发效率极低。我们按优先级把失败用例分三档档位类型处理方式P0核心场景能力退化当天定位阻塞发版P1边界场景、低概率失败进入迭代排期P2环境抖动、判题不准标记剔除不进入指标P2 占比要格外留意。如果某天 P2 特别高通常说明环境不稳定或者判题器出了问题这时候应该优先修环境和判题而不是去改 Agent。我曾遇到过连续三天失败里四成是 mock server 返回了旧格式数据第四天才发现那几天的评测结论全部作废。环境健康度和判题置信度本身就是评测体系的元指标建议一并监控。6.3 从脚本到平台几条务实建议最后聊演进路线。第一版评测体系完全可以是一个脚本加一份 HTML 报告先跑通小闭环。等用例数量过千、团队多人协作时再考虑平台化任务集管理、用例版本管理、多人维护标注集、失败用例讨论区这些功能才是平台化的核心价值不是做个好看的界面。还有一个很推荐的进阶方向把评测失败用例自动回流成新任务。线上用户高频问题、评测中新发现的边界情况都可以自动生成草稿用例人工审核后进任务集。让评测集跟着产品一起进化而不是永远测那几百条老用例这个能力直接决定了评测体系半年后的价值。最后说一点我自己折腾这套体系的心得。评测系统就像一面照妖镜它不会直接把 Agent 变好但能让团队每天睁眼第一时间看到Agent 到底是变好了还是变坏了。搭建阶段不要急着堆指标、铺用例先把过程日志和失败现场抓全让每一个失败都能被复现、被定位这套体系才真正值钱。如果你正准备开始搭 Agent Evaluation我的建议是第一版先跑通最小闭环——几十条任务、一个规则判题脚本、一份报告让它先转起来再谈规模化和平台化。自动化评测这条路没有什么捷径唯一的捷径就是让每次失败都留下痕迹。