训练模型最消耗人的，不总是那一下灵感。

真正磨人的，是灵感后面的重复劳动：改一处结构，启动训练，等结果，核对指标，记下实验，再决定保留还是回退。一个想法只占几分钟，验证它却可能占掉半天。等人开始疲倦，实验记录也容易散，下一轮又要重新回忆上一轮为什么失败。

如果把问题缩小到一台机器、一个训练文件、一个固定指标，编码 Agent 恰好很适合接住这段循环。它不需要在每轮实验后睡觉，也不介意连续做几十次只带来零点几百分之一变化的尝试。

karpathy/autoresearch 做的就是这件事。

它不是一个已经替代研究团队的“AI 科学家”，也不是一套庞大的多 Agent 平台。它更像一间被刻意缩小的自动研究实验室：人写研究规则，Agent 只改一个训练文件，固定评测程序负责裁决，Git 和 TSV 留下每次试验的痕迹。

真正难的不是让 Agent 写代码，而是让它知道什么算进步

让编码 Agent 修改模型并不难。难的是下一步：它凭什么判断这次修改值得留下？

autoresearch 把答案压成一个明确目标：在固定的五分钟训练预算里，让验证集的 val_bpb 尽可能低。BPB 是 bits per byte，数值越低越好。它不依赖词表大小，Agent 即使调整模型结构或分词相关配置，也仍然有一把相对稳定的尺子。

这一步很关键。Agent 不再需要用“损失看起来还行”“模型似乎更复杂”这样的模糊判断来决定去留。每次实验结束后，它只要读取同一种指标，就能执行保留、丢弃或修复。

所以，这个仓库首先解决的不是“怎样让 AI 更有创造力”，而是“怎样把研究进展写成机器可以执行的判定条件”。一旦判定条件明确，连续实验才有可能自动发生。

仓库很小，因为它先把自由度关进笼子里

README 直接说，真正重要的只有三个文件。

prepare.py 是固定区。它负责下载数据、训练 BPE tokenizer、提供 dataloader 和评测函数，还把上下文长度、训练时间预算和验证规模写成常量。Agent 不允许修改它，因为数据、计时方式和裁判一旦跟着实验一起变化，前后结果就失去可比性。

train.py 是实验区。完整 GPT 模型、注意力、MLP、Muon + AdamW 优化器、学习率计划和训练循环都放在这一个文件里。架构、超参数、批大小、模型深度乃至训练逻辑都能改，但改动只能落在这里。

program.md 是控制区。它不是训练代码，而是一份写给 Agent 的工作制度：怎样建立实验分支，先读哪些文件，第一次为什么必须跑 baseline，什么能改、什么不能改，结果如何记录，指标变好后怎样继续，变差后怎样回退。

根目录还有 pyproject.toml、analysis.ipynb 和示例进度图，但它们都围绕这三个责任区服务。仓库没有配置迷宫，也没有复杂服务层。它先用边界把研究问题变小，再把 Agent 的自由度集中到真正需要试验的地方。

先看全景：人写研究组织，Agent 负责一轮轮

知识卡 1：自制知识卡。依据仓库 README、program.md 与结果记录格式绘制，展示一次自动研究实验怎样从规则进入代码，再由指标决定去留。

这条闭环里，人并没有完全退出。

人先在 program.md 里决定研究目标、允许修改的范围、复杂度偏好和停止权。Agent 接手以后，提出一个实验想法，修改 train.py，提交到专用 Git 分支，再运行训练。五分钟后，它读取 val_bpb 和显存占用，把结果写进 results.tsv。

指标更低，提交就成为新的起点；指标持平或变差，代码回到上一份保留状态；运行崩溃，则记录 crash，检查日志，能修就修，不能修就换方向。

这里没有神秘的“研究模式”。它只是把研究者熟悉的试错动作，整理成一条不会忘记验收、不会忘记留痕、也不会因为一次失败就停住的循环。

program.md 才是这个项目最有意思的“代码”

README 把 program.md 称为一份很轻的 skill。这个说法点出了 autoresearch 真正想让人继续改造的对象。

启动一次新实验时，Agent 先和人确认 run tag，从主分支创建 autoresearch/<tag> 分支，再读取 README、prepare.py 和 train.py。它要检查缓存中的数据分片和 tokenizer 是否已经准备好，还要创建只有表头的 results.tsv。正式循环开始前，人仍然拥有一次确认机会。

第一轮必须跑未经修改的 baseline。没有 baseline，后面的“提升”就没有参照点。接下来，Agent 可以改模型架构、优化器、超参数、批大小和训练循环，却不能安装新依赖，不能改 prepare.py，也不能动 evaluate_bpb 这把尺子。

