Karpathy 的 AutoResearch 深度实战：630 行代码如何让 AI 自己做研究——从 program.md 编程范式到 Muon 优化器的全链路拆解

引言：当研究员开始蒸桑拿

2026 年 3 月，Andrej Karpathy 在 X 上发了一条推文："ah yes, this is what post-AGI feels like"。

他不是在开玩笑。在他睡觉的 12 小时里，一个 AI Agent 自主提交了 110 次代码变更，把一个语言模型的验证损失从 0.862415 一路压到 0.858034。醒来后，他去蒸了个桑拿。

然后他把这 630 行代码扔到了 GitHub 上——karpathy/autoresearch。三个月不到，66,000 个 star。

这个项目做的事情听起来简单：给 AI Agent 一个小型 LLM 训练环境，让它自己改代码、跑训练、评估结果、决定保留还是丢弃，然后继续下一轮。整个过程完全自主，不需要人类干预。

但简单背后藏着一个深刻的问题：当 AI 能自己做研究时，人类研究员的角色是什么？

Karpathy 的答案是：写 Markdown。

这不是段子。在 autoresearch 的设计中，人类不碰 Python 代码，只编辑 program.md——一份用自然语言写的研究策略文档。你定义目标和边界，Agent 负责执行。这是一种全新的编程范式：用自然语言编程 AI 的研究行为。

本文将深入拆解 autoresearch 的架构设计、核心代码、优化策略和工程实践，帮你理解这个项目为什么能用 630 行代码掀起一场研究范式的变革。

一、项目全景：630 行代码的最小可行研究实验室

1.1 设计哲学：极简主义的力量

autoresearch 的代码量只有约 630 行，核心文件只有三个：

这个三文件架构不是偷懒，而是深思熟虑的设计决策：

第一，约束搜索空间。 Agent 只能修改一个文件（train.py），这把无限可能的代码修改空间约束到了一个可控范围。你可以想象，如果 Agent 可以修改任何文件，它可能会改评估指标来"作弊"，或者修改数据准备流程来"泄露答案"。单文件约束消除了这些风险。

第二，可审计的变更历史。 每次修改都是 git commit，每次回退都是 git reset。你可以用 git log 回溯 Agent 的每一次决策——它尝试了什么、为什么、结果如何。这在传统的超参搜索中是做不到的。

第三，人类和 AI 的职责分离。 人类写 program.md 定义"做什么研究"，Agent 改 train.py 决定"怎么改代码"。这种分离让人类从代码细节中解放出来，专注于更高层次的研究策略。

1.2 运行环境：一块 GPU 足矣

硬件要求极低：单张 NVIDIA GPU（推荐 H100），Python 3.10+，uv 包管理器。

# 1. 安装 uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2. 安装依赖
uv sync

# 3. 下载数据、训练分词器（一次性，约 2 分钟）
uv run prepare.py

# 4. 手动跑一次训练实验（约 5 分钟）
uv run train.py

如果上述命令都能跑通，说明环境就绪，可以进入自主研究模式。

1.3 启动自主研究

启动方式极其简单——打开你的 Claude Code / Codex / 任何 AI 编码助手，指向这个仓库，然后说：

Hi, have a look at program.md and let's kick off a new experiment! 
Let's do the setup first.

就这样。Agent 会读取 program.md，理解研究目标，然后开始自主循环：改代码 → 跑训练 → 评估结果 → 保留或丢弃 → 继续。

Karpathy 把 program.md 称为一种"超轻量级 skill"——一种用自然语言定义 AI 行为的模式。这个概念后来被更广泛的 Agent 框架采纳。

二、核心架构：无限循环中的进化引擎

2.1 主循环：一个 while True 的研究机器

autoresearch 的核心逻辑可以用一个伪代码循环来描述：

while True:
    # 1. 读取当前 train.py 和实验历史
    current_code = read_file("train.py")
    experiment_history = read_git_log()
    
    # 2. 形成改进假设
    hypothesis = agent.think(
        "Based on current code and history, "
        "what should we try next?"
    )
    # 例如："把学习率从 3e-4 调到 1e-3 试试"
    # 例如："把 attention 头数从 8 增加到 12"
    # 例如："试试在 LayerNorm 之前加 Dropout"
    
    # 3. 修改 train.py
    new_code = agent.modify(current_code, hypothesis)
    write_file("train.py", new_code)
    
    # 4. Git 留痕
    git_commit(f"Experiment: {hypothesis}")
    
    # 5. 运行训练（严格 5 分钟）
    result = run_training(timeout=5 * 60)  # 秒
    
    # 6. 检查验证损失
    new_val_loss = result.val_bpb
    
    # 7. 决策：保留还是回退
    if new_val_loss < best_val_loss:
        best_val_loss = new_val_loss
        # 保留 commit，更新基线
        print(f"✅ Improved! val_bpb: {new_val_loss:.6f}")
    else:
        git_reset_hard()  # 回退到上一个 commit
        print(f"❌ No improvement. Reverting.")

