Karpathy 新项目 autoresearch：把“调模型做实验”交给 AI，睡一觉醒来它自己在跑研究

项目卡片

• 项目：karpathy/autoresearch
• 仓库：https://github.com/karpathy/autoresearch^[1]
• 一句话：把 AI 自动研究压缩成一个能在单卡 GPU 上持续迭代实验的最小闭环。

Karpathy 又放出了一个很容易引发转发的新仓库：autoresearch。

这个项目最抓人的地方，不是“又一个训练框架”，而是它把一个很大的命题做得非常小：如果给 AI 一个真实但足够轻量的模型训练环境，它能不能像研究员一样，自己提出改动、自己动手实验、自己根据结果继续迭代？

autoresearch 给出的答案是：可以先别谈 AGI，先把“自动化做小规模研究”这件事跑通。

autoresearch 最有价值的地方，不是一个单点能力，而是把改代码、跑实验、看结果、继续迭代串成了闭环。

它到底是什么？

它的基本思路非常直接。你准备一个单卡可运行的 LLM 训练项目，AI agent 不需要接管整个复杂工程，也不需要碰一堆分布式系统，只围绕一个核心训练文件反复做实验：修改代码，训练 5 分钟，检查指标有没有变好，变好就保留，没变好就丢弃，然后继续下一轮。

你睡觉的时候，它就在那儿一轮轮试。第二天醒来，看到的是实验日志、代码 diff，以及某些确实带来收益的改动。

所以，autoresearch 不是一个“帮你聊天写提示词”的工具，而是一个把“研究迭代”流程化、自动化的最小研究组织原型。它更像是在回答一个问题：未来的模型研究，是不是可以先从“人写代码”变成“人写研究规则，AI 按规则跑实验”？

为什么它会火？

当然，Karpathy 本人自带传播力，这是第一层。

但更关键的是，这个仓库把“AI 做研究”从口号拉回到了工程现实。过去很多相关讨论都停留在概念层，比如“让 agent 自动发现更优架构”“让 AI 成为研究员”。而 autoresearch 没有把问题做大，反而故意做小：单卡 GPU、固定 5 分钟预算、单文件修改、单一指标比较。

正因为约束足够强，它才第一次显得真的可执行。

第二个原因是，它提供的是闭环，而不是 demo。很多 AI 项目展示的是某一步很聪明，比如会提方案、会改代码、会分析日志。但研究真正难的不是某一步，而是“连续几十轮以后还能不能稳定推进”。autoresearch 的价值就在于，它把提出想法、实施改动、跑实验、读结果、做保留决策这几件事串成了闭环。

很多项目只展示“会不会改”，autoresearch 展示的是“能不能持续做几十轮实验”。

第三个原因，是它重新定义了“研究代码”的入口。

这个仓库里最有意思的一点，是人类不再主要直接改 Python，而是主要去写 program.md。也就是说，你不一定是在手改模型结构，而是在写一份给 agent 的“研究操作手册”：目标是什么、允许改哪里、怎么判断好坏、每轮实验怎么记录、下一轮如何推进。

这个变化很关键。它意味着未来研究者的工作，可能会越来越像“设计研究规则”和“编排 agent 行为”，而不是亲自下场调每一个超参数。

它的核心机制，为什么值得认真看？

从仓库结构上看，autoresearch 其实非常克制。真正重要的文件就几个。

prepare.py 基本不动，负责常量、一次性数据准备、训练 tokenizer，以及一些运行时工具。
train.py 是 agent 主要动手的地方，模型、优化器和训练循环都在里面，架构、超参数、batch size 等改动都围绕它展开。
program.md 则是整套自动研究流程的起点，相当于给 agent 的任务说明书和行为边界。人主要迭代这个文件，AI 主要迭代 train.py。

这个分工设计得很聪明。因为如果把整个仓库都开放给 agent，复杂度会迅速失控，代码 diff 会越来越难审，实验结论也会变得模糊。现在它只让 AI 主要改一个训练文件，研究范围被压缩得足够清晰：你知道它改了什么，也比较容易判断这次收益到底来自哪里。

另一个很巧的设计，是固定时间预算。每轮训练不是固定 step，也不是固定 token，而是固定 5 分钟墙钟时间。

这样做有两个好处：

• 实验之间更容易比较。无论 agent 这次把模型改大了、batch 改了、优化器换了，大家都在同样的 5 分钟窗口里竞争。
• 它天然适合“过夜跑”。按这个节奏，1 小时能做十几轮，一晚上很容易积累出一百轮左右的实验。

它使用的指标也很务实：val_bpb，也就是 validation bits per byte，越低越好。这个指标的好处是相对独立于词表大小，做架构调整时还能维持一定可比性。对于一个想让 agent 自主探索的系统来说，这类“可机器比较”的统一指标非常重要。

autoresearch 最关键的变化，不是 AI 会改 train.py，而是人开始把研究意图写进 program.md。

适合谁？不适合谁？

如果你是想理解“AI agent 到底怎样介入模型研发流程”的人，这个仓库非常值得读。它比很多泛泛而谈的 agent 框架更具体，因为它直接把目标落在了训练代码和实验循环上。

如果你本身在做模型训练、自动调参、研究平台或者 agent workflow，也很适合拿它当原型看。它未必是生产方案，但它把最小闭环搭得很漂亮。

但如果你是想找一个“零门槛跑起来的 AI 工具”，那它不太适合你。这个项目对环境要求比较明确：单张 NVIDIA GPU，作者测试环境是 H100；Python 3.10+；依赖用 uv 管理。它更像一个面向有训练环境的人群的实验仓库，而不是给纯 CPU 用户准备的普适工具。

普通人怎么上手？

如果你只是想理解这个项目，最好的方式不是立刻把它跑满，而是先看清它的最小闭环：

• 先装依赖
• 跑 prepare.py 做一次性数据准备和 tokenizer 训练
• 手动执行一次 train.py
• 确认整个训练链路没问题后，再把 agent 接进来
• 让它按 program.md 里定义的规则开始自动实验

真正的门槛，不在安装，而在你怎么写 program.md。

因为这份文件决定了 agent 像不像一个靠谱研究员。如果你写得太空，AI 可能只会做一些表面优化；如果你把实验记录、成功标准、尝试范围、回滚策略写得清楚，它的表现通常会稳定很多。

这也是 autoresearch 最值得关注的地方：它表面上是在研究模型，实际上也在研究另一件事——什么样的“研究组织提示词”，能让 AI 更有效地产生真实进展。

它最打动人的，不是“会不会自动研究”，而是这件事第一次看起来真的能过夜跑起来。

最后一句话：它不是玩具，而是一个方向信号

这个仓库的野心不在于今天就自动发论文，而在于它给出了一个很强的方向感：未来研究自动化未必先从超级复杂的大系统开始，而是先从一个可验证、可复现、可比较的最小实验单元开始。

把这个单元跑顺，再不断复制、扩展、分工，才有可能慢慢长成真正的 AI research org。

所以，如果你把 autoresearch 当成“一个有趣的新玩具”，那你只看到了表层。它真正有价值的地方在于：它让“AI 自主做研究”第一次不是一句抽象口号，而是一套你今天就能看懂、甚至在合适硬件上跑起来的工程原型。

它未必马上改变研究范式，但很可能会改变大家思考研究范式的方式。

如果这篇对你有用，建议点个关注。我会持续把 GitHub 上值得用的 AI 工具拆成「最短上手闭环 + 坑点清单 + 可复用配置」，让你少走弯路。

关注微信公众号

想第一时间看到后续的工具拆解与实战更新，欢迎扫码关注公众号。

引用链接