program.md 还写进了一个容易被忽略的判断：数值更好，不等于一定值得保留。如果只提升极小一点，却增加二十行难看的特殊处理，未必划算；如果删掉代码还能得到相同或更好的结果，反而是更有价值的简化。

它甚至用大写写下 NEVER STOP，要求循环开始后不要每轮都回来问人要不要继续。这个指令表达的是工作制度，不是后台调度器。仓库本身没有守护进程、任务队列或多 Agent 控制面，能否长时间连续运行，仍然取决于承载它的编码 Agent 和会话环境。

单文件边界，让失败变得可以回滚

train.py 并不是一个玩具超参数表。当前文件里有完整的单 GPU GPT 训练实现：旋转位置编码、分组查询注意力、滑动窗口模式、值残差、MLP、Muon 与 AdamW 参数组、学习率与权重衰减计划、梯度累积、编译、评测和最终摘要都在里面。

这意味着 Agent 的搜索空间比传统网格搜索更宽。它不只是在几组学习率里挑一个数，还能换注意力窗口、改模型深度、调整优化器甚至重写训练过程。

但宽搜索空间没有扩散到整个仓库。每个想法落地前先做一次 Git 提交，训练输出全部重定向到 run.log，结束后只抽取 val_bpb 和 peak_vram_mb。如果关键字段没有出现，Agent 才去看最后几十行堆栈，判断是简单错误还是实验本身已经走不通。

results.tsv 只保留五列：提交哈希、val_bpb、显存、状态和实验描述。状态只有 keep、discard、crash。这个文件不提交进 Git；Git 负责保存代码演化，TSV 负责保存实验判断，两者拼在一起，才是一份能回看的研究轨迹。

五分钟不是性能承诺，而是一把统一尺子

prepare.py 把训练时间预算固定为 300 秒，启动和编译时间不算在内。无论 Agent 把模型改大还是改小，每个方案都只能在同样长的训练窗口里竞争。

这样做有一个直接好处：实验不再需要先争论“这个方案应该训练多久才公平”。同一台机器上，五分钟内谁能得到更低的 val_bpb，谁就更适合这套硬件和这份预算。吞吐量、模型规模、批大小和优化器效率，也会一起进入竞争。

README 据此估算，大约每小时可以跑十二轮，一晚能接近一百轮。这是基于五分钟节奏给出的工作量估计，不是所有设备上的性能保证。编译开销、评测时间、崩溃与修复都会拉长真实周期。

它的代价也写得很清楚：固定时间让同一平台上的方案更容易比较，却让不同硬件之间的结果不再直接可比。H100 上五分钟找到的最优结构，不等于另一块 GPU 上的最优结构。autoresearch 优化的是“这台机器在这段时间里能做到什么”，不是一个脱离算力环境的绝对排行榜。

val_bpb 把“看起来不错”换成了可执行裁决

评测函数放在禁止修改的 prepare.py 里。它把每个 token 的交叉熵按对应字节长度汇总，再从 nats 转成 bits per byte；特殊 token 不参与分母，验证时使用固定上下文长度和固定验证数据。

选择 BPB 的意义，是减少词表大小对指标的干扰。Agent 可以尝试不同模型设计，而裁判仍然围绕每个字节需要多少信息量来比较。指标越低，说明模型在这份验证集上用更少的 bit 表达数据。

显存只是软约束。为了有意义的 BPB 改进，显存略增可以接受；如果显存暴涨，收益却很小，就不算好研究。再加上 program.md 的简洁性规则，Agent 实际面对的是三个判断：分数有没有更好，资源代价是否合理，代码是否变得过于丑陋。

仓库附带的 progress.png 展示了一次示例轨迹：83 次实验里有 15 次改动被保留，其他尝试以灰点散在运行最佳线之上。analysis.ipynb 正是从 results.tsv 读取 keep、discard 和 crash，再画出这条阶梯式进展。研究在这里不是一条直线，而是一大片失败点托着少数有效改动往下走。

把责任拆开，Agent 才不会顺手改掉裁判

知识卡 2：自制知识卡。依据三个核心文件的职责绘制；人负责研究制度，Agent 负责候选方案，固定程序负责数据、计时与评测。

这张分工图解释了为什么仓库要反复强调“不要修改 prepare.py”。

控制面由人维护。program.md 决定目标、边界、复杂度偏好和循环纪律。变更面交给 Agent。train.py 承载每次实验的候选方案。裁判席保持固定。prepare.py 管住数据、时间和指标。

如果 Agent 既能改参赛方案，又能改计时器和评分函数，它很容易找到“分数更好”的捷径，却没有让模型真正变好。把三个责任区拆开，等于先把奖励作弊最明显的入口封住。

