当前的自动AI研究系统虽然已经能够高效执行研发流程，但在真正的方法发现上仍有明显短板——最新的MLS-Bench评测通过140个真实研究任务，清晰展现了这一差距：现有模型更擅长优化和组合已有组件，而非提出具备迁移性的全新研究方法，同时也缺乏可靠的实验规划与证据判断能力。

核心概述

自动科研系统的多数成功案例都依赖于候选方案可以被廉价快速验证的前提，只要评分成本足够低，扩大采样和搜索就能提升效果。但真实的机器学习研究并非如此：完整训练成本高昂，反馈存在延迟，单次实验只能提供部分证据。这时候系统不仅要提出候选方案，还要判断哪些假设值得验证、如何用有限预算规划实验，以及局部的性能增益能否在不同数据和模型规模下成立。

MLS-Bench正是为解决这个问题设计的评测框架，它覆盖12个机器学习领域的140个真实任务，通过严格控制可修改范围、统一复现强人类基线，并在至少三个测试条件中验证迁移能力，将算法贡献和调参、模型容量、实现技巧区分开来。实验结果显示，即便拥有强基线代码并进行多轮实验，当前模型仍更擅长优化和组合已有组件，而非发现新机制；在自由分配算力的实验中，它们也没有表现出可靠的实验规划和证据判断能力。

论文：https://arxiv.org/abs/2605.08678
项目主页：https://mls-bench.com/
代码：https://github.com/Imbernoulli/MLS-Bench

自进化AI的三层目标

在讨论MLS-Bench之前，需要先厘清当前“自进化AI”叙事中的三类不同目标。

第一类是执行能力：模型从生成代码片段，发展到能够进入代码仓库、运行命令、调用工具并完成长程任务。相关机构的内部数据显示，代码助手在开放式问题上的会话成功率快速上升，其编写的代码占合并代码的比例已超过80%。

第二类是系统外围的持续更新：模型可以创建和复用技能、维护记忆、修改工具链，或是参与数据构建与训练流程，这类自我优化是提升研发效率的重要基础。

第三类才是真正的研究成果产出：系统能否提出此前不存在、且比人类已有方案更优秀的方法。

前两类能力可以显著提升研发效率，也是第三类能力的重要基础，但三者不能直接等同——一个智能体可以高效编写训练代码，但仍只是在执行人类给定的研究方向。正如相关学者在经典论述中提出的更高目标：真正长期有效的往往是能够利用更多计算的通用方法，我们最终需要的是能完成发现过程的智能体，而非仅仅包含人类已有发现的系统。

因此，自动科研的关键问题不只是“AI是否参与了AI研发”，而是它能否发现具备迁移性、并能随数据和计算规模扩展持续发挥作用的方法，比如ResNet、Transformer、扩散模型这类推动领域发展的成果，正是因为它们超越了单个具体实例。

研究流程覆盖不等于方法发现能力

在关于自进化智能体的讨论中，“完成了多少研究步骤”常被用来衡量能力，一个完整的系统可以检索文献、生成想法、修改代码、运行实验并根据结果迭代。但研究流程的覆盖程度，和真正的方法发现能力并不等价。

假设一个候选方案获得了更高的分数，其性能增益可能来自四类完全不同的因素：

1. 目标算法组件本身发生了有效变化
2. 超参数和训练日程被更充分地搜索
3. 数据、模型容量或计算预算发生了改变
4. 系统利用了评分流程或测试条件中的捷径

如果不对这些因素进行区分，最终的分数无法说明模型是否真正发现了更好的方法。

这种区分在廉价验证任务中并不重要，比如圆形填充、核函数优化或是固定训练速度的任务，其目标就是在明确约束下找到更高分的候选，任何合法路径都可以接受，大规模搜索是合理的核心机制。

但方法发现面对的是完全不同的目标：一个有价值的机器学习方法，通常需要在数据、模型、环境或规模发生变化后依然有效，它不仅要提升当前指标，还要捕捉比当前实例更通用的问题结构。MLS-Bench的核心贡献，正是为这种方法级的进步建立了可执行、可归因的测试环境。

任务设计：140个研究问题，12个领域

MLS-Bench覆盖了语言模型预训练与后训练、视觉生成、强化学习、机器人、机器学习系统、科学AI、优化与理论、因果推断、时间序列与可信学习等12个方向，总共包含140个任务。具体任务涵盖KV缓存压缩、主动学习、时空交通预测、黑洞图像逆问题、抗体与抗原结合、机器人世界模型、训练量化以及优化理论问题等，这样的覆盖不仅增加了任务数量，也将不同研究社区对“有效方法”的判断标准纳入同一评测体系。

完整评测每个任务仅运行一个候选方案，大约需要700个H100显卡小时；覆盖全部12个领域的30题精简版评测MLS-Bench-Lite，单次评测也需要约90个H100小时。如果允许智能体在提交前探索多个候选方案，实际成本还会进一步增加，这类成本并非额外包装，而是执行真实训练和跨条件验证的直接结果。

