Superpowers-ML 支持 Auto Research：跑两天的 Human on the Loop

type

Post

status

Published

date

Apr 12, 2026

slug

superpowers-ml-autoresearch-zh

summary

在 Claude Code 里跑两天无人值守的 ML 实验循环，靠的不是更聪明的 Agent，而是三层 liveness 机制、TaskList 仪表盘和异步 Note 介入通道。

开头

我在 Superpowers-ML 里实现了 Auto Research，我在使用上相对稳定了，开源出来。

核心思路：利用superpower-ML 的标准流程实现一个 baseline 和Auto Research的协议，auto research 进行循环迭代，关键是如何解决循环稳定性和可观测性的难题。

Karpathy 的 Auto Research

Andrej Karpathy 最近开源了 Auto Research——给一个 AI agent 小号 LLM 训练环境，自己改代码、跑实验、判断改动是否有效，循环下去。630 行 Python，单 GPU，5 分钟一轮，每小时约 12 次实验。

他在 nanochat depth-12 上无人值守跑了两天，agent 尝试了约 700 次改动，留下 20 个有效的，全部可叠加并迁移到 depth-24 的大模型，Time to GPT-2 leaderboard 快了 11%。

Karpathy 的 autoresearch，关键设计四条：

固定 5 分钟预算：每轮训练严格 wall-clock 5 分钟，无论什么架构或 batch size。时间是硬约束，让所有实验可比。

单文件可改：agent 只能改 train.py（模型 + optimizer + 训练循环）。prepare.py 不可动。把行动空间圈死在有意义的位置。

单指标 val_bpb：validation bits per byte，vocab-size 无关，架构变动也能公平比较。

Git 自动回滚：改善就 commit，没改善就 git checkout -- .。不需要 agent 自律，git 就是最严厉的裁判。

Auto Research 难在哪

就两个问题：循环稳定性和可观测性。

我实际从开始使用 claude code 就在尝试怎么让他自动循环研发，当时遇到的问题就是这个循环总会意外卡住。也尝试过用外部循环，claude -p 无头调用，这样稳定性没问题，但是你观测它在做什么，要通过日志，通过另一个无关的 calude session 来做解释，没法实时干预。

它的难度就在于，使用什么样的循环机制，才能既稳定又可观测。还是选择把主循环放在 claude 的 session 里，而不是额外的程序化循环，那需要理解 claude session 的工作原理。

另外，就是怎么去管理主 session 的 context 不爆炸，在循环迭代期间不触发压缩和清理。

上面说的是通用性的困难，到具体的 research 问题，其实成功取决于问题难度，模型的能力，以及迭代协议的设计，这里我会 share 写关键理念。

当然，以上充分融入了 Superpowers-ML 的 auto research skill 的设计。

核心流程：从协议定义到自主循环

阶段 1 · 协议定义。 复用 SPML 的标准流程——brainstorming 收集研究问题，planning 写设计文档，subagent-dev 构建 baseline 代码。和普通实验的区别：brainstorming 识别 autoresearch 意图后追加一组协议问题——研究问题是什么、哪些文件可改（Variable files）、哪些不可改（Fixed files）、评测命令、终止条件。答案进入设计文档的 ## Autoresearch Protocol 一节。

阶段 2 · 基线验证与交接。 VP L1（Validation Pyramid Level 1）是强制前置条件，不可跳过。必须验证四件事：baseline 跑得通、评测脚本独立可运行、输出可解析成 metric 值、两次运行结果一致。通过后生成两个文件——autoresearch-protocol.md（协议）和 experiences.md（含 baseline 指标），交给新 session。

阶段 3 · 自主循环。 新 session 在 git worktree add 创建的隔离 worktree 中启动。Supervisor 读协议，进入主循环——每轮派发 Researcher、审查、训练、评测、判定，直到终止条件触发。

阶段 3 在核心抽象上几乎是 Karpathy 设计的直接映射。对应关系：

Karpathy autoresearch	Superpowers-ML autoresearch
`train.py`（可改）	Variable files（可改）
`prepare.py`（不可改）	Fixed files（不可改）
5 分钟 wall-clock 预算	time_limit（protocol 配置）
`val_bpb`（单指标）	Eval.metric + Eval.command
Git 自动 commit / rollback	Git 自动 commit / rollback（worktree 隔离）
`program.md`（研究方针）	初始 hint + experiences.md + Note 列

