如何为AI Agent构建高质量测试集

最有价值的成果不是 Agent 本身，而是你用来评估它的测试集。它是衡量每个版本的基准真相，经得起模型更换、框架变化和代码重写。

从十个真实案例开始，每个案例都附带一个判定标准来说明"好"是什么样的，然后用每次发现的失败来扩充测试集。

为什么测试集是核心资产

评估的质量取决于它运行的案例质量。测试集是场景的集合——每个场景由输入和对应的"好响应"定义组成——它代表了 Agent 必须处理的各种情况。它是衡量 Agent 每个版本的基准真相，也是唯一能经受模型变化、框架变化和重写的资产。把测试集做好，它会在未来的每一个决策中持续产生回报。

模型会变，框架会变，测试集却历久弥新。

好的测试集包含什么

代表性案例 —— Agent 实际面对的常见情况，这样评分才能反映真实性能。

边界案例 —— 那些罕见、棘手和对抗性的输入，正是 Agent 容易出问题的地方，因为这些才是生产环境中会暴露的情况。

已知失败 —— 每一个发现的 Bug 都转为案例记录，确保它永远不会静默回归。

每个案例的判定 —— 一个预期答案、一份检查清单或一套评分标准。没有判定的案例无法评估任何东西。

测试用例从哪里来

最好的测试用例来自真实场景。真实用户交互 —— 尤其那些出错的交互 —— 是宝贵的资源，因为它们代表真实发生的情况。每个生产环境的事故都应该成为一个测试用例。你可以用模型或团队生成的合成案例来补充覆盖尚未遇到的情况，但强大的测试集的核心始终来自真实使用数据，经过时间沉淀积累而成。

案例是输入加上判定

要精确界定单个案例的构成：Agent 将收到的输入，以及判断响应是否良好的方式。判定可以有不同的形式 —— 精确的预期答案、响应必须满足的条件、由评判者应用的评分标准，或用于对比的参考答案。为每个案例编写判定这一规范化过程，才是真正把一堆示例变成可用的测试集的关键。

{
  "input": "I was charged twice, I want a refund",
  "expects": {
    "task_success": "acknowledges double charge, checks policy",
    "tool": "issue_refund only if within policy",
    "faithfulness": "cites the refund policy",
  },
}

小起步，稳步扩充

常见的错误是等到建立一个庞大的测试集才开始评估。先用十个涵盖核心问题的案例，然后随着你发现 Agent 的不足之处来扩充。一十个经过精心筛选、覆盖真实风险的场景，胜过一千个泛泛的通用案例。测试集是会随着每个 Bug 发现和每个新情况出现而不断增长的活资产。

我如何为 AI Agent 构建测试集？

收集场景 —— 输入加上判定标准来说明什么是好的响应。包含代表性案例、边界案例和每个已知失败。从真实使用中提取数据，为每个案例编写判定，用大约十个案例开始，而不是等一个庞大的集合。

我需要多少测试用例？

先从大约十个涵盖核心问题的精选案例开始，然后在发现失败时逐步扩充。二十个覆盖真实风险的场景胜过一千个通用案例。测试集注定要随着时间增长，而不是在第一天就追求完备。

好的测试用例从哪里来？

来自真实场景 —— 真实用户交互，尤其是那些出错的交互。每个生产环境的事故都应该成为一个案例。合成案例可以补充覆盖，但核心始终来自实际使用。

什么让一个测试用例完整？

输入加上判定：一种判断响应是否良好的方式。判定可以是精确答案、条件检查清单或评分标准。没有判定，一个案例可以训练 Agent 但无法评估它。

为什么测试集如此重要？

它是每个版本的 Agent 都被衡量的基准真相，而且它比模型、框架和重写更长寿。它是你任务中"好"的累积定义 —— 这个资产让未来的每一次变更都更安全。