这个循环的关键设计决策：

固定时间预算（5 分钟）。 不管 Agent 怎么改代码，训练严格跑 5 分钟就停。这有两个好处：一是所有实验可直接比较（相同的计算预算），二是自动适配平台性能——更快的 GPU 跑更多 step，更慢的跑更少，但比较是公平的。

单一评估指标（val_bpb）。 验证集上的 bits per byte——越低越好，且与词表大小无关，这意味着 Agent 改变模型架构时（比如换词表大小），指标仍然可比。

Git 驱动的版本控制。 每次实验是一个 commit，成功就保留，失败就 git reset --hard。这不是简单的"撤销"，而是完整的研究审计日志。

2.2 train.py：Agent 的画布

train.py 是 Agent 唯一可以修改的文件，包含了完整的训练流水线：

• 模型定义： GPT 架构（可调深度、注意力头数、隐藏维度等）
• 优化器： Muon + AdamW（Karpathy 选择的双优化器方案）
• 训练循环： 数据加载、前向传播、反向传播、梯度更新、评估

Agent 可以修改的一切都是"公平游戏"——架构、超参、优化器、batch size、学习率调度器……只要改了之后 5 分钟训练跑完且 val_bpb 下降，就算成功。

下面是 train.py 中一些关键配置的典型值：

# 模型超参数
DEPTH = 8                    # Transformer 层数
HEADS = 8                    # 注意力头数
DIM = 512                    # 隐藏维度
VOCAB_SIZE = 8192            # 词表大小（prepare.py 定义）

# 训练超参数
TOTAL_BATCH_SIZE = 2**16     # 总 batch size（约 65K tokens）
DEVICE_BATCH_SIZE = 32       # 单步 batch size
MAX_SEQ_LEN = 1024           # 最大序列长度

# 优化器
# Muon 用于大部分参数，AdamW 用于不适用 Muon 的参数
LR = 3e-4                    # 学习率
WEIGHT_DECAY = 0.1           # 权重衰减

# 注意力模式
WINDOW_PATTERN = "SSSL"      # 交替带状注意力模式
# S = Sliding Window, L = Global Attention

2.3 Muon 优化器：为什么不用纯 AdamW？

autoresearch 默认使用 Muon + AdamW 的双优化器方案，这是 Karpathy 在 nanochat 中引入的选择。Muon（Momentum-guided Optimization）是 Jordan Juravsky 等人在 2024 年提出的优化器，核心思想是利用矩阵正交化来引导梯度方向。

为什么 Muon 对 autoresearch 特别重要？

第一，更快的收敛速度。 在相同的 5 分钟预算下，Muon 比 AdamW 能多走几步有效更新。这意味着 Agent 的每次实验都能看到更明显的效果差异，减少了噪声对判断的干扰。

第二，对学习率更鲁棒。 AdamW 对学习率非常敏感，稍微调高就爆炸，稍微调低就收敛太慢。Muon 的正交化机制使得学习率的选择空间更大，Agent 改错超参的概率更低。

第三，适合小模型训练。 autoresearch 的训练规模很小（5 分钟、单 GPU），Muon 在小规模训练上的优势比大规模更明显。

# Muon 优化器的核心逻辑（简化版）
class Muon:
    def __init__(self, params, lr=0.02, momentum=0.95, nesterov=True):
        self.lr = lr
        self.momentum = momentum
        self.nesterov = nesterov
        self.momentum_buffer = {}
    
    def step(self, params, grads):
        for p, g in zip(params, grads):
            if p not in self.momentum_buffer:
                self.momentum_buffer[p] = torch.zeros_like(g)
            
            # 更新动量
            buf = self.momentum_buffer[p]
            buf.mul_(self.momentum).add_(g)
            
            # Nesterov 校正
            if self.nesterov:
                update = g + self.momentum * buf
            else:
                update = buf
            
            # 对权重矩阵做 Newton-Schulze 正交化
            if update.dim() >= 2:
                update = newton_schulze_orthogonalize(update)
            
            # 应用更新
            p.add_(update, alpha=-self.lr)

