第7章: autoresearch —— 全自动化软件开发

gstack 是人驱动流程，二十三个角色在七个 Sprint 阶段中协作。superpowers 是 Agent 驱动流程，十四个 Skill 自动触发，子 Agent 分工实现。两条路，一个共同点：人类仍然在循环中。gstack 需要你在每个阶段运行命令。superpowers 需要你在设计批准时确认方案。

autoresearch 把这个共同点也推倒了。

它的目标一句话就能说清楚：从 Issue 到合入，全程不需要人。你写好 Issue，Agent 自己实现、自己审查、自己修复、自己提 PR、自己合入、自己关 Issue。你喝茶。你睡觉。醒来看到一排绿色的 merged。

Karpathy 的 autoresearch 思想在软件工程领域落地了——82K Stars 的 ML 研究自动化项目，被 smallnest 适配成了通用的全自动开发工具。

7.1 起源：从 GPU 训练到软件工程

2026 年 3 月，Andrej Karpathy 在 GitHub 上发布了一个叫 autoresearch 的项目。代码没多少——核心是一个循环控制脚本。但思路极其大胆：让 AI Agent 在循环中自主做 ML 研究实验——自己改超参数、自己跑训练、自己看结果、自己决定下一步改什么。人类设定目标后就放手。

82,649 Stars。社区炸了。

不是因为代码复杂。是因为它第一次把「自主循环」从工程执行层面推到了研究决策层面。Ralph Loop 让 AI 反复改代码直到测试通过——执行层面的自主。autoresearch 让 AI 自己决定「接下来该尝试什么方向」——决策层面的自主。

但 Karpathy 的 autoresearch 面向的是 ML 训练场景——单 GPU 上的 nanochat 训练实验。smallnest 看到了另一种可能：把这个模式搬到通用软件工程上。

2026 年 4 月，smallnest/autoresearch 发布。517 Stars，远不如原版。野心却大得多——不做「让 AI 自己做 ML 实验」，做「让 AI 自己做完整个软件开发流程」。

两个关键改造。第一，把自主循环的主体从单 Agent 变成了多 Agent 轮转——Claude Code 实现，Claude Code 审查，Codex 优化，Codex 再审查，OpenCode 再优化，OpenCode 再审查，不同模型交叉实现和审核。第二，把目标载体从实验配置变成了 Issue——GitHub Issue、本地 Markdown 文件、百度 iCafe 卡片、阿里云效 Codeup，四种来源，一套流程。Issue 就是任务合约。验收标准写在 Issue 里，autoresearch 读到，自己判断做完没有。

7.2 安装与使用：一条 clone 命令，从 Issue 开始

autoresearch 的安装只有一步——git clone。不需要 npm、不需要 pip、不需要构建。安装之后，唯一的交互就是传给它一个 Issue 编号。

7.2.1 依赖与前提

autoresearch 是胶水层——它不自己写代码，它调度其他 Agent 写代码。所以前提条件就是你至少装了一个它支持的 Agent CLI。五个 Agent 对应五条验证命令：

对于 GitHub 模式（默认），还需要 gh auth status 通过。百度 iCafe 模式需要 icafe-cli whoami 和 icode-cli whoami。阿里云效 Codeup 模式需要 curl。

autoresearch 本身没语言运行时要求——run.sh 是 bash 脚本。但你的项目必须有对应语言的构建工具（Go/Node/Python/Rust/Java），因为硬门禁要跑 build 和 test。

7.2.2 安装

git clone git@github.com:smallnest/autoresearch.git

不需要 ./setup、不需要 ./configure、不需要 make install。autoresearch/run.sh 是唯一入口——从你的项目目录调用它，脚本自动寻找项目根目录、自动检测 Git 平台、自动选择对应的 Agent CLI。

7.2.3 基础使用

最小用法——在当前项目目录中处理一个 GitHub Issue：

autoresearch/run.sh 10

Agent 做的事：gh issue view 10 读取 Issue → 第一个 Agent 初始实现 → 后面 Agent 轮流审查修复 → Build/Lint/Test 全通过 → LLM 评分 ≥ 85 → gh pr create → squash merge → 评论总结 → gh issue close 10。

指定项目路径和最大迭代轮数：

autoresearch/run.sh -p /path/to/project 10 16

