目录:
Karpathy 在 2026 年 3 月开源了 autoresearch,两周内收获近 5 万 Star。项目本身很简单——让 AI Agent 自动修改 LLM 训练代码、跑实验、看指标、保留好的、丢弃差的,一夜循环 100 轮。但简单的背后藏着一个深刻的范式转移:在 AI 时代,人的角色从"做实验的人"变成了"设计实验规则的人",而试错循环本身,交给 Token 去完成。
这不只是 AI 研究的事。任何可以量化评估、快速迭代的业务场景,都可以套用这个范式。
autoresearch 的核心方法论
先看 Karpathy 做了什么。整个项目只有三个核心文件:
| 文件 | 角色 | 谁来修改 |
|---|---|---|
prepare.py | 数据准备 + 评估工具 | 不修改 |
train.py | 模型 + 优化器 + 训练循环 | AI Agent |
program.md | Agent 的行为指令 | 人类 |
每轮实验的流程:
Agent 读取 program.md(人定义的策略)
│
▼
Agent 修改 train.py(提出一个假设)
│
▼
训练 5 分钟(固定时间预算)
│
▼
评估 val_bpb(固定指标)
│
├─ 指标提升 → 保留修改
└─ 指标下降 → 回滚
│
▼
记录实验日志 → 开始下一轮
一夜下来,大约 100 轮实验,相当于一个研究员一两周的手动调参工作量。
这个范式为什么能 Work?
抽象来看,autoresearch 能成立需要五个前提条件:
1. 指标可量化且低噪声。 val_bpb(验证集上的 bits per byte)是确定性的数学量,跑同样的配置会得到几乎相同的结果。不需要人类判断"好不好"。
2. 反馈循环极快。 每轮只要 5 分钟,Agent 不需要等人审批,不需要等市场反馈,改完立刻知道结果。
3. 搜索空间有约束。 Agent 只能改 train.py 一个文件,不是漫无目的地改整个系统。约束让搜索高效。
4. 变异是"智能"的。 和随机搜索不同,LLM 理解代码语义。它不会把 learning_rate 改成负数——它会基于实验日志推理"上一轮加大 batch size 有效,这轮试试配合降低学习率"。
5. 实验成本低且可逆。 一块 GPU 的电费,改坏了回滚 git checkout 就行。没有外部副作用。
这五个条件构成了一个判断框架:你的业务场景满足几条,就有多大的可能性套用这个范式。
举一反三:AI 客服 Prompt 自动优化
外呼话术看似可以套用,但仔细检验发现有硬伤——实验对象是真人客户,每通电话都是不可逆的品牌接触,而且转化率噪声极大(同样的话术,遇到不同客户结果完全不同)。五个条件只满足两三个。
但有一个场景几乎完美满足全部五个条件:AI 客服系统的 System Prompt 自动优化。
结构同构
| autoresearch | AI 客服 Prompt 优化 |
|---|---|
prepare.py — 评估数据集 | 标注好的客户问题集 + 标准答案 |
train.py — 被修改的代码 | System Prompt + Few-shot 示例 |
program.md — 人定义策略 | 优化方向和合规红线 |
val_bpb — 评估指标 | 准确率 / 解决率 / 幻觉率 |
| 5 分钟跑一轮 | 30 秒跑一轮(几百条测试 case) |
五个条件逐条验证
✅ 指标可量化且低噪声
temperature=0 时,同一 prompt + 同一问题 = 高度稳定的输出
用 LLM-as-Judge 自动评分,无需人工
✅ 反馈循环极快
跑 500 条测试 case 只需 30-60 秒
一夜可以跑 500+ 轮迭代
✅ 搜索空间有约束
只改一个文件:system_prompt.txt
✅ 变异是智能的
LLM 天然理解自然语言,改 prompt 比改代码更在行
✅ 实验成本低且完全可逆
成本 = API token 费用(几美分/轮)
零外部性:不接触真实客户,改坏了回滚即可
实现架构
# prompt_autoresearch.py — 核心循环(伪代码)
import json
def run_experiment(current_prompt, eval_dataset, agent):
# 1. Agent 提出修改假设
hypothesis = agent.propose_change(
current_prompt=current_prompt,
experiment_log=load_log(), # 历史实验记录
strategy=load_file("program.md") # 人定义的优化方向
)
# 2. Agent 修改 prompt
new_prompt = agent.apply_change(current_prompt, hypothesis)
# 3. 跑评估
scores = []
for case in eval_dataset:
response = llm.chat(system=new_prompt, user=case["question"])
score = judge.evaluate(
response=response,
expected=case["expected_answer"],
criteria=case.get("criteria", "accuracy")
)
scores.append(score)
avg_score = sum(scores) / len(scores)
# 4. 保留或回滚
if avg_score > current_best_score:
save_prompt(new_prompt)
log_experiment(hypothesis, avg_score, status="accepted")
return new_prompt, avg_score
else:
log_experiment(hypothesis, avg_score, status="rejected")
return current_prompt, current_best_score
# 主循环:一夜 500 轮
# generated by hugo's coding agent
program.md 示例
这是"人写规则"的部分——定义优化方向和边界:
# AI 客服 Prompt 优化策略
## 优化目标
- 主指标:问题解决准确率(当前 78%,目标 90%+)
- 副指标:回复简洁度(当前平均 180 字,目标 < 120 字)
- 合规红线:不得出现价格承诺、不得编造政策
## 优化方向建议
1. 先优化退款类问题(当前准确率最低,62%)
2. 尝试增加 few-shot 示例
3. 尝试将长规则拆分为条件分支
4. 注意:不要删除合规相关的规则
## 实验纪律
- 每次只改一个方面,便于归因
- 如果连续 3 轮无提升,尝试完全不同的方向
- 记录每次修改的假设和结果
更深一层:这个范式的本质是什么?
Karpathy 在 README 里写了一段很有预见性的话:
Research is now entirely the domain of autonomous swarms of AI agents… The “code” is now a self-modifying binary that has grown beyond human comprehension. This repo is the story of how it all began.
这段话的核心洞察是:优化过程本身正在从人类的认知域转移到机器的计算域。
传统的优化循环:
人类产生假设 → 人类实施 → 人类评估 → 人类决策 → 重复
↑ │
└───────────── 周级循环 ─────────────────────┘
autoresearch 范式:
人类定义规则和边界(program.md)
│
▼
AI 产生假设 → AI 实施 → AI 评估 → AI 决策 → 重复
↑ │
└──────────── 分钟级循环 ────────────────┘
人的角色上移了一层——从循环内部的执行者,变成了循环外部的架构师。
这和软件工程的演进路径惊人地一致:
- 汇编时代:人写每一条机器指令
- 高级语言时代:人写逻辑,编译器生成指令
- AI 时代:人写规则(program.md),AI 写逻辑并自我迭代
适用场景判断框架
不是所有业务都能套用这个范式。用这个清单快速判断:
| 条件 | 满足 | 不满足 |
|---|---|---|
| 指标可量化 | 代码性能、模型指标、Prompt 准确率 | “用户体验好不好”、品牌调性 |
| 反馈循环快 | 秒级-分钟级出结果 | 需要等市场反馈(天/周级) |
| 搜索空间可约束 | 改一个文件/一组参数 | 需要改整个系统架构 |
| 实验成本低 | GPU/Token 费用 | 真人客户、真实交易 |
| 实验可逆 | 回滚即可 | 已发出的消息、已拨的电话 |
满足 4-5 条 → 直接套用。 满足 3 条 → 加一层模拟预筛(先 AI 对 AI 模拟,再小批量真实验证)。满足 2 条以下 → 这个范式不适合,老老实实用人。
高适配场景举例
除了 AI 客服 Prompt 优化,以下场景同样高度适配:
- SQL 查询自动优化:指标 = 执行时间,搜索空间 = 查询语句,反馈 = 毫秒级
- 推荐算法特征工程:指标 = 离线 AUC,搜索空间 = 特征组合,反馈 = 分钟级
- 前端性能优化:指标 = Lighthouse 分数,搜索空间 = 代码实现,反馈 = 秒级
- CI/CD 流水线优化:指标 = 构建时间,搜索空间 = 配置参数,反馈 = 分钟级
写在最后
autoresearch 项目本身只有几百行代码,但它提出了一个值得每个技术管理者认真思考的问题:
你的团队里,有多少工作本质上是"试错循环"?这些循环中,有多少可以交给 Token 去跑?
答案可能比你想象的多。而那些率先把 program.md 写好的团队,将会在同样的时间窗口里,跑出比竞争对手多一个数量级的实验。
人写规则,Token 做实验——这不是未来,这是 2026 年 3 月已经在发生的事。