设计哲学完全一致：划出可改 / 不可改的边界、固定预算让实验可比、单指标决定去留、git 作裁判。差异主要在两处：

1. 研究方针的粒度。 Karpathy 的 program.md 是静态文档，人迭代它来调整方向。Superpowers-ML 的 experiences.md 是一张实时表格——先验知识写在 R0 的 Note 列，循环中的 guidance 随时追加到当前轮的 Note 列。本质仍是同一个抽象：人通过文本而非代码介入研究方向，只是粒度更细。

2. 分工。 Karpathy 的设计里一个 agent 负责所有事（改代码、训练、评测、提交）。Superpowers-ML 拆成两个角色：Researcher（subagent，只改代码，做调试）和 Supervisor（主 session，合规 + 训练 + 评测 + git）。拆分的动机不是能力不够，是git 写权限必须被一个稳定角色独占，避免 agent 误伤历史。

subagent 做 Researcher 是很自然的，一个是避免了主 session 的 context 爆炸，能运行很久不触发压缩，一个是让 Researcher 是轻Context 的满血版，免受 Conext Rog 的影响。

我最早做 Auto Research 的时候，拆分了 Planer，Executor，Reviewer三个 subagent，现在看是过重了，适合极其复杂的问题。

首先合并了 Planner 和 Executor，是因为更多地依赖了人在初始阶段的hint，已经在循环中给出来的 note，所以独立能提出新策略的角色就不是必选项了，这个当初是为了让一个问题完全自主研究，今天看模型在 ML 领域还是没有那么强，需要人来给一定策略提示，但框架用户可以要求拆分Planer和Executor，提升自主性。

然后我第一个版本是带着独立 Reviewer 的，我发现几个问题：它非常的烧 token，它spawn 出来要重读 Researcher 的所以代码和策略，审查它的全部日志；当用户想了解 Reviewer 的判断细节的时候，其实是主 Agent（Supervisor）去读 Reveiwer 的日志，这一来一回的重读消耗 token，也造成了不一致性，其实我的 auto Research 不是追求完全自主，而是 human-on-the-loop，用户的询问和提示会贯穿始终，这额外的 token 消耗过多，Reviewer 变成了应对复杂问题的可选项。

没有 Reviewer，怎么确保代码质量？怎么避免作弊？这就涉及到一个核心的设计理念。

Programmatic Evaluation：评测脚本不可动。 评测脚本在 brainstorming 阶段由用户定义，VP L1 验证可运行性和确定性，handoff 独立确认。它始终在 Fixed files 里，Researcher 不能改、不能替换、不能在新文件里造替代品。Supervisor 每轮原样执行 eval_command，输出是 metric 的唯一真源。

这条理念防的是一个微妙的失败模式：Researcher 发现改训练代码很难提升 metric，转而写一个"更好的"评测脚本让数字好看。LLM agent 确实会这么做。把评测脚本锁死在 Fixed 层，Supervisor 合规检查用 git diff --name-only 扫一遍就能发现违规。

最后每一轮默认流程如下：

核心理念：Human on the Loop

在讨论怎么解决之前，先说清楚我们要什么样的"人机协作关系"。

传统的软件任务或是 AI 赋能的编码，都是 Human in the Loop：人在循环里每步推动执行。可靠，但也没法有远超出人力的生产力。另一端是 完全托管：扔出去、做别的事、几小时后回来。可远超出人的并行度，但Agent的创造力和直觉还不够。全托管自动跑容易偏航，结果为 0。

ML 问题大多不是一个干净的搜索空间，哪怕对于最强的 Agent也并不是完全胜任。超参和架构变动可以搜索，但哪个方向值得走、何时放弃一个假设、如何注入先验——agent 做得不够好。纯托管会把这些决策让渡出去，盲点就在这里。

Human on the Loop 是中间路线。这个说法不是我造的，控制论里早就在用，区别是介词：

Human in the Loop：人是循环的一部分，每步必经

Human on the Loop：人在循环上方，观察和介入，不参与每一步，但可以随时指挥方向。

