---
name: eval-dataset-design
description: 设计 Agent 评估数据集或单条评估任务时使用——解剖评估任务的四个组成部分、设计验证器与验收标准（含防敷衍性修复）、划分任务难度与陷阱任务、防范训练/评估数据泄漏（参数化实例、canary）、建设评估集的质量控制与长期维护、选择公开基准/自建业务集/生产轨迹回流三个来源。覆盖 τ²-bench、SWE-bench、AndroidWorld、OSWorld、Terminal-Bench、GAIA 的可迁移设计手法。
---

# 评估数据集设计

## 何时使用
- 从零设计评估集，或评审现有任务定义是否站得住
- 为 Agent 编写单条评估任务：工单、用户模拟规范、初始状态、验收标准
- 设计验证器：该断言终态、断言动作，还是检查必须告知用户的信息
- 评估任务被模型"猜答案"蒙过，需要提高信噪比
- 怀疑评估集已被污染/泄漏进训练数据，需要防泄漏与检测手段
- 决定自建评估集的任务从哪来：公开基准、业务集、还是生产失败回流
- 评估集上线后需要长期维护：修补环境、描述、验证逻辑与初始状态问题

## 核心原则
- **一条评估任务 = 四个部分**：给 Agent 的工单、给模拟器的行为规范、两侧状态的初始重置、成功判定标准。缺任何一部分，任务都无法重复运行。
- **把用户的认知边界建模为独立字段，而非靠提示词约束。** 用户不知晓的信息 Agent 无从推测，只能通过提问与引导获得——渐进式信息透露不是一句"不要一次说完"，而是 `known_info` 与 `task_instructions` 的拆分。
- **没有事实锚定的用户模拟器会让评估退化为两个模型相互确认。** 模拟用户关于环境状态的任何回答都必须以工具返回为依据，不许编造工具结果；否则 Agent 稍加引导，用户就确认"问题已解决"。
- **验证器必须核实机器可独立复核的事实，不能采信 Agent 的自我陈述。** Agent 很容易写一篇"任务已全部完成"的报告而实际什么都没做。
- **训练集与评估集严格隔离。** 答案不可从互联网直接检索、任务实例参数化生成、嵌入 canary 使泄漏可检测——三招至少用一招。
- **验收口径要有可核实的边界，防"敷衍性修复"。** "网络已恢复"不可核实；"测速评级 excellent 才算解决，poor/fair/good 均不接受"才堵得住压制症状、不除根因的糊弄。
- **高质量的评估集是修出来的，不是写出来的。** 主流基准的现行形态都是初版暴露问题后逐轮修补的结果；发布前人工淘汰、发布后持续修两类问题都要预算。
- **每道题亲手做一遍。** 做完问两个问题：描述是否有多种合理解释，验证器认可哪一种？蒙混过关的最低成本路径是什么，验证器拦得住吗？
- **难度分层让评估集不过时**，且每层失败指向不同改进方向：基础层失败指向工具使用，中间层指向多步规划，最高层指向长序列思考。

## 实践模式

### 1. 任务解剖：四件套字段清单
以 τ²-bench telecom 一条真实任务为范本，逐项对照自建任务：
- **ticket（给 Agent 的工单）**：只含用户会主动说出的部分。真实用户的初始表述往往只是"我上不了网"，把需求澄清到可执行的程度本身就是 Agent 必须具备的能力。
- **user_scenario（给模拟器的行为规范）**：`known_info` 界定用户知悉范围（姓名、号码、所在国），故障原因不在其中；`task_instructions` 规定透露方式，并包含三类约束——情绪设定（首次修复失败后表现不满）、验收口径（仅 excellent 算解决）、事实锚定（设备状态回答必须基于工具结果）。
- **initial_state（初始重置）**：`initialization_actions` 把两侧状态重置到同一起点，包括用户侧（飞行模式、漫游开关）与 Agent 侧（运营商侧配置）。
- **evaluation_criteria（成功判定）**：四个可检查维度按需组合，外加聚合规则。

### 2. 四维校验与聚合规则
- `env_assertions` 验**终态**：移动数据可用、测速达 200 Mbps 且评级 excellent。
- `actions` 验**关键动作是否发生**（哪些工具被哪一侧调用）。
- `communicate_info` / `nl_assertions` 验**必要信息是否已告知用户**——别只查环境状态。
- `reward_basis` 是聚合规则。二元奖励（只看终态）以过程颗粒度换取跨模型可比的单一数字：满分轨迹里违反"一次只做一个工具调用"的政策也不会被捕获。生产评估系统需要更多：不仅判对错，还要指出问题出在哪。

### 3. 验证器设计的三种模式
- **双命题验证**（SWE-bench Verified）：FAIL_TO_PASS（修复前失败、修复后通过，证明问题确已解决）+ PASS_TO_PASS（修复前后均通过，证明未引入新缺陷）。只验前者，Agent 可以删改妨碍通过的断言蒙混；只验后者等于未检验。另需排除自身不稳定的 flaky test。
- **深状态核查**（OSWorld 式）：134 个独立评估函数，拥有完整系统访问权限，查文件系统结构、进程状态、网络连接与应用内部状态；数据库任务连库核实 SQL 是否真执行，浏览器任务分析 DOM、cookie 与 localStorage 并向后端发验证请求——能抓住"表面完成、实质错误"。
- **不可伪造执行**（Terminal-Bench 式）：成功标准是真实构建并运行（如从源码构建内核并在 QEMU 启动日志出现自定义 printk），Agent 无法伪造输出，只能真做完全流程。

