AutoLab：把模型扔进 12 小时的"科研闭环"，看谁还能坚持下去

核心摘要

最近一段时间，几乎每周都有新榜单，每个榜单都在告诉你某个模型"刷穿"了某个能力维度。但有个问题一直让我挺在意——这些榜单测的几乎都是"短跑"。一个题、一段对话、几十步 trace，做完就走。可真实的研究和工程是这样的吗？我自己在做模型工作的时候，最痛的环节从来不是"想出一个 idea"，而是"想出来之后，能不能在两天内反复测、反复改、反复跑，把它磨到能用"。

AutoLab 这篇 benchmark 把视角拉回到了这件事上。它做了 36 个任务、4 个领域，每个任务都给一个正确但故意写得不够好的 baseline，然后给 agent 一个非常严格的 wall-clock 预算（2 到 12 小时），让它在沙箱里反复 benchmark、改代码、再 benchmark。最后用一组隐藏验证器打分。17 个最前沿的模型跑下来，最戏剧性的结论不是"谁最聪明"，而是——决定胜负的不是你第一版写得多好，而是你愿不愿意一直磨。claude-opus-4.6 拿了 0.68 的 Avg@3，比第二名 gemini-3.1-pro（0.50）整整多 0.18，原因不是它代码写得更巧，而是它不会过早收手，也不会傻乎乎跑超时。这事儿，比"谁刷分高"有意思多了。

论文信息

• 标题：AutoLab: Can Frontier Models Solve Long-Horizon Auto Research and Engineering Tasks?
• 作者：Zhangchen Xu, Junda Chen, Yue Huang, Dongfu Jiang, Jiefeng Chen, Hang Hua, Zijian Wu, Zheyuan Liu, Zexue He, Lichi Li, Shizhe Diao, Jiaxin Pei, Jinsung Yoon, Hao Zhang, Mengdi Wang, Radha Poovendran, Misha Sra, Alex Pentland, Zichen Chen
• arXiv：2606.05080，2026 年 6 月 3 日
• 链接：https://arxiv.org/abs/2606.05080

图 1：上半部分是 11 个旗舰模型按 Avg@3 排序的总榜（实心条是 Avg@3，半透明部分延伸到 Best@3）；下半部分是四个领域的玫瑰图，每个花瓣代表一个模型在该类目的得分。claude-opus-4.6 几乎在四个方向上都伸到了最外圈。

为什么需要 AutoLab？短跑榜单测不出来的那部分能力

先聊聊"为什么"。

现有的 agent benchmark，要么是单轮回答（MMLU、GPQA 这种），要么是短程 trajectory（SWE-Bench、WebArena 大概也就几十步、几十分钟）。这些当然有意义，但它们测的是"agent 一击毙命的能力"——给个题，能不能一发命中。

可你想想真实的工程是怎么发生的。我之前调一个 attention kernel，第一版能跑通就谢天谢地了，性能比 baseline 还慢一倍。然后我做的事是什么？是连着两天反复跑 nsight、看 SM 占用率、改 tile size、再跑、再改。这个"反复磨"的过程，单轮 benchmark 完全测不出来。

AutoLab 想填的就是这个洞。它的 task 设定很明确：

• 每个任务都有一个能跑、能过测试、但性能很烂的 baseline——agent 不需要从零写，它需要的是把它磨好
• 每个任务都有一个 wall-clock 预算，从 2 小时到 12 小时不等。预算到了就强制结束，不管你提没提交
• 评分由隐藏验证器完成，agent 看不到自己得分，只能看到 benchmark 工具的输出（运行时间、正确性等）
• 每个任务都有一个人工写的参考解，参考解一般比 baseline 快 10 倍以上，但不是理论最优

这个设定有几个特别好的地方。第一，避免了"一发命中"的运气成分——你头铁猜对一次，没用，得在多次迭代里证明你能稳定改进。第二，强制 agent 跟环境真正交互——你必须跑代码、看结果、再决策，不能光靠脑子里的 prior。第三，端到端——不是抽象的 toy task，是真的会拉起 GPU、跑 CUDA kernel、训小模型的工程任务。

这就是 long-horizon closed-loop optimization。说人话——让 agent 像一个真实的研究员一样工作半天到一天，看它最后能磨出什么东西。

36 个任务长什么样？四个领域，每一个都是真活

任务分四个领域，加起来 36 个：

