你睡觉，AI 干活：Karpathy 的 AutoResearch 如何让大模型自己学会训练自己

引言：当"调参"变成一种可规模化的生产方式

做机器学习研究的人都有一个共同的经历：深夜盯着 GPU 训练日志，等待那个 loss 值终于往下掉。跑一个实验等几个小时，改个超参数再跑，改个优化器再跑，调个注意力头的数量再跑——大部分时间花在等待和重复操作上，而不是真正的科学思考。

2026 年 3 月，前特斯拉 AI 总监、OpenAI 创始成员 Andrej Karpathy 在 GitHub 上扔下了一个开源项目，这个项目做的事情很简单：让 AI agent 在你睡觉的时候，自主跑完一百个实验，把有用的改动留下来，把没用的还原掉。 项目名叫 autoresearch，三个月不到，收获了 66,000 个 star。README 最后一行 Karpathy 写了一句话："This repo is the story of how it all began."

这不是又一个 AI 搜索或 AI 写作工具。这是一个自主实验引擎——它通过真实的代码执行和实验评估来发现新知识，而不是整理已有的信息。

本文将深入解析这个框架的设计哲学、核心技术机制、实际使用方式，以及它对算法工程师这个职业意味着什么。

一、背景：为什么机器学习研究的瓶颈不是"算力"而是"人力"

1.1 实验循环的囚徒困境

一个典型的 ML 研究迭代循环是这样的：

人 → 写代码 → 跑实验 → 看结果 → 判断方向 → 改代码 → 跑实验 → 看结果 → ...

每个箭头背后都有人类时间的介入。写代码需要几分钟到几小时，跑实验需要几分钟到几天，而"看结果判断方向"需要的是经验和对问题的理解——这部分恰恰是最有价值的。

问题是：大部分 ML 研究员的日常并不是在做"有价值的判断"，而是在做大量重复性的实验操作——改参数、跑实验、记录结果、对比结果。研究员成了 GPU 的"看守员"，而不是思考者。

1.2 传统自动化的局限

之前也有一些自动化工具尝试解决这个问题，但它们大多停留在配置空间搜索层面：

• Grid Search / Random Search：穷举预定义的超参数组合。缺点：组合爆炸，搜索空间有限。
• Hyperband / Bayesian Optimization：更智能的超参数搜索。缺点：只能在给定配置空间内搜索，无法探索代码结构本身的变化。
• AutoML / NAS（神经架构搜索）：搜索模型结构。缺点：计算代价极高，通常需要数千 GPU 小时。

这些方法都有一个共同局限：它们改变的是"配置"，而不是"代码本身"。当你想尝试一种全新的训练策略（比如换一个注意力机制、修改学习率调度逻辑、甚至改变数据增强方式），传统的自动化工具帮不了你——这些需要修改代码，而不是调参数。

AutoResearch 解决的根本问题不是"如何更快地搜索超参数"，而是：如何让 AI agent 自动修改训练代码本身，并在真实执行中验证改进。

二、核心设计哲学：极简中的工程智慧

2.1 三文件架构：极致的边界控制

AutoResearch 的代码库只有三个文件，每个文件有严格且唯一的职责：

这个设计初看之下非常"刻意"，但背后有深刻的工程考量：

边界清晰才能安全迭代。 如果 agent 可以随意修改任何文件，它可能会不小心破坏数据加载逻辑、修改评估标准、甚至改动随机种子——这些都会让"不同实验之间的比较"变得不可能。把可编辑范围限死在一个文件里，失控的风险大幅降低。

人机分工明确。 program.md 是人类研究者与 agent 之间唯一的沟通渠道。你可以在实验中途手动修改 program.md 来调整方向——比如"前几轮优化器效果不错，现在试试注意力头的配置"。Agent 会读取最新的 program.md，按新指令继续探索。

2.2 固定时间预算：跨硬件公平实验

每次实验的训练时间是固定的 5 分钟，无论你用的是 H100 还是 RTX 4070。

这个设计解决了一个实际问题：不同 GPU 的训练速度差异巨大。如果按 epoch 来卡预算，H100 和 RTX 4070 的结果就无法直接对比。用时间做预算，结果天然是可比较的。

