Karpathy的autoresearch让AI自主跑实验，Shopify CEO拿它把Liquid性能提升53%

这两天刷GitHub Trending的时候看到一个有意思的事：Karpathy发了个叫autoresearch的项目，让AI Agent自主跑训练实验。项目本身不算复杂，但Shopify CEO Tobi Lütke两天后就把这个思路搬到了自家的Liquid模板引擎上，结果是——parse+render速度提升53%，内存分配减少61%。一个做AI训练的toy project，被CEO亲自拿来优化生产级代码，还真跑出了结果。这事值得聊聊。

autoresearch是什么

Karpathy的定义很直白：给AI Agent一个小型但真实的LLM训练环境，让它自主跑实验。Agent改代码、训练5分钟、看结果有没有变好，好就留、差就扔，然后继续下一轮。你睡一觉起来，面前摆着一堆实验日志和（理想情况下）一个更好的模型。项目核心只有三个文件：

prepare.py  — 数据准备和评估工具（不改这个）train.py    — 模型、优化器、训练循环（Agent改这个）program.md  — 给Agent的指令（人改这个）

关键设计决策：每次训练固定5分钟墙钟时间。不管Agent怎么改架构、batch size、超参，都是5分钟。这样不同实验之间就能公平对比，评估指标是val_bpb（validation bits per byte），越低越好。Karpathy在README里写了句挺有意思的话：

研究曾经是由肉身计算机完成的，它们在吃饭、睡觉和其他娱乐之间工作，偶尔通过声波互连在”组会”仪式中同步一下。那个时代已经过去了。

玩笑归玩笑，但autoresearch的核心思路是真的：你不再直接写Python代码做研究，你写的是Markdown——定义Agent的研究策略。用Karpathy的话说：”you are programming the program.md”。

Shopify CEO的骚操作

项目开源两天后，Tobi Lütke在GitHub上提了一个PR：把autoresearch的思路用在了Shopify的Liquid模板引擎上。Liquid是2005年Tobi自己写的Ruby模板引擎，现在是Shopify的核心组件，全球几百万商家的店铺都在用。他建了一个auto/目录，里面有两个文件：autoresearch.md——告诉Agent优化目标：

优化目标：combined_µs（parse时间 + render时间，微秒）约束条件：- 所有单元测试必须通过- liquid-spec失败数不能增加- 不能加新的gem依赖- 模板渲染结果必须完全一致

autoresearch.sh——跑测试和benchmark的脚本，输出可解析的JSON格式指标。然后就让Agent开干了。

30次commit的进化过程

看这个PR的commit历史简直像在看一场加速进化。从3月11号到3月12号，两天时间，30个commit，PR标题改了四次：

每个commit都是一次独立实验。Agent做的优化包括：用手写字节解析替换正则表达式——这是最大的收益来源。Liquid的解析器原来大量依赖正则做token匹配，Agent一个一个把它们换成了手动字节扫描。

# 之前：正则匹配FullTokentoken =~ /\A\s*(.*?)\s*\z/m# 之后：手动字节解析def parse_token_manual(source, pos)  # 跳过前导空白  pos += 1 while pos < source.bytesize &&     source.getbyte(pos) == 32  # 直接扫描到结尾  start = pos  # ...end

快速路径短路——大量模板变量其实是简单的{{ product.title }}格式，不需要走完整的Lexer→Parser流程。Agent识别出这个模式后加了快速路径，直接跳过词法分析。减少对象分配——Ruby的GC压力很大程度取决于对象分配数量。Agent把很多临时字符串分配改成了byteslice和getbyte操作，从62,620次分配降到了24,530次。这些优化单独看都不算多复杂——有经验的Ruby开发者都知道正则比手写解析慢，对象分配越少越好。但关键在于：Agent在两天内系统性地找到并实施了30多个这样的优化，每一个都通过了完整测试套件验证。

这跟人类做优化有什么不同