每个任务都来自真实的代码库，并围绕一个具体的研究组件构建，模型可能需要改进训练目标、优化器、注意力机制、采样策略或路由规则，提交的形式不是文本答案，而是可以在给定代码库中训练和评测的实现。单个实例上的分数提升不足以证明方法成立，候选方案还需要通过跨条件验证。

每项任务都包含具体的研究问题与真实代码库、经过领域专家校准的可修改组件、至少三个用于检验迁移能力的测试条件、至少三种强人类基线（包括领域公认的当前最优方法），以及在统一代码库、训练协议和评分流程中复现的基线结果。这些要素共同服务于两个目标：控制性能增益的来源，以及检查方法的可推广性。

为什么必须重新实现强人类基线

很多评测直接引用论文报告的基线数据，但不同方法往往使用不同的代码、数据版本、训练预算和实现细节，将这些数字放在一张表格中并不能形成严格的对照。MLS-Bench要求每个任务至少复现三种强人类方法，复现的结果首先用于建立统一的参考基准，同时也用于反向校准可修改的范围。

如果公认的最优方法无法在指定的组件内实现，说明限制范围过窄，评测可能排除了真实的创新；如果不修改目标组件也能通过其他路径显著提升分数，说明限制范围过宽，算法贡献无法被准确归因。最终形成的边界需要同时满足两个条件：一是表达能力足以容纳当前的强方法；二是模型无法修改目标研究问题以外的环节。

可行性还涉及训练规模，对于原始成本过高的任务，团队会使用更小的模型或更少的数据，但要求所有强人类方法在缩小规模后依然保持原有的性能排序。如果缩小后的实验改变了方法之间的相对优劣，就不能作为原问题的有效代理，140个任务都需要经过这项校准。

强人类基线和模型提交的方案会在相同的代码和训练流程中进行比较，比如在研究训练目标时，数据管线、评分器和共享训练流程保持不变；在研究模型结构时，评测会检查参数规模，避免候选方案通过增加容量获得优势。针对不同的任务，测试条件会改变数据集、模型、环境或规模，以检验局部改动是否具备迁移能力。

由于不同领域包含不同的测试条件和指标，论文使用三级聚合方法得到统一分数：每个原始指标先以复现的人类基线为锚点进行变换，最弱的基线对应0分，最强的基线对应50分；随后在测试条件内进行聚合，最终形成任务级分数，存在理论上界的指标还保留了超过50分的空间。这套设计实际上将研究评测转化为了受控实验：只允许目标算法变量发生变化，再观察这种变化能否在多个条件中产生一致的性能增益。

主实验：多轮迭代提高分数，但不等于方法发现

主实验评测了五个前沿模型，并提供了两种运行方式。第一种是评估模型首次提出并实现的方案；第二种允许模型进入代码库，进行多轮实验、读取反馈并修改实现。每个模型还会获得强基线代码，包括当前公认的最优方法，因此这次评测主要不是考查文献复现或代码重建能力，而是考查模型能否在强方法的基础上继续进行方法发现。

在论文的主实验中，多轮实验确实能够提升模型的得分，但当时评测的五个模型所提出的方法在整体表现上均未超过人类当前的最优水平。随着后续更强的模型进入公开榜单，汇总成绩仍在持续上涨，但当前领先成绩的绝对水平依然不高，评测远未达到饱和状态。与此同时，总分是否越过某个基线锚点，也不是判断方法创新的充分条件。

更有诊断意义的是候选方案的组成和跨条件行为，对论文初版五个模型的消融实验和专家分析显示，模型的性能提升主要来自已有组件的调优和重组，新的方法机制仍然非常少见。参数规模检查的对照实验展示了这些限制的必要性：如果移除检查，所有模型都会通过扩大参数量获得性能增益，部分结果甚至可以超过人类基线；恢复检查后，这些表面的性能提升就会消失。如果只观察最终分数，这类容量增长很容易被错误地归因成算法创新。

需要明确的是，这个结果并非来自工具调用失败，模型确实能够修改代码、启动训练并根据结果进行迭代，主要的差距出现在候选方案本身：模型很少提出具备新机制、且能在多个条件下持续成立的改进。

提示消融与专家分析：优化能力强于发现能力

研究团队通过提示词消融实验区分了模型的两种行为模式。当任务目标更偏向“优化现有方法”时，模型的表现更好；当目标要求“发现一种新方法”时，结果则更差。这说明当前的智能体更适合在已有方向上进行局部的工程搜索。

专家案例分析进一步检查了候选方案的组成，模型经常从多个基线中抽取损失函数、模块和训练策略，再进行重组和参数调整，这样的方案可以产生局部的性能收益，但真正的新机制却很少出现；即便模型提出了新的结构，也往往缺少一个能够解释其有效性并指导跨条件验证的有洞见的假设。

这里需要区分“新组合”和“新方法”：前者可以在特定系统中具备工程价值；后者则要求对已有方法的局限给出新的解释，并由可迁移的实验结果支持。MLS-Bench检测到的主要瓶颈，正是从“新组合”走向“新方法”的能力。

测试时扩展为什么没有跨过这条边界

