你睡前改一版训练代码，等五分钟，看结果，再决定保留还是撤回。然后继续改下一版。真正耗人的往往不是某一次实验，而是这个循环要重复几十次。AutoResearch 想做的，就是把这份夜班交给 AI Agent：它自己改代码、启动训练、读取成绩，再决定下一步。
这套系统面向算力有限的个人研究者。它只要求一张 NVIDIA GPU，而不是一整组机器。不过，“一张卡”不等于普通显卡都能跑出相同速度。项目作者 Karpathy 只明确写了在 H100 上测试过。本文全部关键事实也都来自项目官方仓库，尚无独立实验交叉验证。
它把研究做成了一个循环
AutoResearch 给 Agent 的不是一个玩具任务，而是一套小型但完整的大语言模型训练环境。所谓“实验闭环”，就是提出改动、运行实验、检查结果，再根据结果继续调整。以前，这些步骤通常由研究者反复手动完成；现在，Agent 接手了中间的大部分操作。
具体流程很直白：Agent 修改训练代码，训练五分钟，查看指标有没有改善。有效就保留，无效就丢弃，然后进入下一轮。Karpathy 描述的理想场景是，系统整夜无人值守地反复尝试，第二天留下实验日志，以及一个“希望会更好”的模型。这里的“更好”是项目愿景，不是已经得到充分证明的结论。
项目刻意只保留几个核心文件。prepare.py 负责下载数据、训练 BPE tokenizer——也就是把文本切成模型能处理的符号单元——以及提供数据读取和评估工具，Agent 不修改它。train.py 是 Agent 的主要工作区，里面放着完整的 GPT 模型、训练循环，以及 Muon 和 AdamW 优化器；优化器可以简单理解为训练时调整模型参数的规则。模型结构、超参数、批量大小和优化方式都可以改。
人类主要编辑的是 program.md。这是写给 Agent 的任务说明和上下文，也可以看成一份很轻量的“研究组织章程”。换句话说，人不再逐行修改实验代码，而是通过改写规则，告诉 Agent 应该怎样开展研究。
五分钟不是随便定的
每次训练都有固定五分钟的 wall-clock 预算，也就是按现实时间计时，不包含启动和编译。这样一来，不管 Agent 把模型改大、改小，或更换训练设置，每轮都在同一台机器上花相同时间。仓库据此估算，每小时大约能跑 12 次，睡一夜约 100 次。
这个设计比较的不是“谁在相同训练量下最好”，而是“谁能在这台机器的五分钟里做到最好”。它更贴近个人研究者的现实约束：算力已经固定，重点是怎样把有限时间用得更有效。
评价指标叫 val_bpb，全称 validation bits per byte，可以理解为模型在未参与训练的文本上表示每个字节需要多少信息。数值越低越好。项目方称，这个指标不受词表大小影响，因此更适合比较不同架构。不过，这仍是仓库作者的方法论表述，目前材料没有提供外部验证。
真正有意思的是工作方式
AutoResearch 的训练代码来自 nanochat 的简化单 GPU 实现。它没有分布式训练，也没有复杂配置，只留下“一张 GPU、一个可修改文件、一个指标”。限制范围的好处是，Agent 不容易把实验改成难以追踪的工程项目，人也更容易检查每次代码差异。
更重要的变化发生在人与工具的分工上。研究者过去直接操纵每次实验；在这里，人主要设计目标、约束和工作规则，Agent 负责密集试错。个人研究者未必因此拥有更多算力，但可以减少守着训练任务反复操作的时间。这也是它值得关注的地方：Agent 不只帮人写一段代码，而是开始承担一个有反馈、有取舍、能连续运行的工作流程。
安装方面，项目要求 Python 3.10+、uv 项目管理工具和一张 NVIDIA GPU。首次下载数据并训练 tokenizer 约需两分钟，手动跑一次实验约五分钟。作者也提到其他平台原则上可以支持，但当前主仓库没有提供 CPU、MPS 等通用设备支持。
局限与未知
- 仓库没有给出成功率、实际完成的实验次数、
val_bpb改善幅度，也没有与人工研究者做对照，因此不能据此判断 Agent 的研究质量。 - 五分钟只保证同一平台上的时间预算一致。不同 GPU 的吞吐量不同，各台机器跑出的结果不能直接横向比较。
- “一夜得到更好的模型”在原文中带有
hopefully。它描述的是期待，并非稳定复现的结果。