数学上：一小时约 12 次实验，一晚上（8 小时）约 96 轮，足够完成一次有效的超参数探索。

# 每次实验的核心循环伪代码
while True:
    # 1. Agent 读取 program.md 获取研究方向
    instructions = read("program.md")
    
    # 2. Agent 修改 train.py（唯一的可编辑文件）
    new_code = agent.edit_train_py(current_code, instructions, history)
    
    # 3. 固定 5 分钟训练
    result = run_training(new_code, timeout_seconds=300)
    
    # 4. 评估：如果 val_bpb 下降，保留改动；否则还原
    if result.val_bpb < best_bpb:
        commit(new_code, result)  # Git 提交，保留成功改动
    else:
        revert(new_code)         # 还原，尝试下一个方向

2.3 架构无关的评估指标

AutoResearch 使用 val_bpb（validation bits-per-byte） 作为唯一评估指标。这个指标衡量的是模型对文本的预测准确度——越低越好。

选择这个指标的关键在于：它和模型架构无关。无论 agent 把 attention 头改成多少个、把层数从 12 改到 24、把优化器从 Adam 换成 Muon，评估标准始终是同一个数字。这保证了不同轮次之间结果的可比性。

如果用 loss 或 accuracy 作为指标，不同架构的训练曲线形态差异很大，难以横向比较。Bits-per-byte 是一个信息论指标，本身具有归一化特性，是这个场景下的最佳选择。

三、技术实现：代码即状态

3.1 Code-as-State：把训练脚本当作可进化的状态机

AutoResearch 的核心概念是**"代码即状态"（Code-as-State）**。与传统 RL 环境的离散状态空间不同，这里的"状态"是整个 train.py 文件的文本内容。

# 状态空间 S
S = train_py_code  # 当前训练脚本的完整文本
           + experiment_history  # 历史实验记录（含成功/失败的改动描述）

# 动作空间 A（无限制代码编辑动作）
A = [
    "修改超参数（学习率、batch_size、warmup步数）",
    "调整模型架构（层数、注意力头数、隐藏维度）",
    "更换优化器（Adam → Muon → SGD）",
    "添加正则化（Dropout、Weight Decay、Label Smoothing）",
    "修改学习率调度（Cosine、Linear、ReduceLROnPlateau）",
    "改变数据增强流程",
    # ... 理论上任何代码修改都是合法的动作空间
]

# 奖励函数 R
R = -delta(val_bpb)  # val_bpb 下降越多，奖励越高

Agent 不操作有限的高层配置参数，而是直接操作底层的 Python 代码。这种"无限制动作空间"带来了更大的探索自由度——它能发现那些人类预设的超参数网格里根本不会出现的新技巧。

3.2 环境冻结：隔离变量的艺术

"环境冻结"（Frozen Environment） 是这个框架中另一个精妙的设计。

除了 train.py 以外的所有东西——数据加载代码、评估协议、随机种子、数据增强配置——全部保持不变。只有 train.py 是"可变的"，所有其他因素都被"冻结"。

这样做的好处是：每次实验之间只有一个变量变化。如果同时改了优化器和数据增强，你就无法判断性能提升到底来自哪个改动。环境冻结强制了单变量实验，这是科学实验设计的 ABC。

# prepare.py 中的数据加载代码 — Agent 无法修改
def get_train_data():
    """数据加载逻辑：冻结，不允许 Agent 修改"""
    data = download_shakespeare()  # 固定的 Shakespeare 数据集
    return encode(data)

# train.py — Agent 唯一可以修改的文件
# Agent 可以修改模型结构、优化器、训练循环逻辑
# 但数据加载必须调用 prepare.py 中的 get_train_data()

3.3 Git 自动提交：实验结果的可追溯性

每当一次实验产生了更好的 val_bpb，框架会自动将当前的 train.py 提交到 Git 的一个独立分支，提交信息包含实验指标和改进描述。失败的历史记录也会被保留到一个"负面结果数据库"中。

