如何搭建 Agent 评测体系，并让评测结果推动优化迭代？

核心回答

Agent 评测体系要形成一条可重复的迭代链路：先定义任务验收标准，建设代表性样本和评分器，再批量运行、分析失败原因，验证针对性改动，最后把线上新问题回收到回归集。 评测的产物既要有质量、稳定性和成本指标，也要能回答下一轮该改哪里。

评测对象分三层：最终答案或外部状态是否正确，工具选择、参数及关键步骤是否合理，遇到超时、信息缺失等情况能否恢复。能用规则、测试或状态检查判定的，优先自动验证；开放式语义质量再使用有明确评分标准的模型裁判，并用人工标注校准。

优化时，把失败样本关联到完整执行记录，区分模型判断、上下文、工具、编排和评测环境的问题。每次验证一个明确假设，在相同数据与预算下比较新旧版本，同时检查旧能力是否退化。上线后再结合真实反馈和分层采样发现新场景，逐步更新测试集和验收规则，使评测持续影响开发决策。

先把任务和成功条件定义清楚

一条用例应包含输入、初始环境、成功标准和允许的执行边界。例如问数 Agent 回答“上月销售额”，不仅要有一句通顺的回答，还要使用约定的销售额口径、时间范围和权限内的数据，并给出与查询结果一致的数值。

对于会修改状态的 Agent，还要验证最终状态：建单是否真的成功、金额和对象是否正确、是否发生重复操作。最后回复“已完成”，只是执行记录中的一段文本，不能代替环境验收。

过程评测只约束必要动作与条件。例如查询受限数据前要完成权限检查，但不要求每次使用完全相同的搜索、思考和工具调用顺序。合法路径可能有多条，固定唯一轨迹容易把正确方案误判为失败。若任务只完成一部分，可以记录进度帮助诊断，同时把完整任务是否成功单独统计。

建设能够持续维护的样本集

样本可以来自已经使用的人工验收任务、脱敏后的历史请求、用户反馈和已确认的失败案例。缺少日志时，从典型业务流程构造样本，再补充信息缺失、上下文冲突、工具超时、空结果和权限变化等变体。模型生成的题目和参考答案适合扩展候选集，仍需审核任务是否可解、答案依据是否正确。

样本按业务类型、难度、工具和异常条件分组。高频场景帮助估计常态表现，低频但影响大的错误单独观察；只挑投诉样本，会偏离真实流量，只有正常输入又发现不了边界问题。整体业务指标与困难样本集的表现可以分别报告，不把人为增加的难例比例当作线上失败率。

数据用途也要分开：开发集用于定位和选择方案，回归集保护已经稳定的能力，留出集检验尚未参与调参的新任务。反复根据同一批题目修改 Prompt 后，这批题已成为开发依据，需要保留新的独立验收样本。来自同一用户会话或同一业务案例的近似题，还应避免跨集合泄漏。

维护时保存样本、参考规则和数据版本。业务政策或参考答案发生变化后，应让新旧方案按同一套更新后的规则重新评分，再比较系统差异。

评分器怎样组合

确定性检查负责可明确判断的条件。 包括 JSON Schema、工具参数、权限范围、计算结果、数据库状态或独立测试。评分器也要有正反例验证：正确结果应通过，缺少关键条件的结果应失败；任务说明与断言需要一致，避免用隐藏要求惩罚 Agent。

模型裁判负责开放式语义。 把“正确、完整、有依据”拆成具体标准，给裁判用户问题、必要证据、参考要点和评分示例，并要求返回判定依据。无法确定时允许标记待复核，不强行打分。抽取一批任务让业务人员标注，再分析裁判的误判与分歧；换裁判模型或评分 Prompt 后，也需要重新校准。

人工复核处理争议和校准。 重点检查高影响失败、自动评分分歧及抽样结果，而不必逐条重复机器已经能够稳定完成的判断。用人工判断改进任务描述或评分器后，应记录变化，防止评分口径漂移被误当成 Agent 进步。

指标围绕这些检查产生：端到端成功率、各场景成功率、工具和参数错误、异常恢复、越权或误操作，以及延迟、token、工具费用和人工介入。明确每项的分母、超时与重试口径，首次成功和允许重试后的成功分开；总平均值之外还要看重要场景和长尾。

