# 拆解 Karpathy 的 Autoresearch：Agent 如何进行自进化？

> 作者：晨旭｜发布：2026-06-01｜系列：动手落地AI
> 来源：https://chenxu.xin/writing/karpathy-autoresearch-self-evolving

自进化不是模型在黑盒里重构自己的脑神经。结合自进化 Agent 综述与 Karpathy 的 autoresearch 项目源码，看清进化真正发生在模型外围的哪一层，以及怎么把它搬到 RAG 优化上。

---

在探讨 AI 技术时，最容易陷入的误区就是把 AI 拟人化。比如，最近一直听到 Agent 自进化，下意识地就以为是大模型在黑盒子里反思自己，每完成一次任务，就自动重构一遍自己的脑神经，从此变得更聪明。

但在拆开论文和项目代码后会发现，**自进化并不总是发生在模型参数本身**。更多时候，它发生在模型外围的系统里：记忆怎么更新，prompt 怎么改写，工具怎么生成，代码怎么回滚，工作流怎么被保留下来……

换句话说，Agent 自进化，更多时候不是大模型突然拥有了「生命」，而是人类工程师为它搭好了一个可以持续试错、评估、选择和沉淀的循环。

这篇文章，是结合学术界关于自进化 Agent 的前沿理论，以及 Andrej Karpathy 的开源项目 `autoresearch`，进行的一次从理论到源码的探索。一共会分以下三部分：

- 理论框架：自进化 Agent 到底是进化什么？
- 代码拆解：autoresearch 如何让 Agent 通宵做实验？
- 落地思考：把自进化循环用到 RAG 优化里

