Karpathy开源autoresearch：用一张Markdown让AI代理自主优化GPT模型

2026年3月6日，Andrej Karpathy在社交媒体上扔下了一句话：

"Research used to be done by meat computers in between eating, sleeping, and synchronizing once in a while using sound wave interconnect in the ritual of group meeting. That era is long gone."

翻译过来即是：过去的研究依赖于“肉体计算机”——也就是人类，通过吃饭、睡觉和开会来同步进度。那个时代已经结束了。

我对此的第一反应是，这种转变其实早有迹象，如今只是被大神以更具体的方式呈现了出来。为了验证猜想，我点开了他提到的那个仓库。

浏览完代码后，我沉默了大约两分钟。

第一步：理解他到底做了什么

autoresearch 的核心逻辑异常简单，简单到你可能会觉得“就这？”。

整个项目真正重要的文件只有三个：

• prepare.py：一次性数据准备脚本，永远不会被修改。
• train.py：包含完整的GPT模型、优化器及训练循环，约630行代码，AI可以随意修改。
• program.md：一个Markdown文件，你在这里面告诉AI代理如何进行自主研究。

随后，AI代理便开始工作，流程如下：

1. 读取 program.md，理解研究方向。
2. 修改 train.py（改变架构、调整超参数、更换优化器……）。
3. 运行一次5分钟的训练。
4. 查看 val_bpb 指标，数值降低则进行git commit，升高则丢弃本次修改。
5. 返回第2步，无限循环。

每小时大约进行12个实验，一整晚就能积累约100个。当你在睡觉时，它却在不知疲倦地工作。

为什么迭代周期要设定为5分钟？

看到这里，我脑海中的第一个问题是：为什么是5分钟？ 这直接关系到整个系统评估结果的可信度。

如果每次训练时长不同，实验结果就失去了可比性——一个跑了3分钟的模型可能只是因为训练时间不足才表现不佳。Karpathy选择固定的时间窗口，其实是在构建一个公平的竞技场。所有修改，无论大小，都在相同的GPU时间内接受评估。在这里，时间是常量，模型质量是变量。

当然，这也意味着优化目标是“在这块特定GPU上的5分钟最优解”，而非普适的最优解。但这更像是一种刻意的设计约束，将研究范围明确限定在“给定硬件条件下的高效探索”。

核心评估指标：val_bpb是什么？

第二个值得深思的设计是评估指标：val_bpb，即验证集每字节比特数。

熟悉大模型训练的朋友可能会问，为什么不直接用损失函数值？因为损失值依赖于词汇表大小。如果更换了分词器，词汇表从32K变为64K，损失值的数值基准就变了，无法直接比较不同实验的优劣。

val_bpb 则是与词汇表无关的。无论你如何调整分词器，它都能在同一标准下衡量“模型对未见过的文本预测得有多好”。数值越低代表越好。这为AI代理提供了一个客观、稳定、可量化的优化目标，是自动迭代得以进行下去的基础。

剖析整个自主研究的数据流

我们可以将 autoresearch 的运行逻辑可视化为以下流程：

┌─────────────────────────────────────────────────────────┐
│                      Human（你）                         │
│  编写 program.md：研究方向、策略、优先级                   │
└──────────────────┬──────────────────────────────────────┘
                   │ 读取研究指令
                   ▼
┌─────────────────────────────────────────────────────────┐
│                   AI Agent（不睡觉）                      │
│                                                         │
│   ┌──────────────────────────────────────────────────┐  │
│   │  Step 1: 读 program.md，生成下一个修改假设         │  │
│   └────────────────────┬─────────────────────────────┘  │
│                        │ 修改代码                        │
│   ┌────────────────────▼─────────────────────────────┐  │
│   │  Step 2: 修改 train.py（架构/优化器/超参数...）    │  │
│   └────────────────────┬─────────────────────────────┘  │
│                        │ 启动训练                        │
│   ┌────────────────────▼─────────────────────────────┐  │
│   │  Step 3: 运行训练，精确 5 分钟（固定时间窗口）     │  │
│   └────────────────────┬─────────────────────────────┘  │
│                        │ 读取指标                        │
│   ┌────────────────────▼─────────────────────────────┐  │
│   │  Step 4: 评估 val_bpb                             │  │
│   │    val_bpb 降低 ──→ git commit                   │  │
│   │    val_bpb 升高 ──→ 丢弃，回退                    │  │
│   └────────────────────┬─────────────────────────────┘  │
│                        │ 循环                            │
│                        └──→ 回到 Step 1                  │
└─────────────────────────────────────────────────────────┘
                   │ 早晨
                   ▼
