2026 年 3 月 7 日，[[Andrej Karpathy]] 在 X 上发了一条推文，宣布开源一个叫做 AutoResearch 的项目。帖子的热度出乎很多人的意料——发布几天内 GitHub 累积了 21,000 个星标，原始推文的浏览量达到了 860 万。两周后，《财富》杂志专门写了一篇文章，把这套方法命名为「The Karpathy Loop」，认为它代表了 AI 研究方式的一次范式转变。
我自己看完这个项目之后第一反应是：这个想法太简洁了，简洁到让人觉得「为什么之前没有人这么做」。它的核心思路用一句话就能说清楚：把一个 AI Agent 放进你的机器学习训练代码里，让它自己做实验，你去睡觉，早上看结果。
问题从哪里来
做机器学习实验有一个让所有人头疼的地方：大量时间花在了低价值的重复操作上。你想试试换一种学习率调度策略，需要改代码、跑训练、等结果、记录下来、再改、再跑。这个循环本身并不需要太多智识——更多是时间和精力的消耗。每次实验需要人守着，一天下来跑个五六次已经算高效了。
Karpathy 的观察是：AI Agent 做这件事比人更合适。Agent 不需要休息，不会因为等待而分心，能严格执行预设的评估标准，而且它提出的假设有时候会走一些人类不会主动去想的方向。如果给它一套规范的实验环境和明确的优化目标，它可以每小时跑 12 次实验，一夜下来跑 100 次，全部自动完成，你只需要第二天早上看 git 日志里留下了哪些改动。
三文件架构
AutoResearch 的整个设计非常克制，项目核心只有三个文件，各自有明确的职责边界。
prepare.py 是不可修改的地基。它负责数据准备（下载训练数据、训练 tokenizer）和运行时工具函数，同时也是最终的评估器，负责计算 val_bpb（验证集每字节比特数）这个核心指标。Agent 不能碰这个文件——这保证了评估标准始终一致，不同实验的结果可以直接比较。
train.py 是 Agent 唯一被允许修改的文件。它包含 GPT 模型定义、优化器逻辑和训练循环，以及所有可以被调整的超参数、架构选择、批大小等变量。Agent 在这里提出改动、测试，如果有改善就保留，否则回滚。
program.md 是人写给 Agent 的指令文档。它描述研究方向、哪些类型的改动值得尝试、哪些规则必须遵守（比如「不能修改模型的对外接口」、「不要尝试 X」）。这是人类唯一真正需要持续维护的文件——你通过改写 program.md 来引导 Agent 的探索方向。
这三个文件的分工直接体现了 Karpathy 的设计哲学：人定方向，Agent 执行。两者的边界通过文件权限来强制——不是靠约定，是靠结构。
实验循环
每次实验的流程是固定的：Agent 读取当前的 train.py 和 program.md，形成一个改进假设，对 train.py 做出修改，启动训练，固定跑满 5 分钟。5 分钟到了，用 prepare.py 里的评估逻辑计算 val_bpb，和当前最优基线对比。
如果改善了，执行 git commit，这个改动成为新的基线。如果没有改善，执行 git reset，回到上一个状态，像什么都没发生过一样。然后进入下一轮循环。
固定 5 分钟的时间预算这个设定看似随意，实际上是深思熟虑的结果。它让每次实验的计算成本可控，在不同硬件上都能保证大致相同的实验频率，同时避免某个「看起来有潜力」的方向消耗过多资源。每小时约 12 次实验、一夜约 100 次——规模足够让有意义的改进浮现出来，成本又足够低到可以接受。
所有保留下来的改动都在 git 历史里，每一次 commit 都带着 val_bpb 数值。这意味着整个研究过程天然就是可复现的——你不需要额外的实验记录系统，git log 就是实验日志。
真实案例：两天发现 20 个优化点
Karpathy 自己用 AutoResearch 跑了一个两天的实验，让 Agent 在一个 depth=12 的模型上自由探索。结果跑了大约 700 次实验，找到了 20 个真实有效的改进。他把这些改进叠加起来应用到 depth=24 的更大模型上，所有改动都是累加有效的，而且迁移性良好。
更值得一提的是，Agent 在这个过程中发现了原始 attention 实现里一个人类开发者漏掉了好几个月的 bug。一个自动化的实验循环找到了手动代码审查没有发现的问题——这是任何人都很难提前预期到的收获。
Shopify CEO Tobi Lütke 把这个思路应用到了他们自己的 Liquid 模板引擎（Shopify 每个店铺的页面都通过它渲染）上，一晚上跑了 93 个实验。结果是渲染速度提升了 53%，内存分配减少了 61%。其中最关键的一个改动是把 StringScanner 替换成 String#byteindex，单这一处改动就贡献了 40% 的速度提升——一个 Agent 靠穷举式实验发现的改动，远超他们工程师的预期。
这不只是机器学习的事
Karpathy 在介绍这个项目时说了一句话，我觉得比项目本身更值得记下来：
“All LLM frontier labs will do this. It’s the final boss battle.”
他认为所有顶级 AI 实验室最终都会走到这一步——用 AI 来加速 AI 的研究本身。这不是比喻，是一个关于竞争优势来源的判断：谁能更快速地迭代实验，谁就能更快找到更好的模型架构和训练方法。
他对未来方向的预期也很清楚：「下一步是让 AutoResearch 能够异步大规模协作——像 SETI@home 那样，不是模拟一个博士生做实验，而是模拟一整个研究社区。」分布式的 Agent 群，在不同机器上同时探索不同方向，结果汇总到一个共享的知识库——这个愿景比「一夜跑 100 个实验」还要激进得多。
AutoResearch 的底层哲学和他稍后发布的 LLM Wiki 是同一套逻辑：人负责策展和方向，AI 负责执行和维护。LLM Wiki 里，人选择放进 /raw 的原始资料，AI 维护 /wiki 里的知识积累；AutoResearch 里，人写 program.md 定义研究规则，AI 修改 train.py 做实验迭代。两者都是对「人做什么、AI 做什么」这个问题的同一种回答。
怎么用
Karpathy 在介绍时特别说了一句：「你不是’直接使用’它，它更像是一个配方和思路——把它交给你的 Agent，应用到你关心的问题上。」
这句话很重要。AutoResearch 不是一个开箱即用的产品，它是一套可以被移植的模式。如果你手上有任何可以用代码定义的优化问题——不一定是 LLM 训练，可以是数据库查询优化、算法参数调整、甚至是某种业务规则的 A/B 测试——都可以尝试用同样的三文件结构 + Agent 循环来处理。
具体到机器学习，项目已经适配了 Apple Silicon（MLX 版本），不需要 CUDA。单 GPU 可以跑，M 系列 Mac 也可以跑。仓库地址是 github.com/karpathy/autoresearch，630 行 Python，代码量小到可以完整读一遍。
目前社区里已经有了对各种方向的扩展：有人做了更通用的「任意代码优化」版本，有人把它用在科学计算上，还有人在用 Agent swarm（多 Agent 并行）来对同一个问题同时探索不同方向。[[Awesome AutoResearch]] 这个 GitHub 仓库收集了社区的各种应用案例和优化记录，可以作为参考。
最后
AutoResearch 让我想起了编译器优化的发展历史。在很长一段时间里，手写汇编的程序员认为编译器生成的代码不可能比自己写的好。后来事实证明，在大多数情况下，编译器反而更好——不是因为编译器更聪明，而是因为它可以系统性地穷举人类不会有耐心尝试的每一种优化组合。
AutoResearch 做的事情，某种程度上是把这个逻辑延伸到了算法层面。不是说 Agent 比研究员更聪明，而是它可以不知疲倦地把研究员想到的每个方向都跑一遍，把研究员没想到的方向也顺便跑几遍。
在速度本身成为竞争优势的领域，能跑 100 次实验的人和只能跑 5 次实验的人，最终看到的世界会很不一样。