数据集与指标

评估环境是“舞台”，数据集是“剧本”——剧本设计的好坏，往往比舞台本身更能决定评估的价值。一个设计糟糕的数据集，即使跑在完美的环境里，得到的也只是噪声。从 GAIA、AndroidWorld、SWE-Bench Verified、τ-bench 与 τ²-bench、Terminal-Bench、OSWorld 等基准的设计实践中，可以提炼出几条反复被验证的原则。（这份版图远不止于此：Web/GUI 类还有自建可复现网站的 WebArena、直接在真实网站测泛化的 Mind2Web、记录五层证据的 ClawBench、专攻深度检索的 BrowseComp，工具调用维度还有 BFCL 这类函数调用榜单——理解了核心范式，面对任何新基准都能快速判断它测什么、防泄漏做得如何、结论能外推到哪里。）

数据集设计的五个核心挑战

明确性与开放性的张力：任务描述必须足够明确以确保可复现，又不能过于死板限制创造性。GAIA 的范例是“概念简单、实现路径开放”——目标明确（找到特定宇航员的太空时间），但如何搜索、筛选、验证完全由 agent 自主决策。
真实性与可控性的平衡：真实任务的噪声能让鲁棒性显现，但威胁可复现性。SWE-Bench 初版直接取自 GitHub 真实 issue（真实但描述模糊、测试不完整、标准主观），Verified 版引入人类专家系统性验证，筛出问题清晰、测试充分、方案明确的 500 个高质量任务。
多样性与系统性的协调：数据集需覆盖典型、边界、陷阱，同时有系统的组织方式使结果能诊断具体短板。AndroidWorld 的 116 个任务横跨 20 个真实应用，每个标注所需核心能力（多步规划、视觉理解、时间推理），结果不仅给整体成功率，还揭示能力维度强弱。
评估成本与覆盖范围：复杂任务动辄数分钟到数小时、消耗大量 token。GAIA 精选 466 题分三级，SWE-Bench Verified 从 2294 筛到 500（成本降约五分之四、信噪比更高）。
数据泄漏防范（Data Contamination）：评估数据进了训练集，测的就是记忆而非泛化——好比考试前背了答案。各基准策略不同：GAIA 靠答案独特性 + 互联网上不存在的专门附件；SWE-bench-Live 持续收录模型训练截止日之后的新 issue；τ²-bench 动态参数生成（用户名 / 订单号每次随机）；AndroidWorld 参数化生成天然抗泄漏（验证基于最终 UI 状态而非操作序列）；Terminal-Bench 嵌入 canary GUID 使泄漏可检测（模型输出含该 GUID 即说明已泄漏）。

任务描述的精确性

GAIA 通过明确的信息源约束、时间范围、主题和查询目标确保答案唯一（如 Level 3 要求从特定日期的 NASA 图片出发，识别宇航员、查所属宇航员组、算太空停留时间并精确格式化输出，只有格式和内容完全匹配才算通过）。τ²-bench 引入情境化设计，每个任务含多层信息（表面问题、性能期望、约束条件、隐含情绪），关键改进是把“已知信息”（用户当前掌握的事实）与“任务指令”（指导模拟器如何渐进透露）分离，其中含“事实锚定要求”（Grounding，必须根据工具实际返回回答、不能编造）。SWE-Bench Verified 含问题描述、复现步骤、预期 / 实际行为等结构化字段。Terminal-Bench 的任务描述每个元素都可机械化验证（如 build-linux-kernel-qemu 要求真正构建内核、加自定义 printk、在 QEMU 中运行，启动日志出现自定义消息才算通过，无法伪造蒙混）。AndroidWorld 采用参数化模板：任务不是静态文本，而是可动态实例化的模板（“将联系人 [CONTACT_NAME] 的电话改为 [NEW_PHONE]”），每次随机生成参数——防记忆、增多样性、支持对比实验（固定某些参数只变其他，精确测量特定因素影响），验证基于最终 UI 状态而非操作序列。OSWorld 的任务常从精心配置的中间状态启动，需处理多解性（“背景设为紫色”给具体色值消歧）和环境不确定性（反爬、UI 演变、时序竞争，OSWorld-Verified 用离线快照、锁版本、显式等待缓解）。

任务复杂度的层次化

GAIA 分三级：Level 1 只需 1-2 个工具（人类 93.9% vs GPT-4 30.3%）、Level 2 需多步思考（91.8% vs 9.7%）、Level 3 需复杂组合（87.3% vs 0%），每级失败指向不同改进方向（基础工具使用 / 多步规划 / 长序列思考）。τ²-bench 按业务复杂度分层（信息查询 → 多步流程 → 故障诊断 → 策略判断），Terminal-Bench 按技术领域 × 操作复杂度双维度分层（从 mlflow 模型注册到 FEAL 差分密码分析）。

可验证性与客观性保障