2.4 program.md：用自然语言定义研究策略

program.md 是 autoresearch 最创新的部分。它是一份人类编写的研究指南，用自然语言告诉 Agent 应该怎么进行研究。

一份典型的 program.md 包含：

# Research Program

## Goal
Improve the validation loss (val_bpb) of a small GPT model trained on 
Fineweb-Edu dataset. Lower is better.

## Current Baseline
- val_bpb: 0.8624 (after 5 minutes of training)
- Model: 8-layer GPT with 8 heads, dim=512
- Optimizer: Muon + AdamW

## Strategy
1. Start with architecture changes: try varying depth, heads, and dimensions
2. Then explore optimizer settings: learning rate, weight decay, schedule
3. Finally experiment with attention patterns: sliding window, global, mixed

## Constraints
- You may ONLY modify train.py
- Training must complete in 5 minutes
- The evaluation metric is val_bpb (lower is better)
- Do not change the evaluation methodology

## Experimental Approach
- Make ONE change at a time
- Record your hypothesis before each experiment
- If an experiment fails (NaN loss, OOM), revert immediately
- Keep a mental model of what works and what doesn't

Karpathy 在 README 中强调：默认的 program.md 是故意写得非常简陋的。这是一个 baseline，你显然可以不断迭代它，找到能实现最快研究进度的"研究组织代码"，可以加入更多 Agent，等等。

这个概念——把研究策略从代码中抽离出来，用自然语言编程——是 autoresearch 最重要的思想贡献。它意味着：

1. 研究员的角色从"写代码"变成了"写策略"
2. 策略可以版本化、A/B 测试、持续优化
3. 不同的策略会产生不同的研究行为，就像不同的 prompt 会让 LLM 生成不同的输出

三、实验循环的工程细节

3.1 5 分钟训练：为什么是 5 分钟？

5 分钟不是拍脑袋定的。这个数字经过了精心权衡：

• 太短（<1 分钟）： 训练不充分，损失值噪声太大，Agent 无法区分真正的改进和随机波动。
• 太长（>30 分钟）： 每小时只能跑 1-2 个实验，一晚上只能试 10-20 个方案，搜索效率太低。
• 5 分钟： 大约每小时 12 个实验，12 小时可以跑约 100 个实验。这个数量级足以让 Agent 覆盖主要的超参空间。

# 固定时间预算的实现方式（简化）
import time

MAX_TRAIN_TIME = 5 * 60  # 5 分钟，秒

start_time = time.time()
step = 0

while True:
    # 检查时间预算
    elapsed = time.time() - start_time
    if elapsed >= MAX_TRAIN_TIME:
        break
    
    # 执行一步训练
    loss = train_step(model, batch)
    step += 1
    
    # 定期评估
    if step % eval_interval == 0:
        val_loss = evaluate(model, val_data)
        print(f"Step {step} | val_bpb: {val_loss:.6f} | "
              f"elapsed: {elapsed:.0f}s")

注意一个重要细节：5 分钟是纯训练时间，不包括启动和编译。这意味着 PyTorch 的 JIT 编译、数据加载等开销不计入实验时间。

3.2 val_bpb：与词表无关的评估指标

autoresearch 使用的评估指标是 val_bpb（validation bits per byte），而不是常见的 perplexity 或 cross_entropy_loss。这个选择有深意。

Bits Per Byte 的计算：

def compute_bpb(loss, vocab_size, bytes_per_token):
    """
    将交叉熵损失转换为 bits per byte。
    
    loss: 交叉熵损失 (nats)
    vocab_size: 词表大小
    bytes_per_token: 平均每个 token 对应的字节数
    
    BPB = loss / (ln(2) * bytes_per_token)
    """
    import math
    return loss / (math.log(2) * bytes_per_token)

为什么不用 perplexity？因为 perplexity 和词表大小强相关。如果 Agent 把词表从 8192 改到 4096，perplexity 会显著变化，但这不代表模型真的变好了或变差了——只是词表大小不同导致的指标偏移。

BPB 通过除以 bytes_per_token（每个 token 平均编码的字节数）来做归一化，使得不同词表大小下的结果可直接比较。这在 Agent 可以自由修改模型架构的场景下至关重要。

