企业官网建设流程全解析

👤 个人主页：zzz_2368
🧪 系列主题：Agent 评测｜从结果、轨迹到持续迭代
🔥 热门专栏：Agent | 小z的碎碎念 | Java后端
📚 本系列内容：评测体系、Rubric、Good Case、Bad Case、Trace 与长程 Agent

系列第 3 篇｜上一篇：如何从 0 搭建 Agent 评测体系
本文参考：《Agent 评测漫谈》、OpenAI Evals 和 Anthropic 的 Agent 评测文章。本文不声称拥有真实生产数据，示例中的任务和字段是用于说明流程的抽象示例。

一、为什么平均分不够用

一个 Agent 的总体通过率是 90%，听起来不错，但这个数字可能掩盖了三种完全不同的情况：

1. 低风险任务稳定通过，高风险任务偶尔越权；
2. 所有任务都小幅波动，没有明显短板；
3. 常见任务表现很好，但少数关键客户任务全部失败。

因此，评测结果不能只保存一个总分。至少还要保留任务类型、失败原因、风险等级、执行版本和相关 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. 失败归因

建议至少设置以下分类：

最后一类很重要。若大量评测员无法判断，问题可能不在 Agent，而在评测集设计。

6. 回归与发布门禁

模型、Prompt、Tool、Skill 或编排逻辑变更后，重新执行历史样本。对高风险任务，可以把“任何越权失败”设为阻断条件；对低风险语言风格，可以设置观察阈值。门禁应该和风险等级绑定，而不是所有指标都采用同一阈值。

五、评测集也会老化

评测集不是永久真理，至少有四类老化风险：

• 样本被反复优化，Agent 只学会了固定套路；
• 用户分布变化，旧样本不再代表真实流量；
• 工具和业务规则变化，旧成功标准失效；
• 评测样本过于简单，无法发现长尾失败。

所以应保留训练集、回归集和探索集的边界，定期检查样本覆盖面。对于尚未稳定的业务，不要只追求历史回归分数上涨，还要保留一部分新任务用于发现未知问题。

六、结论

数据飞轮的核心不是“收集更多案例”，而是把案例转成可执行、可复现、可归因的评测资产：

线上现象 → 结构化 Case → 成功标准 → 评分 → 根因 → 修复 → 回归。

OpenAI Evals 提供了面向 LLM 和 LLM 系统的评测框架思路，但具体数据字段和门禁标准仍要由业务场景决定。真正成熟的体系，应该能让一次线上失败减少下一次同类失败的概率。

下一篇将进一步讨论：如果没有完整 Trace，为什么很多归因只能停留在猜测。

一个 Bad Case 如何进入回归

本地 Demo 使用 order-query-empty-result 作为模拟 Bad Case：

运行本地 Demo可以得到这组结果。重点不是版本号或成功率，而是把“工具返回空结果后 Agent 没有处理”从一次现象变成可重复的回归样本。

七、回归资产的发布门禁

一个新 Case 是否进入正式回归集，可以用以下门禁判断：

1. 输入上下文已经脱敏且可重放；
2. 预期行为和最终状态已经定义；
3. 至少有一个确定性 Grader；
4. 失败归因不是空值；
5. 该 Case 能说明一个真实风险或能力边界。

修复后的版本不能只在新增 Case 上通过，还应重新运行历史回归集，并检查是否引入新的工具调用、成本或安全问题。若业务规则发生变化，应给样本标记版本，不要静默修改旧标准。

数据飞轮的成功标准不是“Case 数量越来越多”，而是失败能够被复现、修复能够被验证、历史问题能够被持续拦截。

参考资料

1. 《Agent 评测漫谈》
2. Anthropic：Demystifying evals for AI agents
3. OpenAI Evals GitHub 仓库

感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！