问题描述：

给 AI 一个最小闭环，它能走多远

autoresearch 发布一个月后，社区把它的边界推到了哪里

在 karpathy/autoresearch 刚开源出来时，我也试着把它迁到一个 auto-flappy-bird 的小场景里。跑了十几轮以后，训练出来的模型已经可以比较稳定地飞过 20 多个管道。

但我很快意识到，是它不仅能迁到一个强化学习任务里，而是它把“有对象、有评测、有预算、可回滚”的最小闭环压得足够小。小到你会自然开始追问：这套东西还能被用到哪里去？

现在一个多月过去了，社区里冒出来一批 fork、讨论和衍生项目。我回过头重新看这批东西时，忽然注意到，autoresearch 精神最浓缩的表达，其实就是原实验思路提示词里的：

[!important]
NEVER STOP : Once …

我后来越看越觉得，社区过去一个月里真正值得看的那些探索，几乎都在回答同一个问题：

怎样让一个每几分钟就会停下来的实验，尽可能长成一个不会停下来的研究系统。

这也是为什么我现在不太想再写“autoresearch 是什么”。大家差不多都知道了。现在更值得追踪的是，一个月过去，社区到底把这套东西扩展到了哪里。

先说原点：autoresearch 为什么会火

autoresearch 原版其实很小。人写实验思路提示词 program.md，agent 改算法 train.py，而 prepare.py 负责数据和评估，agent 不能碰。每轮实验给固定预算，跑完看分数，决定 keep 还是 revert，然后继续下一轮。

从代码结构上看，它并不复杂。

但它第一次把一件事压缩得非常清楚：局部可改对象、固定评测、固定预算、可回滚。
也就是说，它把“让 agent 连续试错”这件事，压成了一个真的能跑起来的最小闭环。

这一步很关键。因为很多 agent 项目的问题，不是不会生成，不是不会调用工具，而是没有一个足够硬的闭环。它们能做很多事，但很难一直做下去。autoresearch 则相反。它先把边界收得很死，然后才换来那句 NEVER STOP 的成立。

所以我现在更愿意把它理解成一个起点：不是“AI 开始自己做研究”的起点，而是最小自治研究闭环第一次被压到足够小、足够硬、足够可复现。

第一批扩展，不是更聪明，而是先让它摆脱“人得守在旁边”

原版 autoresearch 更像一个本地脚本。你可以启动它，看着它跑，甚至中间打断它。

但只要你真的把 NEVER STOP 当回事，问题马上就会变。你会开始关心的，不再只是 prompt 怎么写，而是：谁来提供 GPU，谁来保实验日志，程序中断了怎么办。

所以像那些把 AutoResearch 搬到云端、搬到远程执行环境里的项目（如mlpatron等），不适合简单理解成“上云版 AutoResearch”。它们真正补的，不是能力，而是运行形态本身。原版解决的是“怎么启动一个闭环”，远程化和托管化处理的则是另一层问题：

这个闭环能不能脱离人的在场。

这听起来像基础设施，其实已经碰到 autoresearch 最核心的那条线了。因为 NEVER STOP 不是一句漂亮口号。它要成立，后面得有一整套持续运行条件：你离开了，实验还在跑；你睡了，日志还在写；一轮失败了，系统还能自己接着往下试。

我一开始以为这只是一个工程层面的补丁，后来越看越觉得，它其实已经在改写人和研究系统之间的分工。到了这里，社区处理的已经不是“这个 agent 会不会改代码”，而是“这套 loop 能不能真的一直运转”。

再往前一步，一个不会睡觉的 agent 还不够

一个不行，就上更多个。也就是 mutable-state-inc/autoresearch-at-home 这一类项目。它想解决的，不再是“单个 agent 能不能一直试”，而是“很多 agent 能不能像一个研究网络那样协作起来”。

原版 autoresearch 解决的是：一个 agent，围着一个目标，不停试。
到了这里，问题开始变成：很多 agent 怎么一起研究，怎么避免重复劳动，怎么共享当前最优结果，怎么把失败也变成公共经验。