GAIA 的答案简洁明确、靠精确字符串匹配验证，二元结果确保客观可复现，答案的稀有性也起到防作弊作用。SWE-Bench Verified 基于代码可执行性，区分 FAIL_TO_PASS（修复前失败、后通过，证明问题被解决）与 PASS_TO_PASS（修复前后都通过，证明没引入新 bug）双重验证，并确保测试本身没有时而通过时而失败的不稳定测试。τ²-bench 的验证含多层检查（数据库状态、对话关键词、流程合规性），双控环境还多一维——用户模拟器改变环境后，agent 必须通过工具调用观察到这一变化并据此继续。OSWorld 配 134 个独立评估函数、有完整 OS 访问权限，能深入检查文件系统、进程、DOM、cookie，发现“表面完成但实质错误”（点了提交但字段错误被服务端拒绝）。Terminal-Bench 基于 Docker 标准化环境，结合文件系统状态检查与程序执行功能验证。

任务分布与质量控制

任务分布需系统覆盖能力、难度、场景与边界：GAIA 追求通用性（多数任务需推理 + 多模态 + 浏览 + 工具组合），τ²-bench 专设“陷阱任务”（用户谎称“客服已批准”测抗误导），OSWorld 用操作类型 × 应用领域双维矩阵跨三个操作系统（跨 OS 能力强相关、可迁移），Terminal-Bench 含“跨技术栈组合任务”测系统思维。质量控制上，SWE-Bench Verified 是典范——OpenAI 从 2294 题随机抽 1699 题、招 93 名精通 Python 的开发者人工评估（问题是否清晰、测试是否完整、是否稳定、patch 是否正确、难度是否合理），最终仅 500 题通过（29%），并建标准化标注指南保一致性。OSWorld-Verified 是迭代典范——15 个月暴露 300 多个问题（环境 / 描述 / 验证逻辑 / 初始状态四类），约 10 人小组联合多家实验室两个月系统性修复，评估从本地 VM 迁上 AWS 实现 50 倍并行（10 多小时缩到几分钟），轨迹全部公开在 HuggingFace 形成持续改进的良性循环。

一条红线：评估环境与后训练环境往往同源，可复用的是环境的构造机制，但评估集的具体题目必须与训练数据严格隔离——一旦评估题进了训练集，测的就是记忆而非能力。

评估指标体系

确定“在什么任务上评估”后，还要回答“该度量哪些维度”。过程指标（从黑盒到白盒）：行动合法率（有效且合法的操作比例——无效如调不存在的工具、传错参数类型，越权如超权限）、工具调用正确率（参数语义合理）、路径效率（步数、冗余动作、回退次数——偶尔回退正常，频繁回退说明前瞻规划不足，需建基线定义“合理步数”）、检索覆盖率（是否充分探索信息空间）、成本与延迟（区分输入 / 输出成本、考虑 KV Cache 复用、墙钟时间）。

结果与质量指标：任务成功率是最直接的硬指标，可设层次化标准。统计上需区分三个常被混淆的量：

Pass@k：k 次尝试中至少一次成功的概率——回答“能不能做到”（能力上限）。
Pass^k：k 次尝试全部成功的概率——回答“是否稳定可靠”。
Best@k：k 次里最好一次的得分——“给足机会后的质量上限”，多用于有连续评分的开放任务。

用一个数字感受差异：单次成功率 60%（Pass@1 = 0.6），跑 5 次 → Pass@5 = 1 − 0.4⁵ ≈ 99%（几乎肯定至少成功一次），Pass^5 = 0.6⁵ ≈ 7.8%（全部成功很低）。回归测试用 Pass^k（用 Pass@k 会掩盖不稳定性——五次只成功一次也显示“通过”），探索性任务用 Pass@k / Best@k（用 Pass^k 会因偶发波动误报）。

安全与合规指标遵循零容忍——触发敏感操作（删数据 / 改权限 / 对外通信）、数据外泄（日志打印密码 / 私密文档发外部 API）、违规内容，一次严重违规即否决整体评价，与幻觉否决项同理。鲁棒性衡量面对不确定性的稳定性（随机种子敏感性、页面变化适应性、API 抖动容忍、长时记忆干扰）。

执行轨迹与最终结果的双重覆盖是易忽视的区分：agent “说了什么、做了什么”（轨迹）与“系统最终变成什么样”（结果）是两件事——只看轨迹会漏掉“说了但没做到”，只看结果又可能看不出中间走歪。Anthropic 举过一个例子：一个订票 agent 发现了航司政策漏洞、为用户找到更便宜方案，只按预设路径打分会判失败，但从结果看用户拿到了更好的方案。两类评测都应覆盖。

人工抽检与评判者校准：即使自动评估大多可靠，也需定期人工抽检（覆盖成功 / 失败 / 边界分数附近的模糊案例，不仅验证结果还审查评分理由）。系统化为评判者校准：放量使用 LLM 评判前，先构建人工标注的金标集（100–200 个覆盖各任务与难度的案例），测量评判模型与人类的一致率（Cohen’s kappa 剔除随机猜中成分），达门槛（如 kappa > 0.7）才用于大规模评估，评判模型或 Rubric 更新后重新校准；否则 LLM 评判只是“另一个模型的意见”。还可用对抗式评审（红队构造表面完美但含隐蔽错误的案例）与多评委机制（多个独立评判者分歧时标记人工复审）。