一个帖子引发的问题
前两天有人在社区发了个帖子：
一个最能体现你当下 AI Coding 水平的问题：你能让 codex、claude code、gemini cli 无人值守运行多长时间？
注意关键词——无人值守。不是你盯着屏幕一步步确认那种，而是你去跑步、吃饭、睡觉，回来直接拿结果。
有人回复说，他从 Andrej Karpathy 的 autoresearch 项目中得到了很多灵感。
我把这个项目翻了个底朝天。下面聊聊我的理解。
autoresearch 到底在干什么
Karpathy 在 README 开头写了段带点科幻感的话：
以前，前沿 AI 研究靠的是肉体计算机——在吃饭、睡觉、玩耍之余做做实验，偶尔用声波互联（嘴巴）在叫"组会"的仪式上同步进度。那个时代已经过去了。
翻译成人话：autoresearch 让 AI agent 自己跑实验。人类睡觉，AI 干活。
具体来说，它做的事情是这样的：给一个 AI coding agent（比如 Claude Code 或 Codex）一个真实的 GPT 模型训练代码库，然后让它自主地修改代码、训练模型、评估结果、保留或丢弃改动。循环往复，直到人类手动打断。
整个项目只有三个核心文件：
prepare.py：数据准备和评估工具，只读，不许动train.py：模型架构、优化器、训练循环——agent 唯一能改的文件program.md：给 agent 的指令文件——人类唯一需要写的东西
人类的角色从"写代码的研究员"变成了"写指令的研究总监"。
六个让它不会停下来的工程设计
很多人觉得"让 AI 一直跑"靠的是模型够聪明。错了。autoresearch 的答案是：靠一套不容易失控的工程规则。
1. 只允许改一个文件
agent 只能碰 train.py。整个架构、超参数、优化器、batch size 都可以改，但活动范围被死死限在这一个文件里。
这很克制。但克制就是持续运行的前提。
改一个文件，diff 可审查，回滚成本为零（一条 git reset）。如果允许到处改，错误会在文件间互相传播，三轮之后整个代码库就是一团浆糊。
2. 每轮实验固定 5 分钟
不管你改了什么——换架构、调学习率、加大模型——训练永远只跑 5 分钟（wall clock）。超过 10 分钟直接 kill，视为失败。
这个设计有两个好处。
第一，所有实验直接可比。你改了模型大小？没关系，都是 5 分钟，谁的 val_bpb 低谁赢。
第二，系统不会被单个任务卡死。对无人值守来说，最怕的不是 AI 犯错，而是犯错之后卡在那里把整个夜晚都耗掉。5 分钟上限意味着一小时能跑 12 轮，睡一觉大约 100 轮。
3. 棘轮机制：提升就留，不提升就扔
每轮实验结束后，agent 做一个二元判断：
val_bpb（验证集的 bits per byte）降低了 → 保留 commit，推进分支- 没降低或者更差 →
git reset，回到上一个检查点
没有"先存着以后再看"。没有"感觉还行先留下"。好就留，差就扔。
这是整套系统最强的稳定器。它阻止了代码库不断积累"也许有用"的脏改动，确保分支永远围绕一个干净的最优基线前进。
4. 失败是流程的一部分，不是终点
program.md 里明确写了对崩溃的处理策略：
- OOM 了？检查是不是 typo 或者 import 漏了。低级错误就修，改完再跑
- 思路本身就有问题？在
results.tsv里记一笔crash，继续下一轮 - 卡住了？想想有没有新角度，试试组合之前的"差一点就成功"的实验，或者搞个更激进的架构变化
关键是：失败不吞上下文。每次实验的结果——包括失败的——都记录在 results.tsv 里。agent 下一轮可以参考前面的尝试来决定接下来试什么。
5. 记忆存在外面，不在脑子里
持续运行最怕上下文爆炸。对话越来越长，agent 被历史信息淹没，开始犯低级错误。
autoresearch 的做法很直接：
- 训练输出重定向到
run.log（> run.log 2>&1），不让输出涌入 agent 的上下文窗口 - 只用
grep读关键指标：grep "^val_bpb:\|^peak_vram_mb:" run.log - 所有实验历史写入
results.tsv——外部账本，不依赖对话记忆
agent 每一轮只需要知道三件事：我这次改了什么，结果好不好，比上次进步了没有。其他的，翻账本就行。
6. "永远不要停下来问人"
program.md 里有这么一段指令，加粗加大写：
NEVER STOP: Once the experiment loop has begun, do NOT pause to ask the human if you should continue. Do NOT ask "should I keep going?" or "is this a good stopping point?". The human might be asleep.
很多 AI 工具骨子里还是助手逻辑——碰到不确定就停下来提问。交互协作没问题，无人值守就是致命伤。人一离开，系统等于停机。
autoresearch 的要求很明确：在既定规则内持续推进。没灵感了？想办法。读代码里引用的论文，重新审视之前的实验，试试组合之前差一点成功的改动。循环一直跑，直到人类手动打断。
这套思路的普适性
autoresearch 做的是 ML 训练优化，但它的核心模式可以迁移到任何有明确指标的自动化场景：
设计要素
autoresearch 的做法
通用化翻译
限制范围
只改 train.py
限定 agent 的修改边界
限定时长
每轮 5 分钟
给每个任务设硬性超时
强制判断
val_bpb 涨跌决定去留
有明确指标的自动评估
允许失败
崩溃记录后继续
异常降级不中断主循环
外置记忆
results.tsv + run.log
外部状态存储取代上下文膨胀
不打扰人
NEVER STOP
agent 在规则内自主决策
如果你想让自己的 AI coding 工具真的"无人值守"——不管是 Claude Code、Codex 还是 Gemini CLI——核心问题不是"模型够不够聪明"，而是"你有没有设计一套让它不容易停下来的规则"。
真正的产出不是代码，而是筛选后的方向
有人说 autoresearch "能跑出灵感"。这话听起来玄，但逻辑很朴素。
一晚上 100 轮实验。每轮都有明确结果。好的留下，坏的丢掉。你第二天早上看到的不是一团混乱的过程，而是一批已经经过筛选的候选方向和一份清晰的实验日志。
灵感不是从 AI 的"顿悟"里冒出来的。灵感是从大量被验证、被淘汰、被保留的小实验中自然浮现的。
压缩成一句话：
autoresearch 能持续运行，不是因为 AI 会一直"想"，而是因为 Karpathy 把"想、试、判、留、弃"做成了一个不会轻易中断的工程闭环。
想搞无人值守？先别急着调模型。先把你的流程设计成一个不容易死掉的循环。