刚开始做 Agent 评测时，以为数据集就是：根据 PRD 整理测试场景，再让 AI 批量生成一批 Query。

真正跑起来后，发现 Query 多不等于数据集好。预期没有确认、来源无法追溯、边界问题混进黄金集，最后即使算出一个通过率，也解释不了这个数字到底代表什么。

后来重新梳理了整个过程。一个 Agent 项目开始时，第一件事不是造数据，而是：

系统到底在做什么决策？
什么结果才算正确？
从哪里能稳定观察到这个结果？

这三个问题没有说清楚，生成再多 Query，也只是在批量制造无法判定的数据。

后来我把数据集设计抽象成了四层：

定义决策 → 建立契约 → 设计覆盖 → 持续回流

定义决策，是先弄清系统根据什么输入做什么判断，以及成功标准在哪里。意图识别、RAG、工具调用和状态修改的决策结构不同，数据不能套用同一个模板。

建立契约，是让每条 Case 同时包含输入、上下文、预期、判定方式、来源和风险。只有 Query 的文件是测试语料，不是完整的评测数据集。

设计覆盖，是不穷举自然语言，而是识别影响结果的业务对象、系统行为和高风险语境，用等价类选取代表样本。

持续回流，是把执行中确认的 Bad Case 沉淀为失败模式，加入回归集，并反过来更新原来的覆盖模型。

后面的七个步骤，都是这四层在真实项目中的具体落法。

第一步：先定义任务，再设计数据

不同 Agent 任务，数据集结构并不一样。

意图识别属于封闭集分类：

Query → intent

数据集重点是意图全集、正例、负例和意图之间的易混淆边界。每条数据通常包含用户输入和预期意图。

动作微调属于执行型任务：

原始状态 + Query → 新状态

这时只有 Query 就不够了，还要保存原始业务状态，并定义允许发生什么变化、哪些内容不能变化、最终结果要满足什么约束。

例如用户要求：

把动作 A 从 4 组改成 3 组，其他内容不变。

这条数据的预期不只是“识别为调整容量”，而是：动作 A 的组数从4变成3，其他动作和未指定参数保持不变，修改后的结果仍然合法可用。

所以，数据集设计必须从任务的决策结构开始。不能先让 AI 生成句子，再回头猜这些句子应该怎么判。

第二步：一条数据不是一个 Query，是一份评测契约

其实每条正式评测数据至少包含这些语义：

case_id     长期稳定的唯一标识
input       用户输入和必要上下文
expected    明确可判定的预期结果
assertion   自动断言或人工评分规则
tags        所属数据层和风险类型
source      PRD、线上数据、用户反馈或历史 Bug
risk        失败后的业务影响

格式可以是 JSON、JSONL 或 CSV，字段名也可以根据项目调整，但这些信息不能缺。

其中容易被忽略的是 source 和 assertion。

没有来源，后面就不知道这条数据为什么存在，也不知道规则变化后该找谁确认；没有断言，执行完只能靠人重新理解输入、翻响应、临时判断。

如果 expected 还存在争议，或者没有稳定观测方式，我不会把它混进正式通过率，而是标记为 Observation。它可以用于探索，但不能伪装成一条已经可判定的 Golden Case。

第三步：真实数据优先，AI 负责扩展

数据来源决定了评测结果离真实用户有多远。我目前使用的优先级是：

线上真实 Query
→ 用户反馈
→ 历史 Bug / Bad Case
→ PRD 和业务规则
→ 领域专家构造
→ AI 批量扩写

项目上线前拿不到真实流量，可以从需求、真实反馈和领域风险开始。但上线以后，应该持续用脱敏后的真实数据替换早期构造数据。

AI 更适合做的是表达扩展。例如围绕一个已经确认的意图或风险，补充：

• 口语化表达；
• 否定和反问；
• 指代与省略；
• 冗长、夹杂情绪的说法；
• 同一意图的专业和非专业表达。

但 AI 不应该替人决定哪些场景重要、业务正确答案是什么，也不能把自己生成的 expected 直接写进黄金集。

我的分工是：

人提供业务事实、风险和预期，AI 扩展表达，人最后判断这条数据能不能进入正式评测集。

第四步：用覆盖矩阵控制数量

自然语言输入空间无限，Case 永远写不完。解决办法不是继续堆数据，而是找到影响系统决策的等价类。

在最近项目中，用过一个二维覆盖矩阵：

数据结构等价类 × 操作类型等价类

可以理解为：

普通课程 / AI课程 / 单动作课程 / 特殊课程
×
参数调整 / 新增 / 删除 / 替换 / 时间压缩 / 安全避让

每个高风险格子先选1～2个代表样本，而不是围绕每个具体动作复制一批相似 Case。

如果同一个格子中的样本表现明显不同，例如单动作课程和多动作课程在删除操作上的失败模式不同，就说明原来的等价类太粗，需要拆分。没有证据时，不提前制造大量组合。