3.3 Git 驱动的版本控制：研究审计日志

autoresearch 用 Git 来管理实验版本，这是最优雅的工程决策之一：

# Agent 的典型 Git 历史
$ git log --oneline -10
a3f2b1c Experiment: Increase DEPTH from 8 to 10
e7d4c2a Experiment: Try cosine LR schedule with warmup=500
9b1c3f5 Experiment: Add dropout 0.1 before each attention layer
4d8e7a2 Experiment: Switch from SSSL to L-only attention pattern
2f6a9b0 Experiment: Increase learning rate to 1e-3
...

# 成功的实验：commit 保留
# 失败的实验：git reset --hard 回退

这意味着你可以随时回溯 Agent 的决策链：它尝试了什么顺序、哪些成功了、哪些失败了。这在传统超参搜索中是做不到的——你只有一堆数字，没有"为什么"。

一个典型的实验夜间日志：

00:01 - Experiment #1: Increase heads from 8 to 12
00:06 - val_bpb: 0.8618 (improved from 0.8624) ✅
00:07 - Experiment #2: Try RMSNorm instead of LayerNorm
00:12 - val_bpb: 0.8621 (no improvement) ❌ → Revert
00:13 - Experiment #3: Add gradient clipping at 1.0
00:18 - val_bpb: 0.8615 (improved) ✅
00:19 - Experiment #4: Increase learning rate to 5e-4
00:24 - NaN loss! ❌ → Revert immediately
00:25 - Experiment #5: Try learning rate 2e-4 with cosine schedule
00:30 - val_bpb: 0.8609 (improved) ✅
...
07:58 - Experiment #110: Final best val_bpb: 0.8580

四、从 nanochat 到 autoresearch：技术基因的传承

4.1 nanochat：100 美元训练的 ChatGPT

autoresearch 的训练代码源自 Karpathy 的另一个项目——nanochat，口号是"100 美元能训练的最好的 ChatGPT"。

nanochat 用约 8000 行干净的 PyTorch 代码，实现了完整的 LLM 训练流水线：分词、预训练、微调、强化学习、推理、Web UI。在 8 块 H100 上 4 小时，你就能训出一个可以聊天的小型 ChatGPT。

autoresearch 是 nanochat 的极简单 GPU 版本——砍掉了分布式训练、微调、RLHF、推理服务，只保留了核心的训练循环。这种"减法"恰恰是为了让 Agent 能理解和修改代码。

为什么不能直接让 Agent 改 nanochat？ 因为 8000 行代码对当前 LLM 的上下文窗口来说太大了。Agent 很难在 8000 行代码中做出局部一致的修改。630 行的 train.py 刚好在 Agent 的"工作记忆"范围内。

4.2 训练数据：Fineweb-Edu

autoresearch 使用 Fineweb-Edu 数据集——一个从网页中筛选教育质量内容的大规模数据集。选择这个数据集有几个原因：

1. 高质量： 经过教育质量评分过滤，噪声数据少
2. 多样性： 覆盖科学、技术、人文等多个领域
3. 规模适中： 足够 5 分钟训练使用，不需要复杂的采样策略

# prepare.py 中的数据准备逻辑（简化）
DATASET_NAME = "HuggingFaceFW/fineweb-edu"
DATASET_SUBSET = "sample-10BT"  # 10B tokens 采样子集
VOCAB_SIZE = 8192
MAX_SEQ_LEN = 1024

五、实战进阶：如何让 Agent 研究得更聪明

5.1 优化 program.md：策略即代码

默认的 program.md 是一个最小可行版本。以下是几种经过社区验证的改进策略：

策略一：分阶段研究

## Research Phases

### Phase 1: Architecture Search (first 2 hours)
- Only modify model dimensions (DEPTH, HEADS, DIM)
- Goal: find the best architecture for this time budget
- Do NOT touch optimizer settings in this phase

### Phase 2: Optimization (next 2 hours)
- Freeze architecture at Phase 1's best result
- Only modify optimizer settings (LR, schedule, weight decay)
- Try: cosine annealing, warmup, gradient accumulation

### Phase 3: Attention Patterns (final 2 hours)
- Freeze everything from Phase 2
- Experiment with: SSSL, full attention, sliding window size
- Try: Flash Attention if not already used

策略二：鼓励大胆尝试

## Risk Tolerance