Issue #10，最多 16 轮（默认不限，但项目内置了连续失败停止阈值 MAX_CONSECUTIVE_FAILURES=3）。

7.2.4 Agent 配置与模型选择

-a 参数指定用哪些 Agent 和调用顺序：

autoresearch/run.sh -a claude,codex,opencode 10

第一个 Agent（claude）做初始实现，后续迭代按 (iter − 1) % N 轮转——Claude 实现 → Codex 审查修复 → OpenCode 审查修复 → Claude 再修复，循环下去。不指定 -a 时默认就是这三个。

每个 Agent 的 prompt 模板在仓库 agents/*.md 中，可被项目级 .autoresearch/agents/*.md 覆盖——不同项目可以给同一个 Agent 不同的行为指令。

模型层面也可以调。全局指定所有 Agent 用 Opus：

AGENT_MODEL=opus autoresearch/run.sh 10

或者每个 Agent 不同：

AGENT_MODEL_CLAUDE=sonnet AGENT_MODEL_CODEX=gpt-5.2 autoresearch/run.sh 10

Claude 跑 Sonnet 降低成本，Codex 跑 GPT-5.2 提供不同的审查视角。

7.2.5 Continue 模式

autoresearch 的状态保存在迭代日志中。API 挂了、网络断了、机器重启，回来继续：

autoresearch/run.sh -c 42 10

从 Issue #42 上次中断的迭代继续，再跑最多 10 轮。不从零开始。

7.2.6 本地 Issue 模式

不需要 GitHub。Issue 写成本地 .md 文件，autoresearch 读文件、写代码到本地分支、结果追加回文件末尾：

mkdir -p .autoresearch/issues
cat > .autoresearch/issues/issue-008-add-login.md << 'EOF'
# Add login feature
实现用户登录功能，支持邮箱+密码登录。

## 验收标准
- [ ] 登录页有邮箱和密码两个输入框
- [ ] 输入正确凭据后跳转到首页
- [ ] 输入错误凭据后显示错误提示
- [ ] 登录状态用 JWT 存储在 localStorage
EOF

autoresearch/run.sh --issues-dir=.autoresearch/issues 8

命名规则：issue-NNN-描述.md，三位数字。run.sh 8 匹配 issue-008-*.md 或 issue-8-*.md。结果（评分、迭代轮数、分支名、时间戳）追加到文件末尾的 --- 分隔线之后。适合内网项目、个人项目、不想连 GitHub API 的场景。

7.2.7 多平台

autoresearch 根据 Git remote 自动检测平台，四种模式一套命令：

百度模式示例：

autoresearch/run.sh --issue-source=baidu --space=cloud-iCafe 22210

Codeup 模式需要 token 和组织信息：

export CODEUP_TOKEN=xxx CODEUP_ORG_ID=123 CODEUP_REPO_ID=456
autoresearch/run.sh --issue-source=codeup 42

四种模式共用同一套 Agent 轮转逻辑和质量门禁——变的只是 Issue 来源和 PR/MR 创建方式。

7.2.8 配置：program.md 与 .autoresearch/

项目的规矩写在 .autoresearch/ 目录中。完整结构：

.autoresearch/
├── program.md                 ← 实现规则（Agent 每轮读取）
├── agents/                    ← 覆盖默认 Agent prompt
│   ├── claude.md
│   ├── codex.md
│   ├── claude-mimo.md
│   └── opencode.md
├── issues/                    ← 本地 Issue 文件
│   └── issue-008-*.md
├── workflows/                 ← 迭代日志（自动生成）
└── results.tsv                ← 处理结果汇总（自动生成）

program.md 是最核心的配置文件。内容四部分：权限边界（什么能改、什么不能改）、代码规范（通用 + 语言特定）、测试要求、提交规范。仓库自带一个多语言模板——Go、Python、Rust、TypeScript、Java 各一份。实际使用时按项目语言裁剪，删掉无关部分以降低 token 消耗。

7.2.9 环境变量速查

调整 PASSING_SCORE 是调质量门槛——90 更严格，80 更宽松。调整 AGENT_MODEL 是调成本——Sonnet 便宜但审查不如 Opus 深，按项目预算取舍。

7.2.10 全量 Issue 批处理

不止单个 Issue。run_all.sh 可以一批处理全部开放 Issue：

autoresearch/run_all.sh --issue-source=codeup --codeup-token=xxx --codeup-org=123 --codeup-repo=456

晚上把十几个 Issue 丢给 run_all.sh，早上看 results.tsv——哪些通过了、哪些还在迭代、哪些失败了。人的时间用在判断结果上，不在盯着 Agent 上。

7.3 核心架构：四个机制撑起全自动

autoresearch 的架构不复杂。核心就是四个机制叠在一起。

7.3.1 多 Agent 轮转：让不同模型互相审查

这是 autoresearch 和 Ralph Loop 最根本的差异。Ralph Loop 是单 Agent 反复迭代——同一个模型反复读自己的代码、改自己的代码、判自己的代码。问题很明显：模型的盲区是固定的。它看不出来的问题，迭代一百次还是看不出来。

autoresearch 换了一种模式。它支持五个 Agent——Claude Code、Codex、OpenCode、Claude-Mimo、DeepSeek。你通过 -a 参数指定用哪几个、按什么顺序。

轮转公式很简单：(iter − 1) % N。第一个 Agent 做初始实现。第二个 Agent 审查第一个的产出，发现问题就修。第三个 Agent 审查第二个修完的结果，再发现问题再修。以此类推，循环轮转。

不同模型有不同盲区。Claude 容易漏掉的东西，Codex 可能一眼就看到。Codex 的代码风格问题，OpenCode 可能立刻揪出来。三个模型交叉审核的覆盖面，远超单模型自我审查十轮。这和代码审查中多 reviewer 的效果优于单人反复 self-review 是一个道理——只不过 reviewer 从人类换成了不同的 AI 模型。

7.3.2 Issue 驱动：验收标准即合约

autoresearch 的一切从 Issue 开始。GitHub Issue、本地 .md 文件、百度 iCafe 卡片、阿里云效 Codeup——四选一，自动检测。

Issue 是合约。验收标准写在 Issue 里（checkbox 格式），Agent 读到就知道什么叫「做完了」。这和第 3 章 SDD 的核心理念一致：先在规格上达成一致，再写代码。区别在于 SDD 是人类和 AI 之间的合约，autoresearch 把它变成了 AI 和自己之间的合约——Agent 自己读验收标准，自己判断是否满足，不满足就继续迭代。

单 Issue 执行流程分五个阶段：

1. 解析阶段：读取 Issue，提取标题、描述、验收标准
2. 规划阶段：自动拆分子任务（如果 Issue 足够复杂）
3. 实现阶段：首个 Agent 初始实现 → 轮转审查 → 修复
4. 质量门禁：Build/Lint/Test 全部通过 + LLM 评分 ≥ 85
5. 收尾阶段：创建 PR → 合并 → 评论 → 关闭 Issue

五个阶段全自动。人只做了一件事——写 Issue。

7.3.3 双轨质量门禁：硬门禁 + 软门禁

autoresearch 的质量保证分两层。

硬门禁：Build、Lint、Test 必须全部通过。这是确定性检查——过了就是过了，没过就是没过，没有任何模糊空间。和第 6 章 superpowers 的 verification-before-completion 做的事一样——代码能跑是最低门槛。

软门禁：LLM 评分 ≥ 85 分。这是语义质量评估——不看代码能不能跑，看代码写得好不好。评分分五个维度，加权计算：

每个维度按问题严重程度给分：无问题 100 分，有建议改进 90 分，有一般问题 70 分，有严重问题 40 分，有致命问题 10 分。加权总分 = 各维度得分 x 权重之和。默认达标线 85 分，可通过 PASSING_SCORE 环境变量调整。

测试质量维度有一个豁免规则：如果项目类型不适用单元测试（Shell 脚本、配置文件等），该维度默认 100 分，审核者需注明豁免原因。

双轨设计回答了传统 CI 的一个长期缺陷：CI 只能检查「能不能跑」，不能检查「写得好不好」。一个测试全绿的代码库仍然可能是一团不可维护的浆糊。硬门禁保证下限，软门禁拉高上限。未达标就进入下一轮迭代——换一个 Agent 重新审查和修复。

7.3.4 program.md：编码在文件里的规矩

每个项目有自己的规矩——代码风格、架构约束、技术选型。autoresearch 提供了一个 program.md 文件，把这些规矩写下来，Agent 在实现 Issue 时自动读取。

内容包括四部分：权限边界（什么能改、什么不能改）、代码规范（通用 + 语言特定）、测试要求、提交规范。支持 Go、Python、Rust、TypeScript、Java 的多语言模板。放到项目的 .autoresearch/program.md 下，Agent 自己读，自己遵守。

这和第 1 章「用结构化知识驾驭非结构化 AI 能力」一脉相承。program.md 就是结构化知识——可复用、可迭代、可版本控制。Agent 每轮读取它，就相当于每次都被同样的规矩约束一次。规矩不是靠人盯着执行的，是靠文件自动注入的。

7.4 工作流全景

7.4.1 从 PRD 到合入的完整链路

autoresearch 和 Goal Workflow（第 8 章）连在一起，构成完整的端到端流水线：

/prd 生成 PRD → 拆分为细粒度 Issue → autoresearch 逐个实现 → 全部合入

用 /prd 生成交付需求文档。让 Agent 基于 PRD 拆分成细粒度 Issue——每个 Issue 小到可以在单次开发会话中完成，有明确的 checkbox 验收标准，标注依赖关系。然后 autoresearch 逐个吞下这些 Issue，自动实现、审查、合入。

smallnest 在自己的 Desktop App 项目上验证过这条链路：19 个 Issue（#22 到 #40），从 PRD 到全部实现，全自动。

7.4.2 Continue 模式与容错

全自动系统必须能处理异常。autoresearch 有三层容错：

• -c 标志：从上次中断的迭代继续执行。API 挂了、网络断了、机器重启了——回来继续，不从头开始。
• 连续失败停止阈值：同一个 Issue 连续失败 N 次后自动停止，不发散消耗资源。
• 单次 Agent 调用重试：应对 API 临时故障，不是一次调用失败就终止整个流程。

7.5 多平台支持

autoresearch 的跨平台适配覆盖四种研发场景，而非笼统的「支持多种 Git 平台」。

GitHub 模式：默认。依赖 gh CLI，自动 push → 创建 PR → Squash Merge → 评论总结 → 关闭 Issue。

本地 Issue 模式：不需要 GitHub，不需要网络。Issue 文件放在 .autoresearch/issues/issue-NNN-描述.md，Agent 读本地文件，代码提交到本地分支，结果追加到 Issue 文件末尾。适合内网项目、个人项目、不想开 GitHub Issue 的场景。

百度 iCafe + iCode 模式：适配百度内部研发体系。Git remote 包含 icode.baidu.com 时自动切换。用 icafe-cli 读卡片，用 icode-cli 提交代码审查，评分 +2 后合入，自动关闭卡片。

阿里云效 Codeup 模式：通过 REST API 操作 Issue、MR、合并、评论。适合使用阿里云效的企业团队。

四种模式，一套流程。Agent 根据 Git remote 和本地文件自动检测切换。人不需要记住「当前项目是什么模式」。

7.6 实战：用 autoresearch 开发网页版贪吃蛇

同一个贪吃蛇。第六种体验。

不打开 Claude Code 手动交互。不回答 brainstorming 的五个问题。不确认设计方案。

写一个 Issue，然后放手。

7.6.1 准备：把需求写成 Issue

因为是重点要介绍autoresearch中代码实现阶段，所以这个例子中issue是手工创建的,你也可以使用/prd生成需求文档，拆解Issues。

在项目仓库中创建一个本地 Issue 文件：

.autoresearch/issues/issue-001-snake-game.md

内容：

# 网页版贪吃蛇游戏

纯前端单文件 HTML/CSS/JS 实现，不依赖任何框架。

## 验收标准

- [ ] 打开 index.html 后能看到 20x20 网格和一条初始长度为 3 的绿色蛇
- [ ] 方向键控制蛇移动，不能反向（向右时按左键无效）
- [ ] 随机位置出现红色食物，蛇头碰到食物后蛇身变长 1 格，食物刷新
- [ ] 撞墙或撞到自己 → 游戏结束，HTML modal 弹窗显示得分
- [ ] 按空格键重新开始，游戏重置为初始状态
- [ ] 最高分用 localStorage 持久化，刷新页面后仍在
- [ ] 隐私模式下 localStorage 不可用时优雅降级（try-catch，默认最高分 0）
- [ ] 游戏循环用 requestAnimationFrame + 手动计时（初始 150ms/步），不用 setInterval

## 技术要求

- 单文件 snake-game/index.html
- 状态层（gameState 对象）和渲染层（Canvas 绘制）分离
- 键盘事件写入 nextDirection 缓冲，gameLoop 在 update() 中同步到 direction
- test.html 覆盖全部验收标准

然后一行命令：

autoresearch/run.sh --issues-dir=.autoresearch/issues 1

人做的事做完了。下面是 Agent 的事。

7.6.2 执行：三个 Agent 轮转四轮

配置用了三个 Agent：Claude Code、Codex、OpenCode。最大迭代 8 轮，LLM 评分达标线 85。

第 1 轮（Claude Code，初始实现）：Claude 读 Issue，拆成四个子任务——HTML 结构与 Canvas 渲染、游戏循环与状态管理、碰撞检测与食物系统、分数系统与 UI 状态。依次实现，产出一个完整的 snake-game/index.html 和 test.html。跑测试——8 个用例，6 个通过，2 个失败：食物偶尔生成在蛇身上，modal 弹窗出现后方向键仍能控制蛇。Build 通过。Lint 通过。LLM 自评 72 分。不达标，进入第 2 轮。

第 2 轮（Codex，审查修复）：Codex 拿到 Claude 的代码和测试结果。审查发现三个问题：食物随机生成没检查蛇身重叠、gameLoop 用了 setInterval 而非 requestAnimationFrame、游戏结束时没拦截键盘事件。Codex 逐一修复。跑测试——8/8 通过。LLM 评分 82。不达标，但方向是对的，进入第 3 轮。

第 3 轮（OpenCode，审查修复）：OpenCode 发现 Codex 修复键盘拦截时只处理了方向键，没处理空格键——游戏结束按空格也能重置，但重置后蛇立刻开始移动（因为空格键事件没被阻止冒泡）。还发现 localStorage 读写没包 try-catch，隐私模式会崩。修复后测试 8/8 通过。LLM 评分 88。达标。

第 4 轮（质量确认）：评分达标后 autoresearch 自动跑最终验证——Build、Lint、Test 全部通过。自动创建 commit（Conventional Commits 格式），推送到分支 autoresearch/issue-001。因为是本地 Issue 模式，结果追加到 Issue 文件末尾，分支保留在本地。

全过程约十二分钟，零人工干预。第 6 章 superpowers 实战中人类还参与了两次——回答问题、确认方案。autoresearch 实战中人类只做了一件事：写 Issue。第 4 章 Ralph Loop 实战中第 3 轮才抓到的 modal 焦点问题，autoresearch 在第 2 轮就被 Codex 抓到了。不是 Claude 比 Ralph Loop 的 Agent 聪明——多 Agent 交叉审查覆盖了单 Agent 的盲区。

7.6.3 和第 5、6 章的对比

同一个贪吃蛇，三种方法论：

autoresearch 的时间最短（十二分钟），人类参与最少（三分钟）。但它的上限也最依赖输入质量——Issue 里验收标准写得好不好，直接决定最终产出。写得模糊，Agent 在「做没做完」这个问题上就会反复摇摆。写得精确（checkbox 格式、可验证条件），Agent 自己就能判断。

7.7 与 Ralph Loop 的对比

autoresearch 和 Ralph Loop 都解决「让 Agent 自主完成工作」的问题，但思路完全不同。

两者的关系不是替代，是递进。Ralph Loop 是「一个任务反复做到对」。autoresearch 是「一个 Issue 从头做到尾，不同模型轮流做」。后者多了两层东西：多 Agent 交叉审核覆盖盲区，端到端闭环减少人工操作。代价是配置更复杂——需要安装多个 Agent CLI，需要设置 program.md，需要理解轮转逻辑。

选哪个？任务简单、验收标准可以写成 completion promise——Ralph Loop 更轻。任务复杂、需要多角度审查、需要端到端自动化——autoresearch 更完整。

7.8 设计哲学：三个「优于」

autoresearch 的设计背后有三条价值判断。

「交叉审核」优于「反复迭代」。 单模型反复改自己的代码，能纠正语法错误和逻辑 bug，但改不了思维惯性——它觉得「这样写没问题」的地方，迭代多少次都不会改。换一个模型来审查，同样的代码会被不同「审美」重新评估。这和人类代码审查中「多个 reviewer 审同一段代码」的效果一致——每个人（每个模型）看到的都是不同的东西。

「双轨门禁」优于「单维度检查」。 传统 CI 只判断「能不能跑」。能跑不等于写得好——测试全绿的代码库可能是定时炸弹。LLM 评分检查传统 CI 覆盖不到的东西：架构是否合理、命名是否表意、错误处理是否完备、有没有反模式。硬门禁守底线，软门禁拉上限。

「全自动闭环」优于「分步半自动」。 不只是生成代码。PR 创建、等待 CI、合并、关闭 Issue——这些机械操作也自动掉。每一步人工介入都是延迟和出错的机会。人应该把精力花在定义验收标准上——这个标准写得好不好，直接决定最终产出质量——而不是花在点「Merge」按钮上。

7.9 适用边界

autoresearch 有明确的适用条件。它高度依赖一个前提：Issue 写得好。

最适合：

• 验收标准可量化、可验证的功能。 checkbox 里的每一项都能跑测试或 lint 验证。Agent 不需要「觉得」自己做完了——测试结果告诉它做完了。贪吃蛇就是典型：蛇能不能动、食物能不能吃、撞墙会不会死——全都能写 assert。
• 中等粒度的独立 Issue。 一个 Issue 能在单个 Agent 的上下文窗口内完成，验收标准明确，不依赖其他 Issue 的产出。太大——Agent 迷路。太小——autoresearch 的启动成本高于实现成本。
• 需要多轮审查的复杂逻辑。 涉及并发安全、状态机转换、边界条件多的代码——单 Agent 容易漏，多 Agent 交叉审查的收益最高。
• 批量 Issue 的夜间自主执行。 配合 run_all.sh，晚上把十几个 Issue 丢进去，早上看结果。

不适合：

• 验收标准模糊的任务。 「让这个页面更好看」「优化用户体验」——Agent 不知道什么叫「更好看」，LLM 评分也会反复摇摆。autoresearch 不能替你做设计决策。
• 跨 Issue 的架构变更。 每个 Issue 是独立执行的，Agent 不知道其他 Issue 做了什么。跨多个 Issue 的重构、API 变更、数据模型迁移——需要人在更高的层面协调。
• 需要人类判断的探索性工作。 「试试看这个技术方案行不行」——探索的结果需要人来解读，不能交给 LLM 评分来判定。

代价：

适用场景说清了，但 autoresearch 有两个绕不过去的成本。

第一个是时间。一个 Issue 走完「实现 → 审查 → 修复 → 再审查 → 评分达标」的完整流程，少则十几分钟，多则几十分钟。贪吃蛇这种体量的功能跑了四轮十二分钟——这算快的。复杂 Issue 迭代五六轮甚至更多，半小时以上很常见。对比人类开发者自己写可能只要十分钟的功能，autoresearch 反而更慢。但这不是 apples-to-apples 的对比——autoresearch 省的是人的注意力，不是绝对时间。你在等它的十几分钟里可以做别的事，或者干脆不坐在电脑前。

第二个是 token。每轮迭代，Agent 要读 Issue、读代码、读 program.md、读前一轮的审查报告、读测试结果——上下文越积越厚。贪吃蛇的四轮跑下来，token 消耗轻易过几十万。如果三个 Agent 各跑两轮，就是六次完整的上下文加载。单 Agent 的 Ralph Loop 也有这个问题，但 autoresearch 的多 Agent 轮转让每个 Agent 都从头加载上下文，token 成本乘以 Agent 数量。功能全自动了，API 账单也全自动了。

这两个代价不是要否定 autoresearch。它是交易——用时间和 token 换人的注意力解放和代码质量的确定性。交易划不划算，看你更缺什么。缺时间——自己写更快。缺注意力——让 autoresearch 跑，你去睡觉。

一个实用判断：Issue 里的验收标准能写成 checkbox 格式，autoresearch 稳。写不成——先别用。

7.10 与前后章节的关系

autoresearch 与 Ralph Loop（第 4 章）。 autoresearch 是 Ralph Loop 的「多 Agent + 端到端」升级版。Ralph Loop 是单 Agent 反复迭代直到 promise 匹配。autoresearch 是多 Agent 轮转审查直到评分达标。Ralph Loop 止步于代码完成，autoresearch 一路走到 Issue 关闭。两者的核心循环逻辑是一样的——「没达标就继续」——autoresearch 在上面加了两层：交叉审查和自动交付。

autoresearch 与 gstack（第 5 章）。 gstack 的质量保证靠角色覆盖——CEO 审方向、工程经理审架构、QA 测功能、安全官审漏洞。autoresearch 的质量保证靠模型覆盖——Claude 实现、Codex 审查、OpenCode 再审查。gstack 的角色是人格化的——「你是一个有十五年经验的员工工程师」。autoresearch 的 Agent 是去人格化的——就是不同的模型，不带角色身份。两条路：gstack 在 prompt 层面模拟专家多样性，autoresearch 在模型层面实现真实多样性。

autoresearch 与 superpowers（第 6 章）。 superpowers 的 subagent-driven-development 和 autoresearch 的多 Agent 轮转都用了多 Agent 协作。但协作模式不同。superpowers 是分工式——每个子 Agent 负责一个独立任务，主 Agent 协调审查。autoresearch 是接力式——同一个任务在不同 Agent 之间传递，每个 Agent 在前一个的基础上审查和改进。superpowers 的上下文隔离更好（每个子 Agent 全新上下文），autoresearch 的审查覆盖更广（多个模型的视角叠加）。

autoresearch 与 Goal Workflow（第 8 章）。 这是最紧密的一组关系。Goal Workflow 的四步闭环（PRD → Issue 拆分 → /goal 实现 → /ship-it 交付）把研发流程拆成了四个步骤。autoresearch 是其中 /goal 步骤的全自动化版本——「帮我实现这个 Issue」升级为「自动实现所有 Issue」。第 8 章会讲 Goal Workflow 如何把 autoresearch 嵌进一个更完整的研发体系。

7.11 本章小结

autoresearch 的名字来自 Karpathy 的 82K Stars 项目，但 smallnest 做的是完全不同的东西——ML 实验自动化变成了软件工程全流程自动化。

它的核心设计三条：

1. 多 Agent 轮转替代单 Agent 迭代。 不同模型有不同的盲区。Claude 看不到的问题 Codex 能看到，Codex 改不好的地方 OpenCode 能改好。轮转公式 (iter − 1) % N 保证了每个 Agent 都有机会审查和修复。这和人类代码审查中多 reviewer 的效果一致——审的人越多，漏掉的越少。
2. 双轨门禁替代单维度检查。 硬门禁（Build/Lint/Test）保证代码能跑。软门禁（LLM 评分 ≥ 85）保证代码写得好。传统 CI 只能做到前者。autoresearch 两条都做。未达标就换 Agent 继续迭代，直到两条都通过。
3. 端到端闭环替代分步半自动。 不只是生成代码。从 Issue 解析到 PR 创建到合并到关闭 Issue——全自动。人的角色从「操作者」变成了「验收标准定义者」。这和第 1 章的核心主张一脉相承：在 AI 时代，你的价值不再是「你能写多快的代码」，而是「你能不能定义清楚什么算做好」。

把本章和前两章放在一起看，三条路线对应三种自动化程度。gstack 是人驱动流程——你走七个阶段，Agent 辅助执行。superpowers 是 Agent 驱动流程——Agent 自己走流程，人类在关键决策点确认。autoresearch 是全自动流程——人类只定义目标，Agent 从实现到交付全包。

没有高下之分。但自动化程度越高，对输入质量的要求越高。gstack 的 /office-hours 能容忍模糊的想法，六个强制问题帮你逐步澄清。autoresearch 的 Issue 必须一开始就写清楚——它不会在过程中追问你「这个验收标准具体是什么意思」。选哪种路线，看你对自己「能写清楚到什么程度」的诚实判断。

本书第 8 章的 Goal Workflow 把 PRD、Issue 拆分、autoresearch 实现、交付合入串成了一条从 PRD 到上线的研发闭环。如果你觉得 autoresearch 的「全自动实现 Issue」还不够，Goal Workflow 会展开完整的项目研发流程自动化方案。