让执行结果可比较、可追查

评测运行器负责加载任务、初始化环境、调用 Agent、保存记录、执行评分并汇总结果。每次运行关联样本与数据集版本、代码版本、模型实际标识、Prompt 和工具定义版本、运行预算、执行记录及评分结果，便于把分数追到具体行为。

每次试验尽量从相同且干净的初始状态开始，隔离文件、会话、缓存及测试数据，避免上一次运行留下答案或修改后的状态。允许使用缓存时，也要明确哪些缓存属于真实使用条件。工具限流、环境启动失败或评分器报错需要单独标记，不能悄悄丢弃后只汇总成功运行；同时报告有效评测覆盖情况与系统交付表现。

模型有随机性，重要任务可重复运行，观察稳定性。次数和样本规模取决于风险、波动和希望识别的变化，不存在所有场景统一的次数。比较新旧版本时，应尽量使用同一批任务、相同预算和可比环境，并考虑样本量与波动，避免把一次偶然成功当成改进。

从失败分组到下一轮优化

先阅读失败任务的输入、上下文、工具调用与结果，再归类原因。常见情况包括：目标或指标口径理解错误、必要资料未进入上下文、工具选错、参数构造错误、工具自身故障、恢复或停止逻辑有问题，以及参考答案或评分器不合理。

为每类问题保留代表样本，按出现频次、影响和修复成本安排优先级。一个失败可能有多个现象，可以记录主要原因与伴随问题，避免把它重复累计成多个独立失败。

以问数 Agent 为例：如果它把“支付时间”误用成“订单创建时间”，先核对指标定义是否给清楚、相关字段说明是否进入上下文、SQL 工具返回是否被正确理解。若证据表明缺少时间口径，就补充指标定义或工具描述，再验证同义问法、跨月边界、退款与信息不足场景；不是看到数值错就直接换更强模型。

候选改动先跑目标失败集，确认假设是否成立，再跑旧回归集与留出集。记录修复了哪些问题、是否引入新失败，以及额外延迟和成本。效果达到目标且关键能力没有不可接受的退化后，再通过适合业务的灰度或对照观察验证真实流量；明确观察指标和恢复条件，避免只看离线总分。

线上出现新问题后，先确认业务事实与失败原因，再把可重现的案例加入样本集，附上预期行为和检查方法。修复代码或 Prompt 是一次改动，留下能防止同类问题再次出现的用例，才使这次改动进入持续迭代。

怎样控制评测成本

不必每次都完整运行所有长任务。开发早期先做低成本的格式、参数和关键步骤检查，对受影响模块跑针对性用例；候选方案收敛后，再扩大到端到端回归与重要场景的重复试验。Mock 工具或固定回放可以减少外部波动，但只能验证相应层次，仍需保留与实际工具协议一致的集成检查。

模型裁判优先覆盖规则难以处理的语义问题，线上则按场景风险、流量和预算分层采样。复用已有输出重新评分可以节省调用，但只适合验证评分规则变化；Agent、模型或上下文变了，仍需重新运行相应任务。评测预算包含 Agent 调用、裁判调用、工具执行和人工复核，不能只计算生成端 token。

常见追问

整体成功率提高了，能直接采用新版本吗？

还要看哪些分组提高、哪些退化，是否存在样本分布或评分规则变化，以及延迟、成本和关键错误是否可接受。目标失败集提高但旧回归下降，说明改动可能只针对某类题过度适配。

分数下降，怎么判断是 Agent 变差还是评测有问题？

保留原始记录并复查任务、参考答案、评分依据和环境错误。用固定快照回归与实时依赖检查分开观察，再对比模型、Prompt、工具和数据版本。若正确结果被错误评分器拒绝，应修复评分器，并按统一口径重评各方案。

没有唯一标准答案怎么办？

把任务要求转成必须满足的事实、约束与产物标准，允许不同的正确表达或执行路径；开放式质量用明确分档与示例评判。缺少唯一文本答案，不等于缺少可验证的要求。

对应教程

参考资料