这个分布我看了一会儿才反应过来作者的用心——它故意把任务难度的分布拉得很开。系统优化任务相对"传统"，模型开发任务对应的是 ML 研究员的日常，CUDA 任务是真正的硬骨头（只有 4 个，但每一个都极难）。这样一个模型在总榜上的成绩，就不容易因为某个领域天生不擅长而被一棍子打死。

图 3：四个领域下的代表性任务清单。可以看到任务名都很具体——flash_attention、ntt_butterfly_cuda、scaling_law_pretraining 这些都是真实工程里会碰到的东西，不是生造的 toy。

每个任务的"打分函数"也是设计过的，不是简单的 0/1。论文用了两种打分：

性能优化型任务用 log-stretch：

这里 \(m_{\mathcal{B}}\) 是 baseline 性能、\(m_{\mathcal{R}}\) 是参考解性能、\(m(x)\) 是 agent 当前提交的性能。这个公式的工程含义是——追上参考解只能拿 0.5 分，剩下的 0.5 分要靠你跑得比参考解还快。这个设计挺聪明，因为它鼓励 agent 不要满足于"和人类水平一样"，要继续往前推。

质量有界的任务（比如某些模型开发任务，得分天然就在 [0,1] 区间）用线性版本，逻辑一致。

最后用三个聚合指标看模型能力：

• Avg@3：3 次独立 run 的平均分（看典型水平）
• Best@3：3 次里的最高分（看上限）
• Dominance：跟所有其他模型的"两两对决胜率"

评估管道：从 prompt 到 verifier 的闭环

图 2：每个任务的标准化组件——instruction（任务描述）、environment（沙箱代码库 + 数据 + 依赖）、verifier（隐藏的评分脚本）、reference solution（专家解）、wall-clock budget。Agent 在 environment 里反复 read/edit/execute，最后由 verifier 在外部环境给最终 commit 打分。

这套管道我特别欣赏的一点是——verifier 是真正"隐藏"的。Agent 在沙箱里能看到 baseline 的代码、能跑一些自己写的 micro-benchmark、能看到运行时间这种侧面信号，但它看不到自己最终会被怎么评分。这就模拟了真实研究里"你不知道审稿人会用什么标准"的状态——你只能尽量按你认为合理的方向优化。

当然这也带来一个副作用——agent 容易"走偏"。比如它可能为了让自己的 micro-benchmark 数字好看，写了一些只在自己测试用例下快、但 verifier 用更严格的输入分布时直接挂掉的 hack。这个现象论文里其实有提到（后面的失败模式分析里看得很清楚），但作者没有过度纠正——他们觉得这就是真实研究里会出现的偏差，让它暴露出来反而是 benchmark 的价值。

主结果：claude-opus-4.6 一骑绝尘，但故事不在分数里

先看主表。

第一梯队 claude-opus-4.6（0.68）和第二名差了 0.18，这个 gap 在 LLM benchmark 里是巨大的——要知道 MMLU 上前几名通常就 1-2 个点的差距。这里直接拉开了将近一档。

第二梯队（0.43-0.50）挤了一堆模型，包括 gemini-3.1-pro、kimi-k2.6、mimo-v2.5-pro、glm-5。开源模型表现得不错，国产模型在这个梯队占了 3 个席位。

第三梯队（0.27-0.38）包括 deepseek-v4-pro、gpt-5.4、grok-4-20 等。gpt-5.4 排在第七——这个结果说实话挺意外的，毕竟它在很多其他榜单上是 top tier。后面会看到，这跟它"过早收手"的行为模式直接相关。

但真正有意思的不是分数本身，而是接下来这张图。

决定胜负的关键：不是初版有多好，而是肯不肯一直磨

图 4：Flash Attention 优化任务上各模型的实时性能演化。横轴是 wall-clock 时间，纵轴是 self-reported 运行时间（毫秒，越低越好）。两条虚线是 baseline（750 ms）和参考解（100 ms）。

这张图我盯着看了好一会儿，越看越觉得有意思。

• claude-opus-4.6（紫色）是一条持续下降的曲线——它在初期跟其他模型差不多，但后续一直在小步迭代，最后压到 18 ms（相对 baseline 的 42.4 倍加速，远超参考解的 7.5 倍）
• kimi-k2.6、gemini-3.1-pro、glm-5 在 50-80 ms 的区间形成了平台，早早停止改进
• deepseek-v4-pro 是个典型反例——它每步都花大量时间"想"，结果第一次 benchmark 都拖到很晚才出来，迭代次数严重受限
• grok-4-20 这条线最戏剧性——它在很早的时候就几乎不动了，等于交了个跟 baseline 差不多的方案就溜了