技术细节先不展开。我更愿意换成一种容易理解的说法：

原版像一个人在夜里独自改算法 train.py。
到了 autoresearch-at-home，社区开始尝试的是一个研究共同体。有人先认领一个方向，避免大家撞到同一块地方；有人接着跑；有人把结果发出来；后面的人在前面的基础上继续。

这时 autoresearch 碰到的已经不是模型优化问题了，而是研究协作问题。

看到这里我才慢慢意识到，社区在补的已经不只是 agent 的能力，而是研究这件事本身的组织形式。原版里的 NEVER STOP，说的是一个 agent 不要停。到了这里，问题已经变成另一句了：一个 agent 停了，整个研究过程能不能不停。

这一步一出来，味道就变了。因为它说明 autoresearch 的外扩，已经不只是“同一个 loop 跑更多次”，而是在碰研究这件事最老的难题：怎么分工，怎么接力，怎么让局部进展变成公共进展。

不只是模型算法自动优化，而是把 train.py 抽象掉

如果只盯着原 repo，你很容易误以为 autoresearch 的意义主要在训练模型。

但像 kousun12/darwin-derby 这种项目，做的是另一件事。它几乎把 autoresearch 的内核剥出来了：可变对象不再是算法 train.py，而可以是任意“当前状态”；评测器不再是训练损失，而可以是任何一个返回分数的任务；agent 改状态，拿分，保留或回滚，继续。

autoresearch 到这里已经很像一个通用搜索框架了：只要你能定义一个可变对象，给出一个足够硬的评分器，这个 loop 就可能跑起来。

但也正是在这里，问题开始反过来落到人身上。

darwin-derby 有一个我很认同的设计：负责打分的那部分规则，对 agent 是隐藏的。项目里把它写在 score.py 里。原因并不复杂。如果优化器看得到评估函数，它迟早会学会利用它。不是因为它“想作弊”，而是因为你给了它一条更短的路，它就会顺着走。

我原先更在意它能不能迁到新领域，后来反而越来越在意另一件事：谁在定义这个领域里什么叫“更好”。

这也是为什么我现在越来越觉得，autoresearch 的真正边界不是领域，而是评分器的质量。
一个问题能不能塞进这套 loop，不只取决于它能不能被打分，还取决于这个分数是不是值得被无情优化。说得再直一点：你给它一个数字，它就会冲着那个数字跑。至于这个数字和你真正想要的东西是不是一回事，那是人得先想清楚的。

一个典型的非模型训练案例

autoimprove 这个 RAG 案例，我觉得特别值得看。它碰的不是模型训练本身，而是一个混合搜索系统：给定一批文档、查询和评测集，看 agent 能不能把检索效果一点点往上推。

一方面因为 RAG 就是现在最热的 AI 应用层问题之一。
另一方面因为它很直白地说明了一件事：这套 loop 外溢出去的，不是训练技巧，而是把问题改写成“有可变对象、有评测器、有预算”的能力。

这个案例里，agent 在一个 44,000 个文本块组成的混合搜索系统上反复试，14 次实验之后，综合分从 0.42 提升到 0.46。最值得看的不是这个数字本身，而是最大单次改进并不是人手工指定的，而是它自己发现用 RRF 替代原来的加权融合更合适。

它说明 agent 能找到的，并不只是那种“没人想到过的惊天大发现”，而更像另一类东西：

人知道可能有用，但懒得系统试，或者没空完整跑完的工程改法。

这类改法其实最容易被忽视。不是因为它没价值，而是因为它很少值得一个人拿一周时间扎进去穷举。autoresearch 在这里补上的，恰恰就是这段人类通常会放掉的空白。

这里我很喜欢作者想表达的那个意思：你不再主要是在用 Python 写程序，而是在用 Markdown 描述 agent 应该遵循的过程。

Shopify 和营销归因这两个案例，把事情又往前推了一截

autoresearch 发布几天后，Shopify CEO Tobi Lutke 把这个 loop 对准了 Shopify 的模板引擎 Liquid——一个由数百个贡献者持续优化了 20 年的代码库。他用的不是 Karpathy 的 LLM 训练任务，而是渲染速度。Agent 跑了 93 个实验，自动提交了 93 次。结果：渲染速度提升 53%，内存分配减少 61%。