人工优化Ruby代码性能的典型流程：跑profiler，找到热点，想个优化方案，改代码，跑测试，跑benchmark确认。一个经验丰富的开发者一天能做3-5个这样的优化循环。autoresearch的方式：Agent自动跑benchmark识别热点，自己想方案，自己改代码，自己跑测试和benchmark，好就commit、差就revert，然后立刻开始下一轮。一天可以跑十几轮甚至几十轮。核心区别不是Agent比人聪明——它做的每一个优化人类都能想到——而是它不累，不需要上下文切换，不需要等CI跑完再想下一步。Karpathy设计autoresearch时的一个关键约束是"固定时间预算"。每次训练就5分钟，不多不少。Tobi搬到Liquid上也保留了这个思路——benchmark脚本跑完就是一个数字，Agent拿到数字就知道这轮改动该留还是该扔。这种快速反馈循环才是autoresearch真正的价值：把"修改→验证"的周期压缩到最短。

怎么把这个思路用到自己的项目

autoresearch本身需要NVIDIA GPU跑LLM训练，但Tobi的做法证明了这个模式可以泛化。核心要素只有三个：1. 一个可量化的指标必须有一个明确的数字告诉Agent"变好了还是变差了"。Karpathy用val_bpb，Tobi用combined_µs + allocations。没有可量化指标，这套流程就跑不起来。2. 一个快速的验证脚本测试+benchmark必须足够快。如果跑一次要30分钟，一晚上只能做十几次实验，效率太低。Tobi的benchmark脚本几秒钟就能出结果。3. 一份清晰的约束文档Tobi的autoresearch.md写得很精确：优化目标是什么、哪些文件能改哪些不能、基线数据是多少、历史实验记录。Agent需要足够的上下文才能做出合理的决策。如果你有一个前端项目想优化Lighthouse分数，或者一个后端服务想降低P99延迟，完全可以照着这个模式搞：

# auto/autoresearch.md## 优化目标Lighthouse Performance分数（越高越好）当前基线：72## 验证脚本./auto/run_lighthouse.sh输出格式：{"performance": 72, "fcp_ms": 1840, "lcp_ms": 3200}## 可修改文件- src/components/**- src/pages/**- webpack.config.js## 约束- 所有E2E测试必须通过- 不能删除任何用户可见功能- bundle size不能增加超过5%

然后把你惯用的AI编码工具指向这个文件，让它自己跑就行。

冷静一下：这不是银弹

在吹autoresearch之前得说清楚几个限制。它只适合有明确量化指标的优化任务。重构代码结构、改善可维护性、设计新功能——这些没法用一个数字衡量的工作，autoresearch帮不上忙。它不理解业务语义。Agent可以把parse速度提升53%，但它不知道某个优化会不会在边缘case下改变模板输出。这就是为什么Tobi的约束里写了"所有测试必须通过"——测试套件是唯一的安全网。如果你的测试覆盖率不够，Agent可能把代码改对了benchmark但改坏了真实场景。它需要成熟的CI/测试基础设施。没有可靠的自动化测试，autoresearch就是在玩火。单次优化幅度有天花板。Tobi的30个commit里，越到后面每次优化的增量越小。从7,374到5,200很快（正则→手写解析，大块收益），从3,500到3,459就很慢了（已经是微调级别）。这跟人类优化的规律一样——低垂果实摘完了，剩下的都是硬骨头。

一个有意思的信号

Shopify CEO亲自写PR这件事本身就挺值得琢磨的。Tobi这些年一直在推Shopify内部用AI编码工具，去年还发过内部邮件说AI使用率会成为绩效评估标准之一。但他不是那种只喊口号的CEO——这个PR有30个commit，每一个都是真实的代码改动，跑过测试和benchmark。更有意思的是，他在commit message里保留了autoresearch格式的JSON输出：

Result: {"status":"keep","combined_µs":4007,"parse_µs":2808,"render_µs":1199,"allocations":25535}

每一轮实验的结果都记录在案。这不是作秀，是真的在用Agent跑自动化实验。autoresearch这个模式目前还很早期，Karpathy自己也说就是个开始。但"让AI Agent在约束条件下自主实验"这个思路，从LLM训练泛化到生产级代码优化，中间就隔了一个benchmark脚本和一份Markdown文件。如果你的项目有性能benchmark，不妨今晚就试试——让Agent跑一夜，明天早上看diff。最坏情况，你损失一晚上的API调用费；最好情况，你拿到一个53%的性能提升。