基准对照与验证器设计
常用 Agent 基准的关键设计选择有何不同？
| 基准 | 被测能力 | 任务来源 | 环境扮演者 | 验证器 |
|---|---|---|---|---|
| τ²-bench | 客服场景下的人机交互与工具调用 | 人工编写 + 组合生成 | 用户模拟器 + 业务数据库 | 四层检查按 reward_basis 聚合为二元 |
| SWE-bench Verified | 软件开发（coding） | GitHub 真实 issue，人工筛选 | 代码仓库 + 测试套件 | FAIL_TO_PASS / PASS_TO_PASS 双重验证 |
| AndroidWorld | 操作 Android 手机 GUI | 参数化模板实例化 | 真实 Android 模拟器 | 最终 UI 状态断言 |
| OSWorld | 操作 Linux 桌面 GUI | 从预置的中间状态启动 | 真实虚拟机 | 134 个独立评估函数 |
| Terminal-Bench | 操作 Linux 终端（coding） | 人工编写 | Docker 容器 | 文件系统检查 + 真实执行 |
| GAIA | 搜集信息的通用 AI 助手 | 人工编写 + 专有附件 | 开放互联网 | 精确字符串匹配 |
- 可迁移性: 公开基准分数难以直接指导产品决策，但其设计手法（验证深度、参数化生成、泄漏防范、质量维护）充分可迁移;
- 详见: τ²-bench 的任务结构见 评估任务解剖与真实轨迹;
为什么验证器必须核实机器可独立复核的事实？
- 问题: Agent 很容易写一篇洋洋洒洒的报告说任务已经全部完成，但事实上根本没有完成;
- 原则: 评估框架必须核实机器可独立复核的事实，而非 Agent 的自我陈述;
SWE-bench Verified 如何把 “修复完成” 拆成两个可证命题？
- FAIL_TO_PASS: 修复前失败、修复后通过，证明问题确已解决;
- PASS_TO_PASS: 修复前后均通过，证明未引入新的缺陷;
- 必要性: 只检验前者，Agent 可以通过删改妨碍通过的断言蒙混；只检验后者，等同于未作检验;
- 附加: 额外确认测试自身的稳定性，排除时而通过时而失败的不稳定测试（flaky test）;
OSWorld 的验证器能发现哪些表面完成？
- 规模: 配备 134 个独立评估函数，拥有完整的操作系统访问权限;
- 可检查对象: 文件系统结构、进程状态、网络连接与应用内部状态;
- 数据库任务: 不仅确认报告文件存在，还连接数据库核实 SQL 是否正确执行;
- 浏览器任务: 分析 DOM 树、检查 cookie 与 localStorage、向后端发送验证请求确认表单确已生效;
Terminal-Bench 如何做到无法伪造？
- 例: 任务
build-linux-kernel-qemu要求从源码构建 Linux 内核 6.9，在start_kernel中加入自定义 printk，生成 initramfs 并在 QEMU 中运行; - 成功标准: 启动日志中出现该自定义消息;
- 结论: Agent 无法伪造输出，只能真正完成整个流程;
为什么自动化评估要从确定性验证起步？
- 共同点: 前述基准的验证器几乎都是确定性的——运行测试套件、断言 UI 状态、精确字符串匹配、代码执行四层检查;
- 理由: 不引入额外模型开销、结果完全可复现、可像单元测试一样纳入持续集成、便于在不同模型之间排名;
- 代价: 只能评估最终结果对不对，不能给出错误原因;
- 右移条件: 当判断无法写成代码断言时，才转向 Rubric 与 LLM-as-a-Judge;