目录:

Karpathy 在 2026 年 3 月开源了 autoresearch，两周内收获近 5 万 Star。项目本身很简单——让 AI Agent 自动修改 LLM 训练代码、跑实验、看指标、保留好的、丢弃差的，一夜循环 100 轮。但简单的背后藏着一个深刻的范式转移：在 AI 时代，人的角色从”做实验的人”变成了”设计实验规则的人”，而试错循环本身，交给 Token 去完成。

这不只是 AI 研究的事。任何可以量化评估、快速迭代的业务场景，都可以套用这个范式。

autoresearch 的核心方法论

先看 Karpathy 做了什么。整个项目只有三个核心文件：

文件

角色

谁来修改

prepare.py

数据准备 + 评估工具

不修改

train.py

模型 + 优化器 + 训练循环

AI Agent

program.md

Agent 的行为指令

人类

每轮实验的流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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）

五个条件逐条验证

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
✅ 指标可量化且低噪声
   temperature=0 时，同一 prompt + 同一问题 = 高度稳定的输出
   用 LLM-as-Judge 自动评分，无需人工

✅ 反馈循环极快
   跑 500 条测试 case 只需 30-60 秒
   一夜可以跑 500+ 轮迭代

✅ 搜索空间有约束
   只改一个文件：system_prompt.txt

✅ 变异是智能的
   LLM 天然理解自然语言，改 prompt 比改代码更在行

✅ 实验成本低且完全可逆
   成本 = API token 费用（几美分/轮）
   零外部性：不接触真实客户，改坏了回滚即可

实现架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# 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 示例

这是”人写规则”的部分——定义优化方向和边界：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 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.

这段话的核心洞察是：优化过程本身正在从人类的认知域转移到机器的计算域。

传统的优化循环：

1
2
3
人类产生假设 → 人类实施 → 人类评估 → 人类决策 → 重复
     ↑                                           │
     └───────────── 周级循环 ─────────────────────┘

autoresearch 范式：

1
2
3
4
5
6
人类定义规则和边界（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 月已经在发生的事。

AI  AI-agents  LLM  prompt-engineering  best-practices  autoresearch 

原文链接: 人写规则，Token做实验：从Karpathy的autoresearch看AI应用优化新范式