OWE-Bench：26个长时程工程任务，顶级模型仅54.6%——AI离开放世界工程师还差多远

基准设计：为什么用连续评分而非通过/失败

工程项目的评测一直卡在一个尴尬的地方。你给模型一个任务，它交回一个结果，要么对要么错。但对于那些需要几十个小时才能跑完的项目，这种二元判断根本看不出差距。Mercor 发布的 OWE-Bench 想换个玩法。它包含 26 个长时程工程与研究任务，覆盖软件工程、物理工程、机器学习、科学计算四个领域，从 GPU 内核到飞机设计 来源：Mercor OWE-Bench。

评分规则很有意思。所有任务都在未见过的实例上评分，采用连续量表，一个把程序加速到天花板一半的智能体得 50%，而不是零分 来源：Mercor OWE-Bench。这意味着部分进展有回报。作者强调工程需要的不只是记忆，工程师读论文、查规范、适配开源实现，项目简报之外的知识同样关键 来源：Mercor OWE-Bench。

任务分两种形态。scaffolded 任务从可用代码库出发，推动内核速度、延迟或误差这类可测目标；end-to-end 任务从裸环境构建整个产物，比如训练好的模型、数据管道、机械设计 来源：Mercor OWE-Bench。具体两种形态的占比作者没有在摘要中给出，我不确定。每次尝试给 4 到 18 小时，中位 8 小时，全部任务跑一遍需要 257 个智能体小时，硬件按任务匹配，比如 CPU 沙盒、NVIDIA H100 或 B300，其中 7 个任务用到 GPU 来源：Mercor OWE-Bench。

排名与成本：谁在长时程任务上真的有效率

榜单上的数字先让人松一口气，又让人眉头一紧。Claude Fable 5.2 以 54.6% 登顶，平均每次尝试消耗 2.11 亿 token 来源：Mercor OWE-Bench。听起来不少，但第二名 GPT-6 Astra 得分 44.2%，平均只用 8900 万 token，约为 Fable 5.2 的 42% 来源：Mercor OWE-Bench。花更少的 token 拿到接近的分数，这让我对效率的理解有点动摇。

第三名 Claude Opus 5.5 得 41.6%，消耗 2.53 亿 token，是前三名中成本最高的 来源：Mercor OWE-Bench。换句话说，花更多钱不一定买到更高分。小模型的分化更能说明基准的区分度：Inkling 只有 1.1%，Beam 只有 3.3% 来源：Mercor OWE-Bench。

Fable 5.2 在全部四个领域领先，但优势不均衡。Astra 在物理工程与科学计算领域只差几分 来源：Mercor OWE-Bench。这说明领域通用性和领域专用性之间的权衡还没有解决。一个模型想同时在数据库优化、飞机设计、模型训练和科学计算上都拿高分，目前看不太现实。

反直觉发现：多花 token 不等于更高分，领先者效率并非最优

把 token 消耗和得分放在一起看，问题就出现了。得分第一的 Fable 5.2 比第三名 Opus 5.5 少花约 4200 万 token，但分数高出近 13 个百分点 来源：Mercor OWE-Bench。而第二名 Astra 用不到一半的 token 就拿下 44.2% 来源：Mercor OWE-Bench。我原本以为预算越多表现越好，这个基准告诉我没那么简单。

作者在文中明确指出了一个内在矛盾：工程所需知识无法仅从项目简报获得，但基准任务设计仍以项目为起点 来源：Mercor OWE-Bench。这种张力可能是模型无法逼近满分的原因之一。我不确定这是否是全部原因，但至少，模型要查论文、查规范、适配开源实现，这些工作发生在项目简报之外，评测却主要围绕简报里的项目展开。

连续评分让部分进展获得回报，与常见 pass/fail 基准相比，更能暴露模型在长尾工程任务上的真实能力 来源：Mercor OWE-Bench。当前最高分仍不足 55%，没有任何模型接近基准上限 来源：Mercor OWE-Bench。我倾向于认为工程任务的开放性本身被低估了，模型需要从简报之外获取知识，而评测仍以项目为起点，这个错位或许才是天花板的主因。基准将随社区成长，下一版本开放外部贡献者提交任务 来源：Mercor OWE-Bench。

原文：

Introducing OWE-Bench for Long-Horizon Engineering Projects · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月13日