这项由卡内基梅隆大学计算机科学学院主导的研究发表于2026年5月，以预印本形式在arXiv上公开，编号为arXiv:2605.05724v1，有兴趣深入了解的读者可以通过该编号查询完整论文。
研究本身要解决的问题，其实是机器学习领域里一个看起来平常却相当棘手的挑战：一个新模型能不能自己做研究？不是泛泛地写出一篇论文，而是真正地在电脑上动手改代码、跑实验、看结果、再改、再跑——就像人类研究员每天在实验室里做的事情一样。
以往的人工智能研究辅助工具，要么只会帮你写文章，要么只会调调参数，要么只会建议下一步怎么做，但它们很少能把"提出想法→改写代码→运行实验→看懂反馈→再次改进"这整个闭环自动化地转起来，更别说在这个过程中遇到错误、超出限制、结果不好之后，还能从中学习并调整方向。卡内基梅隆大学的这支团队，正是把目标锁定在这个完整的闭环上。
他们构建了一套"自动研究"系统，核心设计是让多个专门负责不同方向的AI代理（就像一组分工协作的研究小助手）轮流提出假设、修改代码、提交实验、读懂外部评测系统返回的结果，然后把这些经验记录下来，传给下一轮继续用。整个过程一旦启动，人类不需要介入——不需要挑选哪个想法值得试，不需要修复崩掉的实验，也不需要判断某次失败是否有价值。机器自己摸索，自己总结，自己继续。
在实验中，这套系统跑了三个不同的机器学习任务，合计提交了1197次正式实验加上600次对照实验。在"参数高尔夫"这个任务上，它把模型压缩效率提升了0.81%；在"NanoChat-D12"语言模型预训练任务上，它把核心评估分数从0.1618提升到0.2244，提升幅度高达38.7%；在CIFAR-10图像分类速度任务上，它在满足精度要求的前提下把训练时间压缩了4.59%。每一项结果都由独立的外部评测系统验证，研究团队没有在中途干预或修改规则。
一、这套系统到底在做什么：一次实验就是一次"提案+动手+看反馈"
要理解这套系统的工作方式，可以把它比作一个认真负责的实习研究员团队正在厨房里改进一道菜谱。每个人负责不同的方向——有人专门研究食材搭配，有人专门负责火候控制，有人专门琢磨调味，还有人专门分析之前每次尝试的记录。每次有人提出"我觉得改用这个食材会更好"，就真的去做一道菜，然后让一个独立的美食评委打分。评委的评分结果会被完整记录下来：这次多少分、花了多长时间、有没有超出食材预算、失败原因是什么。这些记录会被传给整个团队，下次有人提新想法时，可以先看看之前哪些方向试过了、哪些超预算了、哪些方向虽然没提升但离目标最近。
这套系统中，每一次"实验"被称为一个"trial"（试次）。每个试次包含四个要素：一个关于"这次改动为什么有用"的假设、对训练代码的实际修改、外部评测系统给出的结果分数、以及被记录下来供后续参考的反馈信息。这四个要素构成了一次完整的研究动作，就像一次菜谱改进实验从设想到上桌再到记录结论的完整过程。
系统里有一个叫做"lineage"（血缘记录）的核心机制，可以理解为那本越来越厚的"改良菜谱日志"。每次实验结束后，不论成功还是失败，结果都会被追加进这本日志。下一轮的AI代理在开始工作前，会先翻阅这本日志，了解当前最好的结果是什么、哪些方向试过了但没用、哪些方向因为超出限制而被淘汰、最近有没有什么新思路值得借鉴。正是这本日志，让整个系统不会每次都从零开始乱撞，而是能够沿着已有的经验线索继续往前推进。
二、三个不同的"竞技场"：不同的限制条件，不同的反馈信号
为了验证这套闭环系统是否真的有效，研究团队选择了三个截然不同的任务环境，每个环境都有自己独特的"游戏规则"和"得分方式"，就像用不同难度的关卡来测试同一套攻略是否通用。
第一个任务叫"参数高尔夫"。这个名字来自OpenAI发布的一个公开挑战，规则很像真实的高尔夫球——分数越低越好，但还有严格的场地限制。具体来说，选手需要训练一个语言模型，让它在一个固定的文本数据集上达到尽量低的"验证损失"（可以理解为模型读文本时"猜词"的错误率，越低表示模型越聪明）。但关键在于，整个程序打包后的文件大小不能超过16兆字节，训练过程不能超过10分钟，全程使用8块高端显卡（H100）。这意味着每个想法都要在"效果更好"和"体积更小"之间精准拿捏，稍微贪心一点就会因为文件超大而直接被淘汰。这个任务的主要反馈信号，就是文件大小和时间预算——每次超出限制，系统都会返回精确的"超出了多少字节"或"超时了多少秒"，这些信息被直接传回给下一轮的AI代理。
第二个任务叫"NanoChat-D12"。这是由著名AI研究者Andrej Karpathy开源的一套小型语言模型预训练框架，任务目标是在固定的90分钟计算时间内，尽可能提高模型在多个评估基准上的综合分数（称为CORE分数）。这个任务的独特之处在于，它的反馈信号主要是"运行效率"——如果一个代码改动让训练变快了，那省下来的时间就可以用来训练更多轮次，相当于间接提升了最终分数。这就像给赛车手一个固定油量，跑完比赛你的排名取决于终点速度，所以提升引擎效率和降低轮胎磨损都能让你跑得更远。在这个任务中，AI代理最大的收获之一，正是发现了训练代码中存在一个注意力计算模块效率低下的瓶颈，替换后省出了大量计算时间，这些时间随即被用于训练更多数据，分数因此大幅提升。
第三个任务叫"CIFAR-10 Airbench96"。CIFAR-10是一个经典的图像分类数据集，里面有飞机、汽车、鸟、猫等十类图片，任务是训练一个模型来准确区分它们。Airbench96在这基础上加了一个颇具挑战性的规则：模型在测试集上的平均准确率必须达到96%以上，然后在满足这个精度门槛的前提下，谁的训练时间越短谁就赢。这个"精度门槛"就像一道关卡，没有达到它，再快也没用。于是AI代理每次提出"加速训练"的想法，都要先过一关"精度检验"——失败了不会只收到一个笼统的"错误"提示，而是会得到详细的"这次速度是多少、精度是多少、差了多少"，这些精确的失败信息同样会被记入日志，供后续改进参考。
三、分工协作的专家团队：为什么要有"专家"而不是一个全能代理
这套系统里有一个设计选择，乍看之下不那么显眼，但实验结果表明它相当关键：系统里不只有一个AI代理在工作，而是一群分工明确的"专家代理"，每个人只负责训练流程的某一个方面。
以"参数高尔夫"任务为例，这里一共有十个专家角色，分别负责模型架构设计、优化器调参、量化压缩、正则化方法、损失函数设计、评估策略、课程学习、分词方式、测试时训练，以及一个专门负责综合分析已有结果的"元搜索分析师"角色。每个专家有自己的工作目录，有自己的提示词说明自己该负责什么、不该碰什么，还有明确的"改动力度"指导——比如架构专家被告知，如果当前最好的版本已经在小参数上调来调去了，那就应该考虑更大幅度的结构性改动，而不是继续微调同一个数字。
NanoChat-D12任务有五个专家，分别负责模型架构、优化策略、数据处理、训练调度和系统级优化。CIFAR-10任务同样有五个专家，覆盖架构、优化、数据增强、损失函数和正则化。
每个专家都能看到同一份"日志账本"——所有人的实验记录都被汇总在共享的血缘记录里。这意味着，当系统专家发现了训练效率问题并修复了它，架构专家在下一轮工作时就能看到"系统专家刚刚省下了一批时间"这条信息，并据此决定是否值得在这段时间里尝试更复杂的架构。信息在不同专家之间流通，想法可以跨越角色边界相互激发。
研究团队在论文中做了一组对照实验，把这种"分工专家+共享日志"的设计和其他几种方案做了比较。对照方案包括：只有一个全能代理独自工作（单一通才），十个不分专业方向的普通代理同时工作（通用多代理），以及和标准系统完全相同但去掉了历史记录共享机制的版本（无血缘记录）。
实验结果用一个数字来概括就很清楚了：在同样的200次实验预算内，分工专家+共享日志的版本找到了16次有效提升，无血缘记录版本只找到了3次，然后之后跑了125次实验都没有再找到任何新的提升。没有历史记录的系统，就像一个每天早上都失忆的研究员，每次都要从头开始摸索，碰壁了也不知道上次是为什么碰壁的。通用多代理版本虽然也有10个代理同时工作，但因为它们提出的想法高度重叠（最大的一个"想法类别"占了12%的提案，而分工专家版本只有3.5%），实际有效提升反而比分工专家版少。
衡量"提案多样性"的方式也很有意思。研究团队把每次实验的假设文本用一种叫TF-IDF的算法转换成向量，然后统计这些向量聚集成多少个真正不同的"想法簇"。分工专家版本在200次实验中形成了134.8个有效想法簇，通用多代理只有41.1个，单一通才只有61.9个，而且单一通才有10.1%的提案几乎是重复的（分工专家版本只有2%）。这说明，专业分工确实在帮助系统把注意力分散到更多不同的方向上。
四、失败也是信息：崩溃、超时、不达标都是有价值的反馈
在这套系统里，一次实验"失败"并不意味着这次尝试毫无意义。研究团队把每种失败都仔细分类，并将失败的具体信息原封不动地传递给下一轮代理。
实验状态被划分为九种。"keep"表示这次结果比之前最好的记录更好，被正式保留。"discard"表示结果有效但没有改善。"crash"表示训练代码运行出错了，并没有产生有效的评分。"preflight_crash"表示代码在连GPU时间都没用上之前就在本地检查阶段出错了。"size_blocked"表示打包后文件超过了16兆的上限，直接被拦截。"train_budget_overrun"表示训练阶段超时了。"eval_budget_overrun"表示评估阶段超时了。"disqualified"是专门给CIFAR任务用的，表示速度够快但准确率没达到96%的门槛。还有一种"harness_abort"，表示系统调度层面出了问题，这类失败被标记为非实质性信号，不会传递给下一轮代理。
这种精细化的失败分类，在实践中起到了非常具体的作用。以参数高尔夫任务中的一个真实案例为例：第587次实验提出了一个叫做"TTT-only z-loss"的技术改动（简单说就是在测试时自适应阶段引入一种额外的训练目标），这个改动确实让模型的验证损失从1.0810下降到了1.072431，效果是好的——但文件打包后超出了16兆的上限2056个字节，被判为不合格。这个结果被完整记录：分数是多少、超出了多少字节。下一轮的代理读到这条记录，知道"这个想法本身有效，只是体积太大"，于是专门针对压缩部分进行优化，在保留同样技术思路的前提下，从源代码层面回收了足够的字节空间，最终让第596次实验在15,995,930字节的合法范围内实现了1.072251的分数，把这个原本"超限的好想法"变成了一个真正合格的提升。
CIFAR-10任务里有一个更生动的例子。第60次实验跑完之后，时间只用了25.165秒（已经比起始点快了），但准确率只有0.9596，差了0.0004没过96%的门槛，被判为"disqualified"（不达标）。这条记录被传给后续代理：速度已经够快了，差的只是那一点点准确率。于是第70次实验保留了所有加速改动，只把预热阶段的比例从10%调短到5%，结果准确率恢复到0.96008，时间保持在25.1464秒，成功通过了精度门槛。一次"差一点点"的不达标，直接告诉了系统应该调整哪个旋钮。
五、NanoChat的故事：一个运行速度的发现如何滚雪球式地变成38.7%的提升
NanoChat-D12的实验轨迹是这篇论文里最完整的一个"故事弧"，值得详细讲一讲，因为它清晰地展示了这套闭环系统是如何把一个系统层面的发现转变成一系列连锁的研究行动的。
故事从第7次实验开始。系统专家代理在分析NanoChat-D12的训练代码时，发现了一个效率问题：原始代码里，12层Transformer注意力模块中的部分层使用了一种叫做"masked SDPA"的计算路径，这种路径在当前GPU上运行时比另一种叫做"Flash SDPA"的计算路径要慢。这就像一条双车道高速公路里，有几段路莫名其妙地缩窄成了单车道——整体速度被瓶颈拖慢了。代理把这几层全部切换到Flash SDPA路径，代码改动本身并不复杂，但效果是可测量的：训练速度加快了，在固定的90分钟预算内可以训练更多的数据。CORE分数从基准的0.1618上升到了0.1695，这是第一次有效提升。
这条记录进入了血缘日志。关键在于，它记录的不只是"CORE提升了"，还记录了"为什么提升"——因为运行时间省下来了，所以可以多跑一些训练步骤。后续的数据专家和调度专家读到这条记录，意识到时间预算现在有了富余，可以扩大训练数据的量。第20次实验把训练数据的比例从原始设置大幅扩展，这一步带来了最大幅度的单次提升：CORE分数跳到了0.2029，单次提升0.0334。
接下来，第24次实验进一步调整了不同训练阶段的数据混合比例（预训练阶段约12份、中间训练阶段约100份、最后阶段约130份），第25次实验在这个方向上进一步细化，把CORE分数推到了0.2241，形成了一个相对稳定的高点。最后，第156次实验由另一个方向的代理提出了一个细小但有效的改动：在语言模型输出头之后添加一个零初始化的可学习偏置向量，这个向量可以让模型学到词汇层面的先验分布，最终把CORE分数推到了0.2244。
整个过程，一个系统层面的运行效率发现，经过血缘记录的传递，变成了数据预算的扩展决策，又变成了训练阶段配比的调整，最终在一个小型的模型结构改动上收尾。这条链条里的每一步，都是前一步的观察结果催生的下一步假设。
六、实验的严谨性：如何防止AI"作弊"
这套系统在设计上有一个贯穿始终的原则：评测必须由独立于训练代码的外部机制来完成，不能让代理自己报告自己的成绩。这个原则看起来简单，但实现起来需要在多处精心设计。
在参数高尔夫任务中，分数由官方评测路径计算，代理提交的代码无法接触评测逻辑。在NanoChat-D12任务中，CORE分数由一个"受保护的解析器"从训练日志中提取，代理不能修改这个解析器，系统还会自动审计每次提交是否有代理尝试碰触解析器或评估器的文件，发现则直接标记为无效。在CIFAR-10任务中，训练时间由外部Shell命令测量并写入独立的时间记录文件，训练脚本本身不能报告自己的运行时间，准确率评测也由外部分类器执行。
这种设计的意义在于，它在源头上关闭了一种常见的"奖励黑客"风险——如果允许AI代理修改评测代码，那最简单的"提升"方式就是让代码直接输出一个更好看的假分数，而不是真正改进模型。外部评测机制确保了每一个记录在案的分数都对应着真实的训练效果。
每次提交前，系统还会先在本地做一次"预检查"：语法检查（用Python的编译器确认代码没有语法错误）、大小检查（用真实的压缩算法模拟打包，提前判断是否会超出16兆限制）。这两步检查不消耗GPU资源，可以快速过滤掉明显不合格的提交，把宝贵的GPU时间留给真正有机会的实验。
研究团队还为系统设置了明确的终止条件：超过48小时的运行上限，或者超过4小时没有找到任何新的有效改善就会停止。每次有新的有效提升出现，4小时的倒计时就会重置。
七、并行运行与效率：十个专家同时工作能快多少
在计算资源的使用上，研究团队也做了一次有意思的测量。他们定义了一个"并行效率"指标，衡量多代理同时工作相比单代理串行工作能快多少倍。理论上，十个代理同时工作应该快十倍，但实际上因为所有代理共享同一个GPU资源池、共享日志文件的读写锁，效率会有所损耗。
测量结果是：单一通才代理每小时可以完成2.26次实验；分工专家的十代理版本每小时完成18.15次，并行效率约为80%（理论最高值是十倍，实际达到了八倍左右）；通用十代理版本每小时完成16.79次，并行效率约为74%。这意味着，分工专家版本相比通用多代理版本不只是提案更多样，连实际执行效率也略高——因为专家分工减少了代理之间对同一资源的争抢。
这个效率数字在实践中非常重要：如果反馈结果返回得太慢，后续代理在制定新提案时就用不上这些反馈，闭环的价值就会大打折扣。对于一个每次实验本身就需要10分钟到90分钟的任务，保证足够的并行吞吐量，是整套系统能在有限时间内完成大量探索的前提。
八、系统的边界与局限：哪些事情它还做不到
研究团队对这套系统的能力边界有非常坦诚的描述。在整个1197次实验中，AI代理提出的改动，本质上都属于"组合已知技术"的范畴——把现有的高效注意力核、现有的正则化方法、现有的量化策略，以各种方式组合、迁移、适配到当前的任务环境中。
系统提出过的改动包括：把不同类型的注意力机制混合使用（如差分注意力、多头潜在注意力）、在Transformer块内部引入循环结构（类似状态空间模型的思路）、修改学习率调度的形状（从余弦切换到WSD等）、引入GQA（分组查询注意力，一种减少键值缓存体积的技术）、使用哈希嵌入替代标准词嵌入、添加多任务预测目标、调整卷积深度和宽度的比例，以及尝试自定步调的损失缓存策略。这些都是机器学习领域中存在的已知技术方向，系统的贡献在于在特定约束条件下将它们有效组合。
然而，系统在整个过程中没有提出任何可以被称为"范式级创新"的想法——比如提出一种全新的神经网络基本操作，或者打破现有架构假设的根本性结构设计。论文作者明确写道，这套系统在当前阶段的观察范围内，无法做出类似"发明Transformer"这样的结构性突破。这是一个诚实的自我定位，而非缺陷的掩盖。
系统同样不适合那些反馈模糊、无法自动验证的任务场景。如果一个研究问题的评估需要人工判断、或者实验周期过长导致反馈无法及时返回，这套闭环就难以转起来。它最适合的环境是：有明确的可量化目标、失败可以被精确描述、每次实验的时间成本在可接受范围内、评测逻辑独立于训练代码。
归根结底，这项研究要说明的是：AI辅助研究不应该被定义为"AI生成一篇论文"或"AI提出一个大想法"，而应该被理解为"AI真正参与那个每天都在发生的改代码-跑实验-看结果-再改-再跑的循环"。当这个循环被忠实地自动化之后，它产生的不是一个漂亮的结论，而是一份可供检查的轨迹——每次提案是什么、代码怎么改的、评测系统怎么说的、失败原因是什么、下一步怎么变了。这份轨迹本身，就是研究过程的证据，而不只是研究结论的展示。
如果有一天AI系统真的能在这个闭环里提出范式级的新想法，那么同一套评测机制就可以立刻检验那个想法是否真的成立——因为评测标准并不随着想法的大小而改变。那时候，这套系统的价值会比现在更加凸显。目前的成果已经说明，在"组合与改进"这个维度上，机器已经可以做得相当扎实；至于"发明"这个维度，暂时还是留给人类和未来更强大的模型去探索吧。有兴趣深入了解技术细节的读者，可以通过arXiv:2605.05724v1查阅完整论文，代码和实验轨迹也在论文中提到的GitHub仓库公开。
Q&A
Q1：自动研究系统中的"血缘记录"（lineage）是什么，它有什么用？
A：血缘记录是系统在每次实验结束后自动追加的一份历史日志，记录了每次提案的假设内容、代码改动、得分结果、失败原因和耗时等信息。下一轮AI代理在提新想法前会先翻阅这份日志，避免重复踩已知的坑，也能基于之前成功的方向继续深入。没有这份记录的对照实验里，系统在找到3次有效改进后就陷入了125次连续无效探索，说明历史记录对维持研究方向至关重要。
Q2：参数高尔夫任务里的文件大小限制为什么那么重要？
A：参数高尔夫要求整个程序（包括模型权重）打包后不超过16兆字节。这个限制直接影响模型复杂度，每次提出新架构或添加新功能，都必须同时考虑是否会撑破这个体积上限。论文中有个典型案例：第587次实验找到了一个有效的技术改动，模型性能确实提升了，但文件超出上限2056字节被判无效。系统读到这个精确的超出量，专门做了压缩优化，最终在合规体积内复现了同样效果。
Q3：NanoChat-D12任务的CORE分数从0.1618提升到0.2244，这个38.7%的提升是怎么来的？
A：提升主要由三个叠加改动构成。第一步是系统专家发现训练代码中部分注意力层使用了低效的计算路径，替换为更快的Flash SDPA后节省了训练时间；第二步是把省下来的时间用于扩大训练数据量，数据预训练、中间训练和最终训练阶段的比例从原始值调整为约12:100:130；第三步是在模型输出层后添加了一个零初始化的可学习偏置向量。三步改动先后落地，CORE分数依次经过0.1695、0.2029、0.2241，最终稳定在0.2244。
热门跟贴