# 成功实验自动 Git 提交
git checkout -b experiment-042
git add train.py
git commit -m "experiment #42: 
  val_bpb: 0.9832 → 0.9751 (+0.82% improvement)
  change: increased attention heads 8→12, added dropout 0.1
  hardware: M4 Mac Mini 16GB, 5min training"

# 失败实验记录到负面结果数据库
# 未来 Agent 会主动避免重复探索相同的失败路径

这个设计让整个实验过程变得完全可审计、可复现、可回溯。你随时可以 git diff 回到任何一个历史版本，重新审视当时的改动。

四、使用方法：从零到跑起来

4.1 环境准备

# 克隆仓库（MIT 许可证，商业友好）
git clone https://github.com/karpathy/autoresearch
cd autoresearch

# 使用 uv 管理依赖（项目推荐）
uv sync

# 数据准备（下载 Shakespeare 数据集并做 tokenize）
uv run prepare.py

依赖：

• Python 3.10+
• NVIDIA GPU（官方测试基于 H100，社区 fork 支持消费级显卡）
• uv 包管理器
• 至少 12GB 显存（推荐）

4.2 编写 program.md

这是整个流程中最"有人味儿"的一步。你需要用自然语言写清楚你的研究目标：

<!-- program.md -->
# NanoGPT 训练优化实验

## 目标
降低模型在验证集上的 bits-per-byte（val_bpb），这是模型预测文本准确度的度量，越低越好。

## 约束
- 不允许修改数据加载代码（保持可比性）
- 不允许修改评估协议（使用项目自带的评估脚本）
- 每次实验训练 5 分钟（硬件无关）

## 探索方向
当前我们使用 AdamW 优化器，学习率 0.001，12 层 Transformer。

建议优先探索：
1. 学习率调度（warmup + cosine decay）
2. 优化器选择（尝试 Muon 或 Sophia）
3. 注意力机制细节（是否使用 Flash Attention）
4. 正则化策略（Dropout 比例、Weight Decay 系数）

## 评估指标
val_bpb：越低越好。每次实验结束后系统会自动报告此指标。

4.3 启动 AI Agent

用你最顺手的 AI coding agent（Claude Code、Codex、Gemini CLI 都可以），发送一句简单的话：

Hi, have a look at program.md and let's kick off a new experiment!

Agent 会自动进入循环：

读 program.md → 理解目标 → 修改 train.py → 执行 5 分钟训练 
→ 评估 val_bpb → 保留成功改动/还原失败改动 → 继续下一轮

你不需要盯着它。第二天早上回来，看 Git 提交记录，就知道它尝试了哪些方向，哪些有效、哪些无效。

4.4 中途干预

如果在实验进行中你发现方向不对，可以手动编辑 program.md：

<!-- 运行 50 轮后，你认为优化器已经饱和，方向应该转向架构 -->
# NanoGPT 训练优化实验（第二轮）

## 当前状态
已完成 50 轮实验，优化器相关探索效果最佳（AdamW → Muon 提升 0.4%）。

## 新方向
现在聚焦模型架构调整：
1. 增加 Transformer 层数（12 → 16）
2. 扩大隐藏层维度（768 → 1024）
3. 调整注意力头数量和维度分配

Agent 读取更新后的 program.md，下一轮开始按新指令执行。

五、实战案例：数据说话

5.1 不同硬件上的实验结果

社区用户在多种硬件上跑了一段时间，留下了一些记录：

RTX 4070 上能跑出 282 次实验是因为消费级 GPU 的训练速度快（batch size 小但轮次多），在短时间预算内反而能完成更多次迭代尝试。

5.2 Shopify Liquid 引擎优化

最有意思的一个案例是有人把这个框架移植到了 Shopify 的 Liquid 模板引擎上：

# Liquid benchmark 评估脚本（agent 不能修改）
def benchmark_liquid():
    """解析 + 渲染 1000 个 Liquid 模板，测量总耗时（毫秒）"""
    templates = load_templates()
    start = time.time()
    for t in templates:
        render(t)
    return (time.time() - start) * 1000  # 返回毫秒数

这不是机器学习任务，和 NLP 毫无关系。但核心思路完全通用：只要你有一个可运行的 benchmark，能输出一个数字，你就可以用 AutoResearch 的循环来优化它。

