凌晨三点,你的显卡还在跑第 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。

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