- For the first 20 experiments, make BOLD changes
  (e.g., double the model size, halve the learning rate)
- After finding a promising direction, make INCREMENTAL changes
- If you're stuck (no improvement for 10 experiments), 
  try something completely different
- Don't be afraid to revert to an earlier checkpoint
  and try a new direction

策略三：记录实验笔记

## Documentation

After each experiment, briefly note:
1. What you changed
2. Why you thought it might help
3. What actually happened
4. What you learned

This creates a growing knowledge base that helps you 
make better decisions over time.

5.2 多 Agent 协作

autoresearch 的架构天然支持多 Agent 扩展。你可以同时运行多个 Agent，每个使用不同的 program.md：

# Agent A: 专注架构搜索
cat > program_A.md << 'EOF'
Focus ONLY on architecture changes. 
Try different depths, head counts, and dimensions.
EOF

# Agent B: 专注优化器调参
cat > program_B.md << 'EOF'
Focus ONLY on optimizer tuning.
Try different learning rates, schedules, and weight decay values.
EOF

# 同时启动两个 Agent（在不同的 worktree 中）
git worktree add ../autoresearch-arch HEAD
git worktree add ../autoresearch-opt HEAD

这种并行化策略相当于同时雇佣了两个"实习生"，各自专注一个方向，互不干扰。

5.3 小算力适配：MacBook 也能跑

Karpathy 在 README 中专门给了小算力平台的调参建议：

降低模型复杂度：

# 原始配置（H100）
DEPTH = 8
MAX_SEQ_LEN = 1024
VOCAB_SIZE = 8192
TOTAL_BATCH_SIZE = 2**16

# MacBook 适配
DEPTH = 4                  # 减半层数
MAX_SEQ_LEN = 256          # 大幅缩短序列
VOCAB_SIZE = 2048          # 缩小词表
TOTAL_BATCH_SIZE = 2**14   # 减小 batch size（约 16K tokens）

换数据集：

对于小模型，Fineweb-Edu 的多样性太强了，模型学不动。Karpathy 建议用 TinyStories——一个由 GPT-4 生成的儿童短故事数据集，范围窄得多，小模型也能看到明显的训练进展。

注意力模式简化：

# 原始：交替带状注意力（计算密集）
WINDOW_PATTERN = "SSSL"  # Sliding-Window, Sliding-Window, Sliding-Window, Local

# 适配：纯局部注意力（计算高效）
WINDOW_PATTERN = "L"     # Local attention only

社区已经有多个适配分支：

六、与 AutoML 的本质区别

看到这里，你可能会想：这不就是 AutoML / NAS（Neural Architecture Search）吗？

不完全一样。autoresearch 和传统 AutoML 有几个根本性的区别：

6.1 搜索策略：LLM 推理 vs 贝叶斯优化

传统 AutoML 在一个预定义的搜索空间中采样，比如"学习率在 [1e-5, 1e-1] 中选"、"层数在 [2, 12] 中选"。autoresearch 的 Agent 可以做更灵活的事情——比如"在 LayerNorm 之前加一个 Dropout 层"或"实现一个自定义的学习率 warmup 策略"。这些修改不在任何搜索网格中。

6.2 LLM 作为研究者：代码理解 + 因果推理

autoresearch 的 Agent 不只是在试参数，它在理解代码。

当 Agent 看到这样的训练日志：

Step 1000 | val_bpb: 0.8710
Step 2000 | val_bpb: 0.8624
Step 3000 | val_bpb: 0.8589
Step 4000 | val_bpb: 0.8578
Step 5000 | val_bpb: 0.8576
Step 6000 | val_bpb: 0.8575  ← 几乎不动了

它可以推理出："模型已经进入收敛平台期，单纯增加训练步数不会有太大提升。我应该尝试调整学习率调度器，在后期降低学习率，或者修改模型架构来打破瓶颈。"

这种因果推理能力是贝叶斯优化做不到的——它只能看到"这组参数效果不好"，但不知道为什么，更不会提出结构性改进。

6.3 失败处理：自诊断 vs 跳过

传统 AutoML 遇到失败（NaN loss、OOM）就是跳过这组配置。autoresearch 的 Agent 可以自主诊断和修复：

Agent: "Training produced NaN loss. Let me check what changed...
        I increased LR from 3e-4 to 1e-2. That's way too high.
        Let me try 1e-3 instead, and add gradient clipping."