Git 与 results.tsv 则站在三者之外，负责记忆。一个保存代码状态，一个保存实验判断。即使夜间循环跑了几十次，早上仍能回答：试过什么，哪次变好，哪次爆显存，当前分支为什么长成这样。

它和 AutoML、超参数搜索差在哪

传统超参数搜索通常先由人定义搜索空间：学习率从几组数里选，模型深度在几个整数里试，调度器用 A 或 B。搜索器负责更高效地组合这些已知选项。

autoresearch 没有把搜索空间预先写成参数表。Agent 直接编辑 train.py，可以提出代码级变化，也可以把前几轮的经验组合成新方案。它搜索的不是一张固定表格，而是“仍然满足边界的程序变体”。

它和完整的多 Agent 研究平台也有距离。默认实现只有一个 Agent、一块 GPU、一个训练文件和一个指标。README 提到未来可以继续改 program.md，甚至增加更多 Agent，但当前仓库没有实现文献检索、实验排队、GPU 集群调度、同行评审或研究任务分派。

更准确的叫法，是一个研究 Agent 的最小协议。它证明开放式代码修改也能被固定预算、固定评测、版本控制和实验日志约束，而不只是让模型漫无目的地“继续优化”。

更适合这些用法

想研究“研究 Agent”时，它是一个很好的最小样本

如果关心的是 Agent 怎样接受长期任务、怎样处理失败、怎样在不惊动人的情况下继续、怎样避免修改评测标准，autoresearch 的代足够小，规则又足够完整。

它把许多抽象问题落成了可检查文件：提示与组织写在 program.md，候选变更写在 train.py，裁判写在 prepare.py，过程记忆落在 Git 和 TSV。想改进研究组织，不必先读一套庞大平台。

有一块专用 NVIDIA GPU，想把夜间算力换成实验密度

主线代码面向单块 NVIDIA GPU，README 标明测试设备是 H100。数据、依赖和 baseline 都稳定以后，这套循环适合在无人值守时持续积累小实验。

它尤其适合能接受大量失败的探索。83 次里只保留 15 次，并不说明系统低效；在这种工作方式里，快速证明某条路不值得走，本来就是产出的一部分。

想把同一模式迁移到别的可测问题

真正可迁移的不是这份 GPT 训练代码，而是四个条件：一个明确可改的对象、一段固定预算、一个不能被 Agent 修改的评测器，以及可以回滚的状态历史。

编译性能、检索质量、推理吞吐、压缩率或某类工程基准，都可能借鉴这套模式。难点不在复制循环，而在重新设计一把不会诱导 Agent 作弊、又真的代表任务价值的尺子。

它解决不了什么

autoresearch 不会自动完成完整的科学研究。

它没有文献综述，没有因果分析，没有实验论理，也没有同行评审。Agent 能找到让固定验证指标更低的代码，不等于它发现了可推广的理论，更不等于结果能越过不同数据、种子和硬件继续成立。

主仓库也不是跨平台训练框架。README 的要求是 Python 3.10+、uv 和单块 NVIDIA GPU，官方测试基线是 H100。macOS、Windows RTX 与 AMD 支持通过 README 列出的独立 fork 承担，不能把这些能力算进主线代码。

文本里的 NEVER STOP 也不能替代可靠的运行基础设施。如果 Agent 会话有时长限制、权限收紧、上下文耗尽或进程被回收，循环仍然会停。要把它变成生产级长期任务，还需要外层坚控、重启、资源配额和异常告警。

最重要的边界是指标。固定评测让自动裁决成为可能，也会把所有创造力压向同一个数字。研究者仍然要判断：val_bpb 的改善是不是来自真正有意义的设计，是否过拟合同一验证流程，增加的复杂度和显存是否值得。

最后看它的取舍

把开放式研究压成一个可修改对象、一段固定预算、一名不能被收买的裁判和一条可以回退的历史。

这句话几乎解释了 karpathy/autoresearch 的全部设计。

它只允许修改 train.py，因为自由度需要集中；把时间固定为五分钟，因为实验需要公平；锁住 prepare.py，因为裁判不能跟着选手变化；用 Git 提交和 results.tsv 记账，因为无人值守的研究必须能在第二天被人读懂。

这个仓库最有价值的产物，不一定是某个更低的 BPB，也不是一套现成的 AI 研究平台。它展示了一种很朴素的工程判断：让 Agent 长时间工作之前，先把“能改什么、什么算赢、失败怎么退、过程怎么留痕”写清楚。自动研究真正开始的地方，不是 Agent 第一次改代码，而是人把这四件事定义得足够严格。