Shopify 的例子，我觉得真正值得记住的不是提速多少，而是他们工程师那个很准的判断：autoresearch 的价值，不只是把人本来会做的工作做得更快，而是在做那些没人会手动排进 sprint 的工作。

autoresearch 第一批真正有效的场景，很多都长这个样子：价值明确，收益稳定，但执行太枯燥，太碎，太难和其他重点工作抢资源。人理性上知道值得做，现实里总会拖着。agent 则不会烦，也不会觉得无聊。

再看 lucianfialho/mmm-research 这个案例，它做的不是工程优化，也不是搜索系统，而是 Marketing Mix Modeling，也就是营销归因建模。说白一点，就是让 agent 去碰“投出去的钱，最后到底是哪些渠道真正带来了销量”这种业务问题。到这一步，autoresearch 已经不只是进工程系统、RAG 系统，而是开始碰那些业务味更重、但价值也更直接的问题了。

但这个案例最有价值的地方，不是那个漂亮的指标数字，而是后面的复盘。因为它很快暴露出另一件事：只要那部分原本留着做“最终检验”的反馈，持续回流给 agent，它迟早会学会顺着这条反馈去优化自己。它不是“想作弊”，它只是在最小化你给它的那个目标。

看到这里，我越来越认同一个判断：

Goodhart 定律在 autoresearch 里不是一句提醒，而是工程约束。

[!note]
Goodhart定律（Goodhart’s law）的核心是：当一个度量指标被用作目标时，它将不再是一个有效的指标。

你定义的分数是什么，它就优化什么。
你留下的漏洞是什么，它就利用什么。
问题不是 agent 会不会学坏，而是你有没有把游戏规则写明白。

也正因为这样，我现在反而觉得 mmm-research 这种案例特别重要。它当然证明了 autoresearch 可以碰营销归因这种离训练很远的问题，但它更重要的地方在于，它把这套方法最真实的代价也一起摊开了：你不是把一个 loop 扔进去就行了，你还得对自己的评测机制负全责。你想让它一直跑，它就会一直跑。可它到底是在替你做研究，还是在替你钻规则的空子，最后还是你来决定。

后来大家补的，已经不只是更多实验，而是记忆和环境

如果说前面这些扩展，主要还在回答“这套 loop 能不能进更多问题”，那 habanwer/autoresearch-MIL 和 Research Worlds 这两条线，开始处理的是另一件事：这套 loop 能不能长时间活下去。

原版 autoresearch 有一个很明显的限制：它几乎没有长期记忆。一次 session 结束了，下次再开，很多东西就得重新来。autoresearch-MIL 补的正是这个缺口。它让 agent 在每轮结束后写 sessions/memory.md，把目前最好的结果、保留下来的实验和关键上下文记下来。下一轮启动时，先读自己的历史经验，再继续往下跑。

这听起来朴素，实际上很重要。因为一旦 loop 真要接近 NEVER STOP，失忆就会变成结构性问题。你可以接受 agent 某一轮试错失败，但你很难接受它每次重启都像第一次来。

还有一类更抽象、但也更重要的尝试，是开始把“研究环境本身”写出来。Research Worlds 讨论的已经不只是“怎么记住上轮实验”，而是“怎么把研究环境本身写出来”。你可以把它理解成：不再只给 agent 一个 prompt 和几个脚本，而是把数据、目标、约束、角色、算力预算、停止条件这些规则一起写进一个 environment。原来散在 prompt、脚本和人脑子里的东西，开始被明确固化下来。

到这里，我的感觉已经不是“大家在做更多实验”，而是“大家开始认真面对一个长期运行系统到底靠什么活着”。

把这两条线放在一起看，我自己的感受是：

最小闭环正在从 loop 长成 environment。

前面那些扩展，还是在补 loop 的边界。到了这里，社区开始补的是更慢、更麻烦、但也更关键的东西：记忆、治理、环境规则。说得直白一点，大家已经不满足于让 agent 多跑几轮了，开始认真处理“它长期活着时，世界长什么样”这个问题。