### 4. 难度划分与陷阱任务
- 分层标注并用于诊断：GAIA 466 题分三级——Level 1 只需一至两个工具（人类 93.9%，早期模型 30.3%），Level 2 多步思考，Level 3 复杂组合。Level 1 失败指向基础工具使用，Level 2 指向多步规划与信息整合，Level 3 指向长序列思考与复杂性管理，改进方向各不相同。
- **陷阱任务**检验压力与误导下的判断力：用户声称"客服已批准取消"，实际并不符合政策，看 Agent 是否维持正确判断。
- 任务集覆盖从易到难的全谱，模型能力提升时评估集不会快速过时。

### 5. 数据泄漏防范
- **组合多源 + 专有附件 + 精确匹配**（GAIA 式）：答案必须组合多个信息源才能得出，单一网页无法直接给出；部分任务配互联网上不存在的 PDF/音频/图片附件；用精确字符串匹配判定。
- **参数化模板实例化**（AndroidWorld 式）：任务是"将联系人 X 的电话改为 Y"这类模板，每次评估随机生成参数。三收益：回放固定操作序列失效；单模板可生成近乎无限实例；固定部分参数、只改其余，可精确测量特定因素的影响。
- **金丝雀标识符**（Terminal-Bench 式）：题面嵌入 canary GUID，模型能输出含该 GUID 的内容即说明基准已进训练集。它不阻止泄漏，但使泄漏可被检测。

### 6. 质量控制与长期维护
- **发布前人工淘汰**：SWE-bench Verified 从 2294 个原始任务抽 1699 个，93 名精通 Python 的开发者逐条检查（描述是否清晰、测试是否覆盖边界、是否稳定、参考 patch 是否引入新错误、难度是否合理），仅 500 个通过——淘汰 71% 换来更高信噪比，评估成本下降约 80%。复杂 Agent 任务动辄数分钟至数小时，前沿模型跑完一个评估集往往需要数千美元 token，控本就是控迭代速度。
- **发布后持续修补**：OSWorld 发布 15 个月暴露出 300 余个问题，分四类——环境问题（反爬、CAPTCHA、动态内容，靠锁定版本与离线备份）、任务描述歧义（改写消除）、验证逻辑过严或过松（人工建立正确基线再调条件）、初始状态不完整（增加完整性校验）。修补方式可整体借鉴。
- **从初版到成熟版的五处典型重设计**（τ-bench → τ²-bench）：任务指令过于笼统导致可猜 → 拆分 known_info/task_instructions；成功条件不精确 → 改为可核实边界；模拟用户过于机械 → 补情绪、耐心上限与事实锚定；只有 Agent 能改变环境 → 引入用户侧工具的双控机制；静态任务 → 参数化批量生成实例（同时改善覆盖率与抗泄漏）。

### 7. 评估集的三个来源与演进
- **公开基准**：用于粗筛模型与借鉴设计手法（验证深度、参数化生成、防泄漏、质量维护），一般不用于产品决策——其任务分布与业务分布不一致。
- **自建业务集**：覆盖真实任务分布，作为模型选型与 Harness 设计决策的依据。可拿成熟基准当骨架，替换领域数据与工具集。
- **生产轨迹回流**：用户明确纠正、点踩、事后规则/LLM 审计发现的失败案例，经失败归因后沉淀为回归用例。成本最高、准确性最高，直接来自用户实际遇到的问题。
- 演进节奏：起步只有公开基准 + 少量手写业务集；上线运行一段时间后，回流用例成为主体。今天线上暴露的失败模式，明天就是守住底线的回归用例。

## 常见陷阱
- 任务指令写得宽泛，模型无需澄清需求、凭常识猜一套流程也能通过。
- 成功条件是"网络已恢复"这类无边界描述，被压制症状的敷衍性修复蒙过。
- 只验 FAIL_TO_PASS 不验 PASS_TO_PASS，Agent 靠删断言作弊；或不排除 flaky test，结果不可复现。
- 用户模拟器没有事实锚定，评估退化为 Agent 与模拟用户相互确认；没有耐心上限，沟通效率低下不被计失败。
- 静态题面被模型记忆，且无 canary，泄漏发生了都不知道。
- 验证器过严（把正确答案判失败）或过松（放走表面完成实质错误）；初始状态配置不完整，每次运行起点不同。
- `reward_basis` 只看终态，过程违规（策略违背、信息未告知）不被捕获，且不另建过程检查。
- 任务描述存在多种合理解释而验证器只认一种，开发者与人肉执行者的判断不一致。
- 评估集建成后不再维护，上线后仍是手写那几十条，与真实用户分布脱节。

## 配套代码
- `chapter7/tau2-bench-eval/` — τ²-bench telecom 任务定义四部分（ticket / user_scenario / initial_state / evaluation_criteria）的完整解剖与双控环境运行记录
- `chapter7/public-health-reporting-eval/` — 五个确定性任务的六点结构化评分示范验证器设计：工具选择、参数、答案（含数值容差）、证据行精确集合、无依据声明处罚
- `chapter7/android-world/` — T3A 失败轨迹与归因笔记，演示参数化任务实例、验证器终态判定，以及从失败轨迹回流生成轨迹前缀回归任务

## 深度阅读
- `book/chapter7.md`「一条评估任务的解剖：τ²-bench 的 telecom 领域」
- `book/chapter7.md`「评估数据集的设计」