对于可自动验证的任务，一个自然的优化方案是增加迭代和采样的数量。MLS-Bench的测试时扩展实验证实，更多的尝试通常能够提升分数，但收益会很快饱和，尤其是在更困难的研究任务中。

当模型只能看到部分测试反馈时，继续搜索还可能引发另一个问题：候选方案会更适应可见的测试条件，却在未开放的条件中出现性能退化，这正是方法发现和固定目标优化之间的核心区别。大规模采样可以更充分地搜索一个已经定义好的候选空间，但真正的方法发现往往需要重新定义这个空间。模型需要先识别现有方法的失败原因，形成一个有解释力的假设，再决定哪些候选方案值得投入实验，单纯的采样量本身无法提供这种判断。

预训练实验：更多算力选项没有带来更好的研究决策

方法提出只是科学工作的一部分，研究者还需要在有限的资源下选择实验，并根据不完整的反馈更新假设。论文构建了一个受算力约束的真实预训练环境，固定流程原本允许三次完整的345M参数模型训练；新的实验将前两次完整训练转换为自适应预算，由模型自行决定代理模型的规模、训练token数量和实验顺序。

这个设计让模型有机会执行常见的研究策略：先运行便宜的小实验，比较多个假设，再将昂贵的完整训练用于最有希望的方向。但实验结果并没有显示出稳定的优势，更多的可选实验反而经常导致更差的结果，有一个模型积极消耗预算，最终性能反而下降；唯一取得性能提升的模型只使用了很少的算力。

灵活预算的测试考查的是实验的价值判断能力，而不只是代码执行能力。模型在这里缺少的不只是一个更好的候选方法，还包括：选择能够区分多种解释的代理实验、判断小规模结果是否能够外推、根据新证据放弃或修正假设、决定何时值得进行昂贵的验证。

团队还为模型加入了网页搜索、基线论文推导和相关理论背景信息，但整体的性能增益仍然有限，很多情况下和普通的多轮迭代结果接近。信息获取并不是唯一的瓶颈，关键还在于如何将知识转化为假设和证据。因此，当前的模型不仅在提出新方法上存在不足，也缺少建立和验证证据所需的更广泛的科学判断力。

从可规模化搜索到可规模化科学发现

今天的自动发现范式来自一条连续的技术路径。AlphaGo和AlphaZero在规则明确的博弈中结合了模型和树搜索；AlphaTensor将数学问题转换为可搜索的动作空间；FunSearch让语言模型生成代码候选，并由自动评分器进行筛选；AlphaEvolve进一步将候选扩展到完整程序，通过程序库、评分器和迭代生成形成进化循环。

这条路径不断扩大“可以搜索的对象”，但始终保留一个核心条件：验证必须足够快、足够明确，才能支撑大量候选的生成和淘汰。形式化数学处于一个有趣的中间位置：Lean编译器可以给出严格的反馈，但验证成本高于简单的数值函数。AlphaProof这类系统可以围绕形式化状态进行广泛的树搜索，Seed-Prover这类方法则更多依赖强模型生成整段证明，再对失败的局部进行修正。

同一个领域能够同时容纳深度搜索和更强的模型推理，说明搜索并不是错误的路线，真正决定系统形态的是候选生成成本和验证成本之间的比例。现有自进化系统的许多成功案例都依赖廉价的验证器，每个候选都能快速得到明确的反馈，系统可以通过大规模采样来近似换取更高的成功率。

但真实的科学发现约束恰好相反：验证可能昂贵、延迟、多阶段且只能部分观察，一次实验通常不能直接判定一个假设；系统需要通过多个代理实验逐步缩小解释空间，再决定是否投入更大的预算。因此，真正稀缺的资源不是候选的数量，而是能够产生有效信息的计算。论文将这个问题概括为：在验证难以规模化的条件下，实现可规模化的科学发现。

这也意味着自动科研不能只沿着“更长循环、更多采样”的方向扩展，完整的自动科研能力至少包括方法提出、实验设计、预算分配、证据判断和跨条件验证，只有这些环节都具备，模型才可能从自动优化走向真正的科学发现。

从研究评测到模型官方发布

MLS-Bench还提供了覆盖全部12个领域的30题精简版MLS-Bench-Lite，用于更高频率的模型迭代评测。部分主流模型首先在官方发布中采用了该评测，后续也有更多模型将其纳入正式的发版评测表，与软件工程和通用智能体指标并列。

当传统的代码评测逐渐饱和后，面向科研的AI能力正成为新的能力前沿。MLS-Bench提供的不是一次性的排名，而是一套持续测量方法发现和科学判断能力的基础设施。对于当前的系统而言，结论依然明确：模型已经能够成为高效的工程执行者，但尚未成为能够独立提出、验证并推广新方法的研究者。

引用链接

[1] When AI builds itself: https://www.anthropic.com/institute/recursive-self-improvement
[2] Nature 正式论文: https://www.nature.com/articles/s41586-025-09833-y
[3] Seed-Prover 论文: https://arxiv.org/abs/2507.23726
[4] 相关模型技术博客: https://www.kimi.com/blog/kimi-k3
[5] 相关模型官方博客: https://qwen.ai/blog?id=qwen3.8