这就是为什么作者反复强调：最终性能的主导预测因子，不是 agent 第一次提交的质量，而是它能不能持续 benchmark、修改、吸收反馈。说实话这个发现颠覆了我之前对 long-horizon agent 的一些直觉。我原本以为头部模型的差距应该体现在"代码写得有多优雅"上，但 AutoLab 告诉我——真正的差距在性格上。一个会"持续打磨"的模型，比一个"一次写得很好但就此停手"的模型，在长程任务上能拉出明显档差。

失败模式：过早终止 vs 跑超时

图 6：302 个零分 run 的人工分类——超时/上下文耗尽、能力差距、指令违规、其他。不同模型展现出非常不同的失败画像。

作者人工检查了所有 0 分的 run（302 个），把它们分成了四类：

1. 过早终止（gpt-5.4、grok-4-20 重灾区）

这些模型的特征是——还没充分探索就交卷了。论文里举的例子很扎心：grok-4-20 在 flash_attention 任务上只跑了一次评估脚本就提交了。整整 12 小时的预算，它用了大概几分钟就觉得"行了"。这种行为模式在 RLHF 训练里其实有个名字——reward hacking 的反向版本，模型学到了"快速给个看起来合理的答案"是高 reward 路径，结果在 long-horizon 任务上反而是致命弱点。

2. 预算耗尽（deepseek-v4-pro、hunyuan-3-preview、qwen-3.6-plus 重灾区）

这些模型走到了另一个极端——它们一直迭代，从来不主动 commit。结果就是预算到了被强制中断，零分。这个失败模式更让人无奈，因为它说明模型其实在工作，但缺乏"什么时候应该停下来 ship 一个版本"的判断。这特别像我见过的一些工程师，一直在调一直在调，永远不肯交付。

3. 指令违规（gemini-3.1-pro 55 例、glm-5 44 例）

这部分主要是模型违反了任务约束（比如不让用某些库、必须保持某些接口不变）。有意思的是单个任务 ntt_butterfly_cuda 一个就贡献了一半的违规——说明这个任务的约束可能确实写得有点苛刻，或者说大部分模型都在 CUDA 任务上有"我先用 PyTorch 试试看"的偷懒倾向。

4. 其他：服务器错误等上游问题，量很少。

资源使用与性能：花得多 ≠ 跑得好

图 5：左——平均 agent 步数 vs Avg@3（强正相关，迭代次数越多分数越高）；中——平均 agent 总运行时间 vs Avg@3（说明过早终止的模型确实分低）；右——平均推理成本 vs Avg@3（成本与表现并不严格相关）。

这三张图放在一起讲了一个挺清醒的故事。

左图最直接：步数越多，分数越高。这印证了"持续迭代"是 success 的主要驱动力。但这里有个反例值得注意——deepseek-v4-pro 步数其实不少，但分数不高。原因是它的"步"很多是浪费在过度推理上的，不是真的在做有效迭代。

中图显示了过早终止的代价——agent 总运行时间短的模型（grok-4-20、gpt-5.4）在分数上吃了大亏。

右图最有意思——推理成本和最终分数并不严格相关。最贵的模型不一定最强，有些便宜的开源模型反而表现不错。这对落地来说是个好消息——你不需要永远买最贵的服务，关键是模型的"性格"是否适合你的任务。

框架的影响：同一个模型，换个壳子分数能差 0.43

图 7：同一模型在 terminus-2、pi-mono、mini-swe-agent 三个 agent 框架上的得分。最大差距能达到 0.43——意味着选错框架可以让一个 SOTA 模型表现得像个二流模型。*

这个结果某种程度上比主榜更让我警觉。Agent 框架的选择，对最终性能的影响居然能达到 0.43——这跟换一个完全不同档次的模型差不多了。

直觉上你可能会想，框架不就是个壳子吗？工具调用、错误处理、prompt 拼接，能差多少？答案是能差很多。论文里的 case 显示，某些框架在 long-horizon 任务上会主动给模型注入"剩余时间提示"和"是否应该 commit"的提示词，这些 nudge 直接改变了模型的行为模式。一个本来会跑超时的模型，在带 time-awareness 的框架下可能就会及时收尾；一个本来会过早终止的模型，在被 prompt "你还有 8 小时"之后会愿意多迭代几轮。