这样，“到底需要写多少条”就变成了一个更有用的问题：

影响系统决策的核心风险格子，是否都有代表样本？

第五步：数据分层不是分成五份文件

把数据看成五种视图：

数据视图	作用	进入条件
Golden	核心能力和绝对不能退化的路径	expected 已确认，断言稳定
Iteration	本次需求改变的规则和边界	能追溯到具体需求
Risk	安全、异常和高风险场景	有明确失败影响
Regression	历史 Bug 和容易复发的旧能力	有历史结果或缺陷来源
Observation	暂时无法稳定判分的探索场景	不进入正式通过率

它们是标签，不一定是五份物理文件。

一条来自历史高风险 Bug 的核心 Case，可以同时属于：

Golden + Risk + Regression

用标签维护比复制多份数据更稳。否则同一条 Case 修改后，很容易出现几个数据集版本不一致。

第六步：Fixture、Case、Output、Report 分开

执行型 Agent 经常需要复杂的原始业务状态。如果把原始数据、用户输入、expected 和运行结果全部塞进一个文件，数据集很快就会失控。

我在项目里采用了四层结构：

datasets/
├── fixtures/   # 脱敏后的原始业务状态
├── cases/      # Query、expected、断言和标签
├── outputs/    # 每次执行的原始响应
└── reports/    # 聚合后的正式结论

Case 通过稳定 ID 引用 Fixture；Output 记录运行时间、环境、版本和 Case ID；Report 再从原始结果中生成。

这样才能回答：这个结论来自哪条 Case、使用了什么输入状态、在哪个版本执行，以及原始响应是什么。

第七步：数据集要从 Bad Case 中持续生长

数据集不是项目开始时造完一次，以后只负责重复运行。

更实际的循环是：

小批量试跑
→ 发现 Bad Case
→ 判断是规则、数据、断言、模型还是环境问题
→ 确认真实缺陷
→ 回流 Regression
→ 更新风险标签或覆盖矩阵

不是所有失败都应该进入回归集。需求本身没确认、测试数据错误、环境异常，都应该先完成归因。只有已经确认的真实失败模式，才值得沉淀成长期资产。

真实 Bug 回流时，也不应该只保存原始句子。我还会记录它属于哪个风险格子、违反了什么断言，以及同类问题需要怎样扩展。这样修复的不是一句话，而是一类失败模式。

抽象成一套可迁移的方法

回头看，意图识别和动作微调虽然数据结构不同，但设计过程可以复用：

Evaluation Dataset
= Decision Model
+ Evaluation Contract
+ Coverage Model
+ Feedback Loop

对应到实际工作就是：

Decision Model      系统到底在做什么决策
Evaluation Contract 每条 Case 如何定义正确并留下证据
Coverage Model      哪些风险维度需要代表样本
Feedback Loop       真实失败如何回流并扩展覆盖

它同样可以迁移到其他 Agent：

场景	决策模型	主要覆盖维度
意图识别	Query → 意图类别	意图类别 × 易混淆边界 × 表达方式
RAG	Query + 知识 → 有依据的回答	问题类型 × 知识状态 × 引用风险
工具 Agent	目标 + 上下文 → 工具调用与结果	任务类型 × 工具状态 × 异常路径
状态修改 Agent	原始状态 + 指令 → 新状态	数据结构 × 操作类型 × 业务约束

迁移时不需要照搬具体字段和 Case，只需要重新回答四层模型中的问题。

新项目启动八问

新 Agent 项目开始时，我会先检查：

1. 系统在做什么决策？
2. 成功、失败和需要澄清分别是什么？
3. 结果从哪里稳定观察？
4. 每条 Case 是否同时有 expected 和 grader？
5. 数据来自真实场景，还是 AI 凭空生成？
6. 覆盖了哪些业务对象、系统行为和高风险语境？
7. 无法稳定判分的数据是否隔离为 Observation？
8. Bad Case 是否回流，并更新了覆盖模型？

如果前四问回答不了，先不要批量造数据；如果后四问长期没有更新，数据集很可能只是一个静态样本文件，而不是评测资产。

最终可以把这套方法压缩成一句话：

Agent 评测数据集设计，就是先定义系统决策和成功标准，把每条数据做成可判定的评测契约，再用风险矩阵选择代表样本，最后通过真实 Bad Case 持续更新覆盖模型。

AI 可以帮助快速生成表达变体，但什么值得测、什么叫正确、什么能进入正式通过率，仍然需要人来判断。

官方依据

• OpenAI：Evaluation best practices：评测数据应覆盖典型、边界和对抗场景，并持续从真实使用数据中更新。
• Anthropic：Demystifying evals for AI agents：任务应具备明确成功标准，评测集需要代表真实任务分布，并结合适合的 grader。
• ISTQB：Certified Tester Foundation Level：等价类划分用于从输入域中选择有代表性的测试数据。