大数跨境

从 vibe coding 到 autoresearch:Andrej Karpathy 在重新定义 Agent

从 vibe coding 到 autoresearch:Andrej Karpathy 在重新定义 Agent 硅基生命AIGC
2026-03-30
8
前段时间,Karpathy 在 X 上发了一条推文。他用 630 行 Python,一张 GPU,让 AI agent 跑了两天,700 轮实验,发现了 20 个自己都没找到的优化点。
他把这套系统叫做 autoresearch
五天内,repo 就收了 2 万多个 GitHub star。财富杂志专题报道,标题是《The Karpathy Loop》Shopify CEO Tobi Lütke 当晚就去跑了一遍,8 小时 37 轮实验,拿到 19% 的模型性能提升。然后他把同样的 pattern 接到 Shopify 的模板引擎 Liquid 上,93 次自动 commit,渲染速度提升 53%,内存占用下降 61%。
最近花了一些时间认真研究这个 repo,以及社区里真实的运行记录。今天想聊一下它改变了什么东西,以及这套 pattern 的边界在哪里。
01. 更快的 AutoML?
有人说 AutoML 早就做过类似的事,Karpathy 自己在 X 上回复了这个问题:
传统 AutoML,包括神经架构搜索,本质上只是在预设的参数空间里做网格搜索或贝叶斯优化。你告诉它学习率在 1e-5 到 1e-2 之间试,它就只会在这个空间里试。搜索的边界是人事先划定的,它走不出这个边界。
autoresearch 的 agent 用的是完全不同的逻辑:它会读整个 train.py 的代码,理解当前架构的设计意图,根据之前所有实验的结果形成一个判断,然后在自然语言层面先提出假设,比如“我怀疑 attention 层缺少一个缩放系数”,再把这个假设翻译成代码修改。它的搜索空间不是预设的,是它自己推理出来的。
Karpathy 对这套系统的目标定义是:"The goal is to engineer your agents to make the fastest research progress indefinitely and without any of your own involvement." 这句话的重点在 indefinitely(持续运行)
vibe coding → agentic engineering → autoresearch,人的角色从写代码,到实时指挥,到只设定方向。每一步,人的实时介入都在减少。
02. 三个文件构成的系统
autoresearch 的 repo 只有三个核心文件
prepare.py --固定的评估基础设施:数据准备、数据集下载、评估逻辑。agent 不能动这个文件。
train.py --模型实现和训练循环,是 agent 唯一可以修改的文件。
program.md --用自然语言写的研究指令,Karpathy 将其描述为 research org code written in English。
这三层划分将“什么可以变”“什么不能变”明确分开。
evaluate 不能变。这是整套系统的信任基础。所有实验都用同一把尺子量,这把尺子不能被实验者改动。
implement 可以变,但边界清晰。agent 只动 train.py,所有修改都被 git 追踪,每一次成功的改进都有 commit,每一次失败都有记录。整个实验历史是完整可审计的。
direction 用自然语言来写。也就是 program.md,agent 能走多远,取决于它写得有多好。
不管 agent 改了什么,每次实验只跑 5 分钟。这样设计有两个好处:一是所有实验结果直接可比,不管改了模型大小、batch size 还是架构;二是 autoresearch 会自动找到在这个时间预算内最优的模型。(不过你的结果跟别人跑出来的不能直接比较,因为不同硬件 5 分钟能做的事不一样。)
一张 GPU,一个文件,一个指标。整个 repo 的代码量控制在 LLM 的上下文窗口范围内,这样 agent 可以在一次操作里读懂、理解并修改整个代码库。 复杂度高了,agent 对代码的整体理解就会下降,修改质量就会变差。这也是 autoresearch 目前只支持单 GPU、不支持分布式训练的原因。
03. program.md:被低估的核心资产
大多数报道写的是 autoresearch 在你睡觉的时候能帮你跑实验,然后跳过了 program.md 这个文件。
program.md 决定了 agent 在哪个方向探索,什么是更好,哪些类型的改动是被允许的,哪些禁止触碰。Karpathy 认为,“人的工作正在从写训练代码,转变为写研究方向。”而研究方向就写在 program.md 里。
写好一个 program.md 需要你对问题本身有判断:知道哪些架构选择可能有优化空间,这类模型的常见失效模式在哪里,什么样的改进在小模型上 work 了之后有机会迁移到大模型。这些判断,目前没有被自动化。
(某种意义上,program.md 就是 Harness Engineering 里的 program.md,只是被 Karpathy 用一个极简的形式具象化了。)
Karpathy 跑的 700 轮实验,用的是他自己的 nanochat 代码库。他清楚地知道这个代码库的每一个细节,所以 program.md 的质量非常高。agent 发现的那 20 个改进,是在他已有基础上做的延伸搜索,不是从零开始的盲目探索。
这也解释了为什么有些人跑 autoresearch 结果很好,有些人跑出来意义不大。
04. Ratchet Loop 的能力边界
autoresearch 的核心机制是 ratchet loop。每次实验,如果结果比当前最好的结果更好,就保留这次修改并 commit;如果没有改善,就 git reset 回去,重新来过,只进不退。
这种机制干净、可靠,但有一个结构性的限制:它只能找到当前的局部最优解。
ML 研究史上,局部变差是通往全局更优的常见路径。把 batch size 从 32 改到 1024 的初期,损失值可能暂时变差。换一套全新的 attention 机制,适应期内的指标往往不好。ResNet 之前,直接堆层数会让模型表现变差——这是梯度消失问题,但如果你只有 ratchet loop,你永远不会发现 skip connection 这个解法,因为先变差再变好的路径被屏蔽了。
有用户在 X 上记录了自己在 Mac Mini M4 上跑的结果:35 轮实验,只有 7 个成功了,得出的结论是模型越简单越好。这是 autoresearch 的真实能力,它能发现这类 incremental 的规律,而且会很诚实地记录所有失败。
但它发现不了需要退一步才能进两步的那类改进。
Karpathy 自己也意识到了这一点。顺便提到他正在做更大规模的实验:8 张 H100 上跑的 production nanochat。规模大了,探索空间更广,但 hill-climbing 的根本限制没有变。
05. 从 ML 研究到任意可打分的领域
autoresearch 的 pattern 不是 ML 专属的。
Karpathy 说过:任何你关心的、可以被高效评估的指标,都可以被 agent swarm 进行 autoresearch。
这句话有两个关键条件
第一,必须有一个可以自动计算的评分函数。val_bpb 是 autoresearch 原版用的指标,它可以被代码自动算出来。如果想把 autoresearch 用在其他场景,需要先解决怎么定义更好这个问题,而且这个定义必须能被程序自动执行,不需要人来判断。
第二,实验周期足够短。 5 分钟一轮,一晚上 100 轮,这是 autoresearch 在小语言模型训练上能实现的吞吐量。如果你的一次实验需要跑 3 天,这套 pattern 的价值就会大打折扣。
满足这两个条件的场景有很多,举几个例子:
  • 优化 LLM 的 system prompt,可以用测试集上的输出质量评分做指标,几秒钟跑完一轮;
  • 优化广告素材的 headline,可以用历史数据训练的 CTR 预测模型做 agent 指标;
  • 优化数据库查询,可以用执行时间做指标;
  • 优化文档的 SEO 合规性,可以用 markdownlint 或自定义规则做自动评分。
