Agent 上线第二天就被用户投诉答非所问这可能是每个做 Agent 应用的人都经历过的噩梦。我在之前的团队负责过一个基于 ReAct 框架的客服 Agentdemo 演示给老板看时行云流水工具调用一气呵成结果真上线第一周工单系统里堆了十几条投诉有的说 Agent 重复查询同一个接口三次有的说它根本没理解用户意图就瞎回答最离谱的是有一条任务它调了五个工具最后给了个完全错误的结论。更难受的是这些故障在发布前我们完全没发现因为整个团队验证 Agent 的方式就是开发同学手动点几个 case 看看效果。那次事故之后我花了小半年时间把 Agent Evaluation 从零到一搭成了一整套可复用的评测基建。这篇文章就是把整套体系的设计思路、架构选型、指标定义和工程落地细节完整拆开来讲。我会先解释为什么传统的 NLP 评测方法在 Agent 面前会失效再讲评测体系的四层架构怎么设计然后深入测试集建设、指标设计、评估器选型以及流水线工程化这几个核心环节。文章主要面向三类读者正在做 Agent 应用但还在用抽查几个 case代替评测的开发者、已经在用规则评测但发现覆盖不住复杂任务的评测工程师以及想从零搭建端到端 Agent 评测体系但不知道从哪里下手的团队。1. 为什么传统评测方法在 Agent 面前全线失灵1.1 你没法用 BLEU 去衡量一次工具调用是否合理先说一个很多刚接触 Agent 评测的同学最容易踩的坑直接把传统 NLP 评测指标搬过来用。BLEU、ROUGE、METEOR 这些指标本质上是在计算生成文本和参考答案之间的 n-gram 重叠度。它们适合翻译、摘要这类输出必须贴着参考文本的任务。但 Agent 的输出不是一个文本而是一个动作序列——它什么时候调用工具、传了什么参数、依据工具返回结果做了什么决策——这些行为的合理性根本没办法靠文本重叠来衡量。举一个具体的例子。用户问明天北京会下雨吗一个合格的天气 Agent 应该先调用天气 API 查询北京明天的降水概率再根据返回的数据组织回答。这时候你拿它的最终回答跟参考答案做 BLEU 对比可能重合的词非常少因为只要语义对就行用词完全不需要一致。但只要它调用了正确的工具、传入了正确的城市参数、并且回答时引用了真实返回数据这就是一次高质量的任务完成。反过来就算它生成的句子和参考答案高度相似但中间调用工具时把城市参数传成了上海那也是十足的失败。所以 Agent 评测的第一性原理其实很简单要评估的对象不是最终文本而是完整的行为轨迹。轨迹里每一跳的决策质量、每一步工具调用的参数正确性、以及最终任务是否被解决这三个层面缺一不可。1.2 Agent 的失败模式远超普通 NLP 任务传统 NLP 任务一般是输入一段文本输出一段文本失败模式相对可控。Agent 任务则是多步决策问题一边是用户需求表达的不确定性另一边是工具返回结果的不可控再加上 Agent 自身的随机性它的失败模式是指数级增长的。我复盘过当年客服 Agent 上线第一周遇到的所有故障归纳下来 Agent 的典型失败模式至少有这几类理解偏差Agent 误解了用户意图比如把取消订阅里的订阅理解成邮件订阅还是账号会员没分清楚工具选择错误面对多个相似工具时选错比如该调用查询订单却调用了查询退货单参数构造错误工具选对了但参数值错了比如把日期格式从 YYYY-MM-DD 传成了 MM/DD/YYYY决策循环或卡死Agent 陷入调用工具→结果异常→再调用→结果更异常的死循环最后超出最大步数被强制终止幻觉补全工具没有返回关键信息时Agent 自己脑补了一个答案成本失控同一个接口被反复调用三五次或者上下文越滚越长单次任务 token 消耗暴涨。这套失败模式列表我现在还在持续扩充。它给评测体系的一个核心启示是不能只设计一个任务是否成功的二元指标还需要针对每种失败模式设计专项检测。这也是 Agent 评测和传统模型评测最大的差异——传统评测只需要一个分数Agent 评测需要一套多维度的体检报告。1.3 随机性让评测结果天然不可复现另一个让评测工程化变得很麻烦的是 Agent 的随机性。就算你把 temperature 设成 0LLM 的采样、并行执行时的竞态条件、外部 API 的延迟抖动都会让同一条测试用例跑两次得到完全不同的轨迹。我专门做过一个实测一条中等难度的任务同一个模型、同一份配置连续跑五次。结果两次完整成功一次在第二个工具调用环节就出错还有两次虽然最终成功了但绕了一段远路多调用了无用工具。这个数据说明一个很关键的工程结论如果评测体系没有引入多次运行取归一化结果的机制单次跑出来的通过率没有任何统计意义。这个问题是整个评测设计里最优先级的约束后面讲指标计算、回归判定、CI 阈值设置的时候我都会反复回到它。2. 端到端评测体系的四层架构环境、用例、执行器、评估器2.1 架构总览四个组件各司其职在动手写代码之前我建议先把评测体系的逻辑分层画清楚。跟大多数工程问题一样边界划清楚了后面才不会乱。我最终采用的是四层结构环境层负责准备可控的执行环境用例层负责提供任务与标注执行器层负责运行 Agent 并采集轨迹评估器层负责把轨迹变成可量化的结论。四层之间通过标准的评测任务数据结构通信每一层都可以独立替换。举个例子环境层可以在本地 mock 环境和生产影子环境之间切换而用例层、执行器层完全不用改。这是一个很关键的架构决策如果评测数据结构和运行环境耦合死了后面每做一次环境升级就要重写一半代码。2.2 环境层可控性是一切评测的基石环境层要解决的核心矛盾是真实性和可控性之间的平衡。理想情况下我们希望 Agent 在评测时面对的环境和生产环境完全一致但真实环境里外部依赖太多数据库里有未知脏数据、第三方 API 时好时坏、网络延迟随机抖动。这些噪声会直接污染评测结论——你根本分不清这次失败到底是 Agent 的问题还是环境的问题。我的做法是分三层隔离确定性沙盒所有工具返回的数据都来自预先准备好的 fixture响应内容和耗时完全可控。这一层适合做回归测试和确定性断言是评测环境的主体录制回放层从生产环境录制真实的工具请求和响应评测时回放录制数据。这层兼顾了真实性和可复现性是发现 mock 和真实世界不一致的主要手段影子真实调用不时地把评测流量切到真实环境上跑一轮专门用来发现mock 环境和生产环境已经漂移的问题。这里最容易被忽视的是环境状态管理。Agent 任务往往有副作用创建一个订单这类任务会真的写入数据库。如果评测环境没有自动重置机制第二条用例跑的时候库里已经存在一条一模一样的订单Agent 返回订单号已存在任务判定就直接错乱了。所以环境层必须附带一个状态重置机制每跑完一组用例就恢复初始快照或者给每条用例分配独立的命名空间。这个问题在大多数 Agent 评测教程里都不会被强调但它恰恰是评测结果可信度的地基。2.3 用例层评测任务的数据结构设计用例层的数据结构决定了整个评测体系的能力上限。我强烈建议用 JSON Schema 来定义评测用例核心字段包括任务描述给 Agent 的输入、期望结果、可选的参考轨迹、难度级别、所属业务领域、以及一组轻量级标签。这套结构里我最想强调的是期望结果的设计。它不能只是一个字符串而应该是一个结构化的、可被不同评估器消费的对象。比如任务查询订单 OD20240001 的状态期望结果可以这样拆{ task_id: order_status_query_001, task: 查询订单 OD20240001 的状态, expected_outcome: { final_state: order_found, key_facts: [ {target: order_status, value: shipped} ], required_tool_calls: [ {tool: query_order, params: {order_id: OD20240001}} ] }, difficulty: easy, domain: ecommerce, tags: [tool_call, exact_match] }这样设计的好处是规则评估器可以直接对着required_tool_calls做断言模型评估器可以基于key_facts判断回答是否覆盖了关键信息两者解耦互不干扰。2.4 执行器层统一采集轨迹不干预 Agent 内部逻辑执行器层是评测体系里的数据采集端。它的职责是接收一条用例实例化 Agent把任务描述传进去运行到终止条件然后记录下完整的执行轨迹。这里有一个重要的设计原则评测框架不应该对 Agent 的内部逻辑做任何假设或干预。有些评测框架喜欢给 Agent 注入特殊的调试代码或者在每一步强行插入检查点。这么做虽然能拿到更多内部信息但会污染 Agent 的真实行为评测出来的结果根本不能代表线上表现。更好的方案是通过标准化的观测层来采集数据如果 Agent 暴露了回调钩子就通过钩子记录如果 Agent 不暴露就通过包装工具调用来采集动作序列如果连工具都包装不了就直接解析 Agent 输出的结构化日志。采集到的轨迹统一存放为有序事件列表每个事件包含三个核心字段时间戳、事件类型agent_message、tool_call、tool_result、final_answer、事件内容。所有评估器都消费这份标准轨迹格式不依赖任何特定 Agent 框架的内部实现。这也是为什么我们的评估器可以跨框架复用——换了一个 Agent 框架只需要重写执行器适配层后面的评估逻辑一行都不用动。3. 测试集建设评测的地基工程没有捷径3.1 测试用例来源三条路径的组合很多团队做 Agent 评测最大的卡点不是评估器写不出来而是测试集不知道从哪儿来。我的经验是用例来源有三个互补的渠道缺了哪个都会偏。第一个渠道是生产日志挖掘从真实用户请求里采样。这个渠道的最大价值是真实性。用户不会按你预想的方式提问他们的表达带着省略、歧义、口语化甚至错误信息这些在人工编造测试集时几乎不可能复现。我建议对生产日志做聚类分析把语义相似的请求聚成同一类再从每个类别里挑选代表性样本扩展成测试用例。第二个渠道是人工编制的高难度用例。这类用例专门针对系统的薄弱环节比如多条件组合查询、需要跨多个工具协作的复合任务、以及 Agent 历史上真实失败过的 case。它们的作用是划定系统的能力下限避免你在最容易的 80% 用例上自欺欺人。第三个渠道是合成数据生成。用大模型批量生成任务变体再人工抽检。这个方法效率最高但要非常小心生成用例的低质量和同质化问题——模型生成的任务常常千篇一律甚至会在任务描述里泄漏答案。我的经验是合成用例必须走生成-抽检-再平衡的流程而且合成比例控制在总测试集的 30% 以内比较稳妥剩下 70% 还是得靠真实日志和人工编制来撑质量。三条路加起来在一个中等业务场景下我建议起步就应该有 200-500 条用例。太少的话任何模型调整带来的性能波动都会被噪声吃掉评测体系起不到守门员的作用。3.2 标注规范可量化的断言比参考答案更重要测试集的标注质量直接决定评测结论的可信度。而标注最难的地方是定义什么算成功。我们内部把标注拆成三个独立维度每个维度由不同的人或流程负责避免一个人拍脑袋决定任务结果标注任务最终是否被解决。用可执行的断言来描述比如返回数据包含订单状态字段轨迹质量标注在任务被解决的前提下这个解法的路径是否合理有没有不必要的绕路关键步骤标注如果这条用例要用来做步骤级评测那么哪些工具调用是必须出现的、哪些参数必须正确。这里有一个值得反复强调的经验标注时尽量写可自动检查的断言而不是写参考答案。比如Agent 应该调用查询接口并返回订单状态这种描述评估器没法消费。更好的写法是在轨迹中存在tool_call事件其中tooltool_name、arguments.order_idOD20240001且最终回答包含order_status字段。断言语义越明确后面评估器的实现就越简单越不容易产生争议。3.3 测试集的维护版本化、难度平衡与防泄漏测试集不是一次性工程它是一个需要持续运营的资产。我沉淀下来的实践主要有三条。第一测试集必须版本化并且和 Agent 代码版本一一对应。每次重要迭代都要记录当前测试集在旧版本 Agent 上的基线分数作为后续回归的锚点。没有这个基线你拿着新测试集跑出来的分数根本没法跟历史版本比较。第二控制难度分布防止幸存者偏差。如果测试集里全是简单任务Agent 就算退化了一大截通过率也看不出来。我的做法是把用例按难度分成 easy、medium、hard 三档比例控制在 4:4:2并且每次迭代都追踪分档通过率的变化而不是只看总通过率。有时候总通过率没变但 hard 档通过率掉了 10 个点这就是一个非常值得警惕的信号。第三防泄漏。如果评测用例被大模型的训练语料收录了或者被 Agent 的 prompt 缓存命中那么这个分数就是失真的。所以测试集必须脱敏处理不包含生产环境的真实用户数据——这同时也是一个合规要求。4. 指标设计从最终结果到过程质量的多维指标体系4.1 结果指标任务完成率与关键事实覆盖率评测体系的第一类指标是结果指标它回答的问题是任务最终有没有被做完。最直接的指标是任务完成率Task Success Rate也就是测试集中被评估为已解决的用例占比。但这里有一个细节值得注意是否已解决的判断标准到底是什么。我建议把任务完成率再拆细一点至少包含两层严格完成率Strict Success Rate最终答案满足所有关键断言且轨迹中没有严重错误比如调用了错误工具、参数严重错误宽松完成率Loose Success Rate最终答案满足关键事实断言不要求过程完全合理。这两个指标放在一起看能快速判断一个 Agent 是结果对但路径乱还是路径对但结果飘。我之前带过的一个售后 Agent 项目就出现过这种情况模型升级后宽松完成率涨了 3%但严格完成率掉了 2%。翻了轨迹才发现新版模型喜欢先调用一个错误的查询接口再自我纠正最终答案是对的但白白浪费了两次工具调用和大量 token。如果只盯着最终答案这个性能回归就完全漏掉了。另一个补充指标是关键事实覆盖率Key Fact Coverage衡量最终回答覆盖了多少用户明确关心的信息点。这个指标特别适合开放式任务。开放式任务没法用非对即错来判定但可以检查用户明确要求的信息点是否都覆盖了。比如帮我规划一个北京三日游虽然规划得好不好是主观的但有没有包含交通、住宿、景点三块信息是可检查的。4.2 轨迹指标工具选择准确率、绕路率与循环检测第二类指标关注轨迹过程。我在线上长期在跑的主要有这几个工具选择准确率Tool Selection Accuracy统计所有tool_call事件中选择正确工具的比例。这个指标是 Agent 能力的基础工具都选不对后面一切免谈参数正确率Parameter Accuracy在工具选择正确的前提下统计参数构造正确的比例。这里要小心定义正确——我建议拆成必填参数是否齐全和参数值是否准确两层。日期格式写错了但值没变和值本身传错了是两种完全不同的错误级别绕路率Detour Rate统计那些最终成功但走了多余步骤的轨迹占比。怎么判定绕路一个实用的做法是参考人工标注的最短路径如果轨迹步数超过最短路径的 1.5 倍或者包含查询-改参数-再查询完全同参数的模式就算绕路循环检测Loop Detection检测 Agent 是否陷入重复调用同一个工具、且参数基本没变的死循环。我用过一个很简单的启发式如果连续 N 次tool_call的目标工具和参数哈希相似度超过阈值就告警。N 我一般设 3阈值设 0.9。这些轨迹指标的价值在于它们能把一个任务失败的黑盒拆解成具体是哪一步决策错了。研发同学拿到评测报告时不需要再大海捞针地翻完整轨迹日志直接看是工具选择错了还是参数构造错了定位效率高一个量级。4.3 成本与稳定性指标评测必须看的资源维度结果指标和轨迹指标衡量的是做得好不好成本指标和稳定性指标衡量的是能不能放心用。我在评测报告里固定输出这几项单任务 Token 消耗统计完整轨迹的输入输出 token 总和。模型升级后如果这个指标暴涨即使成功率微涨也要重新算算账任务完成延迟从用户请求到最终回答经过的总时长。注意这里要看端到端延迟而不是模型单次推理延迟因为工具调用和重试会显著拉长时间稳定性评分同一条用例重复运行 n 次得出的成功率方差归一化值。Agent 评测天然有随机性如果一条用例三次里成功一次、失败两次它贡献的成功率是 1/3但它的真实状态是不稳定。我们会把用例按稳定性分为稳定、波动、随机三档重点跟踪波动档的变化——很多时候 Agent 升级后成功率没变但波动档的比例悄悄上升了这本身就值得警惕。4.4 多轮任务与边界场景的指标设计多轮对话是 Agent 评测里最容易被低估的复杂度。单轮任务的指标设计已经够复杂多轮任务又新增了两个评测维度状态一致性用户在第二轮提到了第一轮的实体Agent 能否正确关联上下文。比如第一轮用户问帮我查一下订单 A 的物流第二轮说如果延迟了我再退款Agent 必须记住订单 A和物流状态这些实体跨轮计划性Agent 能否在多轮对话中记住用户的长期目标而不是被用户的即兴提问带偏。比如用户在规划旅行中途问了一句明天下雨吗回答完天气后还能不能自然地回到旅行规划主线上。多轮任务的标注要复杂得多。我的做法是给用例增加一个回合结构定义标明每一轮的意图切换类型比如延续确认型、新增约束型、话题转移型。评估时除了看最终结果还会单独统计状态一致率——第二轮提到第一轮实体时Agent 是否正确引用了同一实体的概率。这个指标在客服、销售、医疗问诊这类强上下文场景里比整体成功率更能反映真实体验。5. 评估器选型规则、模型裁判与混合方案的实战对比5.1 规则评估器什么时候该写什么时候该放弃评估器是整个评测体系里负责打分的部分。我的第一原则是能用规则判断的绝不用模型判断。规则有确定性和零成本两个无可替代的优势。规则评估器适合那些结果可以被明确枚举的任务类型。典型场景包括查天气、查订单、算价格、表单校验、状态查询。对这些任务期望结果里的断言已经写得足够结构化直接用断言匹配就行。比如判断是否调用了query_order工具、返回结果是否包含order_status字段都是几条简单的断言代码。但规则评估器有两个硬边界。第一它无法处理开放式任务。帮我写一份销售周报这种任务成功标准是主观的没法枚举。第二它对部分正确无能为力。任务完成了 70% 但漏了最后一步规则只能判失败无法给出中间档次的评分。遇到这两种情况就要引入模型评估器。5.2 模型评估器LLM-as-Judge 的评分卡设计用大模型当裁判是目前做开放式任务评测的主流方案。它的核心思路很朴素把任务描述、Agent 的执行轨迹、评分标准一起喂给一个评判模型让它输出分数和理由。但 LLM-as-Judge 用得好不好差距非常大。我踩过不少坑之后现在固定遵守这几个实践第一评分标准必须量化成可对照的评分卡而不是一句抽象的请根据质量打分。比如 0-5 分的标准里要写清楚 1 分是完全错误或幻觉、3 分是答案基本正确但漏掉次要信息、5 分是答案完整且轨迹高效。好的评分卡能让评判模型输出的一致性从 50% 提升到 80% 以上。第二必须给评判模型提供完整轨迹而不仅仅是最终回答。我早期犯过一个错误评估器只看最终回答打分。结果 Agent 在过程中调用了错误工具最后靠另一个工具偶然给出正确结果这种低质量轨迹被评成了满分。加上轨迹输入之后评估器能分辨出结果对但过程错评分才回到正常状态。第三注意评判模型自身的偏见问题。位置偏见先出现的回答更容易被偏好、冗长偏见回答越长分数越高、自我偏见评判模型更容易给同系列模型打高分都是真实存在的。缓解办法主要有两种多次采样不同顺序做配对比较或者让评判模型先输出证据链再给分数强制它思考后再打分。5.3 混合评估策略一条真实的决策链路我最推崇的是混合评估策略流程大概是这样的先用成本最低的规则检查做快速通道。凡是能通过规则断言的用例直接判通过不进入模型评估环节。这条快速通道通常能覆盖 30%-50% 的用例成本几乎为零。剩下的用例进入模型评估环节。这里建议做两级判断先让评判模型判断任务是否成功这个二元问题再针对成功或失败的轨迹分别做质量评分。把是否成功和打几分分开能显著降低模型误判的概率。最后一定要设置人工抽检环节。从模型评估结果中随机抽取 10%-15% 的样本由标注人员复核。复核的目的不只是修正误差更重要的是持续校准评判模型——如果发现评判模型在某一类任务上系统性判错就应该把这类任务回归到规则判断或者调整评分卡。这套混合策略的核心逻辑是让确定性逻辑处理确定性问题让大模型处理开放性问题让人力只处理剩余的不确定性。我最终用这套策略把单条用例的评估成本降到了纯模型评估方案的 40% 左右准确率反而更高。6. 端到端评测流水线的工程落地从脚本到持续回归6.1 评测任务编排调度、并行与资源隔离评测体系工程化的第一步是把跑用例这件事编排成可控的流水线。我遇到的最早的问题是一条用例平均要跑 30-60 秒包含多次大模型推理和工具调用200 条用例串行跑要两三个小时根本没法在每次代码提交后运行。解决思路就是并行编排。我的方案是用任务队列把评测用例打散按并发度分散到多个 worker 上执行每个 worker 独立跑一条用例完成后上报轨迹数据。并发度的设置要考虑评测环境的资源上限和被评测 Agent 的并发承载能力。我的经验是从 4 并发起步逐步调高直到评测环境出现资源竞争导致的超时再回落。这里要特别注意资源隔离。评测环境和开发环境一定要分开甚至每个并发 worker 最好独占一份干净的 mock 环境防止用例之间互相污染。我遇到过的一个极其隐蔽的问题是某个工具服务的缓存是全局共享的两条用例用了同一个缓存键第二条用例直接命中了第一条的缓存结果导致轨迹异常。排查了很久才发现是资源隔离的问题而不是 Agent 的问题。6.2 评测报告的消费方式研发要能直接定位问题评测体系的价值最终体现在报告怎么被消费。如果评测报告只给你一个通过率 78%的数字研发同学拿到报告根本没法干活。我们的报告模板里每个失败用例都会附带以下定位信息失败类型标签属于哪一类失败模式意图理解、工具选择、参数错误、循环卡死、幻觉补全等关键轨迹摘要把轨迹中的每一步tool_call和关键决策点压缩成 3-5 行摘要不需要翻几十条事件日志失败置信度评估器对这次判定的信心分数方便研发判断这个失败是真实失败还是评估器误判可复现信息这条用例在哪个环境、用什么配置跑的能否稳定复现。这套带定位信息的报告最大的好处是研发同学处理一条失败用例的时间从半小时缩短到五分钟。评测体系只有在不消耗团队耐心的情况下才能长期跑下去并持续产出价值。6.3 CI 集成与回归预警让评测真正成为守门员评测流水线的最终形态是接入 CI/CD在每次代码合并前自动触发回归评测。但这里有一个重要经验不建议把通过率低于阈值就阻止合并作为唯一的门禁策略因为它太容易被绕过——团队赶进度的时候只要注释掉评测 job 就能合并。我的做法是双轨道主干评测和预发布评测。主干评测在 PR 阶段触发跑精简版测试集约全部用例的 30%几分钟出结果用于拦截明显回归。预发布评测在合并到主干之后触发跑全量测试集和稳定性采样结果以趋势报告形式展示如果通过率出现五个点以上的下滑自动创建缺陷单并通知相关负责人。为什么用双轨道因为 Agent 的随机性决定了单次评测的置信度天然有限。主干评测出现偶发失败时不能因为一次失败就把 PR 打回否则团队会为了过门禁而反向调整测试集反而破坏了评测的可信度。双轨道的主干做快速拦截预发布做趋势监控两者配合才能既保护代码质量又不消耗团队对评测体系的信任。6.4 评测环境与生产环境的对齐避免评测通过、上线翻车最后一块工程拼图是持续维护评测环境和生产环境的一致性。前面提到的三层环境里最重要的就是把录制回放层当作一个持续更新的活资产每次生产环境的工具接口变更都要同步刷新录制数据每次新增一个工具服务都要先在评测环境里补充对应的 mock 或录制。我吃过最大的亏是生产环境的某个查询接口悄悄改了参数格式评测环境里的 mock 还是旧格式于是评测全绿、线上全挂。后来我把环境对齐做成一个自动化巡检任务每周自动对比生产环境接口定义和评测环境 mock 定义有差异就生成变更任务给对应负责人。这个巡检实施之后评测通过但上线翻车的问题基本绝迹了。7. 我在实际踩坑中积累的五个经验教训7.1 评测集膨胀会让你失去对分数的敏感度测试集不是越全越好。我有一段时间拼命扩充用例从 300 条扩到 2000 多条结果发现通过率变得钝了——模型明显有小范围回归但总通过率只掉了零点几个点趋势完全看不出来。原因很简单新增的用例大量集中在容易的、重复的模式上稀释了少数困难用例的权重。现在的做法是控制测试集的质量上限保持 300-500 条的核心黄金集每条用例都要求至少覆盖一种独特的能力点或失败模式。这个黄金集是评测的主基线另设一个不断扩充的边缘集用于探索性评测两者分开统计。7.2 评判模型会学坏需要定期校准我还发现一个反直觉的现象评判模型本身也是一个 LLM它也在被各种因素持续影响。API 供应商更新了底层模型、prompt 格式微调都会改变它对同样轨迹的评分分布。这意味着你的评测基准本身不是静态的。应对方法是定期做裁判一致性校准。具体做法是每月抽一批历史轨迹用当前配置的评判模型重新打分和一个月前的分数做纵向对比。如果同一条轨迹的分数出现系统性漂移就要排查到底是评判模型升级导致的还是 Agent 真实退化了。把这两者区分开是评测体系长期可信运行的必要条件。7.3 太快的评估器会带来虚假的安全感规则评估器虽然快但有它的盲区。一个让我记忆深刻的案例是一个 Agent 在查询订单任务里规则判定调用了正确工具、返回了订单状态所以通过。但实际上它把订单号参数传成了硬编码的测试值根本没处理用户传入的真实订单号。规则评估器被形式正确但语义错误骗过去了。从那以后我给规则评估器加了一层参数语义校验所有工具调用的关键参数必须对照用户输入中的实体去做一致性校验而不能只检查参数格式。这个教训让我明白任何自动评估器都要假设它可能被骗。评测体系需要定期用人工抽检来发现评估器的盲区然后用更严格的规则去堵住漏洞。7.4 失败类型的标签体系要持续迭代评测体系刚上线的时候我定了 8 种失败类型标签。用了三个月之后发现完全不够用——陆续新增了多轮状态丢失、上下文污染、工具结果解析错误好几种之前完全没预料到的失败模式。标签体系如果僵化评测报告对研发的指导价值就会快速下降。我的建议是标签体系不是一次设计完的它应该和业务一起进化。每两周过一次失败用例看有没有新的共性问题出现有就新增标签同时合并那些实际上属于同一原因但被拆得过细的标签保持标签体系的信息密度而不是数量。7.5 没有人维护的评测体系就是数字游戏这是我最想强调的一点。评测体系的代码写出来很容易真正难的是持续维护。用例要更新、环境要对齐、评判模型要校准、标签要迭代这些都是持续的运营成本。我的经验是评测体系必须有一个明确的负责人并且把这个体系的健康度当成一个可观测的系统来运维而不是写完就完了。我现在的团队里就有人专职负责评测基建每周输出一份评测体系健康度周报包含用例变更、环境对齐情况、裁判一致性、失败标签分布等。这套体系到今天还能稳定运转最关键的因素不是技术选型而是有人持续在为它的可信度负责。最后再分享一个小技巧。如果你身边有人刚开始做 Agent 评测我会建议不要急着搭复杂的大规模流水线而是先用 50 条高质量用例搭一个最小的规则评估器 人工复核闭环把通过率基线跑出来。基线有了之后不管是加模型评估器、接 CI 门禁还是建仪表盘每一步都可以量化地验证这一步到底有没有让评测体系变得更好。评测这项工程最怕的不是慢而是走着走着忘了自己到底在守什么。
