3 月初，Andrej Karpathy 开源了一个叫 AutoResearch 的项目。
没有复杂的 Agent 框架，没有花哨的多 Agent 协作，整个仓库核心就三个文件、约 630 行代码。但它做到了一件事：让 AI Agent 在你睡觉的时候自主跑 ML（Machine Learning，机器学习）实验，保留有效改进，丢弃无效尝试，第二天早上给你一份实验日志。
一觉醒来，上百次实验跑完，val_bpb（validation bits per byte，衡量模型压缩文本能力的指标，越低越好）持续下降。
开源三周，近 60k stars。
这篇文章，我会先拆解 AutoResearch 到底是怎么工作的，然后探讨一个更重要的问题：这个模式能迁移到哪些非 ML 的场景？
1. AutoResearch 在做什么
传统 ML 研究的循环是这样的：
研究员想 idea → 改代码 → 跑实验（等半小时到几小时）→ 看结果 → 想下一个 idea → 重复
这个循环里，人是瓶颈。跑实验那几个小时，人在摸鱼或者开会。结果出来之后，人还要花时间消化、思考下一步。
Karpathy 的做法是把这个循环完全交给 AI Agent：
Agent 提出改进 → 改代码 → 跑 5 分钟 → 自动评估 → 好就留、差就滚 → 下一个 idea → 重复
人只做一件事：写 program.md，定义 Agent 的研究策略。 然后去睡觉。
2. 三文件架构：极简到没法再减
整个项目只有三个核心文件：
program.md（人类唯一需要编写的文件）
Agent 的行为手册。定义了：可以做什么、不可以做什么、怎么判断好坏、怎么记录结果、永远不要停下来。人类的全部杠杆，都在这一个文件里。
prepare.py（不可修改）
数据下载、tokenizer 训练、dataloader、评估函数和时间预算常量。这个文件是"规则裁判"——program.md 明确禁止 Agent 修改它，确保评估标准和训练约束不被篡改。
train.py（Agent 唯一可修改的文件）
GPT 模型定义 + 优化器 + 训练循环。模型架构、超参数、batch size、优化器选择——一切都可以改。Agent 的全部创造力，都在这一个文件里施展。
3. 核心机制与 program.md
实验循环没有调度脚本或 cron job，而是 program.md 写给 Agent 的行为指令。 Agent 读完 program.md 后自主执行以下循环：
1. 创建实验分支（如 autoresearch/mar5），按日期命名，标记一轮实验批次
2. 改 train.py，提出一个实验想法
3. git commit 存档
4. uv run train.py 跑 5 分钟训练
5. 检查 val_bpb：降低了就保留，没降就 git reset 回滚
6. 无论结果如何，记一笔到 results.tsv
7. 回到第 2 步，永不停歇
每轮实验在独立的 git 分支上进行（如 autoresearch/mar5），今天一轮、明天换策略再开一轮，互不干扰。results.tsv 不提交到 git（untracked），只在本地记录所有尝试。它有 5 列：commit hash、val_bpb、peak memory（GB）、status（keep/discard/crash）和描述。人类回来扫一眼就知道 Agent 试了什么、哪些管用哪些不管用。
崩溃也不会让循环停下来。跑挂了，Agent 会查 run.log 判断：小 bug（typo、missing import）修了重跑；根本性问题（OOM、架构不可行）记一笔 crash 直接跳过。超过 10 分钟没跑完的实验也会被杀掉当失败处理。
program.md 对单次实验定义了三层约束：
探索边界：只能改 train.py，架构/超参/优化器全部可以动，但不能改评估函数，不能装新依赖。同等效果下越简单越好——删代码获得同样效果 = 大胜利。
判定规则：val_bpb，越低越好。有了客观、可量化、可自动计算的指标，Agent 才能独立判断好坏，不需要人介入。如果指标是主观的（比如"代码是否优雅"），这个循环就跑不起来。
时间预算：固定 5 分钟，且不只是口头约定——prepare.py 中有常量 TIME_BUDGET = 300，训练循环超时自动中断。所有实验直接可比，一晚上能跑约 100 次（12 次/小时 × 8 小时），自动找到在你的硬件上 5 分钟内能训出的最好模型。
而在整个循环层面，还有一条核心运行策略——永不停止。program.md 里写得很直白："人类可能在睡觉，你是自主的，如果没有 idea 了，想得更努力一点。" 你是研究员，不是助手。研究员不会干了两个实验就停下来问老板要不要继续。
Karpathy 在 README 里直接点明：program.md 本质上就是一个轻量级 "skill"。未来的"编程"，可能不是写代码，而是写 Agent 的行为策略——定义"做什么、怎么判断好坏、什么时候该坚持、什么时候该放弃"。
4. 落地场景探索：不止于 ML
AutoResearch 目前只做 ML 训练优化。但它的核心模式——"改→跑→评→保留/回滚"的自主循环——是通用的。
关键前提只有一个：你得有一个可自动计算的量化指标。
下面说几个可以复用这个模式的场景。
4.1 Prompt 自动调优
Agent 修改 System Prompt → 跑测试用例 → 通过率提升就保留，下降就回滚 → 循环。
这可能是最直接的迁移场景。Prompt Engineering 本身就是"试→评→调"的循环，自动化后效率提升可能是数量级的。量化指标天然存在：测试用例通过率、LLM-as-Judge 评分。
4.2 API 性能调优
Agent 修改服务配置（连接池、缓存策略、查询优化）→ 跑压测 → P99 延迟和吞吐量改善就保留 → 循环。
后端日常有大量"调参"工作：连接池大小、缓存 TTL、超时设置。最优值依赖具体负载模式，人工调优效率很低，但指标（P99、QPS、错误率）天然可量化，完美适配这个模式。
4.3 自动化测试进化
Agent 阅读源代码并生成测试用例 → 跑测试计算覆盖率 → 覆盖率提升且无误报就保留 → 循环。
测试质量可以通过变异测试客观衡量：把代码故意改坏，看测试能不能抓到。抓到越多，测试越好——这是一个完美的自动化指标。
5. 总结
AutoResearch 的代码量极少，设计极简，但思路极其深刻：
- 三文件架构：评估标准不可篡改 + 探索空间足够大 + 人类只编排策略
- 四步循环：改 → 跑 → 评 → 保留/回滚，用 Git 做版本控制，朴素但有效
- 三层约束 + 一条运行策略：探索边界、判定规则、固定时间预算，以及贯穿始终的"永不停止"
把这个模式迁移到新场景，核心工作就是定义好"一个文件 + 一个指标 + 一个时间预算"。挑战在于：很多领域没有 val_bpb 这种天然的量化指标，指标不靠谱 Agent 就会"刷分"；探索空间也要控制好，太窄没发挥余地，太宽容易失控。
但更值得关注的是这背后的趋势：人类的角色正在从"执行者"变成"系统设计者"。 Karpathy 不做任何具体实验，他设计评估标准、定义探索空间、编写研究策略，然后去睡觉。人类真正不可替代的贡献是——定义"什么叫好"，以及"在什么范围内探索"。
约 630 行代码，没有框架，没有依赖，没有花哨。
朴素，但击中本质。
项目地址：github.com/karpathy/au… MIT License | 59k+ Stars