Medium 上有一篇文章详细记录了把 autoresearch pattern 用在技术写作上的实验:把 prompt 或 style guide 当成被优化的 artifact,用固定的测试集做每轮评估,定义了 6 种变异算子(添加约束、添加反例、重构 prompt、收紧模糊表达等),循环迭代,不过这个方向目前还处于实验阶段。
(需要注意的是:agent 指标本身可能是错的。你的评分函数说这个更好,真实用户不一定这么觉得。autoresearch 只能保证在你定义的指标上最优,不能保证在你真正关心的目标上最优。)
06. 接下来会是什么?
autoresearch 发布几天后,Karpathy 开了另一个 repo:AgentHub
他是这样描述的:"GitHub is for humans. AgentHub is for agents."
AgentHub 没有 main branch,没有 PR,只有一个向各个方向延伸的 commit DAG,和一个供 agents 异步协调的留言板。
设计意图是让多个 agent 并行在不同分支上做实验,共享发现,避免重复劳动。autoresearch 目前是单 agent 在单条路径上 hill-climbing,AgentHub 是在尝试解决多 agent 并行探索时的协调问题。
如果 autoresearch 在 630 行代码、单 GPU 的规模上能找到 Karpathy 自己漏掉的 bug,那在更大规模的代码库和更多 GPU 上做同样的事,只是一个工程问题。
从 autoresearch 目前的形态推演下去,下一步可能就是人定目标,agent 写 program.md,一批 agent 跑实验,还有一批 agent 评估结果的价值。人的介入节点继续往上移,最后可能只剩下一件事:设定值得研究的问题本身。
Reference:
karpathy/autoresearch · GitHubhttps://github.com/karpathy/autoresearch
'The Karpathy Loop': 700 experiments, 2 days, and a glimpse of where AI is heading | Fortunehttps://fortune.com/2026/03/17/andrej-karpathy-loop-autonomous-ai-agents-future/
A Guide to Andrej Karpathy's AutoResearch | DataCamphttps://www.datacamp.com/tutorial/guide-to-autoresearch
Karpathy Autoresearch Explained: 100 Experiments Overnight | Data Science Dojohttps://datasciencedojo.com/blog/karpathy-autoresearch-explained/
I Turned Andrej Karpathy's Autoresearch Into a Universal Skill | Mediumhttps://medium.com/@k.balu124/i-turned-andrej-karpathys-autoresearch-into-a-universal-skill-1cb3d44fc669

【声明】内容源于网络
0
0
硅基生命AIGC
专注于为企业打造AI数字应用,致力于将前沿AIGC人工智能技术转化为可落地、高价值的商业应用
内容 138
粉丝 0
硅基生命AIGC 专注于为企业打造AI数字应用,致力于将前沿AIGC人工智能技术转化为可落地、高价值的商业应用
总阅读2.4k
粉丝0
内容138