参考资料：[A Survey of Self-Evolving Agents](https://openreview.net/forum?id=CTr3bovS5F)、[karpathy/autoresearch](https://github.com/karpathy/autoresearch)

## Agent 自进化到底是什么？

之前的文章中有多次探讨过 Agent 的记忆和反思模块，并做过一个比喻：大模型就像一个极其聪明但患有重度失忆症的盲人顾问。你给它什么上下文，它就基于什么上下文出主意。而 Agent 自行思考，其实是用 Python 写一个 `while` 循环，不断地把上一步的执行结果喂给它，让其继续输出。

那这个 Agent 自进化又多出了些什么呢？简单来说，其实是将大模型无缝接入到了一个进化循环中：

- **变异**：大模型作为点子生成器，基于当前的困境或瓶颈，提出一段新的代码或新的 prompt。
- **评估**：外围的 Python 脚本在一个安全的沙箱环境中运行这段新代码，并给出一个客观的量化评分。
- **选择**：如果评分变高了，就保留这次修改；如果变低了或者代码崩溃了，就回滚。

顺着这个循环逻辑，最近一篇综述论文（A Survey of Self-Evolving Agents）将其核心机制拆解为了三个维度。

### 1、What to Evolve（进化什么对象？）

**进化记忆**：Agent 在不断试错中，会将成功的经验总结成 SOP，写进记忆库。下次遇到类似问题，它会先翻这个笔记本。

**进化工具**：如果现有的 API 不好用，Agent 可以自己写一段 Python 脚本，将其封装成一个新的 Tool，存入自己的工具箱中供之后调用。

**进化架构**：Agent 可以修改自己的思考链路。比如一开始它只会简单的 ReAct，后来它发现需要多加一层自我纠错，它就会把这个流程固化下来。

### 2、When to Evolve（什么时候发生进化？）

**任务内进化**：这就像我们在考试时，写到一半发现思路不对，立刻在草稿纸上划掉重来。是在线的、实时的纠偏。

**任务间进化**：这像是我们考完试后的复盘分析。Agent 完成了一天的工作，在夜深人静时（离线状态），通过批量分析今天的执行日志，提炼出新的规则或更新模型权重。

### 3、How to Evolve（如何驱动进化？）

这是让飞轮转起来的最核心的一点。

大模型自己是不知道绝对对错的，必须有环境给它提供**进化压力**。这种反馈可以是一段具体的文本评价，也可以是一个数值奖励。有了一把标尺，Agent 才知道自己的突变到底是进化，还是退化。

理论听起来可能有些抽象。下面通过 Karpathy 的 autoresearch 项目代码，来进一步理解自进化 Agent 的具体实现。

## 拆解 Autoresearch 的项目代码

> 「曾经，前沿的 AI 研究是由肉体计算机（人类）在吃饭、睡觉之余完成的……那个时代一去不复返了。如今，研究完全是由天空中计算集群巨型结构上运行的自主 AI Agent 蜂群主导……」

简单来说，这个项目就是一个「LLM + Python 执行 + 评估脚本」的经典工程化闭环。整个项目最核心的文件只有 3 个：

- `prepare.py`：环境与数据准备（坚固地基，不可修改）
- `train.py`：模型训练代码（沙盒，Agent 唯一可以修改的地方）
- `program.md`：系统提示词（人类给 Agent 下达的终极指令）

Karpathy 的 `autoresearch` 其实也是一个[拉尔夫循环](/writing/agent-model-plus-harness)：给模型一个干净的上下文，让它去执行任务，执行完就物理死亡，然后在新循环中读取外部硬盘上的进度继续干活。

下面让我们深入这个闭环，看看它究竟是如何转起来的。

### 1、规则的制定者：program.md

在这个系统中，人类唯一要做的，就是编写 `program.md`。这其实就是一个长篇的 System Prompt，它向大模型清晰地定义了它的角色、权限和目标。下面是几个最核心的指令设计：

**（1）明确界限（What you can / cannot do）**

- 能做的事：你只能修改 `train.py`。你可以改模型架构、优化器、超参数（比如批次大小、层数）。
- 不能做的事：绝对不准碰 `prepare.py`，不准安装新包，不准修改评估指标。

**（2）唯一北极星指标（The Goal）**

获得最低的 `val_bpb`。不要管训练时间，因为系统强制规定每次训练只跑 5 分钟。只要代码不崩，在 5 分钟内跑出更低的 `val_bpb`，你就是 winner。

**（3）奥卡姆剃刀原则（Simplicity criterion）**

指令明确告诉 Agent：All else being equal, simpler is better（同等条件下，越简单越好）。

如果 Agent 增加了一大堆补丁代码，仅仅让 `val_bpb` 降低了 0.001，这就不是进化，这是在制造技术债，应当予以抛弃。相反，如果删掉一段陈旧冗余的代码，结果持平，这就是巨大的架构胜利。

Agent 并不是一个自由意志的载体，它完全是一个被 prompt 严格约束在特定状态机里的文本生成器。

### 2、进化法则：Git 版的适者生存

有了 prompt 之后，这只 Agent 究竟是怎么工作的呢？

它不能随便乱改文件，只能围绕 `train.py` 做一次次小优化：改一点代码，跑一次训练，看一次分数。分数变好，就活下来；分数变差，或者代码崩了，就被 git 无情回滚。



所谓的进化，就是 Agent 下令改几行代码，然后程序脚本去跑一下，最后再检验执行结果决定是否保留修改。因为设定了固定的 5 分钟时间预算，这意味着一小时能跑 12 个实验，一晚上如果按照 8 小时算能跑将近 100 个实验。

当第二天早上醒来，就会看到一个名为 `results.tsv` 的台账，上面记录了这 100 次修改的存与亡。



### 3、沙盒里的基因：train.py

为了更有体感，我们最后来看一下 Agent 到底在改些什么。在 `train.py` 中，预留了大量的参数供 Agent 调优。



大模型通过阅读源码，结合它庞大的世界知识（它知道什么是 AdamW，什么是学习率预热），在 `program.md` 的驱使下，不断修改这些变量，甚至是重写 `Block` 类里的神经网络结构。然后通过 5 分钟的微型训练，验证自己的猜想。

补充一点：这里 autoresearch 的自进化，并不是让外层大模型自己更新参数。它更像一个研究员，负责读代码、提想法、改 `train.py`、跑实验、看指标，再决定保留还是回滚。**真正被进化的，是 `train.py` 这套训练系统**，包括模型架构、优化器、超参数、训练循环等。每次运行时，里面的小 GPT 模型参数会被正常训练更新；但长期保留下来的，主要是更好的代码架构、git commit 和实验记录，而不是外层 Agent 自己的大脑权重。

（当然，论文里确实提到过「进化模型参数」这条路线，只是 autoresearch 这个项目更像是工程系统的自进化，而不是大模型本体的自我改造。）

## 落地思考

看到这里，可能会觉得有些摸不着头脑。这是 AI 大牛用来训练底层模型的高级玩具，和我们日常工作有什么关系呢？

关系其实非常大。**自进化架构的本质，是将人工调参的苦力活，转嫁给大模型自身的试错机制。**

回想一下在落地 RAG 时的痛点：我们需要手动调整 Chunk Size、Overlap，纠结是用 BM25 还是向量检索。通常是改个参数，跑几条测试用例，凭感觉决定好坏。

如果借鉴 `autoresearch` 的思路，是不是就可以尝试搭建一个 RAG 的自进化环境：

- **准备环境（`prepare.py`）**：提前人工标注好 100 个「问题-标准答案」的测试集，并写好一个用大模型进行自动打分的评估脚本。这部分锁死，不可以动。
- **基因文件（`rag_pipeline.py`）**：将 RAG 链路中所有的参数和检索逻辑暴露在这个文件中。
- **指令（`program.md`）**：让 Agent 观察当前的召回率和准确率，提出新的参数组合或检索策略（比如引入混合检索），修改代码，并运行那 100 个测试用例。
- **循环迭代**：分数变高则 git commit 保留，变低则回滚。

这样，（理想情况下）就可以让这个 RAG 系统在周五下班后自己跑一个周末。周一早上，得到的可能就是一个经过了几百次排列组合后，最契合当前业务数据集的 RAG 链路。

## 最后

所以，真正有价值的，并不是 LLM 生成代码的速度又快了多少，而是人类工程师如何定义那个 5 分钟，如何设计那个 `val_bpb`，以及如何规定什么可以改、什么绝对不能碰。

自进化听起来很科幻，但落到工程里，其实就是：

> 能不能为一个具体任务，搭出一套可执行、可评估、可回滚、可复用的循环？

## 核心结论

- Agent 自进化并不总是发生在模型参数本身，更多时候发生在模型外围的系统里——记忆怎么更新、prompt 怎么改写、工具怎么生成、代码怎么回滚。它不是模型突然有了生命，而是人类工程师搭好了一个可持续试错、评估、选择和沉淀的循环。（判断 · 把握较大）
  永久链接：https://chenxu.xin/writing/karpathy-autoresearch-self-evolving#self-evolution-happens-outside-the-model
- 把大模型接入进化循环只需三步：变异（模型基于当前瓶颈提出新代码或新 prompt）、评估（脚本在沙箱里运行并给出量化评分）、选择（分数变高就保留，变低或崩溃就回滚）。（把握较大）
  永久链接：https://chenxu.xin/writing/karpathy-autoresearch-self-evolving#evolution-loop-is-mutate-eval-select
- 大模型自己是不知道绝对对错的，必须由环境提供进化压力。有了一把标尺（文本评价或数值奖励），Agent 才知道自己的突变到底是进化还是退化。这是让飞轮转起来最核心的一点。（判断 · 把握较大）
  永久链接：https://chenxu.xin/writing/karpathy-autoresearch-self-evolving#environment-provides-evolutionary-pressure
- autoresearch 里被进化的是 train.py 这套训练系统——模型架构、优化器、超参数、训练循环，而不是外层大模型自己的权重。长期保留下来的是更好的代码架构、git commit 和实验记录。（把握较大）
  永久链接：https://chenxu.xin/writing/karpathy-autoresearch-self-evolving#autoresearch-evolves-the-system-not-the-brain
- 真正有价值的不是 LLM 生成代码的速度，而是人类工程师如何定义那个「5 分钟」、如何设计那个 val_bpb，以及如何规定什么可以改、什么绝对不能碰。（判断 · 把握较大）
  永久链接：https://chenxu.xin/writing/karpathy-autoresearch-self-evolving#human-value-is-defining-the-constraints

---

本文出自晨光里的AI（https://chenxu.xin），作者晨旭。
引用时请保留来源链接。文中标注「判断」「假设」的部分是作者的个人看法，不是事实。
