# 读懂 Karpathy 的 autoresearch：把 Agent 关进训练场，让它自己跑一夜实验

你可以先想象一个画面。

晚上 11 点，你没有继续盯着 loss 曲线，也没有再手动改超参数，而是把一个 Agent 扔进仓库里，让它自己去做这件事：

- 改一点 `train.py`
- 跑一轮 5 分钟训练
- 看结果是不是更好
- 更好就保留
- 不好就回滚
- 然后继续下一轮

第二天早上醒来，你看到的不是一句“我觉得这个方向不错”，而是一整串实验记录：哪个 commit 变好了，哪个改动崩了，哪次只是徒增显存，哪次真的把 `val_bpb` 压低了。

这就是 `karpathy/autoresearch` 想做的事。

到 2026 年 3 月中旬，GitHub 仓库页显示它已经有 4.2 万左右 Star、5.8k 左右 Fork。它火起来，不是因为“又一个 Agent 框架”横空出世，而是因为它把一个更尖锐的问题，压缩成了一个极小、极硬、而且真的能跑的系统：

如果给 AI 一个真实但受限的训练环境，它能不能自己做实验？

我把这个仓库从 README 一路读到 `program.md`、`prepare.py`、`train.py`，最大的感受是：它真正有意思的地方，不是“自治”这两个字，而是它把“研究”缩成了一条非常短的闭环。

不是大而全的平台，不是复杂调度系统，也不是一层层叠上去的 Agent orchestration，而是先把最关键的规则钉死：

- 只允许改一个训练文件
- 每次实验固定跑 5 分钟
- 结果只看一个统一指标
- 变好就保留，没变好就回滚

它更像一个“自动实验员”，而不是“自动科学家”。