┌─────────────────────────────────────────────────────────┐
│              你醒来，看到 git log                         │
│  ≈100 个实验记录，每条 commit 都是一次优化尝试             │
└─────────────────────────────────────────────────────────┘

值得注意的是，prepare.py 完全处在这个循环之外。它只运行一次，提前准备好数据。无论AI如何折腾，都不会触及数据预处理部分。这是一种非常聪明的职责边界划分。

真正的难点：如何编写program.md？

最困难的部分并非训练或评估，而是 program.md 该如何编写。是的，我们又回到了类似“提示词工程”的领域，但这可能是系统中最难以量化的环节。

你写在Markdown文件里的内容，直接决定了AI代理的探索方向。你让它“优先尝试更深的网络”，它就会朝深度方向调整；你让它“关注优化器的动量参数”，它就会围绕动量做文章。Karpathy对此的描述是：

“The goal is to engineer your agents to make the fastest research progress indefinitely and without any of your own involvement.”

你的角色不再是编写Python代码，而是在“为程序员编写程序”。这个转变意义重大。

传统的机器学习研究流程是：产生想法 → 编写代码 → 运行实验 → 分析结果 → 调整代码 → 再次实验。

而 autoresearch 将中间的多个步骤外包给了AI，你只需要专注于两件事：产生想法（编写program.md） 和 分析最终结果。研究员从“科学方法的执行者”转变为“科学方法框架的设计者”。Karpathy在项目介绍中使用的“agentic engineering”一词，恰如其分地描述了这种状态——你99%的时间都在编排与监督智能体。

潜在问题：代码理解与审查的挑战

试想，当迭代到第10000个commit时，train.py 已经被AI改得面目全非。Karpathy在README中开玩笑说，那时的代码可能已经“grown beyond human comprehension”（超出了人类的理解范围）。

这虽然是夸张，但其背后的担忧是真实的：当AI产出的代码复杂度超出即时理解范围时，我们该如何进行有效审查？

目前，autoresearch 通过约束机制来应对：AI只能修改一个文件，且每次修改都对应一个独立的git commit。你可以完整追溯每一步变化，明确知道每个commit带来了多少性能提升。这套机制目前是可审查、可追溯的。

然而，随着系统复杂度的提升（例如，未来可能出现数十个AI代理并行实验），这个问题将越来越难以回避。这也是所有自主研究系统未来需要面对的课题。

为什么这个项目值得关注？

autoresearch 的价值不在于它现在有多么复杂，恰恰相反，它的力量源于其极简设计：630行代码，3个核心文件，1块GPU。

在这极简的外表下，却是一个完整的自主研究闭环：

• 执行单元 (train.py)
• 评估标准 (val_bpb)
• 控制逻辑 (AI代理 + program.md)
• 历史记录 (git commit log)
• 边界约束 (单文件修改，固定时间窗口)

每一个设计决策都在针对性地解决“自动化科研可能出什么错”的问题。没有客观指标，AI就会迷失方向；没有固定的时间预算，实验结果就无法比较；没有边界约束，AI的修改将失控，让人无从审查。

因此，与其说 autoresearch 是在炫耀“AI有多强大”，不如说它在示范“如何设计一个能让AI安全、高效、自主工作的系统”。这套设计哲学，比代码本身更值得学习和探讨。

我个人在实践“vibe coding”时，也始终坚持让AI同时生成并维护自动化测试用例。只有通过了自身验证的迭代，我才认为它是可靠的，不会在引入新功能时破坏旧有的稳定功能。我目前正在开发的纯C版本Claw项目，就贯彻了这一思路，其迭代过程相当稳定。

最后的思考

这个方向的终点在哪里，我并不确定。Karpathy本人称其为“一个玩笑”，但他将这个能跑通的“玩笑”开源了，所有的实验都是真实的。

从时间线上看，这更像是一个连续的信号：

• 2025年2月，他提出了“vibe coding”的概念。
• 2026年2月，他阐述了“agentic engineering”的理念。
• 2026年3月，autoresearch 项目诞生——人甚至无需编排，只需写一张Markdown。

每一步，人类都在向后撤退一步，而AI则向前迈进一步。这更像是一种不可逆的趋势，而非昙花一现的技巧。对于开发者而言，理解并适应这种以AI代理为核心的自主研究范式，或许比掌握某个具体框架更为重要。如果你想了解更多关于AI前沿的实践与讨论，欢迎来云栈社区的人工智能板块交流。

引用链接

[1] autoresearch: https://github.com/karpathy/autoresearch