Agent 在一晚上探索了各种缓存策略、解析器优化和渲染路径改进。最终结果：解析 + 渲染速度提升了 53%。没有人通宵工作，也没有人盯着每一次改动。

这个案例证明了 keep-or-revert 循环的思路具有领域无关性——它不依赖 ML 背景知识，本质上就是一个"进化式代码优化器"。

六、与现有"AI 研究工具"的本质区别

目前市面上的深度研究工具（Perplexity Deep Research、OpenAI Deep Research、Gemini Deep Research）本质上都在做同一件事：搜索 + 综合 + 生成报告。它们能把已有的知识组织得更好，但产出的是"整理"，不是"发现"。

AutoResearch 的本质完全不同：

打个比方：搜索综合类工具像是帮你把图书馆里的书整理好、做摘要；而 AutoResearch 像是在实验室里做实验——它真的会跑东西，会有意外发现，会产生那些"没有人写在书里的洞察"。

七、局限性：它不是万能的

7.1 当前能力边界

AutoResearch 目前有几个明确的局限：

硬件依赖严重。 需要 NVIDIA GPU，消费级显卡（RTX 3090/4090）通过社区 fork 可以跑，但速度和效率远不如 H100/A100。没有 GPU，这个框架完全无法工作。

只能优化可量化的目标。 如果你的"好坏"无法用一个数值来衡量（比如"用户体验"、美学价值），就无法构建奖励函数，也就没法跑这个循环。这是所有自动化实验框架的根本限制。

单 GPU 运行，无分布式支持。 目前不支持多卡分布式训练，无法用于大规模模型的探索（比如训练一个 70B 级别的模型）。它最适合的场景是小到中等规模的模型（nanoGPT 量级）。

环境配置不算简单。 Python 3.10+、uv 包管理、GPU 驱动，全部需要自己配。对于非 ML 背景的开发者，有一定的上手门槛。

Setup 存在潜在问题。 在某些云环境（如 RunPod root 模式）可能会遇到 --dangerously-skip-permissions 的权限问题，需要一定的 Linux 运维知识。

7.2 无法替代的工作

AutoResearch 能做的：

• 消融研究（Ablation Studies）和超参数敏感性分析
• 在标准基准上复现和扩展已有论文的实验
• 单 GPU 可完成的小到中型模型探索
• "探索性实验"：快速验证"如果改 X，性能如何变化"

AutoResearch 无法替代的：

• 大规模分布式训练（需要多 GPU/多节点）
• 全新数学推导和理论创新（能测试假设，但无法从零推导新理论）
• 判断"哪个问题值得问"（需要领域经验和科学直觉）
• 跨模态创新（如将 NLP 技术迁移到视觉，需要人类的类比能力）

八、对职业的影响：重新定义算法工程师

8.1 人机协作的新分工

AutoResearch 不会取代算法工程师，但它会重新定义这个角色的工作内容：

效率倍增效应：

• 个人层面：1 个研究员 + AutoResearch overnight ≈ 原来需要 3-5 人团队手工实验的工作量
• 组织层面：Anthropic、DeepMind、OpenAI 内部其实早有类似的自动实验基础设施，Karpathy 的开源版本是将这一能力民主化（democratize）给个人研究者和小团队

8.2 "认知外骨骼"隐喻

Karpathy 本人在项目 README 中写道：

"Seeing the agent do this entire workflow end-to-end and all by itself… is wild"

但"wild"之后，人类仍然需要判断这些发现的意义。AutoResearch 更像是程序员世界里的"认知外骨骼"——它将人类从繁琐的实验调参中解放出来，让研究员可以专注于更高层次的科学创造：提出正确的问题，定义有意义的目标，判断哪些发现值得深挖。

就像机械外骨骼让人类能举起更重的物体，但它不会让人类失去对"为什么要搬运这些货物"的思考能力。

九、生态扩展：超越 Karpathy 的原版

9.1 AutoResearchClaw：端到端学术论文生成

社区在 Karpathy 的框架基础上开发了一个更激进的版本：AutoResearchClaw（aiming-lab，10,400 stars）。

