autoresearch：全自动化软件开发

<blockquote><p>「你只需负责喝茶和睡觉。一觉醒来，Features 全自动高质量的实现了。」</p><p>——smallnest, autoresearch 作者, 2026 年</p></blockquote><p>gstack 是人驱动流程，二十三个角色在七个 Sprint 阶段中协作。superpowers 是 Agent 驱动流程，十四个 Skill 自动触发，子 Agent 分工实现。两条路，一个共同点：人类仍然在循环中。gstack 需要你在每个阶段运行命令。superpowers 需要你在设计批准时确认方案。</p><p>autoresearch 把这个共同点也推倒了。</p><p>它的目标一句话就能说清楚：从 Issue 到合入，全程不需要人。你写好 Issue，Agent 自己实现、自己审查、自己修复、自己提 PR、自己合入、自己关 Issue。你喝茶。你睡觉。醒来看到一排绿色的 merged。</p><p>Karpathy 的 autoresearch 思想在软件工程领域落地了——82K Stars 的 ML 研究自动化项目，被 smallnest 适配成了通用的全自动开发工具。</p><span id="more"></span><h2 id="7-1-起源：从-GPU-训练到软件工程"><a href="#7-1-起源：从-GPU-训练到软件工程" class="headerlink" title="7.1 起源：从 GPU 训练到软件工程"></a>7.1 起源：从 GPU 训练到软件工程</h2><p>2026 年 3 月，Andrej Karpathy 在 GitHub 上发布了一个叫 autoresearch 的项目。代码没多少——核心是一个循环控制脚本。但思路极其大胆：让 AI Agent 在循环中自主做 ML 研究实验——自己改超参数、自己跑训练、自己看结果、自己决定下一步改什么。人类设定目标后就放手。</p><p>82,649 Stars。社区炸了。</p><p>不是因为代码复杂。是因为它第一次把「自主循环」从工程执行层面推到了研究决策层面。Ralph Loop 让 AI 反复改代码直到测试通过——执行层面的自主。autoresearch 让 AI 自己决定「接下来该尝试什么方向」——决策层面的自主。</p><p>但 Karpathy 的 autoresearch 面向的是 ML 训练场景——单 GPU 上的 nanochat 训练实验。smallnest 看到了另一种可能：把这个模式搬到通用软件工程上。</p><p><img src="/images/image-20260530013613746.png"></p><p>2026 年 4 月，smallnest&#x2F;autoresearch 发布。517 Stars，远不如原版。野心却大得多——不做「让 AI 自己做 ML 实验」，做「让 AI 自己做完整个软件开发流程」。</p><p>两个关键改造。第一，把自主循环的主体从单 Agent 变成了多 Agent 轮转——Claude Code 实现，Claude Code 审查，Codex 优化，Codex 再审查，OpenCode 再优化，OpenCode 再审查，不同模型交叉实现和审核。第二，把目标载体从实验配置变成了 Issue——GitHub Issue、本地 Markdown 文件、百度 iCafe 卡片、阿里云效 Codeup，四种来源，一套流程。Issue 就是任务合约。验收标准写在 Issue 里，autoresearch 读到，自己判断做完没有。</p><p><img src="/images/image-20260531042122802.png"></p><h2 id="7-2-安装与使用：一条-clone-命令，从-Issue-开始"><a href="#7-2-安装与使用：一条-clone-命令，从-Issue-开始" class="headerlink" title="7.2 安装与使用：一条 clone 命令，从 Issue 开始"></a>7.2 安装与使用：一条 clone 命令，从 Issue 开始</h2><p>autoresearch 的安装只有一步——<code>git clone</code>。不需要 npm、不需要 pip、不需要构建。安装之后，唯一的交互就是传给它一个 Issue 编号。</p><h3 id="7-2-1-依赖与前提"><a href="#7-2-1-依赖与前提" class="headerlink" title="7.2.1 依赖与前提"></a>7.2.1 依赖与前提</h3><p>autoresearch 是胶水层——它不自己写代码，它调度其他 Agent 写代码。所以前提条件就是你至少装了一个它支持的 Agent CLI。五个 Agent 对应五条验证命令：</p><table><thead><tr><th>Agent</th><th>CLI 检查</th><th>角色</th></tr></thead><tbody><tr><td>Claude Code</td><td><code>which claude</code></td><td>默认实现 + 审查</td></tr><tr><td>OpenAI Codex</td><td><code>which codex</code></td><td>审查 + 修复 + 优化</td></tr><tr><td>OpenCode</td><td><code>which opencode</code></td><td>审查 + 修复</td></tr><tr><td>Claude-Mimo</td><td><code>which claude-mimo</code></td><td>审查 + 修复（fallback 到 claude.md）</td></tr><tr><td>DeepSeek</td><td><code>which deepseek-tui</code></td><td>审查 + 修复</td></tr></tbody></table><p>对于 GitHub 模式（默认），还需要 <code>gh auth status</code> 通过。百度 iCafe 模式需要 <code>icafe-cli whoami</code> 和 <code>icode-cli whoami</code>。阿里云效 Codeup 模式需要 <code>curl</code>。</p><p>autoresearch 本身没语言运行时要求——<code>run.sh</code> 是 bash 脚本。但你的项目必须有对应语言的构建工具（Go&#x2F;Node&#x2F;Python&#x2F;Rust&#x2F;Java），因为硬门禁要跑 build 和 test。</p><h3 id="7-2-2-安装"><a href="#7-2-2-安装" class="headerlink" title="7.2.2 安装"></a>7.2.2 安装</h3><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">git <span class="built_in">clone</span> git@github.com:smallnest/autoresearch.git</span><br></pre></td></tr></table></figure><p>不需要 <code>./setup</code>、不需要 <code>./configure</code>、不需要 <code>make install</code>。<code>autoresearch/run.sh</code> 是唯一入口——从你的项目目录调用它，脚本自动寻找项目根目录、自动检测 Git 平台、自动选择对应的 Agent CLI。</p><h3 id="7-2-3-基础使用"><a href="#7-2-3-基础使用" class="headerlink" title="7.2.3 基础使用"></a>7.2.3 基础使用</h3><p>最小用法——在当前项目目录中处理一个 GitHub Issue：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">autoresearch/run.sh 10</span><br></pre></td></tr></table></figure><p>Agent 做的事：<code>gh issue view 10</code> 读取 Issue → 第一个 Agent 初始实现 → 后面 Agent 轮流审查修复 → Build&#x2F;Lint&#x2F;Test 全通过 → LLM 评分 ≥ 85 → <code>gh pr create</code> → squash merge → 评论总结 → <code>gh issue close 10</code>。</p><p>指定项目路径和最大迭代轮数：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">autoresearch/run.sh -p /path/to/project 10 16</span><br></pre></td></tr></table></figure><p>Issue #10，最多 16 轮（默认不限，但项目内置了连续失败停止阈值 <code>MAX_CONSECUTIVE_FAILURES=3</code>）。</p><h3 id="7-2-4-Agent-配置与模型选择"><a href="#7-2-4-Agent-配置与模型选择" class="headerlink" title="7.2.4 Agent 配置与模型选择"></a>7.2.4 Agent 配置与模型选择</h3><p><code>-a</code> 参数指定用哪些 Agent 和调用顺序：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">autoresearch/run.sh -a claude,codex,opencode 10</span><br></pre></td></tr></table></figure><p>第一个 Agent（claude）做初始实现，后续迭代按 <code>(iter − 1) % N</code> 轮转——Claude 实现 → Codex 审查修复 → OpenCode 审查修复 → Claude 再修复，循环下去。不指定 <code>-a</code> 时默认就是这三个。</p><p>每个 Agent 的 prompt 模板在仓库 <code>agents/*.md</code> 中，可被项目级 <code>.autoresearch/agents/*.md</code> 覆盖——不同项目可以给同一个 Agent 不同的行为指令。</p><p>模型层面也可以调。全局指定所有 Agent 用 Opus：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">AGENT_MODEL=opus autoresearch/run.sh 10</span><br></pre></td></tr></table></figure><p>或者每个 Agent 不同：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">AGENT_MODEL_CLAUDE=sonnet AGENT_MODEL_CODEX=gpt-5.2 autoresearch/run.sh 10</span><br></pre></td></tr></table></figure><p>Claude 跑 Sonnet 降低成本，Codex 跑 GPT-5.2 提供不同的审查视角。</p><h3 id="7-2-5-Continue-模式"><a href="#7-2-5-Continue-模式" class="headerlink" title="7.2.5 Continue 模式"></a>7.2.5 Continue 模式</h3><p>autoresearch 的状态保存在迭代日志中。API 挂了、网络断了、机器重启，回来继续：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">autoresearch/run.sh -c 42 10</span><br></pre></td></tr></table></figure><p>从 Issue #42 上次中断的迭代继续，再跑最多 10 轮。不从零开始。</p><h3 id="7-2-6-本地-Issue-模式"><a href="#7-2-6-本地-Issue-模式" class="headerlink" title="7.2.6 本地 Issue 模式"></a>7.2.6 本地 Issue 模式</h3><p>不需要 GitHub。Issue 写成本地 <code>.md</code> 文件，autoresearch 读文件、写代码到本地分支、结果追加回文件末尾：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br></pre></td><td class="code"><pre><span class="line"><span class="built_in">mkdir</span> -p .autoresearch/issues</span><br><span class="line"><span class="built_in">cat</span> &gt; .autoresearch/issues/issue-008-add-login.md &lt;&lt; <span class="string">&#x27;EOF&#x27;</span></span><br><span class="line"><span class="comment"># Add login feature</span></span><br><span class="line">实现用户登录功能，支持邮箱+密码登录。</span><br><span class="line"></span><br><span class="line"><span class="comment">## 验收标准</span></span><br><span class="line">- [ ] 登录页有邮箱和密码两个输入框</span><br><span class="line">- [ ] 输入正确凭据后跳转到首页</span><br><span class="line">- [ ] 输入错误凭据后显示错误提示</span><br><span class="line">- [ ] 登录状态用 JWT 存储在 localStorage</span><br><span class="line">EOF</span><br><span class="line"></span><br><span class="line">autoresearch/run.sh --issues-dir=.autoresearch/issues 8</span><br></pre></td></tr></table></figure><p>命名规则：<code>issue-NNN-描述.md</code>，三位数字。<code>run.sh 8</code> 匹配 <code>issue-008-*.md</code> 或 <code>issue-8-*.md</code>。结果（评分、迭代轮数、分支名、时间戳）追加到文件末尾的 <code>---</code> 分隔线之后。适合内网项目、个人项目、不想连 GitHub API 的场景。</p><h3 id="7-2-7-多平台"><a href="#7-2-7-多平台" class="headerlink" title="7.2.7 多平台"></a>7.2.7 多平台</h3><p>autoresearch 根据 Git remote 自动检测平台，四种模式一套命令：</p><table><thead><tr><th>平台</th><th>检测条件</th><th>Issue 来源</th><th>PR&#x2F;MR</th></tr></thead><tbody><tr><td>GitHub</td><td>默认</td><td><code>gh issue view</code></td><td>PR → merge → close</td></tr><tr><td>本地</td><td>本地文件匹配</td><td><code>.md</code> 文件</td><td>仅本地分支</td></tr><tr><td>百度 iCafe</td><td>remote 含 <code>icode.baidu.com</code></td><td><code>icafe-cli</code></td><td>push CR + submit review</td></tr><tr><td>阿里云效 Codeup</td><td>指定 <code>--issue-source=codeup</code></td><td>REST API</td><td>MR → merge → close</td></tr></tbody></table><p>百度模式示例：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">autoresearch/run.sh --issue-source=baidu --space=cloud-iCafe 22210</span><br></pre></td></tr></table></figure><p>Codeup 模式需要 token 和组织信息：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line"><span class="built_in">export</span> CODEUP_TOKEN=xxx CODEUP_ORG_ID=123 CODEUP_REPO_ID=456</span><br><span class="line">autoresearch/run.sh --issue-source=codeup 42</span><br></pre></td></tr></table></figure><p>四种模式共用同一套 Agent 轮转逻辑和质量门禁——变的只是 Issue 来源和 PR&#x2F;MR 创建方式。</p><h3 id="7-2-8-配置：program-md-与-autoresearch"><a href="#7-2-8-配置：program-md-与-autoresearch" class="headerlink" title="7.2.8 配置：program.md 与 .autoresearch&#x2F;"></a>7.2.8 配置：program.md 与 .autoresearch&#x2F;</h3><p>项目的规矩写在 <code>.autoresearch/</code> 目录中。完整结构：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br></pre></td><td class="code"><pre><span class="line">.autoresearch/</span><br><span class="line">├── program.md ← 实现规则（Agent 每轮读取）</span><br><span class="line">├── agents/ ← 覆盖默认 Agent prompt</span><br><span class="line">│ ├── claude.md</span><br><span class="line">│ ├── codex.md</span><br><span class="line">│ ├── claude-mimo.md</span><br><span class="line">│ └── opencode.md</span><br><span class="line">├── issues/ ← 本地 Issue 文件</span><br><span class="line">│ └── issue-008-*.md</span><br><span class="line">├── workflows/ ← 迭代日志（自动生成）</span><br><span class="line">└── results.tsv ← 处理结果汇总（自动生成）</span><br></pre></td></tr></table></figure><p><code>program.md</code> 是最核心的配置文件。内容四部分：权限边界（什么能改、什么不能改）、代码规范（通用 + 语言特定）、测试要求、提交规范。仓库自带一个多语言模板——Go、Python、Rust、TypeScript、Java 各一份。实际使用时按项目语言裁剪，删掉无关部分以降低 token 消耗。</p><h3 id="7-2-9-环境变量速查"><a href="#7-2-9-环境变量速查" class="headerlink" title="7.2.9 环境变量速查"></a>7.2.9 环境变量速查</h3><table><thead><tr><th>变量</th><th>默认值</th><th>作用</th></tr></thead><tbody><tr><td><code>PASSING_SCORE</code></td><td>85</td><td>LLM 评分达标线（0-100）</td></tr><tr><td><code>AGENT_MODEL</code></td><td>CLI 默认</td><td>所有 Agent 统一模型</td></tr><tr><td><code>AGENT_MODEL_CLAUDE</code></td><td>—</td><td>Claude 专属模型</td></tr><tr><td><code>AGENT_MODEL_CODEX</code></td><td>—</td><td>Codex 专属模型</td></tr><tr><td><code>AGENT_MODEL_OPENCODE</code></td><td>—</td><td>OpenCode 专属模型</td></tr><tr><td><code>MAX_CONSECUTIVE_FAILURES</code></td><td>3</td><td>连续失败 N 次后停止</td></tr><tr><td><code>MAX_RETRIES</code></td><td>5</td><td>单次 Agent 调用重试次数</td></tr></tbody></table><p>调整 <code>PASSING_SCORE</code> 是调质量门槛——90 更严格，80 更宽松。调整 <code>AGENT_MODEL</code> 是调成本——Sonnet 便宜但审查不如 Opus 深，按项目预算取舍。</p><h3 id="7-2-10-全量-Issue-批处理"><a href="#7-2-10-全量-Issue-批处理" class="headerlink" title="7.2.10 全量 Issue 批处理"></a>7.2.10 全量 Issue 批处理</h3><p>不止单个 Issue。<code>run_all.sh</code> 可以一批处理全部开放 Issue：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">autoresearch/run_all.sh --issue-source=codeup --codeup-token=xxx --codeup-org=123 --codeup-repo=456</span><br></pre></td></tr></table></figure><p>晚上把十几个 Issue 丢给 <code>run_all.sh</code>，早上看 <code>results.tsv</code>——哪些通过了、哪些还在迭代、哪些失败了。人的时间用在判断结果上，不在盯着 Agent 上。</p><h2 id="7-3-核心架构：四个机制撑起全自动"><a href="#7-3-核心架构：四个机制撑起全自动" class="headerlink" title="7.3 核心架构：四个机制撑起全自动"></a>7.3 核心架构：四个机制撑起全自动</h2><p>autoresearch 的架构不复杂。核心就是四个机制叠在一起。</p><h3 id="7-3-1-多-Agent-轮转：让不同模型互相审查"><a href="#7-3-1-多-Agent-轮转：让不同模型互相审查" class="headerlink" title="7.3.1 多 Agent 轮转：让不同模型互相审查"></a>7.3.1 多 Agent 轮转：让不同模型互相审查</h3><p>这是 autoresearch 和 Ralph Loop 最根本的差异。Ralph Loop 是单 Agent 反复迭代——同一个模型反复读自己的代码、改自己的代码、判自己的代码。问题很明显：模型的盲区是固定的。它看不出来的问题，迭代一百次还是看不出来。</p><p>autoresearch 换了一种模式。它支持五个 Agent——Claude Code、Codex、OpenCode、Claude-Mimo、DeepSeek。你通过 <code>-a</code> 参数指定用哪几个、按什么顺序。</p><p><img src="/images/image-20260531010044594.png"></p><p>轮转公式很简单：<code>(iter − 1) % N</code>。第一个 Agent 做初始实现。第二个 Agent 审查第一个的产出，发现问题就修。第三个 Agent 审查第二个修完的结果，再发现问题再修。以此类推，循环轮转。</p><p>不同模型有不同盲区。Claude 容易漏掉的东西，Codex 可能一眼就看到。Codex 的代码风格问题，OpenCode 可能立刻揪出来。三个模型交叉审核的覆盖面，远超单模型自我审查十轮。这和代码审查中多 reviewer 的效果优于单人反复 self-review 是一个道理——只不过 reviewer 从人类换成了不同的 AI 模型。</p><h3 id="7-3-2-Issue-驱动：验收标准即合约"><a href="#7-3-2-Issue-驱动：验收标准即合约" class="headerlink" title="7.3.2 Issue 驱动：验收标准即合约"></a>7.3.2 Issue 驱动：验收标准即合约</h3><p>autoresearch 的一切从 Issue 开始。GitHub Issue、本地 <code>.md</code> 文件、百度 iCafe 卡片、阿里云效 Codeup——四选一，自动检测。</p><p>Issue 是合约。验收标准写在 Issue 里（checkbox 格式），Agent 读到就知道什么叫「做完了」。这和第 3 章 SDD 的核心理念一致：先在规格上达成一致，再写代码。区别在于 SDD 是人类和 AI 之间的合约，autoresearch 把它变成了 AI 和自己之间的合约——Agent 自己读验收标准，自己判断是否满足，不满足就继续迭代。</p><p><img src="/images/image-20260531010339852.png"></p><p>单 Issue 执行流程分五个阶段：</p><ol><li><strong>解析阶段</strong>：读取 Issue，提取标题、描述、验收标准</li><li><strong>规划阶段</strong>：自动拆分子任务（如果 Issue 足够复杂）</li><li><strong>实现阶段</strong>：首个 Agent 初始实现 → 轮转审查 → 修复</li><li><strong>质量门禁</strong>：Build&#x2F;Lint&#x2F;Test 全部通过 + LLM 评分 ≥ 85</li><li><strong>收尾阶段</strong>：创建 PR → 合并 → 评论 → 关闭 Issue</li></ol><p>五个阶段全自动。人只做了一件事——写 Issue。</p><h3 id="7-3-3-双轨质量门禁：硬门禁-软门禁"><a href="#7-3-3-双轨质量门禁：硬门禁-软门禁" class="headerlink" title="7.3.3 双轨质量门禁：硬门禁 + 软门禁"></a>7.3.3 双轨质量门禁：硬门禁 + 软门禁</h3><p>autoresearch 的质量保证分两层。</p><p><strong>硬门禁</strong>：Build、Lint、Test 必须全部通过。这是确定性检查——过了就是过了，没过就是没过，没有任何模糊空间。和第 6 章 superpowers 的 <code>verification-before-completion</code> 做的事一样——代码能跑是最低门槛。</p><p><strong>软门禁</strong>：LLM 评分 ≥ 85 分。这是语义质量评估——不看代码能不能跑，看代码写得好不好。评分分五个维度，加权计算：</p><table><thead><tr><th>维度</th><th>权重</th><th>检查内容</th></tr></thead><tbody><tr><td><strong>正确性</strong></td><td>35%</td><td>功能是否符合 Issue 需求、边界和错误是否处理、有无逻辑错误和并发问题</td></tr><tr><td><strong>测试质量</strong></td><td>25%</td><td>核心逻辑是否被测试覆盖、边界和错误路径有无测试、用例命名是否清晰</td></tr><tr><td><strong>代码质量</strong></td><td>20%</td><td>命名是否清晰、结构是否合理、是否遵循项目规范、有无重复代码</td></tr><tr><td><strong>安全性</strong></td><td>10%</td><td>有无注入风险、有无敏感信息泄露、输入验证是否完备</td></tr><tr><td><strong>性能</strong></td><td>10%</td><td>有无明显性能问题、有无不必要的内存分配、并发控制是否合理</td></tr></tbody></table><p>每个维度按问题严重程度给分：无问题 100 分，有建议改进 90 分，有一般问题 70 分，有严重问题 40 分，有致命问题 10 分。加权总分 &#x3D; 各维度得分 × 权重之和。默认达标线 85 分，可通过 <code>PASSING_SCORE</code> 环境变量调整。</p><p>测试质量维度有一个豁免规则：如果项目类型不适用单元测试（Shell 脚本、配置文件等），该维度默认 100 分，审核者需注明豁免原因。</p><p>双轨设计回答了传统 CI 的一个长期缺陷：CI 只能检查「能不能跑」，不能检查「写得好不好」。一个测试全绿的代码库仍然可能是一团不可维护的浆糊。硬门禁保证下限，软门禁拉高上限。未达标就进入下一轮迭代——换一个 Agent 重新审查和修复。</p><h3 id="7-3-4-program-md：编码在文件里的规矩"><a href="#7-3-4-program-md：编码在文件里的规矩" class="headerlink" title="7.3.4 program.md：编码在文件里的规矩"></a>7.3.4 program.md：编码在文件里的规矩</h3><p>每个项目有自己的规矩——代码风格、架构约束、技术选型。autoresearch 提供了一个 <code>program.md</code> 文件，把这些规矩写下来，Agent 在实现 Issue 时自动读取。</p><p>内容包括四部分：权限边界（什么能改、什么不能改）、代码规范（通用 + 语言特定）、测试要求、提交规范。支持 Go、Python、Rust、TypeScript、Java 的多语言模板。放到项目的 <code>.autoresearch/program.md</code> 下，Agent 自己读，自己遵守。</p><p>这和第 1 章「用结构化知识驾驭非结构化 AI 能力」一脉相承。program.md 就是结构化知识——可复用、可迭代、可版本控制。Agent 每轮读取它，就相当于每次都被同样的规矩约束一次。规矩不是靠人盯着执行的，是靠文件自动注入的。</p><h2 id="7-4-工作流全景"><a href="#7-4-工作流全景" class="headerlink" title="7.4 工作流全景"></a>7.4 工作流全景</h2><h3 id="7-4-1-从-PRD-到合入的完整链路"><a href="#7-4-1-从-PRD-到合入的完整链路" class="headerlink" title="7.4.1 从 PRD 到合入的完整链路"></a>7.4.1 从 PRD 到合入的完整链路</h3><p>autoresearch 和 Goal Workflow（第 8 章）连在一起，构成完整的端到端流水线：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">/prd 生成 PRD → 拆分为细粒度 Issue → autoresearch 逐个实现 → 全部合入</span><br></pre></td></tr></table></figure><p>用 <code>/prd</code> 生成交付需求文档。让 Agent 基于 PRD 拆分成细粒度 Issue——每个 Issue 小到可以在单次开发会话中完成，有明确的 checkbox 验收标准，标注依赖关系。然后 autoresearch 逐个吞下这些 Issue，自动实现、审查、合入。</p><p>smallnest 在自己的 Desktop App 项目上验证过这条链路：19 个 Issue（#22 到 #40），从 PRD 到全部实现，全自动。</p><h3 id="7-4-2-Continue-模式与容错"><a href="#7-4-2-Continue-模式与容错" class="headerlink" title="7.4.2 Continue 模式与容错"></a>7.4.2 Continue 模式与容错</h3><p>全自动系统必须能处理异常。autoresearch 有三层容错：</p><ul><li><code>-c</code> 标志：从上次中断的迭代继续执行。API 挂了、网络断了、机器重启了——回来继续，不从头开始。</li><li>连续失败停止阈值：同一个 Issue 连续失败 N 次后自动停止，不发散消耗资源。</li><li>单次 Agent 调用重试：应对 API 临时故障，不是一次调用失败就终止整个流程。</li></ul><h2 id="7-5-多平台支持"><a href="#7-5-多平台支持" class="headerlink" title="7.5 多平台支持"></a>7.5 多平台支持</h2><p>autoresearch 的跨平台适配覆盖四种研发场景，而非笼统的「支持多种 Git 平台」。</p><p><strong>GitHub 模式</strong>：默认。依赖 <code>gh</code> CLI，自动 push → 创建 PR → Squash Merge → 评论总结 → 关闭 Issue。</p><p><strong>本地 Issue 模式</strong>：不需要 GitHub，不需要网络。Issue 文件放在 <code>.autoresearch/issues/issue-NNN-描述.md</code>，Agent 读本地文件，代码提交到本地分支，结果追加到 Issue 文件末尾。适合内网项目、个人项目、不想开 GitHub Issue 的场景。</p><p><strong>百度 iCafe + iCode 模式</strong>：适配百度内部研发体系。Git remote 包含 <code>icode.baidu.com</code> 时自动切换。用 <code>icafe-cli</code> 读卡片，用 <code>icode-cli</code> 提交代码审查，评分 +2 后合入，自动关闭卡片。</p><p><strong>阿里云效 Codeup 模式</strong>：通过 REST API 操作 Issue、MR、合并、评论。适合使用阿里云效的企业团队。</p><p>四种模式，一套流程。Agent 根据 Git remote 和本地文件自动检测切换。人不需要记住「当前项目是什么模式」。</p><h2 id="7-6-实战：用-autoresearch-开发网页版贪吃蛇"><a href="#7-6-实战：用-autoresearch-开发网页版贪吃蛇" class="headerlink" title="7.6 实战：用 autoresearch 开发网页版贪吃蛇"></a>7.6 实战：用 autoresearch 开发网页版贪吃蛇</h2><p>同一个贪吃蛇。第六种体验。</p><p>不打开 Claude Code 手动交互。不回答 brainstorming 的五个问题。不确认设计方案。</p><p>写一个 Issue，然后放手。</p><h3 id="7-6-1-准备：把需求写成-Issue"><a href="#7-6-1-准备：把需求写成-Issue" class="headerlink" title="7.6.1 准备：把需求写成 Issue"></a>7.6.1 准备：把需求写成 Issue</h3><blockquote><p>因为是重点要介绍autoresearch中代码实现阶段，所以这个例子中issue是手工创建的,你也可以使用&#x2F;prd生成需求文档，拆解Issues。</p></blockquote><p>在项目仓库中创建一个本地 Issue 文件：</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">.autoresearch/issues/issue-001-snake-game.md</span><br></pre></td></tr></table></figure><p>内容：</p><figure class="highlight markdown"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br></pre></td><td class="code"><pre><span class="line"><span class="section"># 网页版贪吃蛇游戏</span></span><br><span class="line"></span><br><span class="line">纯前端单文件 HTML/CSS/JS 实现，不依赖任何框架。</span><br><span class="line"></span><br><span class="line"><span class="section">## 验收标准</span></span><br><span class="line"></span><br><span class="line"><span class="bullet">-</span> [ ] 打开 index.html 后能看到 20x20 网格和一条初始长度为 3 的绿色蛇</span><br><span class="line"><span class="bullet">-</span> [ ] 方向键控制蛇移动，不能反向（向右时按左键无效）</span><br><span class="line"><span class="bullet">-</span> [ ] 随机位置出现红色食物，蛇头碰到食物后蛇身变长 1 格，食物刷新</span><br><span class="line"><span class="bullet">-</span> [ ] 撞墙或撞到自己 → 游戏结束，HTML modal 弹窗显示得分</span><br><span class="line"><span class="bullet">-</span> [ ] 按空格键重新开始，游戏重置为初始状态</span><br><span class="line"><span class="bullet">-</span> [ ] 最高分用 localStorage 持久化，刷新页面后仍在</span><br><span class="line"><span class="bullet">-</span> [ ] 隐私模式下 localStorage 不可用时优雅降级（try-catch，默认最高分 0）</span><br><span class="line"><span class="bullet">-</span> [ ] 游戏循环用 requestAnimationFrame + 手动计时（初始 150ms/步），不用 setInterval</span><br><span class="line"></span><br><span class="line"><span class="section">## 技术要求</span></span><br><span class="line"></span><br><span class="line"><span class="bullet">-</span> 单文件 snake-game/index.html</span><br><span class="line"><span class="bullet">-</span> 状态层（gameState 对象）和渲染层（Canvas 绘制）分离</span><br><span class="line"><span class="bullet">-</span> 键盘事件写入 nextDirection 缓冲，gameLoop 在 update() 中同步到 direction</span><br><span class="line"><span class="bullet">-</span> test.html 覆盖全部验收标准</span><br></pre></td></tr></table></figure><p>然后一行命令：</p><figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">autoresearch/run.sh --issues-dir=.autoresearch/issues 1</span><br></pre></td></tr></table></figure><p>人做的事做完了。下面是 Agent 的事。</p><h3 id="7-6-2-执行：三个-Agent-轮转四轮"><a href="#7-6-2-执行：三个-Agent-轮转四轮" class="headerlink" title="7.6.2 执行：三个 Agent 轮转四轮"></a>7.6.2 执行：三个 Agent 轮转四轮</h3><p>配置用了三个 Agent：Claude Code、Codex、OpenCode。最大迭代 8 轮，LLM 评分达标线 85。</p><p><strong>第 1 轮（Claude Code，初始实现）</strong>：Claude 读 Issue，拆成四个子任务——HTML 结构与 Canvas 渲染、游戏循环与状态管理、碰撞检测与食物系统、分数系统与 UI 状态。依次实现，产出一个完整的 <code>snake-game/index.html</code> 和 <code>test.html</code>。跑测试——8 个用例，6 个通过，2 个失败：食物偶尔生成在蛇身上，modal 弹窗出现后方向键仍能控制蛇。Build 通过。Lint 通过。LLM 自评 72 分。不达标，进入第 2 轮。</p><p><strong>第 2 轮（Codex，审查修复）</strong>：Codex 拿到 Claude 的代码和测试结果。审查发现三个问题：食物随机生成没检查蛇身重叠、gameLoop 用了 <code>setInterval</code> 而非 <code>requestAnimationFrame</code>、游戏结束时没拦截键盘事件。Codex 逐一修复。跑测试——8&#x2F;8 通过。LLM 评分 82。不达标，但方向是对的，进入第 3 轮。</p><p><strong>第 3 轮（OpenCode，审查修复）</strong>：OpenCode 发现 Codex 修复键盘拦截时只处理了方向键，没处理空格键——游戏结束按空格也能重置，但重置后蛇立刻开始移动（因为空格键事件没被阻止冒泡）。还发现 localStorage 读写没包 try-catch，隐私模式会崩。修复后测试 8&#x2F;8 通过。LLM 评分 88。达标。</p><p><strong>第 4 轮（质量确认）</strong>：评分达标后 autoresearch 自动跑最终验证——Build、Lint、Test 全部通过。自动创建 commit（Conventional Commits 格式），推送到分支 <code>autoresearch/issue-001</code>。因为是本地 Issue 模式，结果追加到 Issue 文件末尾，分支保留在本地。</p><p>全过程约十二分钟，零人工干预。第 6 章 superpowers 实战中人类还参与了两次——回答问题、确认方案。autoresearch 实战中人类只做了一件事：写 Issue。第 4 章 Ralph Loop 实战中第 3 轮才抓到的 modal 焦点问题，autoresearch 在第 2 轮就被 Codex 抓到了。不是 Claude 比 Ralph Loop 的 Agent 聪明——多 Agent 交叉审查覆盖了单 Agent 的盲区。</p><h3 id="7-6-3-和第-5、6-章的对比"><a href="#7-6-3-和第-5、6-章的对比" class="headerlink" title="7.6.3 和第 5、6 章的对比"></a>7.6.3 和第 5、6 章的对比</h3><p>同一个贪吃蛇，三种方法论：</p><table><thead><tr><th>维度</th><th>gstack（第 5 章）</th><th>superpowers（第 6 章）</th><th>autoresearch（本章）</th></tr></thead><tbody><tr><td><strong>人类参与</strong></td><td>逐个阶段运行命令，约 2 小时</td><td>回答 5 个设计问题，约 5 分钟</td><td>写一个 Issue，约 3 分钟</td></tr><tr><td><strong>Agent 模型</strong></td><td>多角色但同一 Agent</td><td>子 Agent 分工，主 Agent 协调</td><td>多 Agent 轮转交叉审核</td></tr><tr><td><strong>审查方式</strong></td><td>4 个角色分维度审查</td><td>子 Agent 两阶段审查（规格+质量）</td><td>不同模型交叉审查 + LLM 评分</td></tr><tr><td><strong>质量门禁</strong></td><td>PreToolUse hooks</td><td>HARD-GATE 认知门控</td><td>硬门禁（Build&#x2F;Lint&#x2F;Test）+ 软门禁（评分 ≥ 85）</td></tr><tr><td><strong>交付方式</strong></td><td>手动 <code>/ship</code></td><td>手动选择合入方式</td><td>全自动 PR → 合入 → 关 Issue</td></tr><tr><td><strong>最佳场景</strong></td><td>从零到一的完整项目</td><td>中等复杂度的独立功能</td><td>Issue 明确、可独立验证的功能</td></tr></tbody></table><p>autoresearch 的时间最短（十二分钟），人类参与最少（三分钟）。但它的上限也最依赖输入质量——Issue 里验收标准写得好不好，直接决定最终产出。写得模糊，Agent 在「做没做完」这个问题上就会反复摇摆。写得精确（checkbox 格式、可验证条件），Agent 自己就能判断。</p><h2 id="7-7-与-Ralph-Loop-的对比"><a href="#7-7-与-Ralph-Loop-的对比" class="headerlink" title="7.7 与 Ralph Loop 的对比"></a>7.7 与 Ralph Loop 的对比</h2><p>autoresearch 和 Ralph Loop 都解决「让 Agent 自主完成工作」的问题，但思路完全不同。</p><table><thead><tr><th>维度</th><th>autoresearch</th><th>Ralph Loop</th></tr></thead><tbody><tr><td><strong>驱动方式</strong></td><td>Issue + checkbox 验收标准</td><td>prompt 文件（.md）</td></tr><tr><td><strong>Agent 模型</strong></td><td>多 Agent 轮转交叉审核</td><td>单 Agent 反复迭代</td></tr><tr><td><strong>质量判断</strong></td><td>硬门禁（Build&#x2F;Lint&#x2F;Test）+ 软门禁（LLM 评分 ≥ 85）</td><td>completion promise 短语匹配</td></tr><tr><td><strong>审查机制</strong></td><td>不同模型交叉审查</td><td>同一模型自我审查</td></tr><tr><td><strong>端到端</strong></td><td>Issue → PR → 合并 → 关闭（全自动闭环）</td><td>止步于代码完成</td></tr><tr><td><strong>容错</strong></td><td>continue 模式 + 连续失败停止 + 调用重试</td><td>max-iterations 安全阀</td></tr><tr><td><strong>多平台</strong></td><td>GitHub &#x2F; 本地 &#x2F; iCafe &#x2F; Codeup</td><td>依赖 Claude Code Stop Hook</td></tr></tbody></table><p>两者的关系不是替代，是递进。Ralph Loop 是「一个任务反复做到对」。autoresearch 是「一个 Issue 从头做到尾，不同模型轮流做」。后者多了两层东西：多 Agent 交叉审核覆盖盲区，端到端闭环减少人工操作。代价是配置更复杂——需要安装多个 Agent CLI，需要设置 <code>program.md</code>，需要理解轮转逻辑。</p><p>选哪个？任务简单、验收标准可以写成 completion promise——Ralph Loop 更轻。任务复杂、需要多角度审查、需要端到端自动化——autoresearch 更完整。</p><h2 id="7-8-设计哲学：三个「优于」"><a href="#7-8-设计哲学：三个「优于」" class="headerlink" title="7.8 设计哲学：三个「优于」"></a>7.8 设计哲学：三个「优于」</h2><p>autoresearch 的设计背后有三条价值判断。</p><p><strong>「交叉审核」优于「反复迭代」。</strong> 单模型反复改自己的代码，能纠正语法错误和逻辑 bug，但改不了思维惯性——它觉得「这样写没问题」的地方，迭代多少次都不会改。换一个模型来审查，同样的代码会被不同「审美」重新评估。这和人类代码审查中「多个 reviewer 审同一段代码」的效果一致——每个人（每个模型）看到的都是不同的东西。</p><p><strong>「双轨门禁」优于「单维度检查」。</strong> 传统 CI 只判断「能不能跑」。能跑不等于写得好——测试全绿的代码库可能是定时炸弹。LLM 评分检查传统 CI 覆盖不到的东西：架构是否合理、命名是否表意、错误处理是否完备、有没有反模式。硬门禁守底线，软门禁拉上限。</p><p><strong>「全自动闭环」优于「分步半自动」。</strong> 不只是生成代码。PR 创建、等待 CI、合并、关闭 Issue——这些机械操作也自动掉。每一步人工介入都是延迟和出错的机会。人应该把精力花在定义验收标准上——这个标准写得好不好，直接决定最终产出质量——而不是花在点「Merge」按钮上。</p><h2 id="7-9-适用边界"><a href="#7-9-适用边界" class="headerlink" title="7.9 适用边界"></a>7.9 适用边界</h2><p>autoresearch 有明确的适用条件。它高度依赖一个前提：Issue 写得好。</p><p><img src="/images/image-20260531010541230.png"></p><p><strong>最适合：</strong></p><ul><li><strong>验收标准可量化、可验证的功能。</strong> checkbox 里的每一项都能跑测试或 lint 验证。Agent 不需要「觉得」自己做完了——测试结果告诉它做完了。贪吃蛇就是典型：蛇能不能动、食物能不能吃、撞墙会不会死——全都能写 assert。</li><li><strong>中等粒度的独立 Issue。</strong> 一个 Issue 能在单个 Agent 的上下文窗口内完成，验收标准明确，不依赖其他 Issue 的产出。太大——Agent 迷路。太小——autoresearch 的启动成本高于实现成本。</li><li><strong>需要多轮审查的复杂逻辑。</strong> 涉及并发安全、状态机转换、边界条件多的代码——单 Agent 容易漏，多 Agent 交叉审查的收益最高。</li><li><strong>批量 Issue 的夜间自主执行。</strong> 配合 <code>run_all.sh</code>，晚上把十几个 Issue 丢进去，早上看结果。</li></ul><p><strong>不适合：</strong></p><ul><li><strong>验收标准模糊的任务。</strong> 「让这个页面更好看」「优化用户体验」——Agent 不知道什么叫「更好看」，LLM 评分也会反复摇摆。autoresearch 不能替你做设计决策。</li><li><strong>跨 Issue 的架构变更。</strong> 每个 Issue 是独立执行的，Agent 不知道其他 Issue 做了什么。跨多个 Issue 的重构、API 变更、数据模型迁移——需要人在更高的层面协调。</li><li><strong>需要人类判断的探索性工作。</strong> 「试试看这个技术方案行不行」——探索的结果需要人来解读，不能交给 LLM 评分来判定。</li></ul><p><strong>代价：</strong></p><p>适用场景说清了，但 autoresearch 有两个绕不过去的成本。</p><p>第一个是时间。一个 Issue 走完「实现 → 审查 → 修复 → 再审查 → 评分达标」的完整流程，少则十几分钟，多则几十分钟。贪吃蛇这种体量的功能跑了四轮十二分钟——这算快的。复杂 Issue 迭代五六轮甚至更多，半小时以上很常见。对比人类开发者自己写可能只要十分钟的功能，autoresearch 反而更慢。但这不是 apples-to-apples 的对比——autoresearch 省的是人的注意力，不是绝对时间。你在等它的十几分钟里可以做别的事，或者干脆不坐在电脑前。</p><p>第二个是 token。每轮迭代，Agent 要读 Issue、读代码、读 program.md、读前一轮的审查报告、读测试结果——上下文越积越厚。贪吃蛇的四轮跑下来，token 消耗轻易过几十万。如果三个 Agent 各跑两轮，就是六次完整的上下文加载。单 Agent 的 Ralph Loop 也有这个问题，但 autoresearch 的多 Agent 轮转让每个 Agent 都从头加载上下文，token 成本乘以 Agent 数量。功能全自动了，API 账单也全自动了。</p><p>这两个代价不是要否定 autoresearch。它是交易——用时间和 token 换人的注意力解放和代码质量的确定性。交易划不划算，看你更缺什么。缺时间——自己写更快。缺注意力——让 autoresearch 跑，你去睡觉。</p><p>一个实用判断：Issue 里的验收标准能写成 checkbox 格式，autoresearch 稳。写不成——先别用。</p><h2 id="7-10-与前后章节的关系"><a href="#7-10-与前后章节的关系" class="headerlink" title="7.10 与前后章节的关系"></a>7.10 与前后章节的关系</h2><p><strong>autoresearch 与 Ralph Loop（第 4 章）。</strong> autoresearch 是 Ralph Loop 的「多 Agent + 端到端」升级版。Ralph Loop 是单 Agent 反复迭代直到 promise 匹配。autoresearch 是多 Agent 轮转审查直到评分达标。Ralph Loop 止步于代码完成，autoresearch 一路走到 Issue 关闭。两者的核心循环逻辑是一样的——「没达标就继续」——autoresearch 在上面加了两层：交叉审查和自动交付。</p><p><strong>autoresearch 与 gstack（第 5 章）。</strong> gstack 的质量保证靠角色覆盖——CEO 审方向、工程经理审架构、QA 测功能、安全官审漏洞。autoresearch 的质量保证靠模型覆盖——Claude 实现、Codex 审查、OpenCode 再审查。gstack 的角色是人格化的——「你是一个有十五年经验的员工工程师」。autoresearch 的 Agent 是去人格化的——就是不同的模型，不带角色身份。两条路：gstack 在 prompt 层面模拟专家多样性，autoresearch 在模型层面实现真实多样性。</p><p><strong>autoresearch 与 superpowers（第 6 章）。</strong> superpowers 的 <code>subagent-driven-development</code> 和 autoresearch 的多 Agent 轮转都用了多 Agent 协作。但协作模式不同。superpowers 是分工式——每个子 Agent 负责一个独立任务，主 Agent 协调审查。autoresearch 是接力式——同一个任务在不同 Agent 之间传递，每个 Agent 在前一个的基础上审查和改进。superpowers 的上下文隔离更好（每个子 Agent 全新上下文），autoresearch 的审查覆盖更广（多个模型的视角叠加）。</p><p><strong>autoresearch 与 Goal Workflow（第 8 章）。</strong> 这是最紧密的一组关系。Goal Workflow 的四步闭环（PRD → Issue 拆分 → &#x2F;goal 实现 → &#x2F;ship-it 交付）把研发流程拆成了四个步骤。autoresearch 是其中 <code>/goal</code> 步骤的全自动化版本——「帮我实现这个 Issue」升级为「自动实现所有 Issue」。第 8 章会讲 Goal Workflow 如何把 autoresearch 嵌进一个更完整的研发体系。</p><h2 id="7-11-本章小结"><a href="#7-11-本章小结" class="headerlink" title="7.11 本章小结"></a>7.11 本章小结</h2><p>autoresearch 的名字来自 Karpathy 的 82K Stars 项目，但 smallnest 做的是完全不同的东西——ML 实验自动化变成了软件工程全流程自动化。</p><p>它的核心设计三条：</p><ol><li><p><strong>多 Agent 轮转替代单 Agent 迭代。</strong> 不同模型有不同的盲区。Claude 看不到的问题 Codex 能看到，Codex 改不好的地方 OpenCode 能改好。轮转公式 <code>(iter − 1) % N</code> 保证了每个 Agent 都有机会审查和修复。这和人类代码审查中多 reviewer 的效果一致——审的人越多，漏掉的越少。</p></li><li><p><strong>双轨门禁替代单维度检查。</strong> 硬门禁（Build&#x2F;Lint&#x2F;Test）保证代码能跑。软门禁（LLM 评分 ≥ 85）保证代码写得好。传统 CI 只能做到前者。autoresearch 两条都做。未达标就换 Agent 继续迭代，直到两条都通过。</p></li><li><p><strong>端到端闭环替代分步半自动。</strong> 不只是生成代码。从 Issue 解析到 PR 创建到合并到关闭 Issue——全自动。人的角色从「操作者」变成了「验收标准定义者」。这和第 1 章的核心主张一脉相承：在 AI 时代，你的价值不再是「你能写多快的代码」，而是「你能不能定义清楚什么算做好」。</p></li></ol><p>把本章和前两章放在一起看，三条路线对应三种自动化程度。gstack 是人驱动流程——你走七个阶段，Agent 辅助执行。superpowers 是 Agent 驱动流程——Agent 自己走流程，人类在关键决策点确认。autoresearch 是全自动流程——人类只定义目标，Agent 从实现到交付全包。</p><p>没有高下之分。但自动化程度越高，对输入质量的要求越高。gstack 的 <code>/office-hours</code> 能容忍模糊的想法，六个强制问题帮你逐步澄清。autoresearch 的 Issue 必须一开始就写清楚——它不会在过程中追问你「这个验收标准具体是什么意思」。选哪种路线，看你对自己「能写清楚到什么程度」的诚实判断。</p><p>本书第 8 章的 Goal Workflow 把 PRD、Issue 拆分、autoresearch 实现、交付合入串成了一条从 PRD 到上线的研发闭环。如果你觉得 autoresearch 的「全自动实现 Issue」还不够，Goal Workflow 会展开完整的项目研发流程自动化方案。</p>