在这个“姿势”下，系统默认自治——出门前一键启动，两天后回来看结果；但也可以每隔几小时看一眼，发现跑偏就插一句话扳回来。控制权的粒度在你手上。 这不是"最优"架构，是在 agent 能力有限的当下最"务实"的架构。

要让这个“姿势”成立，需要三种能力，缺一不可：

自治——人可以离开，loop 自己跑下去

观测——人可以随时看清 agent 在做什么

介入——人可以引导，但不必暂停 loop

缺自治，退回 Human in the Loop。缺观测，退化成盲跑。缺介入，看得见却改不动。下面三节就是这三种能力的落地。

Supervisor 稳定循环

听起来很简单：改代码 → 训 5 分钟 → 看指标 → commit 或 rollback → 下一轮。Python while True 就完了。程序化框架确实很容易，但是就失去了随时可以交互及干预灵活性，这种灵活性才是 agentic 的核心体验。

但给 Agent 一段 system prompt，告诉它如何循环，这种软编码的指令会在 Conext 变长后可能失效。也会因为工具和程序调用意外卡住。如果把循环放进主 Agent 的 session 里，自然会获得更好的可交互性和干预性，那么稳定性就变成了核心难题。

举几个常见难题：

主 Agent 退出循环。 Claude Code 的在多轮任务后，忘了它要自主运行了，停下来问你是否继续？那循环就中断了。

主 Agent 被任务阻塞。 5 分钟预算，但 agent 改完的代码可能卡在数据加载、死循环、OOM 后的僵尸状态。任务卡住，主 Agent 无法响应，循环中断。

后台任务卡住。 你把所有的任务都变成后台任务，这时候任务卡主，就没法触发主 Agent 的下一步动作，循环终止。

claude code 本质就是一个循环——REPL：

Read — 读取用户输入，将原始字符串解析成内部数据结构

Eval — 对解析后的表达式求值/执行

Print — 将求值结果格式化后输出给用户

Loop — 回到第 1 步，等待下一次输入

一旦 Agent 进入 Read 阶段，或者在 Eval 阶段卡主，那么循环就终止了。

非阻塞执行。 我是默认任务都走后台模式（run_in_background: true），主 Agent 那随时接受用户输入，另外是主 Agent 一旦阻塞，除非人来把任务终止（ESC）或挪到后台（ctrl+b），循环是卡的最死的。Researcher 或程序在后台跑完，Claude Code 自动通知 Supervisor，这个通知就是让 Supervisor 继续的信号。正常路径只靠这层就够：派活 → 跑 → 通知 → 评测训练 → 下一轮。

per-round 一次性超时。 Researcher 卡死、脚本卡住通知没发出来，Supervisor 就永远在等一个不会来的信号。所以每轮开始时 Supervisor 创建一个一次性 cron，延迟 time_limit × 2（5 分钟预算就 10 分钟）。到时间 Researcher 没回来，cron 触发消息："本轮超时，宣告失败，下一轮"。正常完成时 Supervisor 主动删掉这个 cron。

session 级 heartbeat。 前两层还不够。如果两层都漏了——进程异常、race condition——Supervisor 就完全静默。第三层是 recurring cron，每 30 分钟触发"autoresearch heartbeat — 检查循环状态"。session-scoped，只在 REPL idle 时触发，不积压。最后的兜底。

Claude Code 的 REPL 是个天然的 while 循环，既是限制也是资源。限制是你要再它的 REPL 里按规则执行；资源是 cron 和 subagent 通知已经做好了，只需要把它们组合成事件源。我没写新调度器，只是选对了三个已有机制做冗余。

可观测性：利用 Task List

下一个问题：用户回来一眼，怎么在 3 秒内建立状态认知？

Claude Code 内置的 TaskList 本来是给 agent 追踪自己待办的，用户平时很少看。在 autoresearch 里我们把它重新诠释成循环仪表盘。

每一轮开始前，Supervisor 强制创建 6 个任务对应 6 个 step：

执行过程中，每完成一步，Supervisor update 这条任务写回实际结果：

用户打开 Claude Code 一眼看清：第几轮、走到哪一步、每步结果、best 有没有动。不需要读日志，TaskList 这一屏就是全量状态。