这种自修复能力极大地提高了搜索效率——一次失败不是浪费，而是学习机会。

七、性能基准：Agent 一晚上到底能做多少？

7.1 Karpathy 的原始实验

在 Karpathy 的 H100 上，12 小时内 Agent 跑了 110 次实验，val_bpb 从 0.8624 降到 0.8580。让我们分析一下这些数字：

• 实验效率： 约 9.2 次/小时，略低于理论的 12 次/小时。差额来自 Agent 的思考时间和 Git 操作。
• 改进幅度： val_bpb 降低了 0.0044，相对改进约 0.51%。
• 成功率： 根据社区复现，大约 30-40% 的实验能带来改进。

7.2 不同平台的性能参考

7.3 成本效益分析

以 H100 为例（云服务器约 $2-3/小时）：

• 12 小时成本：约 $30
• 110 次实验：约 $0.27/次
• 相当于一个初级研究员 1-2 天的工作量

如果考虑人类研究员的时薪（即使是实习生，$20-30/小时），autoresearch 的性价比是碾压级的。当然，目前它只能处理特定类型的研究任务——但这个领域正在快速扩展。

八、进阶玩法：从 LLM 研究到软件工程

8.1 AutoResearch 思想的泛化

autoresearch 的核心思想——"让 AI Agent 在一个受控环境中自主迭代"——不限于 LLM 训练。社区已经将它扩展到多个领域：

软件开发领域： smallnest/autoresearch 项目将 Karpathy 的方法迁移到软件开发，通过多 AI Agent 交叉审核、5 维度量化评分和反馈驱动迭代，构建了全自动的软件开发系统。该系统能在约 10 分钟内自主完成中等复杂度的开发任务，达到 9.0/10 的代码质量标准。

科学计算领域： 有研究者用类似框架自动优化 CFD（计算流体力学）模拟参数，一夜之间完成了原本需要一周的参数搜索。

A/B 测试优化： 电商团队用类似循环自动优化推荐算法参数，每天自动跑几十组实验。

8.2 构建你自己的 AutoResearch 系统

如果你想把 autoresearch 的思路应用到自己的领域，以下是核心设计原则：

原则一：固定评估指标。 必须有一个单一、明确的指标来判断改进。模糊的"感觉更好了"不行。

原则二：约束修改范围。 Agent 只能修改一个（或少数几个）文件。无约束的修改会导致不可预测的行为。

原则三：固定时间预算。 每次实验必须在相同的时间/计算预算下进行，否则无法公平比较。

原则四：完整的历史记录。 每次实验的输入、输出、决策原因都要记录。这是 Agent 学习的基础，也是人类审计的基础。

原则五：快速失败。 一次实验的时间越短，搜索效率越高。宁可牺牲单次实验的信息量，也要保证高吞吐量。

# 一个通用的 AutoResearch 框架骨架
class AutoResearchFramework:
    def __init__(self, config):
        self.target_file = config["target_file"]  # Agent 可修改的文件
        self.eval_metric = config["eval_metric"]  # 评估指标
        self.time_budget = config["time_budget"]  # 时间预算（秒）
        self.best_score = float('inf')             # 最佳分数
        self.history = []                           # 实验历史
    
    def run_experiment(self, agent, hypothesis):
        """执行一次实验"""
        # 1. Agent 修改目标文件
        agent.modify(self.target_file, hypothesis)
        
        # 2. Git 留痕
        self.git_commit(hypothesis)
        
        # 3. 运行评估
        score = self.evaluate(timeout=self.time_budget)
        
        # 4. 决策
        if score < self.best_score:
            self.best_score = score
            self.history.append({
                "hypothesis": hypothesis,
                "score": score,
                "status": "improved"
            })
            return True
        else:
            self.git_reset()
            self.history.append({
                "hypothesis": hypothesis,
                "score": score,
                "status": "reverted"
            })
            return False
    
    def run_loop(self, agent, max_experiments=100):
        """主循环"""
        for i in range(max_experiments):
            # Agent 基于历史形成新假设
            hypothesis = agent.propose(self.history)
            
            # 执行实验
            success = self.run_experiment(agent, hypothesis)
            
            # 日志
            status = "✅" if success else "❌"
            print(f"[{i+1}/{max_experiments}] {status} "
                  f"{hypothesis[:50]}... "
                  f"(best: {self.best_score:.6f})")

九、局限与风险

9.1 当前局限

