Karpathy 今年 3 月开源的 autoresearch，做了一个极简却有力的实验：把一份 5 分钟训练预算的 nanochat 单 GPU 实现交给 AI 代理，让它自主改代码、跑训练、看指标、提交或回滚，循环往复。一夜之间，~100 次实验跑下来，nanochat 达到 GPT-2 等效水平的耗时从 2.02 小时压缩到 1.80 小时------端到端提速 11%。本文将拆解这套设计背后的关键取舍，并深入探讨它与经典 AutoML / NAS 的本质区别。
一、autoresearch 的核心机制
autoresearch 仓库只有几个文件，刻意保持小到一眼看完：
prepare.py：数据准备和工具函数，代理不允许改。train.py：完整的 GPT 模型、优化器（Muon + AdamW）、训练循环------代理唯一可以修改的文件。program.md：给代理的"研究规程"提示词------人类负责迭代这个文件。
代理被要求在每轮做四件事：读 program.md 与 train.py，提出一项修改（必须给出理由），改完跑一次固定时长 5 分钟（墙钟时间，排除编译启动）的训练，用 val_bpb（validation bits per byte，词表大小无关，便于跨架构比较）打分；优于 baseline 就 commit，劣化就 discard，结果一律写入实验日志。
按 Karpathy 的描述，单台 H100 一晚能跑大约 100 个实验。在 3 月的第一轮过夜实验里，代理找到约 20 项有效改动，所有改动都是"加性"的，并且能迁移到更深的 depth=24 模型上。3 月 8--9 日那次更激进------35 个代理在 Hyperspace 网络上并行跑了 333 个实验，全程无人监督。
二、关键约束：固定时间预算 + 单一指标
这套设计最值得算法工程师琢磨的，是 Karpathy 在 README 里反复强调的"固定 5 分钟时间预算"。
传统 NAS 或超参搜索为了让对比公平，要么固定 FLOPs，要么固定 epoch 数。autoresearch 反其道而行之：你只能用 5 分钟，无论你改了 batch size、改了模型深度、还是引入了更快的 kernel。这条约束的副作用是非常有意思的：它把"训练效率"和"模型质量"压成同一个标量。代理无法靠"我把模型做小、再多跑几个 epoch"取巧，因为时间预算砍死了一切。同时它也无法靠"我做更大的模型、收敛更平稳"取巧，因为 5 分钟根本跑不完一次完整训练。
这其实是把研究问题重新表述为：在固定算力窗口内，最大化模型在 val 集上的信息密度。它非常接近大模型预训练里常说的 time-to-quality 指标，比传统 NAS 那种"先搜架构，再 retrain"要更贴近真实研发场景。
三、代理找到了什么？
按 Karpathy 在推特和分析文章里披露的细节，3 月那轮过夜实验里有几类典型发现：
第一类是实现 bug 级别的修复 。代理注意到 train.py 里一个"无参数的 QKnorm 没接缩放因子"------这种问题人类工程师在反复改代码的过程中常常视而不见，但代理只看代码不带感情，反而能挑出来。
第二类是正则化补漏。Value Embeddings 缺少应用的正则化项，代理把它补上后 val_bpb 稳定下降。
第三类是结构超参的微调。原 baseline 里"banded attention"（带状注意力）的窗口设得过于保守，代理把它放开后训练效率提升。
值得注意的是，这些发现没有一项是真正"新颖的架构创新"。Karpathy 自己也承认，autoresearch 当前更像是自动化的 ablation + debugging 工具，而不是真正的科研伙伴。但即便如此，11% 的端到端速度提升是实打实地落到了仓库主分支上。
四、与 AutoML / NAS 的关键不同
如果你是做 AutoML 或 NAS 出身，看完上面的描述可能会觉得似曾相识，但仔细看会发现 autoresearch 的几个本质区别。
第一，搜索空间是自然语言定义的。NAS 必须先设计一个搜索空间（操作符候选、连接方式等），代理无法越界。autoresearch 没有这个空间，代理改的是源码本身，理论上可以引入任意新模块、任意新优化器，只要它能写出可运行的 Python。
第二，没有 surrogate model，也没有 early stopping。每一次提议都要付出完整 5 分钟训练的代价。这看似低效，但因为整体预算很小（一台 H100、几个小时），它绕开了 NAS 那种"训练 surrogate 不准、调 surrogate 又是个新问题"的死循环。
第三，人类的角色变了 。在 NAS 里，人类设计搜索空间和奖励函数；在 autoresearch 里，人类迭代的是 program.md ------也就是代理的"研究方法论"。Karpathy 把它形容成一个极简的 skill 文件。你可以加新的检查项，比如"每次提议必须先在 1 分钟的微观跑里验证可行"，或者"每 N 次失败必须切换探索方向"。
这让 autoresearch 的范式更接近研究流程自动化，而不是单点的超参优化。
第四，评估指标是"端到端"的。NAS 通常用 proxy metric（小数据集上的 val acc）替代真实任务表现，再二次训练。autoresearch 的 val_bpb 就是真实训练在真实数据上的真实表现，没有 proxy 偏差。对应代价是探索空间小（受 5 分钟预算约束），但对于"调一个已有模型的实现细节"这种场景反而恰到好处。
五、它真的能"自我改进"吗？
要泼一盆冷水：autoresearch 的代理并不会"越用越聪明"，它每次实验都是冷启动地读 program.md。所谓的"进步"，体现在 train.py 这份代码本身被代理改得越来越好，并不是代理本身的能力提升。
要真正进入"自我改进"叙事，得叠加另外两层：
一是 Anthropic 在 5 月 6 日 Code w/ Claude 上发布的 Dreaming ------ Claude Managed Agents 的一项研究预览，会在会话之间复盘代理过往行为，提取共性、整理记忆，让下一次会话用更优策略起步。结合 autoresearch 这种"代理修改代码"的回路，理论上可以构成"代码 + 方法论"双层进化。
二是把 autoresearch 这条 5 分钟实验的链路替换成更接近真实研究的链路（更长时间、更复杂的指标、跨多个 repo），让代理不只是调一个文件，而是在一个 codebase 里做架构级改动。Karpathy 自己在仓库 README 里写下的那段"10,205 代"的科幻独白，正是在勾这个方向。
六、对算法工程师的实际启示
如果你不打算复现这套实验，autoresearch 仍然给出了几条值得借鉴的工程经验：
把"实验代价"压到极小、固定，是让代理有效迭代的关键前提。任何让 5 分钟变成 5 小时的优化都不值得做。
让代理修改的范围"单文件可见"，diff 容易 review，否则你天亮看日志的时候会哭。
代理找到的改进里有相当一部分是"修 bug + 补正则"，这暗示你自己工程里可能也存在大量"看了一万次都没看见"的细节，值得在自己仓库里跑一次类似的小型代理审计。
最后，把"研究的工程化"和"研究的智力化"分开看。autoresearch 自动化的是前者，后者目前仍是人类的优势区。但当 Mythos、Dreaming 这种基础组件越铺越多时，前者占研究时间的比重会迅速下降------而这才是真正值得 ML 工程师关注的趋势。