![autoresearch-night-loop.png](https://developer.qcloudimg.com/http-save/yehe-7136204/8d1629c8ceffad04794398184a8f8469.png)

## 先说清楚：autoresearch 自动化的，不是整个科研，而是一段最耗时间的循环

很多人看到这个项目，第一反应是“AI 要自己做研究了”。

但如果你仔细看 README 和 `program.md`，就会发现它自动化的其实不是全部科研过程，而是研究里最具体、也最容易反复消耗人的那一段：

提出一个局部想法，改代码，跑实验，看指标，记结果，决定是否保留。

仓库里把这个循环写得非常直白。按 README 和 `program.md` 的主路径，大意就是：

1. 建一个新的实验分支
2. 先跑一遍 baseline
3. 之后每一轮只改 `train.py`
4. 跑 `uv run train.py`
5. 从日志里读出 `val_bpb` 和 `peak_vram_mb`
6. 写进 `results.tsv`
7. 如果结果更好就推进分支，否则 reset 回去

它甚至要求把每轮实验的 commit、指标、显存占用和运行状态都记进 `results.tsv`，这样第二天回看时，你面对的是一串可追踪的实验历史，而不是一堆模糊印象。

换句话说，这个仓库不是在鼓励 Agent “自由探索”，而是在要求它像一个有纪律的实验员一样工作。

## 如果把它跑起来，一夜大概是什么样子

这是这篇文章里我觉得最值得讲清楚的地方。

你并不是把 Agent 扔进去，然后神秘地期待它“自己变聪明”。  
你其实是在把它放进一个非常窄、非常明确的夜班岗位里。

README 和 `program.md` 给出的典型节奏大概是这样：

```bash
git checkout -b autoresearch/mar19
uv run train.py > run.log 2>&1
grep "^val_bpb:\|^peak_vram_mb:" run.log
```

如果结果更好，留下这个 commit；如果结果更差，就回到上一轮，再试另一个改动。

`program.md` 甚至明确要求第一轮一定要先跑 baseline，因为你必须先知道“什么都不改”的成绩是多少。

进一步收紧的是，它把训练时间预算直接钉死成 5 分钟。README 里给出的估算很直观：大约每小时 12 次实验，睡一觉能跑接近 100 次。

这一下，整个项目的气质就变了。

它不再像一个“会聊天的编码助手”，而更像一个你晚上交班、第二天验收的自动实验员。

## 如果你想自己跑一遍，先确认最低前提

这不是一个“随便开个终端就能看 demo”的仓库。

按 README 的主路径，至少要先满足三个条件：

- 你有一张能稳定跑训练的 NVIDIA GPU
- 你已经把依赖、数据和 tokenizer 准备好，能单独运行 `prepare.py` 和 `train.py`
- 你能从训练日志里稳定读出 `val_bpb` 和 `peak_vram_mb`

也就是说，正确顺序不是“先上 Agent”，而是：

```bash
uv run prepare.py
uv run train.py > run.log 2>&1
grep "^val_bpb:\|^peak_vram_mb:" run.log
```

只有当 baseline 能稳定跑通，你才知道后面每一轮 keep / discard 到底有没有意义。

## 这个仓库为什么看起来很小，却一点都不像玩具

`autoresearch` 真正重要的文件其实只有三个，但这三个文件的分工切得很漂亮。

![autoresearch-three-files.png](https://developer.qcloudimg.com/http-save/yehe-7136204/82459f6bc598c01be53ec77e688ea449.png)

### 第一层：`program.md`，写给 Agent 的不是提示词，而是岗位说明书

这是整个仓库最值得读的文件。

表面上看，它只是一个 Markdown 文档；但实际上，它更像一份“研究组织章程”。

它规定的不是一句 prompt 怎么写，而是 Agent 在这里到底要怎么工作：

- 用什么分支命名
- 第一轮必须做什么
- 哪些文件需要读
- 哪些文件不能动
- 结果怎么记录
- 什么情况下保留改动
- 什么情况下回滚
- 如果跑崩了要怎么处理

最关键的是，它把“继续做实验”写成了一个几乎没有歧义的循环。

人类在这个体系里不再直接改训练代码，而是改 `program.md` 这份“组织协议”；Agent 不再随便发挥，而是在协议里执行实验。

这个思路很新。  
你真正编程的对象，不再只是 Python，而开始变成“研究流程本身”。

### 第二层：`prepare.py`，把评测环境钉死

`prepare.py` 在这个仓库里的角色，不是“准备数据”这么简单。

它更像整个系统的裁判和场地管理员。

从代码里能看到几件关键的硬约束：

- `MAX_SEQ_LEN = 2048`
- `TIME_BUDGET = 300`
- `EVAL_TOKENS` 固定

除此之外，它还负责：

- 下载并组织数据分片
- 训练和加载 tokenizer
- 固定验证分片
- 提供 dataloader
- 定义最终评测函数 `evaluate_bpb`

这意味着和“实验公平性”有关的环节，都被锁进了 `prepare.py`。Agent 不能靠偷偷换评测方式来“刷成绩”，也不能靠改数据入口来混淆结果。

这里还有两个很容易被忽略、但很重要的实现细节。

第一，验证指标不是常见的 perplexity，而是 `bpb`，也就是 bits per byte。  
它会把 token 级损失按字节长度折算，这样不同 tokenizer 方案之间也更容易公平比较。

第二，`make_dataloader` 不只是一个普通 dataloader。  
它用了 BOS 对齐和 best-fit packing，尽量把每一行塞满，不做 padding，必要时还会裁切最短文档来补齐剩余空间。它追求的是训练 token 的高利用率，而不是“先跑起来再说”。

所以 `prepare.py` 的真正作用是：把实验舞台钉死。

### 第三层：`train.py`，把所有可变空间压缩进一个文件

仓库最激进的一刀，是几乎把全部可变空间都压进了 `train.py`。

能改的，只有它。

但这并不意味着它是个玩具脚本。相反，它里面放的是一套真正能跑的小型预训练系统，里面有很多你在正式训练代码里会看到的东西：

- 单 GPU GPT 训练循环
- Rotary Embedding
- `WINDOW_PATTERN = "SSSL"` 这样的局部注意力模式
- Muon 与 AdamW 的参数分组
- `torch.compile`
- `bfloat16` 自动混合精度
- 显存、吞吐、MFU 的训练日志

默认超参数也不是随便糊的：

- `DEPTH = 8`
- `HEAD_DIM = 128`
- `ASPECT_RATIO = 64`
- `TOTAL_BATCH_SIZE = 2**19`
- `DEVICE_BATCH_SIZE = 128`

除此之外，源码里还能看到一些额外的门控和残差相关设计。它们未必已经是“被证明最优”的方案，但它们的存在说明：Agent 面对的不是一块空地，而是一套已经有基础性能、也有真实优化空间的小型训练系统。

这非常重要。

因为如果底座太弱，Agent 做的只是“玩具级改动”；但 `autoresearch` 明显不满足于此。它要的是：让 Agent 在一个真训练场里做局部搜索。

## 这个项目真正聪明的地方，不是 Agent，而是约束

我读完整个仓库后最强烈的判断就是这一句。

真正聪明的，不是“让 AI 自己做研究”这个口号，而是它怎么设计约束。

![autoresearch-constraints.png](https://developer.qcloudimg.com/http-save/yehe-7136204/99a2897d9b4d0aab019f623a849f70ae.png)

### 第一刀：只给一个改动面

如果一个 Agent 同时能改数据、改评测、改训练逻辑、改依赖，最后你很难知道它到底是怎么把结果变好的。

`autoresearch` 的做法非常硬：

- 只改 `train.py`
- 不准改 `prepare.py`
- 不准改评测函数
- 不准额外装依赖

这样做的直接好处是，因果关系更清楚。

你知道变化几乎都来自训练脚本本身，而不是别的地方偷偷动了手脚。

### 第二刀：把“是否成功”收缩成一个数字

它让 Agent 几乎只盯一个目标：`val_bpb`。

当然，这会损失一些维度，比如可解释性、长程泛化和下游迁移表现，这些都没有被完整表达出来。

但对自动循环来说，单目标的价值非常大。  
因为 Agent 最需要的不是哲学上的全面理解，而是一个明确反馈：这次比上次更好，还是更差。

### 第三刀：把实验过程离散成 Git 操作

这也是我觉得它特别漂亮的一点。

一次实验不再是模糊的“试试看”，而是：

- 改一版
- 提一个 commit
- 跑一轮
- 记一条结果
- keep 或 discard

于是研究过程第一次变得像代码演化一样可追踪。

第二天你醒来，看到的不是“Agent 研究了一晚上”，而是一串具体的实验历史。这种感觉非常不一样。

## 为什么这套方法对做 Agent 的人有价值

因为它踩中的，不是“AI 会不会自己读论文”这种远期想象，而是一个更现实的问题：

当任务长度开始超过几分钟，Agent 最容易失败的地方，往往不是“不会写代码”，而是没有稳定反馈回路。

`autoresearch` 给出的答案并不夸张，反而很克制：

- 不是自动读十篇论文
- 不是自动写研究报告
- 不是自动发明新架构

它只是先把“局部实验循环自动化”做通。

但正是这种克制，让它对 Agent 工程很有参考价值。

因为这套方法强调的不是“让 Agent 尽量聪明”，而是：

- 给它一个可编辑面
- 给它一个固定预算
- 给它一个单一反馈
- 给它一个可回滚的历史

这四件事凑在一起，才会形成一个真正能迭代的长任务闭环。对做 benchmark、做调参、做自动回归测试的人来说，这个思路是可以直接迁移的。

## 但别把它神化，它离“自动科研”还很远

我很喜欢这个仓库，但也很明确地觉得：它不是“AI 已经会做科研了”的证明。

原因至少有四个。

第一，它优化的是一个很窄的目标。  
`val_bpb` 很适合自动循环，但科研里很多重要判断并不能被单个指标概括。

第二，它依赖一个人类提前搭好的舞台。  
数据集、时间预算、评测规则、可改文件、不可改文件，全都是人先定好的。Agent 更多是在这个边界里搜索，而不是自己定义研究问题。

第三，它仍然明显偏向单卡 NVIDIA 环境。  
README 写得很诚实，主路径就是单张 NVIDIA GPU。虽然已经出现了 Mac、Windows、AMD 的 fork，但主仓库本身并没有把跨平台当作第一优先级。

第四，如果 baseline 本身不稳定，这个循环就会失真。  
`autoresearch` 的前提是“同一场地、同一预算、同一指标”下，单轮结果足够可比较。只要训练波动过大，或者日志提取不稳定，keep / discard 的判断就会被噪声污染。

换句话说，`autoresearch` 真正做到的，不是“自动科研”，而是“自动科研里最容易先跑通的一小段”。

但这恰恰也是它值得看的地方。  
因为很多大词最后都停留在大词，反而是这种把问题切小、切硬、切到能跑起来的项目，更能把未来往前推一格。

## 我最想从这个仓库抄走的，不是代码，而是方法

如果你也在做 Agent、做模型工程，或者做更长任务链的自动化，我觉得 `autoresearch` 最值得抄的有两样东西。

第一，别一上来就给 Agent 太大自由。

很多人会觉得，Agent 越自由越聪明。  
但真实工程里，真正稳定的进展往往来自相反的设计：先把边界画窄，把成功标准写死，再让它在小空间里高频试错。

第二，Prompt 不该只是提示词，而应该是流程协议。

`program.md` 最妙的地方就在这。  
它不是在教模型“怎么回答”，而是在规定“这个组织如何运行”。

这种思路其实完全可以迁移到别的场景：

- 自动 benchmark
- 自动回归测试
- 自动调参
- 自动 A/B 试验
- 自动化内容生产流水线

从这个角度看，`autoresearch` 不只是一个训练仓库，它更像一个样板：演示怎么把 Agent 从“对话助手”推进成“实验执行者”。

## 最后

如果你只看 README，可能会觉得它的卖点是“让 AI 自动做研究”。

但真正读完代码之后，我反而觉得，这个仓库最打动人的地方是另一句潜台词：

研究不一定要先被做成庞大的平台，它也可以先被压缩成一个极小的、能持续迭代的闭环。

而 `autoresearch` 的价值，就在于它真的把这个闭环做出来了。

它当然还很早期，也当然还很粗糙，但正因为足够小、足够硬、足够具体，它反而比很多宏大的“Agent 愿景”更值得认真看一遍。

## 仓库信息

仓库名：`karpathy/autoresearch`

作者：Andrej Karpathy

获取方式：GitHub 搜索 `karpathy autoresearch`

本文主要参考的仓库文件：

- `README.md`
- `program.md`
- `prepare.py`
- `train.py`

如果这篇文章对你有帮助，欢迎点个赞、点个在看，也欢迎关注。
后面还会继续写 Claude Code、Codex、OpenClaw 这些项目的源码分析和使用笔记。

晚上 11 点，你没有继续盯着 loss 曲线，也没有再手动改超参数，而是把一个 Agent 扔进仓库里，让它自己去做这件事：

读懂 Karpathy 的 autoresearch：把 Agent 关进训练场，让它自己跑一夜实验

软件研发

人工智能

职业发展

算法

Karpathy的autoresearch项目将AI研究自动化，打造了一个极简实验闭环：Agent在固定5分钟训练周期内仅修改train.py文件，根据val_bpb指标自动保留或回滚改动。项目通过program.md明确实验规则，prepare.py锁定评测环境，实现可追踪的实验历史记录。这种将研究流程压缩为可执行小闭环的方法，为AI自动化实验提供了实用范例。

数据分片

回归测试

Windows

Python

GitHub

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Karpathy的autoresearch项目将AI研究自动化，打造了一个极简实验闭环：Agent在固定5分钟训练周期内仅修改train.py文件，根据val_bpb指标自动保留或回滚改动。项目通过program.md明确实验规则，prepare.py锁定评测环境，实现可追踪的实验历史记录。这种将研究流程压缩为可执行小...

读懂 Karpathy 的 autoresearch：把 Agent 关进训练场，让它自己跑一夜实验-腾讯云开发者社区-腾讯云

读懂 Karpathy 的 autoresearch：把 Agent 关进训练场，让它自己跑一夜实验

读懂 Karpathy 的 autoresearch：把 Agent 关进训练场，让它自己跑一夜实验

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