局限一：搜索空间受限于 LLM 的代码理解能力。 如果训练代码太复杂（比如混合专家模型、分布式训练），Agent 可能无法做出有效的修改。这就是为什么 autoresearch 要把代码压到 630 行。

局限二：5 分钟训练可能不足以评估某些改进。 比如正则化策略的效果通常在长时间训练后才会显现。5 分钟的短期训练可能会误判某些有效改进为无效。

局限三：单一指标的优化可能导致过拟合。 Agent 只看 val_bpb，可能会找到一些在验证集上"刷分"但泛化性差的技巧。

局限四：不具备理论基础。 Agent 的修改基于经验推理，不是基于理论推导。它可能会发现一些"works but nobody knows why"的技巧。

9.2 安全与伦理考量

代码执行风险。 Agent 可以执行任意 Python 代码（通过 uv run train.py）。如果 Agent 修改了 train.py 中的代码来执行恶意操作（比如删除文件、网络请求），后果可能很严重。Karpathy 建议在沙盒环境中运行，并禁用 Agent 的所有权限。

研究诚信问题。 如果 Agent 发现了一个在验证集上有效但不具备泛化性的"技巧"，而我们不加审查就使用它，可能会导致有缺陷的研究结果发表。

对研究员职业的影响。 autoresearch 的终极愿景是自动化研究过程，这不可避免地引发了对研究员职业前景的讨论。Karpathy 的观点是：研究员会从"做实验"转向"设计实验策略"，就像程序员从"写汇编"转向"写高级语言"。

十、生态与未来

10.1 社区生态

autoresearch 开源不到三个月，已经催生了丰富的社区生态：

平台适配： macOS、Windows、AMD GPU 的分支已经出现，让更多人可以参与。

领域扩展： 从 LLM 训练扩展到软件开发、科学计算、A/B 测试等多个领域。

工具链集成： 有项目将 autoresearch 与 Weights & Biases、MLflow 等实验追踪工具集成，提供更丰富的可视化和分析。

多 Agent 框架： 一些项目在探索多 Agent 协同——一个 Agent 提出假设，另一个 Agent 实现修改，第三个 Agent 评估结果。这种分工模式更接近真实的研究团队。

10.2 未来方向

方向一：多 GPU 和分布式训练。 当前的单 GPU 限制是最大的瓶颈。未来版本可能会支持多 GPU 训练，让 Agent 可以探索更大的模型和更长的训练时间。

方向二：自动 program.md 优化。 既然 program.md 本身也可以被优化，为什么不写一个"元 Agent"来自动调优研究策略？

方向三：跨领域迁移。 将在 LLM 训练上学到的"研究经验"迁移到其他领域，比如蛋白质结构预测、材料科学等。

方向四：人机协同研究。 不是完全自主，而是 Agent 提出候选方案，人类做最终决策。这可能是最现实的短期路径。

总结

autoresearch 的意义不在于它能训练出最好的模型——它不能。它的意义在于它展示了一种全新的研究范式：

1. 人类写策略，AI 做实验。 研究员的角色从"做实验"变成了"设计实验策略"，用自然语言编程 AI 的研究行为。

2. 极简架构，无限可能。 630 行代码、3 个核心文件、1 块 GPU。约束出创造力。

3. Git 驱动的可审计研究。 每次实验都是一个 commit，成功保留，失败回退。完整的研究审计日志。

4. LLM 推理超越贝叶斯优化。 Agent 能理解代码、做因果推理、自主诊断失败——这是传统 AutoML 做不到的。

5. 从研究到工程的泛化。 autoresearch 的核心思想——受控环境中的自主迭代——可以应用到任何有明确评估指标的优化问题。

Karpathy 在 README 的开头写了一段科幻式的描述：终有一天，前沿 AI 研究完全由自主的 AI Agent 集群完成，代码已经进化到人类无法理解的程度。然后他说：这个仓库就是这一切的起点。

也许他只是在开玩笑。但 630 行代码，66,000 个 star，和一个蒸完桑拿后的推文——这确实可能是某种起点。

项目地址： https://github.com/karpathy/autoresearch

相关项目：

• nanochat: https://github.com/karpathy/nanochat
• autoresearch-macos: https://github.com/miolini/autoresearch-macos
• autoresearch-mlx: https://github.com/trevin-creator/autoresearch-mlx
• autoresearch-win-rtx: https://github.com/jsegov/autoresearch-win-rtx