所以最后真正重要的，不是 NEVER STOP，而是谁来决定它追什么

这一个月的社区实验，已经证明了很多事。

它证明 loop 能离开原始训练任务。

• 能去 RAG。
• 能去营销归因。
• 能去协作网络。
• 能去跨 session 记忆。
• 甚至开始往 environment 的方向长。

但这些实验同时也反过来证明了一件更硬的事：

loop 能走多远，最后还是卡在写 program.md 的人，和定义 score.py 的人。

DataCamp 有一句话，我觉得放在这里特别合适：

[!important]
写一个好的 program.md，需要你自己做过这件研究。你得知道哪些方向值得试，“更好”对你的问题到底意味着什么。

这句话背后的意思很直白：你不能用 autoresearch 去替代你还没形成的理解。它能加速你已经理解的问题空间，但它不会自动替你发明一个可靠的问题定义。

同样，score.py 也从来不只是个技术附件。谁定义 score，谁就在定义这个系统会朝哪儿冲；谁没有把漏洞堵住，谁就等于提前把作弊的路径写进了规则里。

说到底，人的角色没有消失，只是变了。

以前你是那个亲手做实验的人。
现在你越来越像那个写研究环境的人：定义目标，收紧边界，设计评测，决定哪些方向值得浪费预算，哪些不值得。

我写到这里，反而越来越不觉得 autoresearch 的核心是“自动做研究”这四个字。它当然让 agent 的执行能力往前走了很多步，但它也顺手把人的工作重新划了一遍。人不再主要负责把每一轮实验亲手跑完，而是负责决定：这个系统应该追什么，应该看什么，哪些反馈信号可信，哪些根本不能放进回路里。

这活没有轻松多少，只是更靠前了。

结尾

如果只看热度，autoresearch 很容易被写成一个“agent 开始自己做研究”的故事。

但我现在更愿意把它理解成另一种变化：研究这件事，第一次被压缩成了一个可以持续运行的最小闭环。过去一个月里，社区最有价值的探索，不是在重复这个 repo，而是在不断补齐让这条闭环更接近 NEVER STOP 的条件。

只是走到最后，人的位置并没有消失，反而变得更清楚了。

AutoResearch 这一个月的社区实验，证明了 loop 能走进的领域比很多人一开始想得更宽。
但它也同样证明了：能走多远，取决于写 program.md 的人的知识边界，以及定义 score.py 的人有没有把漏洞提前堵住。

NEVER STOP 是给 agent 的指令。
但谁来决定它追什么、怎么算赢、哪些反馈信号根本不该放进回路里——这件事还没有办法委托出去。

参考链接

1. karpathy/autoresearch
   https://github.com/karpathy/autoresearch
2. 原始 program.md
   https://github.com/karpathy/autoresearch/blob/master/program.md
3. mutable-state-inc/autoresearch-at-home
   https://github.com/mutable-state-inc/autoresearch-at-home
4. kousun12/darwin-derby
   https://github.com/kousun12/darwin-derby
5. autoimprove 项目说明
   https://adelzaalouk.me/2026/mar/15/autoimprove-autonomous-optimization/
6. Shopify 工程文章
   https://shopify.engineering/autoresearch
7. lucianfialho/mmm-research
   https://github.com/lucianfialho/mmm-research
8. habanwer/autoresearch-MIL
   https://github.com/habanwer/autoresearch-MIL
9. Research Worlds 讨论串
   https://github.com/karpathy/autoresearch/discussions/275
10. DataCamp 指南
    https://www.datacamp.com/tutorial/guide-to-autoresearch

网友解答：

---

--【壹】--：

pdca，把检验标准列出来，然后无限循环。把人从检验的位置上抽出来，提高ai的效率。

---

--【贰】--：

对的，其实一定程度上来说，就是人来扮演这群Agent的BOSS/CEO，不需要知道Agent工作的每个细节，但KPI一定要人来定、评

---

--【叁】--：

还是要HUMAN IN THE LOOP.