先问：这是不是我的任务？
你是在修复已有仓库里的 issue，还是从零搭建一个应用？你需要的是算法实现、终端排障，还是浏览器与桌面操作？这些工作并不等价。
SWE-bench 的仓库修复、LiveCodeBench 的竞赛题与 OSWorld 的计算机操作，提供的是不同能力的证据。优先挑选与自己任务相近的评测，再看模型表现。
确认你比较的是同一份试卷
记录数据集版本、子集、题目时间窗口和任务数量。Full、Hard、Verified、Public 这些词不是装饰，它们往往对应不同难度和任务分布。
例如 Terminal-Bench 4.0 调整了资源限制，修复并移除了任务。不同版本之间的分数差，不能直接解释成模型能力的进步幅度。
把 harness 也算进去
模型并不是独自在完成任务。系统提示词、上下文管理、工具接口、失败重试和执行环境一起决定了 agent 的行为。这个围绕模型的运行系统通常被称为 harness 或 scaffold。
比较基础模型时，尽量固定 harness；选择实际使用的 agent 时，则应关注模型与 harness 的完整组合。两种比较都合理，但它们回答的是不同问题。
同样的分数，可能花了不同的成本
查看尝试次数、token 预算、推理设置、时间上限与费用。一次成功与多次尝试后成功，不是同样的使用体验。
关注你自己的约束：交互任务能等多久，自动化任务允许重试几次，每次成功的成本是多少。缺失的条件应被视为未知，而非默认相同。
最后，保留一点不确定性
公开题集可能进入训练语料；测试覆盖也可能漏掉真实缺陷。按发布时间选择新题能降低一些污染风险，却无法证明污染绝不存在。
用多个互补评测形成初步判断，再拿自己的真实任务进行小规模验证。把评测作为筛选工具，而不是对日常表现的保证。
更好的阅读顺序：任务相关性 → 数据集版本 → model + harness → 预算与指标 → 局限与自己的验证。