这个设计有一个意外的副作用：它强制 Supervisor 不能跳步。任务必须显式创建和 update，Supervisor 没法"看起来搞定了"就跳过评测进下一轮。我们早期见过这类错误——看到训练脚本里的测评指标变好就宣称改进，跳过真正的客观评测。加了强制 TaskList 之后这类问题消失。它在做监控面板的同时，顺带成了过程的强制锚点。

更多的信息，因为 Supervisor 处于 Read 状态，可以随时让他汇报，甚至可以通过 sleep-check 循环机制，来实时播报，它自己会控制频率！

随时介入：Note 列

观测解决"看见"，下一个问题是"看见了想改"。

主 Supervisor 不能被同步任务阻塞，阻塞了用户消息就进不去。两天里你可能想说十几次话，每次都等 5-10 分钟，体验就崩了。

解法两部分：后台执行 + 异步介入通道。

后台执行的原则是 Supervisor 主循环除了调度和决策，什么同步阻塞的事都不做：

Researcher subagent 用 run_in_background: true 派发，Supervisor 发完就回

训练用 Bash(train_command, run_in_background: true) 跑，Supervisor 定期回来检查状态

这样 Supervisor 大部分时间 REPL 是 idle 的。你说一句话它立刻能回——因为它本来就在等 Researcher 通知或下一次 heartbeat，没在跑任何同步任务。

但光能响应还不够。半夜你想起"下一轮试试 warmup 200 步"，直接告诉 Supervisor——它怎么处理？暂停循环问清楚？不行，loop 必须继续。直接灌进下一轮 prompt？太粗暴。

Note 列是答案。experiences.md 是每轮的结构化实验记录，一个 Markdown 表格：

最后一列 Note 就是用户 guidance 的落脚点。你半路说"下一轮试试 warmup 200 步"，Supervisor 把这句话追加到当前轮的 Note 列，继续自己的流程，循环不暂停。下一轮开始时 Supervisor 把 experiences.md 最近 N 行（包括 Note 列）注入新的 Researcher prompt，Researcher 自然读到你的 hint。

这个机制把用户介入从"同步指令"转成了"异步数据"。你不是在打断进程，是在往一张表格里写一列。

三个能力加起来，Human on the Loop 才算真正成立——可以离开（自治）、可以观察（TaskList）、可以介入（Note）。任一缺失都不成立。

长循环的上下文管理

循环不停做到了，但还有一个安静的风险：跑 50 轮之后，Supervisor 的对话上下文已经很长。LLM 在长上下文下指令跟随能力会退化——步骤被跳过、格式遗忘、判断变随意。循环物理上在跑，行为质量在衰减。

控制上下文增长：

Researcher 每轮是新 subagent。 不是一个 Researcher 跑 50 轮积累上下文——每轮新建，拿到裁剪过的 prompt 和当前代码，做完销毁。Researcher 的上下文大小和轮数无关。这是最关键的一条：做创造性工作的角色永远在干净的上下文里。

experiences.md 窗口化。 完整实验记录始终保留在文件里，但注入 Researcher prompt 的只有摘要加最近 N 轮（默认 N=5）。更早的轮次压缩成一行 addendum。Researcher 看得到趋势和近期细节，看不到 30 轮前的具体参数。

再说说 hearbeat 内容，这些都是 Context 变长后，模型常常出现的不按规则的问题，通过 hearbeat 不断强化。

效果：第 50 轮的行为质量和第 1 轮基本一致。循环不只是物理上在跑，行为上也保持纪律。

最后

框架是给了一个稳定的循环，让 Researcher 能在循环里做创造性的工作。稳定性是前提，不是最终答案。Auto Research 的价值由大模型的创造力、问题空间的可搜索性、baseline 的质量，决定——这些都不是稳定性机制的事。但如果循环跑不下去，后面一切都是零。

我自己也会反思，跑了这么多token，哪些结果是带来了生产力的？它的准确率比人低，但是实际 token 还是比人力成本低的多，我对它的期待是哪怕 100 次能带来一些 insight，那可能就还清了 token 的成本。

最后总结下，skill 通过 superpower-ML 的范式创建 Auto Research 任务，测试 Baseline 的健康性，在 Claude Code 的 REPL 循环里保持任务的稳定性和可交互性，实现了 Human-On-The-Loop。

尝试 Superpowers-ML autoresearch, 在Claude Code 里：

Superpowers-ML | Karpathy autoresearch | Superpowers