它的野心更大：从一个研究 topic 出发，走完"文献搜索 → 假设生成 → 实验设计 → 实验执行 → 论文撰写"的全流程，最后输出一篇 LaTeX 排版的学术论文。

核心流程：

1. 从 arXiv、Semantic Scholar、OpenAlex 拉取真实文献
2. 提取研究假设和技术路线
3. 生成实验设计
4. 自动执行实验（调用 AutoResearch 框架）
5. 撰写完整论文（NeurIPS/ICML 模板）

它的 citation 校验做了四层递进：标题匹配 → 摘要匹配 → 关键段落匹配 → 数值结果匹配。确保论文中引用的每一条数据和每一篇文献都有原始出处。

9.2 跨领域迁移

Keep-or-revert 的思路已经被社区用到了 ML 以外的领域：

• GPU Kernel 优化：用 benchmark 的 GFLOPs 作为指标，自动搜索最优的 CUDA 代码参数
• 编译器调优：用二进制性能作为 reward，自动探索编译器 flag 的最优组合
• 量化交易策略：用策略收益率作为 reward，自动迭代策略代码
• 体育数据建模：用预测准确度作为 reward，自动探索特征工程和模型组合

核心框架不依赖于任何 ML 知识，它本质上就是一个："给定一个可执行脚本 + 一个数值指标 + 一个时间预算，循环探索代码改动，直到找到最优实现" 的通用引擎。

十、总结与展望

10.1 这个框架教会我们什么

AutoResearch 最大的意义不是它能帮你调参，而是它展示了一种全新的研究思维：

第一，研究过程本身可以工程化。 过去我们把"做实验"当成一种需要人类全程看守的活动，但 AutoResearch 证明，只要你能定义清楚"好"的标准，研究过程就可以自动化、研究循环就可以规模化。

第二，最简单的设计往往最有效。 630 行代码，三个文件，固定 5 分钟预算，keep-or-revert 循环。没有复杂的 RL 算法，没有分布式架构，没有花哨的 AutoML 技术。但它work。好的工程往往在于知道什么不该做，而不是堆砌功能。

第三，工具改变的是"什么人能做什么事"，而不是"谁来做事"。 AutoResearch 让一个没有大量实验员资源的小团队，也能完成过去只有大公司实验室才能做到的探索规模。这是工具民主化的力量。

10.2 下一步方向

Karpathy 本人提出的下一步方向是 SETI@home 风格的异步协作：

• 从"模拟单个研究员"转向"模拟整个研究社区"
• 多 agent 分布式探索，结果去重和跨 agent 记忆共享
• 利用闲置算力（志愿者集群或企业 GPU 农场）众包模型评估

最终形态可能是：人类负责提出科学问题和解释突破性发现，AI 代理负责穷尽性实验探索和渐进式优化——就像人类天文学家提出"寻找系外行星"，而 AI 管理望远镜阵列进行海量观测和初步筛选。

10.3 写在最后

如果你是一个 ML 研究者或算法工程师，AutoResearch 值得你现在就去试试。它不需要你有任何"AI Agent"的开发经验，只需要你有一块 NVIDIA 显卡、一个研究目标、和一个愿意让 AI 在后台跑一晚上的耐心。

三行命令：

git clone https://github.com/karpathy/autoresearch
cd autoresearch
uv sync && uv run prepare.py

然后写一个 program.md，对你的 coding agent 说一声"let's start"，然后去睡觉。

当你醒来的时候，你的 AI 研究助手可能已经帮你找到了你自己都没想到的优化方向。

参考链接：

• autoresearch GitHub（Andrej Karpathy）
• AutoResearchClaw（端到端论文生成）
• awesome-autoresearch（生态收录）
• MarkTechPost 教程（Colab 教程）

标签： AI研究 | 机器学习 | AutoML | LLM训练 | Andrej Karpathy | GitHub开源 | 自动化调参 | Python | 研究效率 | Agent

Keywords： AutoResearch | autonomous ML research | AI agent experiment | Andrej Karpathy | GitHub trending | NanoGPT | keep-or-revert | code-as-state | ML automation | experimental research loop