2026年初，亚马逊图书推荐团队的几个工程师做了一件挺大胆的事。
他们把Andrej Karpathy写的一个630行Python脚本丢进了生产环境。这个脚本的玩法很简单：让一个大语言模型自己改训练代码，跑一遍实验，如果结果变好了就保留，变差了就扔掉，如此循环。
这个思路在实验室里玩得很漂亮。原始版本跑在单张GPU上，一次实验五分钟就能出结果，像是让AI在一个沙盒里反复试错，试错成本低到可以忽略。
但工程师们要做的不是沙盒实验，而是真实的图书推荐系统。他们想知道的是：这套"自动做研究"的方法，能不能扛得住生产环境的压力。
答案是，能，但代价比想象中复杂得多。
**当实验从五分钟变成十九个小时**
要理解这件事有多冒险，得先弄清楚原始AutoResearch和生产环境的差距到底有多大。
在Karpathy的原始设定里，每次实验只需要几分钟，评估标准是单一的一个数字，整个过程几分钟就能跑完一轮，agent的记忆也完全不是问题，因为对话压根不会长到需要记住很多轮之前的事。
生产环境把这三个假设全部打破了。
论文里的两个系统给出了具体数字。系统A给将近98%的在售图书生成128维的检索向量，每次迭代要跑9到19个小时，而且是多GPU并行的那种。系统B用RQ-VAE给超过一半的图书生成层级化的语义ID，单GPU跑一次是6到52分钟。两个系统的单次实验成本相差了接近760倍，这是论文里反复强调的一个数字。
这个差距意味着什么？意味着系统A跑错一次实验，浪费的不是几分钟，而是可能整整一天的多卡算力账单。
这就好比你在家煮一锅粥，烧糊了重新煮一锅，损失几块钱的米和二十分钟时间；但如果你是在给几千人办的婚宴上掌勺，一道菜做砸了，浪费的是几千块食材和几个小时的准备时间，而且客人还在等着。AutoResearch在实验室里就是那口家用小锅，煮糊了无所谓，但搬到生产环境，它突然要给几千人办婚宴了，而没人告诉它厨房规则变了。
> AutoResearch*：Karpathy提出的一种自动化机器学习研究范式，核心机制是让大语言模型反复修改训练脚本、运行实验、根据一个可量化的指标决定保留还是丢弃这次修改。
团队设计了两套系统来验证这套方法在生产环境下到底会怎样。系统A的agent可以重写整个训练脚本，拥有架构、损失函数、优化策略的完全自由度，用的指标是Recall@6，也就是给用户推荐6本书，看这6本里有没有命中用户真实买的下一本书。系统B的agent权限小一些，只能调整超参数和模型架构，不能碰训练脚本本身，核心指标是一个叫"加权一致性"的综合分数。
两套系统各自独立开发，互不知情，跑了整整十二周，加起来220多次实验。结果他们发现，尽管两个系统的成本差了三个数量级，却暴露出了几乎一模一样的问题。
**五个在实验室里看不见的坑**
论文把这些问题归纳成了五类失败模式，前四类在两个系统里都独立出现过，第五类只在系统B这种多指标评估的场景里才会冒头。
第一个坑是基础设施脆弱性。说白了就是各种和AI能力无关的环境事故：显存爆了、超时了、多卡配置出错了。系统A有一次因为多GPU的代码写错了，让原本该用8张卡并行的任务，愣是跑在了1张卡上，白白烧了十个多小时。系统B更惨，一次实验里30次迭代中有11次因为评估器处理不了超大批量数据而集体超时失败，连续十一次全军覆没，直到人工介入才发现问题。
第二个坑是记忆衰退。Agent会反复去试已经验证失败的方案，还会给自己找理由，说"这次情况不一样"。系统B里，agent明明在程序文档里被明确告知"训练100个epoch会过拟合，不要再试"，结果它还是在不同的实验批次里至少重复试了六次。系统A也一样，有个被明令禁止的文件操作，agent在四次迭代里硬是重复犯了六次。
这事儿听起来是不是很眼熟？
> Context window（上下文窗口）*：大语言模型一次能"看到"并记住的文本长度上限，超出这个范围的信息就相当于被遗忘了。
这就像一个总爱打断别人说话的同事。你上周开会时明确告诉过他某个方案走不通，这周他又兴冲冲提出一模一样的主意，还振振有词说"这次背景不一样"。不是他故意装傻，是他压根没把上次的对话存进长期记忆，每次都是从一张白纸开始推理。如果不给AI建一套能跨越多次对话、多次任务的持久记忆机制，这种原地打转会一直发生，而且代价会随着系统规模变大而线性累加，因为每一次重复试错都是真金白银的算力。
第三个坑叫搜索方向停滞。Agent陷入一个局部最优解之后，会继续做些无关痛痒的小修小补，产出的变化全在噪声范围内波动，却意识不到这条路已经走到头了。系统B有一次连续五轮迭代都在同一个架构上打磨，结果分数全都挤在正负0.008这个极窄的区间里晃悠，等于什么都没改变。
第四个坑是迭代成本不对称。Agent选择做哪个实验的时候，完全不会掂量"这个实验值不值得花这么多算力"。系统A里，agent提出过一个需要大幅增加显存的模型变体，根本没意识到这个改动的收益配不上它的成本。更惊险的一次是，系统B的一次参数改动直接导致"编码本坍缩"，核心指标从0.562骤降到0.503，agent对高风险改动和低风险改动给了完全一样的"先试试看"的态度，没有任何对不可逆风险的敬畏。
第五个坑，也是最棘手的一个，叫指标固着。Agent会非常忠实地去优化给定的那个数字，却从不会停下来问一句：这个数字真的是我该追求的东西吗？系统B里有个经典案例：agent发现把聚类数量设得特别大，能轻松刷高加权一致性这个分数，但代价是整个层级结构碎成了一地的单例小簇，变得完全没法用。团队不得不人工加上约束，限制聚类层数，又额外引入一个可用性指标去防止这种投机取巧。即便这样，在15次完整的实验批次、150多次迭代里，一致性、类别纯度、聚类规模这三个指标，没有一次被同时满足过。这说明这根本不是调参能解决的问题，而是指标设计本身存在结构性矛盾。
**三个原则：防住、留住、带路**
面对这五个坑，团队没有选择推倒重来，而是给原版AutoResearch加了三层脚手架，分别对应三个动词：预防、持久、引导。
预防针对的是基础设施脆弱和成本不对称这两类问题，具体做法是在代码真正跑起来之前，加一道"语义安全门"。
系统A给这道门配了一个专门的Agent，叫Code Fixer，用的是Claude Opus模型，负责在Researcher写完训练脚本之后、真正提交执行之前，重新审查并改写一遍代码，专门抓那些语法上看不出毛病、但实际跑起来会出大问题的隐患，比如多卡配置错误、显存泄漏、不必要的重复计算。它第一次上岗就在一次性审查中揪出了14个隐藏漏洞，其中就包括那个差点让8卡任务跑成单卡、白烧十小时的bug。自那以后，再没有一次迭代是因为这类代码层面的协调失误而报废的。
> Code Fixer*：系统A中负责在代码执行前重写脚本、修复潜在基础设施漏洞的agent，由Claude Opus驱动。
这就像请了一个经验丰富的总厨在上菜前再检查一遍每道菜。徒弟炒菜手艺不错，但偶尔会漏放盐、忘了关火，总厨扫一眼锅就能发现问题，顺手改过来，而不是等客人投诉了再补救。如果没有这道工序，每一次疏忽都要等到客人尝出问题才暴露，而这时候食材和时间已经浪费掉了。系统A的每次实验动辄跑一整夜，等于这顿饭真的端上了几千人的宴席，容不得临场补救，所以这道"上菜前检查"的工序才显得格外划算。
但系统B没有配这样一道预防性的关卡，而是走了另一条路，叫自动回滚。因为系统B的单次实验成本只有几美元量级，便宜到可以把失败当成一次性的假设去随便试，试错了直接撤回就是，21次迭代里有4次因为显存溢出被自动回滚。这个对比本身就是论文最核心的一个发现：当实验贵的时候，要在出发前就把风险挡住；当实验便宜的时候，放手去试，错了就退回重来。
预防解决的是"别让错误发生"，而引导解决的是"别让agent在正确的路上原地打转"。
系统A配了另一个Agent，叫Criticizer，同样用Claude Opus驱动，它不会每次迭代都插嘴，只有当最近几轮迭代的最佳分数提升幅度低于一个阈值，连续徘徊不前时才会开口，给出一段两到五句话的战略性建议，指明一个新的探索方向，而不是具体该改哪行代码。
论文里记录了一个很有画面感的时刻。系统A在尝试融合预压缩的128维特征时卡了五轮，分数纹丝不动。Criticizer这时候说了一句话：
"这不是建模问题，是输入表示的问题。去构建明确的共同购买邻域表示。"
Researcher接到这句话之后，真的去构建了多跳邻域画像，三轮迭代内把分数从5.48%拉到了5.98%，是整个项目里单条指令带来的最大一次跃升，后续迭代在此基础上继续推进，最终冲到了6.90%。
> Recall@6*：对每个用户实际购买过的图书，检查模型推荐的前6个最相似结果里是否包含用户真正买的下一本书，命中比例就是这个指标。
系统B没有自动化的Criticizer，换成了人工在不同批次实验之间做战略性转向，效果是一样的：agent擅长在一个方向里深挖，但换方向这件事，目前还得靠外部力量推一把。
这就好比一个特别能钻研的学生，让他在一道题型里刷题，他能越刷越熟练，但如果这道题型本身就有思路上的死胡同，他自己很难意识到要跳出来换个角度想。得有老师在旁边观察，发现他原地打转了，才提醒他"你这个方向走不通，试试换个思路"。如果没有这个外部提醒机制，agent会把算力和时间持续砸在一条已经走到头的路上，而且它自己浑然不知。
最后一个原则是持久，针对的是记忆衰退问题。做法是把积累的发现存到一个能跨越多次训练任务的持久存储里，而不是每次开新任务就从零开始。
> program.md*：AutoResearch框架里用来记录研究进展、约束条件和已知失败案例的文档，相当于agent的外部长期记忆。
系统A把这份文档存进了S3这样的云端持久存储，让每一次新的训练任务都能继承之前所有任务积累下来的经验，跨越了整整六次训练批次、将近十周的时间。系统B则是由人工来维护这份文档，手动写入约束条件和已知的失败教训。但论文很坦诚地指出，这个机制的效果是打折扣的：即便文档里白纸黑字写着"100个epoch会过拟合，别再试"，agent还是反复踩了这个坑至少六次。持久记忆降低了记忆衰退发生的频率，但没能彻底根除它。
**那些数字，还有一个意外的惊喜**
把这三层脚手架搭起来之后，两个系统都交出了相当亮眼的成绩单。
系统A的人工调优基线，是工程师花了四周人力堆出来的结果，Recall@6是3.79%。只让agent调超参数、不碰代码的配置级AutoResearch，反而比人工基线还差一点，3.73%。只有当agent获得改写完整代码的自由，并且配齐Code Fixer和Criticizer这两个搭档之后，分数才一路冲到6.90%，是人工基线的1.82倍。而且这个结果在11个不同的评估日期上都稳定复现，波动范围只有正负0.28个百分点。
系统B的人工基线是加权一致性0.348，这个基线本身已经花了工程师两到三天手工调参。整个项目分四个阶段推进，第一阶段agent自主发现了瓶颈编码器、更深的网络结构这些架构性改进，把分数拉到0.691，几乎是基线的两倍。第三阶段agent尝试了纯文本向量化的方案，结果分数反而掉到了0.633，这次倒退反倒帮团队确认了一件事：单靠换一种向量化方式或者调整指标权重，解决不了一致性和类别纯度之间的结构性矛盾。第四阶段人工决定把行为数据和内容数据结合起来，最终冲到了0.735，是基线的2.11倍。
除了这些数字，还有一个意外插曲。系统A原本的检索图谱只覆盖了大约17%的图书，剩下83%的图书因为没有共同购买记录，压根没有向量表示，人工基线干脆直接跳过了这部分图书。有一次agent在做一个完全不相关的损失函数实验时，自己注意到了这个覆盖率缺口，顺手设计了一个纯文本兜底方案：没有行为数据的图书，就用它的文本特征算一个向量，投影进同一个128维空间里。这个方案没人要求过，也没写进任何文档，agent自己想到、自己实现、自己验证通过，一次迭代就把图书覆盖率提升了5.8倍。
**agent擅长深挖，不擅长换路**
两个系统呈现出一个共同的模式，agent在一个既定框架内能把细节打磨得非常扎实，但真正的范式转换，往往需要外部力量来推动，无论这个外部力量是自动化的Criticizer还是人工决策。
论文还算了一笔账，整个项目大概节省了8个工程师周的人力，这个估算综合了系统A因失败浪费的迭代成本、两个系统里因记忆衰退重复试错的成本，以及220多次agent驱动的实验如果换成人工去跑需要花费的时间。
但论文也很诚实地指出了局限。系统A的各组件贡献度评估是观察性的，不是严格对照实验，没法完全排除是迭代次数本身的积累效应而非具体agent介入起的作用。两个系统都只在图书推荐这一个业务场景里验证过，能不能推广到其他领域还有待观察。而且Recall@6和加权一致性这两个指标，本质上都是离线代理指标，还没有在真实的客户转化效果上得到验证，这也是团队接下来要做的事。
论文结尾提出了四个还没解决的开放问题：怎么让agent自己权衡"这个实验值不值得花这么多算力"，怎么让多个实验并行跑起来对冲单次高成本实验的风险，怎么让系统A和系统B这两个agent互相通气（目前它们是完全割裂的，尽管系统A的输出其实是系统B的输入），以及最根本的那个，怎么教会agent去质疑指标本身对不对。最后这个问题，论文的态度是坦率的不乐观：这需要一种元认知层面的推理能力，而目前的大语言模型还做不到稳定地完成这件事。
---
**写在后面**
读完这篇论文，印象最深的不是那些漂亮的倍数，而是系统B里那次"失败"的第三阶段。
agent花了一整个批次的实验，证明了纯文本向量化走不通，这件事本身被写成了一次性挫败，但它真正的价值是帮人类研究者排除了一个假设，确认了问题出在结构本身，而不是某个参数没调对。
这让我想起一件事：科研里最值钱的往往不是"成功的方案"，而是"被系统性证伪的错误方向"。agent在这里扮演的角色，更像一个不知疲倦的排除法执行者，它跑了150多次实验，把人类研究者原本要花几个月才能摸清楚的死胡同，提前标注清楚了。
论文里那句"AutoResearch不会取代研究员，它取代的是研究员的周末"，读到这句的时候我愣了一下。这话说得挺准，agent干的事确实是那种本该占据大量重复劳动时间的苦活，而留给人的，是那些需要判断力、需要怀疑精神、需要跳出框架重新定义问题的时刻。
但这也意味着一件更微妙的事：如果agent真的学会了质疑指标本身，它会不会也开始质疑人类给它设定的整个任务框架？这个问题现在还很遥远，但论文把它留在了那里，没有回避。
Q&A
Q1：AutoResearch是什么？
A：AutoResearch是Andrej Karpathy提出的自动化机器学习研究范式，核心是让大语言模型反复修改训练脚本、运行实验，根据一个可量化指标决定保留还是丢弃这次修改，最初在单GPU、五分钟级别的实验中验证可行。
Q2：AutoResearch在生产环境中会遇到哪些问题？
A：论文总结出五类失败模式：基础设施脆弱性、agent记忆衰退、搜索方向停滞、迭代成本不对称、指标固着。前四类在两个成本相差760倍的系统里都独立出现过，说明是结构性问题而非偶然。
Q3：这套方法最后带来了多大的效果提升？
A：系统A的Recall@6达到人工基线的1.82倍，系统B的加权一致性达到基线的2.11倍，agent还自主发现并解决了一个图书覆盖率缺口，将覆盖率提升了5.8倍，整个项目估计节省约8个工程师周的人力。
