人写规则,Token做实验:从Karpathy的autoresearch看AI应用优化新范式

把人从试错循环中解放出来,用Token一夜跑完500轮实验

目录:

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

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

autoresearch 的核心方法论

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

文件角色谁来修改
prepare.py数据准备 + 评估工具不修改
train.py模型 + 优化器 + 训练循环AI Agent
program.mdAgent 的行为指令人类

每轮实验的流程:

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 自动优化。

结构同构

autoresearchAI 客服 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 月已经在发生的事。


See also