Loop Engineering:Karpathy 方法论,和那篇让它再快 5 倍的研究
本文原题《Loop Engineering: The Karpathy Method》,作者 @0xCodila。它把两件真事串成一条线:Karpathy 今年三月开源的 autoresearch——一个约 630 行、三个文件、能整夜自己跑实验调模型的小项目;以及随后 arXiv 上那篇 Bilevel Autoresearch 论文,用「在 loop 之上再套一个 loop」把同样的方法又推快了 5 倍。这两样我都核过:repo 和论文都真实存在、在海外技术社区被反复解读。中文翻译、重排、6 张配图本地化:Yaqin Hei(非原创,已保留原文出处)。
译者的话:为什么翻这篇
国内现在用 AI,绝大多数人还停在 2005 年用 Google 的姿势:输入一句、读一段回答、再输入一句——你是那台发动机,模型只是你每回合捡起又放下的一把扳手。
这篇点破的事很朴素但很扎心:真正把 AI 用出 10 倍的人,不是 prompt 写得更好、也不是拿到了什么秘密模型,而是把「自己盯着一步步问」换成了「定义一次目标、让它自己带 verifier 循环到达标」。区别就一个词——verifier。没有对结果的真检查,你跑一百轮也只是让 agent 反复给自己点赞。
对我最大的改变,是它把我起一个自动化任务的第一个动作给改了。以前上来就想「prompt 怎么写」,现在我先问自己三件事:这活儿有没有一个能自动判红 / 判绿的闸?值不值得每周重复?我的 token 预算扛不扛得住它乱试?这三问过不了,我就老老实实写个好 prompt,不碰 loop。它帮我省掉的,恰好是那些「看着很酷、上线就烧钱」的自动化。
如果你手里有个每周都要重复、又有测试 / 构建能当裁判的活儿,这篇末尾那段「LOOP 协议」提示词,你下周就能贴进任何一个模型里先跑起来——不需要 Claude Code,也不需要 Codex,先感受一下什么叫「让它自己迭代到 8 分以上」。
以下是正文
大多数人用 AI 的方式,和 2005 年用 Google 一模一样——输入点什么,读读返回的东西,再输入点什么。在你推它之前,AI 就那么干等着——你才是那台发动机,AI 只是你每回合捡起、又放下的一把扳手。
这套打法过去两年一直好用。现在不行了。
眼下从 AI 身上多榨出 10 倍的人,靠的既不是更好的 prompt,也不是什么秘密模型。他们在造 loop。 而把这个念头顶到你没法忽视的那个人,是 Andrej Karpathy。这篇文章会讲清楚:1)从零说明白一个 loop 到底是什么;2)带你看 Karpathy 本人怎么用;3)再讲一个能把这套方法再提升 5 倍的做法;4)给你上手的建议。
第一部分 · 基础
1.1 —— loop 到底是什么?
一个 prompt 是一条指令。你问,你得到一个答案,你决定下一步干什么。
一个 loop 是一个目标,AI 会朝它一直干到到达为止——不需要你坐在椅子上一步步喂 prompt。
AI 自己发现要做什么、规划怎么做、动手做、检查结果,如果还没到位——就把结果喂回去,再来一轮。你只定义一次目的。剩下的交给 loop。 三样东西决定它成或败:
- Verifier(验证闸) 才是把「重复」变成「进步」的东西。没有对结果的真检查,你手里就不是 loop——只是一个 agent 在反复认同自己。这个检查可以是一个测试的过 / 不过、一个指标的涨 / 跌、一次构建的通过 / 崩溃。没有闸,agent 就是自己给自己批作业。
- State(状态) 是让 loop 会学的东西。每一轮,AI 都得知道自己已经试过什么。没有它,它每个循环都重犯同一个错。旁边一个小文件,记下做完了什么、什么失败了、下一步是什么。明天的运行是接着跑,而不是从零开始。
- Stop condition(停止条件) 让它保持理智。一个没有出口的 loop 会一直跑到成功、崩溃,或者把你的账户榨干。每个能用的 loop 都有两种停法:目标达成,或者一条硬上限说「跑满 N 次就停下来报告」。
1.2 —— 你真的需要一个吗?先跑这个测试。
大多数文章在告诉你 loop 什么时候是个错误之前,就先把它卖给你了。
只有下面四条同时成立,一个 loop 才配得上它的成本。 缺一条,它的花费就超过回报。
- 任务会重复——至少每周一次。低于这个频率,搭建成本永远赚不回来。一次性的活,还是一个好 prompt 更合适。
- 验证是自动的——一套测试、一个类型检查器、一个 linter、一次构建。某个不需要你在场就能判活儿死活的东西。没有自动检查,你就又回到了逐个 diff 去读的老路——而那正是 loop 本该替你干掉的活儿。
- 你的 token 预算扛得住浪费——loop 会重读 context、会重试、会乱探。不管这一趟有没有产出,token 都在烧。这条随预算而变,所以它在 token 免费的人看来天经地义,在 $20 套餐的人看来鲁莽至极。
- agent 有真工具——日志、一个可复现的环境、能跑自己写的代码并看到哪里崩了的能力。没有这些,loop 就是在盲跑。
说句实在话: loop engineering 是真东西,但大多数人还用不上重型版本。如果你在一个 token 有限的消费级套餐上,一个重型 loop 会在生产力提升到来之前,先撞上你的速率上限或你的钱包。
第二部分 · Karpathy Loop
Karpathy 是怎么从「写 prompt」切到「跑 loop」的。 2026 年 3 月,Andrej Karpathy 开源了一个叫 autoresearch 的 GitHub 仓库。
三个文件。约 630 行代码。
一个月内,它拿到 66,000+ stars,《Fortune》杂志给它起了个名字:The Karpathy Loop(Karpathy 循环)。
—— karpathy/autoresearch ——
整个设置简单得近乎荒唐:
- train.py——训练脚本。唯一允许 agent 改动的文件。
- prepare.py——给模型打分的评估器。agent 碰不了它。如果能碰,它就会去把测试改简单,而不是把模型改好。
- program.md——告诉 agent 探索什么、遵守哪些约束的指令。agent 就在一个 loop 里跑:
读代码 → 提一个改动 → 训练五分钟 → 看结果有没有变好 → 好就 commit,不好就 roll back → 重复。
你去睡觉。醒来面对一份实验日志,和一个但愿更好的模型。
人类从不碰 train.py。 你写 program.md——执行交给 agent。结果是:
Karpathy 把它指向一个他已经用二十年经验亲手仔细调过的模型,让它跑了两天。
- agent 跑了 700 次实验
- 找到了 20 处他漏掉的改进
- 比如注意力机制里少了一个标量乘子,导致注意力在各个 head 上摊得太散
- 这不是 fuzzer 能抓的 bug——而是一个细心的人本可以找到、却没找到的微妙优化
因为人到第十二次实验就累了。 agent 一点都不会累。
Shopify CEO Tobi Lütke 拿它在一个内部模型上跑了一夜:
- 他醒来看到 19% 的质量提升
- 优化后的模型只有他之前那个的一半大小
- 小模型打赢了大模型——因为 agent 是冲着硬件去优化的,而不是默认「越大越好」
Karpathy 的核心洞见:如果你手里有一个客观指标,那跑实验的就不该是你。你才是瓶颈。 把自己从 loop 里挪走,让它跑。(Fortune 报道)
第三部分 · 五块积木
让一个 loop 跑起来的五个零件。 每一个能用的 loop——不管你是用 Claude Code、Codex 还是 bash 脚本搭的——都是由五块积木拼起来的。Claude Code 和 Codex 现在都把这五块凑齐了。
- Automation(自动化)—— 心跳。 某个按时间表、按事件、或按触发器点火的东西。在 Claude Code 里:
/loop管节奏,/goal管「跑到某个条件成立为止」。在 Codex 里:Automations 标签页。没有这颗心跳,你只是跑了一次脚本然后忘了它。那不是 loop。 - Skill(技能)—— 存项目知识, 让 agent 别每个会话都重新猜。你的约定、你的构建步骤、那件因为三个月前踩过坑而绝对不做的事。写一次进一个 markdown 文件,每一次运行都读。没有 skill,loop 每个循环都从零重新推导你的整个项目背景。有了 skill,意图会复利累积。
- Sub-agents(子 agent)—— 把「造的人」和「验的人」拆开。 写代码的那个模型,给自己批作业太手软了。换一套指令的第二个 agent,能抓住第一个自己说服了自己的地方。你的写手可以快而便宜,你的审稿人可以慢而严格。这种分离,就是质量的大头。
- Connectors(连接器)—— 让 loop 在你真实的环境里动手。 读你的 issue tracker、开一个 PR、戳一下 Slack、更新一张 Linear 卡片。一个只会说「这是修复方案」的 agent,和一个把修复真发出去、第二天早上告诉你的 loop,差的就是这个。
- Verifier(验证闸)—— 那道闸。 那个自动打回烂活儿的测试、类型检查或构建。其余全是水管。这才是让 loop 成为真 loop 的部分。 没有它,你就是在花钱雇一个 agent 通宵认同它自己。
第四部分 · Karpathy 之后
Bilevel —— loop 之上的 loop。 好玩的地方从这儿开始,嘿嘿。
2026 年 3 月,两位研究者在 arXiv 上发了一篇论文,叫 《Bilevel Autoresearch: Meta-Autoresearching Itself》。他们拿 Karpathy 的 loop,问了一个很简单的问题:
如果 autoresearch 本身也是一种研究——那你能不能用 autoresearch 去研究 autoresearch 这件事本身?
他们在第一个 loop 之上,又搭了第二个 loop:
- 内层 loop——干 Karpathy 原版干的事:提一个改动、训练、评估、留下或丢弃。
- 外层 loop——盯着内层 loop 干活,读它的代码和 trace,找出搜索过程本身卡在哪,然后生成改变内层搜索方式的新 Python 代码。接着把那段代码注入进去,让内层 loop 再跑一遍。
—— 结果: 在 Karpathy 的 GPT 预训练基准上——
- 相比标准的单层 loop,提升了 5 倍(-0.045 对 -0.009 val_bpb)
- 不是好 5%。是好 5 倍。
- 两个 loop 用的是同一个 LLM——你并不需要一个更聪明的模型来做元层
- 提升来自架构,而不是来自原始智力
外层 loop 到底发现了什么: 内层 loop 老是掉进同一批搜索模式。LLM 对「该试哪些优化」有先验,而它会一直回到那些先验上——哪怕它们早就不管用了。 外层 loop 打破了这些模式,办法是逼它往模型直觉本能回避的方向去探索。
论文结尾有一句值得坐下来想想的话:「如果 autoresearch 能 meta-autoresearch 它自己,那么原则上,它能 meta-autoresearch 任何有可度量目标的东西。」
第五部分 · 自己试一下
现在就跑一个 loop —— 不需要任何工具。 你不需要 Claude Code 或 Codex 就能感受到它怎么运转。把下面这段贴进任何一个 LLM,看看会发生什么:
你将在一个 loop 里工作,直到任务达到标准。
任务:
[准确描述你想产出什么]
成功标准(要严格):
- [标准 1]
- [标准 2]
- [标准 3]
LOOP 协议,每一轮重复:
1. PLAN(规划) —— 说出下一个单一步骤。
2. DO(执行) —— 产出或改进作品。
3. VERIFY(验证)—— 按每条标准给结果打 1-10 分。
要残酷地诚实。逐条列出还弱在哪。
4. DECIDE(决定)—— 若每条标准都到 8 分及以上,打印 FINAL 并停止。
否则打印 ITERATING 再来一轮,先修最弱的那条。
规则:
- 在每条标准都到 8 分或以上之前,绝不宣称完成。
- 每一轮都必须修掉上一次 VERIFY 里最弱的分。
- 不要问我问题。做一个合理的假设,然后继续。
开始。
模型会起草、拿你的标准给自己的活儿打分、找出弱点、重写,然后重复——直到它越过那道标准线。
这就是一个 loop。你刚用一段话就造出了一个。 它是有局限的——你仍然是那个触发器,没有时间表、没有持久 state,关掉标签页它就没了。但它把核心机制展示了出来。从这一步到一个完整的自主 loop,要加的就是那套 automation、那个 state 文件,和那道闸。
第六部分 · 说点实在的
loop 修不好的东西。 Loop 改变了工作,但它没有把你从工作里删掉。 而且有两个问题,会随着 loop 越变越好而越来越尖锐——不是越来越轻松:
- 理解债(comprehension debt)。 loop 越快地发出你没写过的代码,你 repo 里「已存在的东西」和你「真正理解的东西」之间的鸿沟就越大。一个跑得顺滑的 loop,会对这道鸿沟收复利利息。等到某天你必须去 debug 一个全队没人读过的系统,那笔账会比你烧掉的所有 token 都贵。
- 认知投降(cognitive surrender)。 当 loop 自己在跑,人很容易就不再形成自己的判断,照单全收它吐回来的一切。设计这个 loop,在你带着判断力去做时是解药——在你为了逃避思考去做时则是加速器。同一个动作,相反的结果。
两个人可以造出一模一样的 loop,得到完全相反的结局。一个用它在自己深刻理解的活儿上跑得更快。另一个用它来彻底逃避理解这件活儿。loop 分不出这个区别。你分得出!
Karpathy 停下的是写代码,Boris Cherny(Claude Code 的作者)停下的是一句一句敲 prompt——他们谁都没停下思考。如果你从这篇里只带走一件事,带走这个:开始像工程师那样用 loop。
译自 @0xCodila《Loop Engineering: The Karpathy Method》。翻译、重排、配图本地化:Yaqin Hei。
Subscribe for updates
Get the latest AI engineering posts delivered to your inbox.