给售后助手准备测试集时，最容易写下两列：“问题”和“标准答案”。对于政策问答，这可以作为起点；对于要查订单、申请审批和执行退款的 Agent，这两列缺少了决定结果的环境。
相同的“帮我退款”，在已经批准和尚未批准的订单上，正确动作不同。数据集必须描述 Agent 面对的世界，而不只是用户说的话。
一条样本应当还原一个小世界
我们把样本分成公开输入、初始环境和隐藏判定条件。公开输入是被测系统正常可以看见的内容；环境提供工具能够查询的事实；隐藏条件只交给评分器。例如预期退款金额不能在运行前被拼到 Agent Prompt 中，否则我们测到的可能是抄答案能力。
case = {
"id": "refund-approved-001",
"family_id": "quality-return",
"split": "test",
"input": {"message": "退掉 A1042", "actor": "u-1"},
"initial": {
"order_id": "A1042", "owner": "u-1", "tenant": "shop-a",
"refundable_minor": 29900, "quality_verified": True,
"approved": True, "policy_version": "v3",
},
# oracle 只供评分器读取，不能进入模型上下文或工具返回。
"oracle": {
"refund_minor": 29900,
"max_refund_records": 1,
"forbidden_reads": ["shop-b"],
},
"tags": ["refund", "approved", "single-order"],
}
# Agent 入口只拿公开输入；环境由独立工具层持有。
public_input = case["input"]
print(public_input["message"]) # 退掉 A1042family_id 用于识别来自同一原始情景的变体；id 标识具体样本。仅仅把订单号换十遍，不能当作十种独立业务难题。案例的价值在于覆盖新的决策边界，例如质量未确认、审批过期、余额不足、重复请求。
标准答案可以是一组允许条件
问题“退货运费谁付？”可以接受“经核实属于质量问题时由商家承担”，也可以接受先解释核实条件再说明承担方。若强制逐字相同，会惩罚合理表达。
我们更适合标注必需事实“质量问题需要核实”“满足条件后商家承担”，禁止事实“所有签收十天的订单都免费退”，以及引用应当指向的政策段。对于执行任务，则记录最终状态、禁止副作用、必要审批和金额上限。
允许条件也不能无限宽松。如果只要求出现“商家承担”，模型删掉“核实后”也能通过。标注应让关键条件和结论绑定，例如用同一条事实描述“核实质量问题 → 商家承担运费”。
数据覆盖决定你能看到什么
先按业务决策画出分支，再采集数据。查询、政策解释、申请、审批、执行、恢复是不同阶段；每个阶段都有正常输入、缺失输入、矛盾输入和权限边界。低频但损失高的场景应独立形成风险集，而不是等随机抽样碰到。
业务代表集用于估计日常质量，困难集用于暴露能力边界，事故回归集用于防止旧问题复发。三者可以同时存在，但不要混成一个无法解释的总体平均分。若故意把越权案例提高到一半，最终通过率就不能称为自然流量成功率。
生产数据有真实表达，但要脱敏、处理授权和保留期限，并去重。合成数据能沿着可信种子扩展，比如改写措辞和添加干扰字段；它也可能不断生成同一种简单问法。应抽查政策一致性、可解性和难度，而不是仅看生成数量。
人工标签为什么也需要质量管理
两位标注者对“待人工核实”是否算完成有分歧，不一定是某人粗心，可能是任务目标不清。先独立标注，再记录分歧理由，修订标准，最后由仲裁给出标签。应保留原始标签与仲裁结果，避免只留一个看起来确定的最终值。
不能确定的样本可以标为不确定，或者等待更多证据。强迫每个案例二选一，会把事实缺失包装成干净数据。数据评审还应确认任务本身可完成：如果环境从未提供审批接口，却要求 Agent 获得审批后执行，失败可能是评测设计造成的。
为什么要按案例族切分
如果开发集是“查询 A1042 状态”，测试集是同一段对话只把 A1042 换成 A1043，开发过程已经见过几乎相同的结构。随机按行切分会低估这种泄漏。
应按用户、文档来源、任务模板或事故族等相关单元分组，再分开发、验证和测试。开发集用于改 Prompt；验证集用于选版本和阈值；测试集用于最终报告。长期反复查看测试集并调整系统，会让它逐渐变成开发集，需要轮换新的保留集。
时间切分也很有用：用早期政策案例开发，用后续出现的真实问题检查泛化。但此时要区分模型能力下降和政策变化，保留每条样本对应的政策版本。不能用今天的规则判昨天原本正确的回答而不作说明。
版本比文件名更重要
一次实验要绑定数据集内容摘要、被测模型标识、Prompt、工具 Schema、环境快照、评分器和运行参数。改了预期金额，即使只改一个数字，也应该产生新数据集版本。
这里的可复现是能解释输入和配置，并重新执行比较；外部模型服务可能更新，无法保证每次逐字相同。记录原始输出与评分中间证据，才有机会在裁判升级后重新评分。不要仅保存最终平均分。
配套工程把开发案例、参考条件和运行结果分开保存。随着案例增加，先检查覆盖矩阵里的空白，再决定需要更多改写还是一个全新的任务分支。数据集的规模应服务于你要做的判断。
继续阅读与配套材料
上一篇：怎样判断一个 Agent 做得好：从回答正确到任务真正完成。
下一篇：评测指标怎样计算：准确率、召回率与平均分背后的问题。
完整示例、运行方式和验证边界见评测实验指南下载。本系列的订单、政策、金额和实验数据均为教学示例。