图 8：三个 agent 框架下的成本-性能权衡（成本是 log 轴）。可以看到不同框架的 Pareto frontier 形状差别明显，框架可以放大或抹平特定模型的优势。

工程启示挺直接——做长程 agent 系统时，框架本身就是一个超参，必须当成 first-class citizen 来调。光选对模型不够。

我的判断：这篇 benchmark 真正值钱的地方

聊聊感受。

我对这篇 benchmark 的总体评价是——它捕捉到了一个之前被严重低估的能力维度。所谓"持续性"和"时间感知"，听起来挺玄，但 AutoLab 用一个非常具体的实验设计把它量化了出来。这种"把模糊的能力概念落到可测的数字"的工作，在 LLM 领域其实非常稀缺。

它打动我的几个点：

第一，benchmark 的"质感"对。36 个任务都是真活，CUDA kernel、scaling law、SFT 数据筛选——这些都是 ML 工程师实际会碰到的事，不是为了凑数生造出来的题。Wall-clock 预算的设计也很真实——12 小时的上限既不会让基准跑成"无限长"，又给了足够空间来体现"持续性"。

第二，失败模式的人工分析做得很扎实。302 个 0 分 run 一个一个看完、归类、给出每个模型的失败画像——这个工作量大但价值高。它让 benchmark 不只是"一个数"，而是一个能告诉你"这个模型为什么不行"的诊断工具。

第三，结论是反直觉的，但有强证据。"持续性比初版质量更重要"——这个 take 之前 community 里有人零星提过，但从来没有这种规模的实证支持。AutoLab 几乎是从根上挑战了"看 benchmark 单分排名选模型"的做事方式——如果你的真实场景是 long-horizon，你应该看的不是 Avg@3，而是看模型在 trajectory 上"会不会过早收手"和"会不会跑超时"。

但我也有几个疑问：

第一，框架影响 0.43 这个数据，会不会让主榜的可比性变差？ 论文用了 terminus-2 作为主框架，但既然换框架能差这么多，那"claude-opus-4.6 拿 0.68"这个数字到底有多稳？如果换 mini-swe-agent，第一名会不会变？作者的 honest take 是"框架就是 agent 系统的一部分"，但这意味着 benchmark 的绝对分数不能太当真，相对排名也要打个折。

第二，36 个任务、3 次 run、17 个模型，资源消耗是 2544 GPU 小时、86 亿 token——这个 benchmark 复现成本极高，社区跟进会比较慢。短期内可能只有大厂能完整跑。

第三，"持续性"这个能力到底是 RL 训出来的、还是 SFT 数据里就带的、还是测试时 prompt 影响的，论文没有给出机制层面的分析。这是个未来工作的金矿——如果能搞清楚 claude-opus-4.6 的"耐心"是哪里来的，理论上其他模型也能学到。

工程启示：如果你也在做长程 agent

看完这篇有几个事情我会立刻拿到自己手上的项目里试。

1. 在 prompt 里显式注入时间感知——告诉 agent 当前用了多少 wall-clock、还剩多少。论文的实验暗示这个 nudge 对很多模型来说是关键的行为校正。

2. 不要相信"一次输出"——做长程任务时，明确鼓励 agent 多次迭代、自我 benchmark、保留中间结果。一个"先 commit 个能跑的版本，再持续改进"的协议比"一次性写完美"靠谱得多。

3. 选模型时不要只看主榜分数——如果你的任务是 long-horizon 的，要专门看模型在 trajectory 上的行为画像。是过早终止型还是跑超时型？这个性格和你任务的匹配度，比绝对分数更重要。

4. Agent 框架本身就是超参——别只调 prompt，框架的选择、tool 设计、错误处理逻辑都会显著影响最终性能。如果可能，多框架做 A/B。

最后一个 takeaway 是这样的——AutoLab 这篇论文里反复出现一个词：persistence。在他们的语境里，这是模型最稀缺的能力。不是更聪明，不是更快，不是更准——是更能磨。

这件事让我有点感慨。我们做了这么多年模型工作，模型越变越大、推理速度越来越快、benchmark 一个比一个高。但现在最难的事情，居然变成了让模型"愿意一直工作下去"。某种程度上，这跟人也很像——大部分人在大部分时候都不缺能力，缺的是坐住板凳的耐心。

模型的世界，最终也走到这一步。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我