转载请注明出处：莫潇羽 @ 无忆研习社
快速摘要
本文核心结论：
AutoResearch 是由前特斯拉 AI 负责人、OpenAI 联合创始人 Andrej Karpathy 于 2026 年 3 月发布的开源项目（GitHub 地址：https://github.com/karpathy/autoresearch），整个项目只有 630 行 Python 代码，却实现了 AI 智能体对大语言模型训练代码的全自主迭代优化。其核心机制是：人类负责用 Markdown 文件写高层研究指令，AI 智能体负责修改训练脚本、跑实验、评估结果、决策保留或回滚——整个闭环完全无需人工干预，每晚可运行约 100 次独立实验。项目发布一周内便斩获超过 37,000 个 GitHub Star，成为 GitHub 历史上增长最快的开源项目之一。
关键数字：每小时约 12 次实验、每晚约 100 次、Karpathy 本人用它在两天内完成约 700 次自主变更，最终将模型效率提升约 11%。
往下看，有更详细的原理拆解、架构分析和完整的上手操作指南。
一、这件事为什么值得认真对待
2026 年 3 月初，AI 圈发生了一件看起来不起眼、但回头看可能意义深远的事情。Andrej Karpathy 在 GitHub 上悄悄推送了一个叫做 AutoResearch 的项目。没有发布会，没有论文，就是一个压缩包，里面只有 3 个核心文件、总计不超过 630 行 Python 代码。
但就是这个小小的仓库，在一周之内收获了超过 37,000 个 Star，Forks 数量突破 5,000，成为 GitHub 有史以来增速最快的开源项目之一。不是因为它炫酷，而是因为它说清楚了一件事：AI 已经可以自己做机器学习实验了。
所谓"自己做实验"，不是在说一个比喻。AutoResearch 的意思是：你给 AI 智能体一套真实的大语言模型训练环境，它会自己读代码、自己提出假设、自己改代码、自己跑训练、自己看结果，然后决定这次改动是否值得保留。这个循环，在你睡觉的八小时里，可以自动跑上接近 100 轮。
Karpathy 在项目 README 开头写了一段带有浓烈科幻味道的文字，值得在这里细细品味：
"曾几何时，前沿 AI 研究还是由'肉体计算机'来完成的——他们在吃饭、睡觉、娱乐的间隙思考，偶尔用声波互联网（也就是'组会'）来同步进展。那个时代已经一去不复返。研究现在完全属于自主 AI 智能体集群的领域，它们在云端的计算巨构上奔跑。智能体们声称我们现在已经处于代码库的第 10,205 代，但究竟对不对，没有人能说清楚，因为'代码'现在已经是一个超出人类理解的自修改二进制体。这个仓库，就是一切开始的故事。"
—— @karpathy，2026 年 3 月
这段话写得像科幻小说，但背后的逻辑是清醒的工程判断：人类研究员做实验的瓶颈在于时间有限、注意力有限；如果能把"修改→训练→评估→迭代"这个闭环交给 AI 去做，研究速度可以提升几个数量级。AutoResearch 就是对这个判断的第一个极简实现。
作为长期跟踪 AI 工具链的莫潇羽，我认为这个项目的意义不仅仅在于它本身，更在于它定义了一种新的范式：人类不再是实验的执行者，而是实验规则的设计者。这一点，后面会详细展开。
二、Andrej Karpathy 是谁？为什么他的项目值得关注
如果你对 AI 圈不算特别熟悉，有必要先了解一下这个名字背后的分量。
Andrej Karpathy 是斯坦福大学计算机科学博士，师从李飞飞，研究深度学习在计算机视觉中的应用。2015 年，他成为 OpenAI 的联合创始成员，是这家公司最早期的核心研究员之一。2017 年，他加入特斯拉，担任 AI 及 Autopilot 视觉部门负责人，主导了特斯拉自动驾驶系统中神经网络感知模块的研发。2022 年，他离开特斯拉，重回技术写作和开源社区。
在开源社区，Karpathy 以极致的简洁风格著称。他创作的 nanoGPT 项目用几百行代码还原了 GPT 的核心训练逻辑，成为全球最流行的 Transformer 入门项目之一。他在 YouTube 上发布的神经网络系列教程，被全球数百万学习者当作入门圣典。他还是"氛围编程（vibe coding）"这个词的提出者，描述了用自然语言和 AI 协作写代码的新工作方式。
nanoGPT 和 AutoResearch 之间有一条清晰的演化脉络值得梳理。nanoGPT 的定位是"让人类能够以最小的代码量理解 GPT 的工作原理"，它是一个教学工具，帮助人类学习。nanochat 在 nanoGPT 的基础上进一步精炼，专注于单 GPU 的高效训练实践。AutoResearch 则更进一步：它不再是为了让人类学习，而是为了让 AI 智能体能够在这个精炼的环境里自主工作。三个项目，代表了从"人类理解 AI"到"AI 替人类工作"的三个层次。这条演化路径，在某种意义上，也是整个 AI 工程领域正在经历的宏观趋势的一个缩影。
AutoResearch 脱胎于他此前的项目 nanochat——一个极简的单 GPU LLM 训练框架。AutoResearch 的本质是把 nanochat 的训练核心提取出来，加上一个 AI 智能体的控制循环，让整套系统能够自主运转。
理解了这个背景，就能理解为什么这个项目虽然只有 630 行代码，却让整个 AI 社区如此兴奋。这不是一个实习生的 demo，而是一个深度参与过 OpenAI 和特斯拉 AI 工程的人，用最精炼的方式表达了他对 AI 研究未来走向的判断。
三、AutoResearch 解决了什么问题
要理解这个项目，需要先理解它在解决一个什么样的真实痛点。
做机器学习研究，本质上是一个反复试错的过程。研究员的日常工作大致是这样的：有一个训练脚本，跑一次训练，看看验证集上的损失降了多少，然后根据经验调整某个超参数或者某个模块的结构，再跑一次，再看结果，如此循环往复。
这个过程中，真正需要智力投入的部分——提出假设、设计实验——其实只占很小一部分时间。大量时间被消耗在等待训练完成、解析输出日志、手动记录结果、复制粘贴代码修改这些机械性的操作上。更关键的是，人类研究员每天醒着的时间有限，一天能跑多少轮实验，取决于你愿意熬多少夜。
Karpathy 自己在项目描述中说得很清楚：这个项目的动机来自他亲身经历的痛苦——预训练小型 Transformer 语言模型时，他要花大量时间在手动循环上：修改超参数或架构选择，跑一段时间，读验证指标，决定这次改动是否值得保留，然后继续。
AutoResearch 的目标就是把这个整个循环自动化。不是部分自动化，而是把"修改代码→跑训练→看结果→决策保留/回滚"这个完整闭环，全权交给 AI 智能体来执行。人类只需要在一个 Markdown 文件里写清楚研究目标，剩下的，就让 AI 去搞。
结果是什么？你可以在睡觉的时候让 AI 完成 80 到 100 次实验，覆盖一个在手动模式下需要人类研究员花好几个星期才能探索完的配置空间范围。
Karpathy 本人用这套系统在两天时间里让 AI 独立完成了约 700 次自主修改，发现了大约 20 项有效改进，将模型训练效率提升了约 11%。更有意思的是，他说 AI 智能体发现了他在注意力缩放和正则化方面长达二十年手动研究中遗漏的问题——这是一个让这位深度学习领域的顶级专家也感到震撼的结果。
从更宏观的视角来看，机器学习领域在过去十年里其实一直处于一种"人力密集型"的运转模式。顶级实验室的研究员每天的核心工作就是调参、跑实验、分析 loss 曲线，大量时间和精力投入在这些重复性的操作上。学术界甚至有一个半玩笑的说法，叫做"gradient descent on graduate students"——指的是通过大量消耗研究生的时间和精力，来推动机器学习的进步。这个说法虽然有些夸张，但也道出了一个事实：现有的研究流程，在实验执行层面，对人力的依赖过于严重。
AutoResearch 的出现，代表了一种对这种模式的直接挑战。它不是要替代研究员的创造性思维，而是要把研究员从重复性的实验操作中解放出来，让他们把时间和精力集中在更高层次的问题上——提出真正有价值的研究方向，设计更精妙的评估体系，解读实验结果背后更深层的规律。这种分工，才是 Karpathy 认为未来 AI 研究应有的形态。
回头看整个项目的发展历程，有一个细节非常耐人寻味：Karpathy 在发布 AutoResearch 时，把它描述为"一个让你在周末玩一玩的小项目"。但社区的反应完全超出了这个定位——不到两周，它就成了 GitHub 有记录以来增长最快的开源仓库之一。这种反差，恰恰说明了一件事：大量的开发者和研究员，早就在等待一个足够清晰的框架，来把心中对"AI 自主做实验"的模糊想象，变成可以亲手运行的现实。AutoResearch 做到了这件事，尽管它只有 630 行代码。
对于个人开发者和独立研究者而言，这套工具的意义同样重大。以前，密集的超参数搜索是大机构的专属领地，因为只有他们才有足够的人力和计算资源来支撑这种探索密度。AutoResearch 把这种能力下沉到了单卡 GPU 的水准，让个人研究者也有机会在一夜之间完成以前需要一个月才能做完的实验规模。
四、核心设计理念：三个约束撑起整个系统
AutoResearch 的设计哲学是极简主义的工程美学。整个系统建立在三个核心约束上，而不是靠复杂的中间件堆砌。理解这三个约束，就理解了这个项目为什么有效。
可编辑的单一文件（Editable Asset）
AI 智能体只被允许修改一个文件：train.py。不能碰 prepare.py，不能新建文件，不能修改配置。所有的实验假设都必须通过修改这一个文件来实现。
这个约束看起来很苛刻，但工程上的好处是巨大的。首先，每次实验的变化是可审计的——你可以直接看 git diff 来理解 AI 做了什么。其次，搜索空间被限定在一个已知边界内，不会出现 AI 随意创建新文件导致系统状态失控的情况。第三，这个约束迫使 AI 必须把所有的改进压缩到一个文件里，形成了一种对"改动最小化"的隐性约束。
正如 The New Stack 的分析指出的：把智能体限制在这里，让搜索空间可解释，每个假设都可以用 diff 的形式来审阅。
把所有修改限定在 train.py 一个文件里，同时也是对代码演化历史的保护。整个实验过程在 git 里留下的每一个提交，都精确对应一次具体的代码变更。任何时候，你都可以通过 git diff 来准确了解"AI 在这一步到底动了什么"。这种透明度在传统的超参数搜索工具中几乎不存在——大多数 AutoML 工具的内部决策过程是黑盒的，你只能接受它给出的最终配置，无法理解它是如何得出这个结论的。
单一标量指标（Scalar Metric）
所有实验只用一个评估指标：val_bpb，也就是验证集每字节比特数（validation bits per byte）。数值越低，代表模型表现越好。
选择这个指标而不是更常见的验证集损失（validation loss）有一个重要原因：val_bpb 与词汇表大小无关。这意味着，如果 AI 决定把词汇表从 8192 调整到 4096，或者换一种分词方式，两次实验的结果依然可以直接比较。如果用普通的验证损失，词汇表大小一变，损失值就失去了可比性。
这个指标的选择让 AI 可以大胆地修改架构本身，而不仅仅是调调超参数。
固定时间预算（Time-boxed Cycle）
每次训练运行，无论 AI 做了什么修改——加深了模型层数、缩小了批次大小、换了个注意力机制——训练时长固定是 5 分钟（挂钟时间，不包含启动和编译时间）。
这个设计解决了一个隐蔽的公平性问题：如果 AI 把模型变得更大，训练一次需要更长时间，那结果当然可能更好，但这是因为它花了更多算力，还是因为它的架构确实更优？固定时间预算让每次实验在"同等算力投入"的条件下进行比较，找到的是"在你的平台上给定时间预算内的最优解"。
这也带来了另一个好处：你的结果是针对你的硬件平台优化的。在 H100 上跑出来的最优配置，在消费级 3080 上未必最优，因为两者的每5分钟算力差异极大。AutoResearch 找到的是"你的机器在5分钟内最能发挥的配置"，而不是一个脱离实际算力的理论最优。
五、项目架构全解析：三个文件，四层模块
AutoResearch 的整个项目只有三个真正重要的文件，但这三个文件之间的分工极其清晰，形成了一个完整的四层架构。
项目文件一览
autoresearch/
├── prepare.py # 人类固化，AI 不得修改
├── train.py # AI 智能体的唯一操作对象
└── program.md # 人类写给 AI 的研究指令这个结构极其精炼。没有 config.yaml，没有 utils/ 文件夹，没有 models/ 目录，没有任何复杂的中间层。整个系统的状态，在这三个文件里完全可读。
第一层：基础层（prepare.py）
prepare.py 是整个系统的地基，也是唯一一个被人类固化、AI 智能体不得触碰的文件。它承担两类职责：一次性任务和运行时工具。
一次性任务部分负责数据的获取和预处理。默认使用 OpenWebText 数据集的子集作为训练语料，低算力环境下可以替换为 TinyStories（由 GPT-4 生成的短篇故事集，熵值更低，适合小模型）。数据下载完成后，它会在本地训练一个 BPE 分词器（Byte-Pair Encoding，字节对编码），默认词汇表大小为 8192。训练好的数据分片和分词器会被缓存到 ~/.cache/autoresearch/ 目录下，供后续实验复用。
运行时工具部分提供两类函数：数据加载器（按固定序列长度切分 token，支持流式读取）和评估工具函数（计算 val_bpb 指标、在验证集上采样固定数量的 token）。这些函数在 train.py 的训练循环中被调用。
把这些功能固定在 prepare.py 里不让 AI 修改的原因很清楚：数据处理的基础设施必须保持一致，否则每次实验不是在相同的基础上比较，而是在不同的数据视角下比较，那所有结果都失去意义。
第二层：实验载体层（train.py）
train.py 是整个系统的核心，也是 AI 智能体的唯一操作对象。这个文件大约 630 行，包含了一个完整的 GPT 风格语言模型从定义到训练的全部逻辑。
模型架构部分实现了一个标准的 Transformer 解码器架构，包含多头自注意力、前馈网络、层归一化等组件。关键的超参数都以大写常量的形式定义在文件顶部，AI 智能体可以方便地定位和修改：
# 这些参数都是 AI 可以自由调整的目标
DEPTH = 8 # Transformer 层数，默认 8，低算力可降到 4
HEAD_DIM = 64 # 注意力头的维度
vocab_size = 8192 # 词汇表大小
MAX_SEQ_LEN = ... # 最大序列长度
TOTAL_BATCH_SIZE = ... # 总批次大小（需保持 2 的幂次）
WINDOW_PATTERN = "LLLG" # 注意力模式（L=Local, G=Global）优化器部分默认使用 Muon + AdamW 的组合。Muon 是一种基于 Nesterov 动量和矩阵正交化的优化器，在 Transformer 训练中表现出色；AdamW 则用于处理嵌入层等不适合 Muon 的参数。当然，AI 智能体也可以把这个组合换成其他方案——这正是实验的一部分。
训练循环部分实现了一个标准的梯度下降循环，包含梯度累积（用于在显存有限时模拟大批次）、学习率调度（余弦退火）、定期评估等逻辑。每隔固定步数，训练循环会调用 prepare.py 提供的评估函数，在验证集上计算 val_bpb 并输出到标准输出。
训练结束时，程序会输出最终的 val_bpb 和峰值显存占用（peak_vram_mb）。AI 智能体通过 grep "^val_bpb:\|^peak_vram_mb:" run.log 来读取这两个关键数值，据此做决策。
第三层：自主智能体层（program.md + AI Agent）
这一层是 AutoResearch 最具创新性的部分，也是让它区别于普通自动化脚本的核心所在。
program.md 是一个 Markdown 格式的指令文件，由人类研究员编写，定义了 AI 智能体的研究目标、操作约束和决策准则。默认的 program.md 故意写得很精简，Karpathy 说它"90%是 AI 写的"——连用来指导 AI 的指令，本身就是 AI 协作的产物。
program.md 的完整工作流程是这样的：
- 初始化阶段：智能体读取仓库中的所有关键文件（README.md、prepare.py、train.py），获得完整上下文；检查
~/.cache/autoresearch/是否存在数据分片，不存在则提示人类先运行uv run prepare.py；在git上创建一个新的特性分支（如autoresearch/mar5），所有实验的提交都记录在这个分支上。 - 实验循环阶段：在每一轮迭代中，智能体提出一个实验假设（如"将模型深度从8层改为12层看看效果"），直接修改
train.py，运行命令uv run train.py > run.log 2>&1，等待 5 分钟训练完成，然后用grep提取val_bpb值。 - 决策阶段：如果新的
val_bpb低于之前的最佳值，智能体执行git commit把这次修改记录下来，将其作为新的基准；如果val_bpb持平或变差，智能体执行git reset回到上一个版本，换一个新的方向尝试。 - 记录阶段：每次实验的结果（包含实验假设、val_bpb 数值、峰值显存等）记录到
results.tsv文件中，但这个文件不提交到 git（以免污染提交历史）。
这个流程的精妙之处在于，它利用了 git 本身作为实验版本控制系统。每一个保留下来的"好实验"都变成一个 git commit，整个研究过程的演进历史就写在 git log 里，完全透明可审计。AI 智能体运行在一个独立的特性分支上，不会影响主分支的稳定性。
承担智能体角色的 AI 模型可以是 Claude Code、OpenAI Codex，或者任何一个有文件读写和命令执行能力的编程智能体。你只需要在仓库目录下启动智能体，并发出一句简单的提示：
Have a look at program.md and let's kick off a new experiment!然后，就可以去睡觉了。
值得注意的是，program.md 里有一条非常关键的指令：NEVER STOP。这个指令告诉 AI 智能体，实验循环要持续进行，直到达到预设的迭代次数或时间上限，不允许因为某次实验失败或者找不到改进方向就自行终止。这确保了智能体的持续运转，而不是遇到困难就放弃。
一些提升实验质量的实用技巧
在实际使用过程中，有几个细节值得特别注意，莫潇羽@无忆研习社根据社区讨论整理如下：
关于 git 分支管理： 每次启动新的自主研究会话时，都应该基于 master 分支创建一个新的 autoresearch/<日期> 分支。不同日期的实验运行在不同分支上，互不干扰。如果某次实验方向错了，直接切换回 master 重新开始，不会损失之前的实验历史。
关于实验日志的保存： results.tsv 文件记录了本次会话中所有实验的指标数据，但它不被 git 追踪（program.md 明确要求不要提交这个文件）。如果你希望跨会话积累实验数据，需要手动把这个文件复制保存到其他地方，或者在 program.md 中修改这一规则。
关于中途干预： 在 AI 自主运行期间，你可以随时查看 run.log 来了解当前实验的进展。如果发现智能体朝着一个你认为明显无效的方向探索（比如它连续多次尝试增大模型参数但显存已经快撑不住了），可以直接中断当前实验，在 program.md 里补充一条"避免超过当前模型规模"的约束，然后重新启动。
关于 program.md 的迭代： 正如 Karpathy 设计的那样，program.md 本身也是一个需要随时间迭代的文件。在一个自主研究会话结束后，审阅实验记录，思考"AI 在哪些方向上浪费了时间""有哪些有价值的方向它完全没有尝试"，然后把这些观察转化成 program.md 的修改，是提升下次会话质量的关键步骤。你在提升 program.md 的过程，和 AI 在提升 train.py 的过程，在某种意义上是对称的——都是基于反馈的迭代优化。
第四层：评估与迭代层（val_bpb 机制）
评估层是整个闭环的"反馈节点"，决定了 AI 智能体的进化方向。
val_bpb 的计算原理
val_bpb（validation bits per byte）的含义是：模型在验证集上，平均每个字节需要多少比特来编码。数学上，它等于验证集的交叉熵损失除以 log(2)，再除以平均字节数。
公式的直觉理解：如果一个完美的模型能够完全预测下一个 token，它的 val_bpb 就是 0；如果模型完全随机猜，val_bpb 就趋近于理论上界。实际的语言模型 val_bpb 值通常在 1.0 到 2.0 之间，数值越低表示模型对文本的压缩/拟合效果越好。
val_bpb = cross_entropy_loss / log(2) / avg_bytes_per_token选择这个指标而不是直接用交叉熵损失，关键在于它对词汇表大小的无关性。假设一个词汇表有 8192 个词元，另一个有 256 个字节级词元，两者的交叉熵损失在同等建模能力下是不同数量级的（因为分类类别数不同），但 val_bpb 将它们换算到了同一个"每字节信息压缩效率"的维度，可以直接比较。
迭代逻辑的具体流程
每轮实验完成后，智能体会把新的 val_bpb 与历史最佳值对比：
- 若 val_bpb 降低（即提升），则保留这次的 git commit，更新最佳基准，继续在此基础上探索；
- 若 val_bpb 持平或升高（即退步），则 git reset 回滚，记录这次实验为"无效"，转换思路，尝试不同方向；
- 若连续多次尝试均无改进，智能体会回到更早的状态或者尝试更大胆的架构变更。
这个保留/回滚机制保证了整个实验过程具有单调性——在 git 分支上，每一个保留的提交都代表一次真实的性能提升。长期累积下来，git log 就变成了一条清晰的"性能提升路径"。
六、程序核心内幕：train.py 里究竟藏了什么
对技术感兴趣的读者，这里详细讲一讲 train.py 的内部结构。这部分内容有助于理解 AI 智能体在实际操作中有哪些可以调整的旋钮。
模型架构
默认配置下，AutoResearch 训练的是一个 GPT 风格的 Transformer 解码器，具体参数如下：
DEPTH = 8 # 8 层 Transformer 块
HEAD_DIM = 64 # 每个注意力头的维度
N_EMBD = HEAD_DIM * N_HEADS # 嵌入维度
vocab_size = 8192 # BPE 词汇表大小
MAX_SEQ_LEN = 1024 # 最大序列长度（具体取决于环境）注意力机制采用了 WINDOW_PATTERN 变量来控制注意力模式。默认模式是 "LLLG"，意思是每4层中前3层使用 Local（窗口化）注意力，最后1层使用 Global（全局）注意力。这种混合注意力策略在效率和能力之间取得了平衡——Local 注意力的计算复杂度是 O(n)，而 Global 注意力是 O(n²)，合理搭配可以在不损失太多模型能力的前提下显著降低显存占用。
AI 智能体可以修改这个模式，比如把所有层都设为 "L"（全 Local，速度最快）或者 "G"（全 Global，能力最强但最慢）。
Muon + AdamW 混合优化器
这是 train.py 中一个技术含量较高的设计。Muon（Momentum + orthogonal Update）是近年来在大语言模型训练中表现出色的一种优化器，其核心思想是在梯度更新时加入矩阵正交化操作，使得参数更新的方向在整个训练过程中保持数值稳定。
在 AutoResearch 的实现中，Muon 被用于处理 Transformer 的主体参数（如注意力权重和 FFN 权重），而传统的 AdamW 被用于处理嵌入层参数。这种分工是因为 Muon 的正交化操作对矩阵形状有要求，不适合所有类型的参数张量。
AI 智能体可以调整这两个优化器的学习率、权重衰减、动量系数等超参数，也可以尝试把 Muon 替换为纯 AdamW 或者其他优化器，只要实验能跑通并输出 val_bpb 就行。
梯度累积与批次大小
TOTAL_BATCH_SIZE = 131072 # 总批次大小（token 数量），需为 2 的幂次
DEVICE_BATCH_SIZE = ... # 单次前向传播的批次大小，受显存限制
# gradient_accumulation_steps = TOTAL_BATCH_SIZE // (DEVICE_BATCH_SIZE * SEQ_LEN)AI 智能体在调整模型深度（加深层数）或序列长度（增大 MAX_SEQ_LEN）时，可能需要相应地降低 DEVICE_BATCH_SIZE 以防止显存溢出，同时相应地调大梯度累积步数来维持总批次大小不变。这是一个需要同时修改多个相关参数的典型案例，也是对 AI 智能体代码理解能力的考验。
七、program.md 的精髓：你在编程的是程序，而不是模型
AutoResearch 中最容易被忽视、但也是最深刻的一个设计，是 program.md 文件。
在传统的机器学习工作流中，研究员的全部工作都发生在代码层面——你直接修改 Python 脚本来表达你的想法。在 AutoResearch 里，这个分工被彻底颠倒：AI 智能体在代码层面工作，而人类在 program.md 这个 Markdown 文件里用自然语言工作。
program.md 承担了三个同时存在的功能：
- 指令层：告诉 AI 当前要优化什么指标，可以尝试什么方向（如"关注注意力效率的改进"或"探索不同的位置编码方案"）；
- 约束层：告诉 AI 哪些东西不能改（如"不要修改 prepare.py"、"必须保持 WINDOW_PATTERN 中至少一层 Global 注意力"）；
- 终止层：告诉 AI 什么情况下该停止或换方向（如"连续 5 次无改进则尝试更激进的架构变更"）。
没有其他格式能同时优雅地表达这三层含义。YAML 有结构但没有推理上下文；Python 可执行但不适合策略性叙述；JSON 没有叙事流。Markdown 坐在人类可编辑性和 AI 可解析性的完美交汇点上。
这就是为什么 The New Stack 的分析认为，AutoResearch 中最被低估的文件不是 train.py，而是 program.md。类似的设计模式正在整个 AI 工程生态中蔓延：Claude Code 仓库里的 CLAUDE.md 文件控制智能体的代码库特定行为，Cursor 的规则文件在会话间保持项目约定。这是一种新的编程范式正在成形的信号。
从写法上来说，一份高质量的 program.md 需要在以下几个方面做出明确的陈述：
研究方向的优先级排序。 比如，"优先探索注意力机制层面的改进，其次才考虑优化器参数的调整。" 如果没有这个优先级，智能体可能会在容易但低价值的地方（比如反复微调学习率）花费大量实验次数，而忽略更有潜力但更难探索的方向（比如替换注意力模式）。
明确的边界约束。 比如，"不得修改 BPE 词汇表大小"或者"模型深度不得低于 6 层"。这些约束的目的是防止智能体通过"缩小问题规模"来人为地降低指标——比如通过大幅缩减模型参数来减少过拟合，从而得到更好的验证集表现，但这并不代表真正的架构改进。
失败处理策略。 比如，"若连续 3 次实验均无改进，则尝试回退到 5 个 commit 之前的状态，从那里重新探索。" 这种策略防止智能体在一个局部陷阱里反复挣扎，浪费实验次数。
实验记录格式。 program.md 中通常会规定 results.tsv 的列结构（包含时间戳、实验假设描述、val_bpb 值、峰值显存占用等），确保每次实验的记录格式一致，便于后续分析。
Karpathy 在框架里设定了一种有趣的角色分工：
- 人类 = 元研究者，负责设计研究组织（research org），即编写
program.md； - AI 智能体 = 执行研究者，负责执行实验循环，即修改
train.py； - Git = 实验室记录本，记录所有有效的改进路径。
人类的工作不是直接做实验，而是设计做实验的规则。这是一种角色的根本性转移。在这个框架里，人类研究员的核心竞争力，从"能快速调参跑实验"转变为了"能准确描述有价值的研究方向、并设计合理的评估和约束体系"。这两种能力之间，前者更多依赖执行力，后者更多依赖判断力和领域深度。从这个角度看，AutoResearch 并不是在削弱研究员的价值，而是在提高对研究员判断力的要求。
这个角色转移的深层逻辑，在某种意义上和软件工程领域已经发生的变化有共鸣。高级软件工程师的价值，从来不只在于"能写更多的代码"，而在于"能设计更好的系统架构"——这是一种从执行走向设计的能力演化。AI 工具链的普及，正在加速这种演化：会写代码的 AI 工具越来越多，但能设计出正确架构的人判断力，依然是稀缺的。AutoResearch 在 AI 研究领域里，对这种趋势做出了同样的诠释。
八、实际效果：Karpathy 本人的真实实验数据
理论再好，还是需要看真实数据。Karpathy 本人公开分享了他用 AutoResearch 的实验结果，非常值得参考。
他让智能体对一个"depth=12"的模型进行持续优化，整个运行时间约两天。结果：
- AI 智能体独立完成了约 700 次自主修改；
- 从中筛选出了约 20 项有效改进，这些改进在迁移到更大模型时依然有效（即改进具有泛化性，不是过拟合到特定配置的）；
- 通过叠加这 20 项改进，模型在 nanochat leaderboard 上的"Time to GPT-2"指标从 2.02 小时降到了 1.80 小时，效率提升约 11%。
Karpathy 在 X（原 Twitter）上对这个结果的评论是："看到智能体端到端独自完成这整个工作流……是震撼的（wild）。"他特别提到，智能体发现了他在注意力缩放和正则化方面长达二十年手动研究中遗漏的问题。
这 11% 的提升听起来不算巨大，但背景是：这是在 Karpathy 本人认为"已经调得很好"的基础上额外提升的 11%。在机器学习
