睡一觉=100次实验：Karpathy开源autoresearch，AI研究正在无人化

凌晨三点，你的显卡还在跑第 37 个实验。早上七点，它已经自己回滚了 29 次失败的改动，只留下 8 个让模型变好的提交。

这不是科幻设定，是 Karpathy 今年 3 月开源的 autoresearch 的默认工作方式。

前 30 秒：它到底是什么

一句话：给 AI Agent 一个真实但很小的 LLM 训练环境，让它整晚自己改代码、训练、看指标、保留或回滚。

数字先摆出来（截至 2026 年 10 月 21 日）：98.2k Star、13.6k Fork、MIT 协议，整个仓库只有36 次提交，作者只维护了三个核心文件。

它解决的不是"模型不够好"，是人的循环成本

做一次训练实验，真实流程是这样的：改一行代码，启动训练，等结果，看指标，不行就回滚，再想下一个点子。

单次可能只要五分钟，但人的损耗远不止五分钟——你要记住上一版改了什么，要在十个念头里挑一个执行，要在结果出来时判断"这是噪声还是真提升"。

一天能认真跑完的实验，多数人不到二十个。

autoresearch 的做法很直接：把这个循环交给 Agent，人只负责写"研究组织"的规则。它一晚能跑约100 次实验。

特点一：三个文件，三种角色，边界焊死

这个项目的精髓不在模型代码，在分工。

文件

谁来改

作用

关键约束

prepare.py

谁都不能改

数据、分词器、dataloader、评测函数

只读，裁判不能下场

train.py

只有 Agent 改

完整 GPT 模型 + 优化器 + 训练循环

唯一实验场，diff 可审

program.md

只有人改

研究策略：怎么选题、记录、回滚、放弃

本质是一份超轻量 skill

注意最后一行：人不再写 Python，改写 Markdown。

README 里写得很清楚：默认的 program.md 只是裸基线，怎么加 Agent、怎么设计研究组织，让使用者自己去迭代。

这句话的分量比它看起来重——它把"研究流程"本身变成了可版本化、可传承、可被 Agent 执行的代码。

特点二：固定 5 分钟，把"实验"变成可比的单位

每次训练都严格跑 5 分钟墙钟时间，不含启动和编译。

这个约束解决了一个老问题：模型变大、batch 变大、架构变复杂之后，实验之间根本没法比。

固定预算之后，所有改动都落在同一个标尺上。指标用val_bpb（验证集 bits per byte），越低越好，而且与词表大小无关——换分词器、改架构也能公平比较。

代价也很明确：跨平台结果不可比。它找的不是"全世界最好的模型"，而是"你这张卡、这个预算下的最优解"。

顺带一提，5 分钟意味着大约12 次/小时。这就是"睡一觉 100 次实验"的算术来源，不是营销话术。

特点三：记忆不放在上下文里，放在磁盘上

这是我认为最值得抄的一点。

Agent 每一轮要做的事：改 train.py → git commit → 跑训练 → 从日志里 grep 出 val_bpb → 变好就留在分支上，变差就 reset 回上一版。

三个设计细节：

1. git 分支就是实验谱系。好改动逐层叠加，坏改动直接回退，不需要 Agent"记得"自己做过什么。
2. results.tsv 是实验台账，五列：commit、val_bpb、显存 GB、状态（keep/discard/crash）、一句话描述。这个文件刻意不提交进 git。
3. 日志全部重定向到 run.log，Agent 只读关键两行。不让几千行训练输出淹掉上下文。

崩溃处理也写进了流程：grep 不到指标就说明挂了，读栈修；小 bug 修完重跑，思路本身错了就记 crash 继续下一个。单次超过 10 分钟直接判失败回滚。

特点四：一条"永不停止"的条款

program.md 里有一段几乎是命令式的规则：实验循环开始后，不许问人类"要不要继续"，不许找"合适的停止点"。

没思路了怎么办？去读代码里引用的论文，重读在范围内的文件找新角度，组合之前差一点的方案，或者试更激进的架构改动。

很多人把这句当成打鸡血。我觉得它是在设计系统边界：如果 Agent 每隔几轮就回来问一句，人类睡觉这件事就不成立，整个模式也就失效了。

几个得先说清楚的坑

1. 硬件门槛是真的。官方要求单张 NVIDIA GPU，实测在 H100 上。Mac、Windows、AMD 都有 fork，但要大幅降配：换 TinyStories 这种低熵数据集、把词表从 8192 降到 4096 甚至字节级、MAX_SEQ_LEN 砍到 256、DEPTH 从 8 降到 4、窗口模式只用 L、TOTAL_BATCH_SIZE 降到 2 的 14 次方。
2. 100 次实验不等于 100 个好想法。这是典型的局部搜索：它在现有代码附近试探，跳不出"评测器定义的这座山"。program.md 写得平庸，Agent 就只能在平庸的区域里打转。
3. 裁判固定是双刃剑。防作弊很有效，但你也失去了"改进评测方式"的自由。想换指标，得改 prepare.py——那就等于换了一场比赛。
4. Star 数高不代表你能直接复现。98.2k Star 说明的是共识和关注度，不是"随便一台笔记本就能跑"。

我看完三个文件后最大的感受：这个项目最激进的地方，不是让 AI 写训练代码——那件事很多人已经在做。

它把研究的最小可编程单位从 Python 换成了自然语言写的研究组织。

以前你优化的是模型；现在你优化的是"怎么让 Agent 更快地找到更好的模型"。

这个转向可以迁移到任何有明确自动指标的优化问题上，只需要四件套：

1. 一个不可动的评测裁判
2. 一个固定的资源预算
3. 一个受控的改动范围（单文件最理想）
4. 一套外置的状态记录（git + 台账）

附：这套系统的关键数字

数据来源：GitHub 仓库页（2026-10-21 抓取）、README、program.md、train.py 源码。默认配置跑出的基线示例为 val_bpb 0.9979、约 50.3M 参数、953 步、峰值显存约 44GB。

如果给你一张卡跑一整夜，你会让它优化什么？是自己的小模型，还是某个一直没时间调的工程参数？评论区说说你的"过夜实验"。