个人主页zzz_2368 系列主题Agent 评测从结果、轨迹到持续迭代 热门专栏Agent | 小z的碎碎念 | Java后端 本系列内容评测体系、Rubric、Good Case、Bad Case、Trace 与长程 Agent系列第 3 篇上一篇如何从 0 搭建 Agent 评测体系本文参考《Agent 评测漫谈》、OpenAI Evals 和 Anthropic 的 Agent 评测文章。本文不声称拥有真实生产数据示例中的任务和字段是用于说明流程的抽象示例。一、为什么平均分不够用一个 Agent 的总体通过率是 90%听起来不错但这个数字可能掩盖了三种完全不同的情况低风险任务稳定通过高风险任务偶尔越权所有任务都小幅波动没有明显短板常见任务表现很好但少数关键客户任务全部失败。因此评测结果不能只保存一个总分。至少还要保留任务类型、失败原因、风险等级、执行版本和相关 Trace才能回答“哪里变差了”。二、从线上问题到评测样本一个 Bad Case 不应只是截图或一句“效果不好”。建议整理成结构化记录case_id:support-2026-001source:production-feedbacktask:用户要求取消订单并查询退款进度input_context:已登录订单状态为配送中observed_result:Agent 只解释了退款规则没有执行查询expected_behavior:-识别查询与取消两个子任务-先确认取消操作的风险-返回真实订单状态failure_category:planningseverity:mediumregression:true这里要区分三个概念现象用户看到了什么根因假设可能是规划、工具、权限、上下文还是评测规则问题回归标准下一次怎样证明问题已经修复。如果只有现象没有成功标准样本就很难进入自动回归。三、Good Case 和 Bad Case 各自解决什么问题Bad Case 用来暴露能力边界和系统短板例如工具参数错误、循环调用、权限越界和最终状态不一致。Good Case 则用来定义“什么叫高质量完成”。它不只是用来展示 Demo也可以帮助团队明确哪些步骤是必要的哪些额外解释是有价值的哪些简化路径可以接受哪些结果虽然正确但成本过高。需要注意Good Case 不等于唯一标准答案。对于复杂任务可能存在多条满足约束的成功路径。评测更适合检查必要条件、禁止条件和最终状态而不是强制 Agent 复刻某一条轨迹。四、一个可执行的数据飞轮可以把闭环分为六个阶段采集 - 清洗与脱敏 - 标注成功标准 - 执行与评分 - 失败归因 - 回归与发布门禁 ↑ ↓ └── 新的线上 Case ──┘1. 采集来源可以包括线上 Trace、用户反馈、人工抽检、客服升级和开发测试。采集时应保留必要上下文但不能为了方便把密钥、个人信息或完整业务数据直接复制进公共评测集。2. 清洗与脱敏处理重复样本、无效输入、缺失上下文和敏感字段。脱敏不能破坏任务语义。例如订单号可以替换成稳定的占位符但订单状态关系仍要保留。3. 标注成功标准把用户的自然语言诉求转成可检查的expected_behavior、outcome和约束条件。Anthropic 的 Agent 评测说明将任务、试验、评分器、记录和结果分开描述这种拆分很适合用来设计样本字段。参考原文。4. 执行与评分确定性规则优先例如最终状态、Schema、权限和文件存在性语义质量再使用人工或 LLM Judge。不要让一个模糊的总分遮住确定性失败。5. 失败归因建议至少设置以下分类分类例子规划没有拆分依赖任务工具参数错误、没有处理错误返回上下文读取了错误或过期信息环境沙箱、网络或外部系统不可用Skill/Prompt规则缺失或表达冲突评测成功标准本身不清楚最后一类很重要。若大量评测员无法判断问题可能不在 Agent而在评测集设计。6. 回归与发布门禁模型、Prompt、Tool、Skill 或编排逻辑变更后重新执行历史样本。对高风险任务可以把“任何越权失败”设为阻断条件对低风险语言风格可以设置观察阈值。门禁应该和风险等级绑定而不是所有指标都采用同一阈值。五、评测集也会老化评测集不是永久真理至少有四类老化风险样本被反复优化Agent 只学会了固定套路用户分布变化旧样本不再代表真实流量工具和业务规则变化旧成功标准失效评测样本过于简单无法发现长尾失败。所以应保留训练集、回归集和探索集的边界定期检查样本覆盖面。对于尚未稳定的业务不要只追求历史回归分数上涨还要保留一部分新任务用于发现未知问题。六、结论数据飞轮的核心不是“收集更多案例”而是把案例转成可执行、可复现、可归因的评测资产线上现象 → 结构化 Case → 成功标准 → 评分 → 根因 → 修复 → 回归。OpenAI Evals 提供了面向 LLM 和 LLM 系统的评测框架思路但具体数据字段和门禁标准仍要由业务场景决定。真正成熟的体系应该能让一次线上失败减少下一次同类失败的概率。下一篇将进一步讨论如果没有完整 Trace为什么很多归因只能停留在猜测。一个 Bad Case 如何进入回归本地 Demo 使用 order-query-empty-result 作为模拟 Bad Case版本结果失败归因v1失败tool-error-handlingv2通过已增加工具空结果的失败分支运行本地 Demo可以得到这组结果。重点不是版本号或成功率而是把“工具返回空结果后 Agent 没有处理”从一次现象变成可重复的回归样本。七、回归资产的发布门禁一个新 Case 是否进入正式回归集可以用以下门禁判断输入上下文已经脱敏且可重放预期行为和最终状态已经定义至少有一个确定性 Grader失败归因不是空值该 Case 能说明一个真实风险或能力边界。修复后的版本不能只在新增 Case 上通过还应重新运行历史回归集并检查是否引入新的工具调用、成本或安全问题。若业务规则发生变化应给样本标记版本不要静默修改旧标准。数据飞轮的成功标准不是“Case 数量越来越多”而是失败能够被复现、修复能够被验证、历史问题能够被持续拦截。参考资料《Agent 评测漫谈》AnthropicDemystifying evals for AI agentsOpenAI Evals GitHub 仓库感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
个人主页zzz_2368 系列主题Agent 评测从结果、轨迹到持续迭代 热门专栏Agent | 小z的碎碎念 | Java后端 本系列内容评测体系、Rubric、Good Case、Bad Case、Trace 与长程 Agent系列第 3 篇上一篇如何从 0 搭建 Agent 评测体系本文参考《Agent 评测漫谈》、OpenAI Evals 和 Anthropic 的 Agent 评测文章。本文不声称拥有真实生产数据示例中的任务和字段是用于说明流程的抽象示例。一、为什么平均分不够用一个 Agent 的总体通过率是 90%听起来不错但这个数字可能掩盖了三种完全不同的情况低风险任务稳定通过高风险任务偶尔越权所有任务都小幅波动没有明显短板常见任务表现很好但少数关键客户任务全部失败。因此评测结果不能只保存一个总分。至少还要保留任务类型、失败原因、风险等级、执行版本和相关 Trace才能回答“哪里变差了”。二、从线上问题到评测样本一个 Bad Case 不应只是截图或一句“效果不好”。建议整理成结构化记录case_id:support-2026-001source:production-feedbacktask:用户要求取消订单并查询退款进度input_context:已登录订单状态为配送中observed_result:Agent 只解释了退款规则没有执行查询expected_behavior:-识别查询与取消两个子任务-先确认取消操作的风险-返回真实订单状态failure_category:planningseverity:mediumregression:true这里要区分三个概念现象用户看到了什么根因假设可能是规划、工具、权限、上下文还是评测规则问题回归标准下一次怎样证明问题已经修复。如果只有现象没有成功标准样本就很难进入自动回归。三、Good Case 和 Bad Case 各自解决什么问题Bad Case 用来暴露能力边界和系统短板例如工具参数错误、循环调用、权限越界和最终状态不一致。Good Case 则用来定义“什么叫高质量完成”。它不只是用来展示 Demo也可以帮助团队明确哪些步骤是必要的哪些额外解释是有价值的哪些简化路径可以接受哪些结果虽然正确但成本过高。需要注意Good Case 不等于唯一标准答案。对于复杂任务可能存在多条满足约束的成功路径。评测更适合检查必要条件、禁止条件和最终状态而不是强制 Agent 复刻某一条轨迹。四、一个可执行的数据飞轮可以把闭环分为六个阶段采集 - 清洗与脱敏 - 标注成功标准 - 执行与评分 - 失败归因 - 回归与发布门禁 ↑ ↓ └── 新的线上 Case ──┘1. 采集来源可以包括线上 Trace、用户反馈、人工抽检、客服升级和开发测试。采集时应保留必要上下文但不能为了方便把密钥、个人信息或完整业务数据直接复制进公共评测集。2. 清洗与脱敏处理重复样本、无效输入、缺失上下文和敏感字段。脱敏不能破坏任务语义。例如订单号可以替换成稳定的占位符但订单状态关系仍要保留。3. 标注成功标准把用户的自然语言诉求转成可检查的expected_behavior、outcome和约束条件。Anthropic 的 Agent 评测说明将任务、试验、评分器、记录和结果分开描述这种拆分很适合用来设计样本字段。参考原文。4. 执行与评分确定性规则优先例如最终状态、Schema、权限和文件存在性语义质量再使用人工或 LLM Judge。不要让一个模糊的总分遮住确定性失败。5. 失败归因建议至少设置以下分类分类例子规划没有拆分依赖任务工具参数错误、没有处理错误返回上下文读取了错误或过期信息环境沙箱、网络或外部系统不可用Skill/Prompt规则缺失或表达冲突评测成功标准本身不清楚最后一类很重要。若大量评测员无法判断问题可能不在 Agent而在评测集设计。6. 回归与发布门禁模型、Prompt、Tool、Skill 或编排逻辑变更后重新执行历史样本。对高风险任务可以把“任何越权失败”设为阻断条件对低风险语言风格可以设置观察阈值。门禁应该和风险等级绑定而不是所有指标都采用同一阈值。五、评测集也会老化评测集不是永久真理至少有四类老化风险样本被反复优化Agent 只学会了固定套路用户分布变化旧样本不再代表真实流量工具和业务规则变化旧成功标准失效评测样本过于简单无法发现长尾失败。所以应保留训练集、回归集和探索集的边界定期检查样本覆盖面。对于尚未稳定的业务不要只追求历史回归分数上涨还要保留一部分新任务用于发现未知问题。六、结论数据飞轮的核心不是“收集更多案例”而是把案例转成可执行、可复现、可归因的评测资产线上现象 → 结构化 Case → 成功标准 → 评分 → 根因 → 修复 → 回归。OpenAI Evals 提供了面向 LLM 和 LLM 系统的评测框架思路但具体数据字段和门禁标准仍要由业务场景决定。真正成熟的体系应该能让一次线上失败减少下一次同类失败的概率。下一篇将进一步讨论如果没有完整 Trace为什么很多归因只能停留在猜测。一个 Bad Case 如何进入回归本地 Demo 使用 order-query-empty-result 作为模拟 Bad Case版本结果失败归因v1失败tool-error-handlingv2通过已增加工具空结果的失败分支运行本地 Demo可以得到这组结果。重点不是版本号或成功率而是把“工具返回空结果后 Agent 没有处理”从一次现象变成可重复的回归样本。七、回归资产的发布门禁一个新 Case 是否进入正式回归集可以用以下门禁判断输入上下文已经脱敏且可重放预期行为和最终状态已经定义至少有一个确定性 Grader失败归因不是空值该 Case 能说明一个真实风险或能力边界。修复后的版本不能只在新增 Case 上通过还应重新运行历史回归集并检查是否引入新的工具调用、成本或安全问题。若业务规则发生变化应给样本标记版本不要静默修改旧标准。数据飞轮的成功标准不是“Case 数量越来越多”而是失败能够被复现、修复能够被验证、历史问题能够被持续拦截。参考资料《Agent 评测漫谈》AnthropicDemystifying evals for AI agentsOpenAI Evals GitHub 仓库感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
