Loop Engineering 实践：一次批量实现 8 个 issue，完成夔牛工具的开发

<blockquote><p>I don&#39;t talk to an agent anymore, I talk to a loop or a routine.<br>——Boris Cherny</p></blockquote><p>![image-20260611034205752.png<img src="/2026/06/17/loop-engineering-batch-8-issues-kuiniu-tool/image-20260611034205752.png" class=""></p><p>先讲一个真实的 case。</p><p>6 月 10 日下午，我把一个新工具 <strong>kuiniu（夔牛）</strong> 的 PRD 丢给 Claude Code，让它生成 8 个 issue 卡到 GitHub 仓库。然后我敲了一句 <code>/loop-it</code>，然后离开了。</p><p>一个小时后打开仓库一看，<a href="https://github.com/baidu/nettools/issues?q=is:issue%20state:closed">8 个 issue 全 closed</a>，对应的 PR 全 merge 了。main 分支上多出了 client、server、codec、bitflip 检测、丢包统计、命令行入口、Makefile&#x2F;goreleaser 集成，还顺手抽出了一个 <code>util/rotate_writer.go</code>。</p><span id="more"></span><p>我没有 prompt 任何一步。我只<strong>触发</strong>了一个循环。</p><p>![image-20260611042519659.png<img src="/2026/06/17/loop-engineering-batch-8-issues-kuiniu-tool/image-20260611042519659.png" class=""></p><p>这就是这个月在 AI 编程圈里把所有人都拽进去吵的那个词——Loop Engineering（循环工程）。</p><hr><h2 id="01-这周最火的一个单词-Loop-Engineering"><a href="#01-这周最火的一个单词-Loop-Engineering" class="headerlink" title="01 这周最火的一个单词: Loop Engineering"></a>01 这周最火的一个单词: Loop Engineering</h2><p>6 月 7 日，Peter Steinberger 在 X 上发了一条推文：</p><blockquote><p>&quot;Here&#39;s your monthly reminder that you shouldn&#39;t be prompting coding agents anymore. You should be designing loops that prompt your agents.&quot;</p><p>（温馨提示：你不应该再 prompt 你的 coding agent，你应该设计 loop 去 prompt 它。）</p></blockquote><p>220 万次浏览，整条 timeline 被它锁住了。下面回复区秒变战场，最经典的一条来自 Matthew Berman：</p><blockquote><p>&quot;nobody knows but him and boris.&quot;（除了他自己和 Boris，没人知道在说啥。）</p></blockquote><p>Boris Cherny 是谁？Anthropic Claude Code 的负责人。9 个月前 Claude Code 还是他的一个 side project，现在它写出了 GitHub 上接近 4% 的公开 commit。</p><p>6 月 2 日，他在 WorkOS 主办的 Acquired Unplugged 上场，给了这个词最干净的定义：</p><blockquote><p>&quot;我已经不再 prompt Claude。我有一堆 loop 在跑，是它们在 prompt Claude，决定下一步做什么。我的工作就是写 loop。&quot;</p></blockquote><p>Simon Willison 的 receipt 更直接：过去 30 天，Boris 提交到 Claude Code 的代码 100% 由 Claude Code 自己写，他合入了 259 个 PR。11 月份开始他直接把 IDE 删了。</p><p>注意：他不是说工程师过时了。他说工作&quot;上移&quot;了一层，从写代码变成写&quot;那个写代码的东西&quot;。</p><p>我自己读完最大的感受是，过去两年我们玩 prompt engineering、context engineering，今年上半年开始玩 harness engineering，到 6 月直接跳到 loop engineering。抽象层级一年蹦了三档，节奏挺猛的。</p><p>![image-20260611042700262.png<img src="/2026/06/17/loop-engineering-batch-8-issues-kuiniu-tool/image-20260611042700262.png" class=""></p><hr><h2 id="02-Loop-到底是什么：从-ReAct-到编排"><a href="#02-Loop-到底是什么：从-ReAct-到编排" class="headerlink" title="02 Loop 到底是什么：从 ReAct 到编排"></a>02 Loop 到底是什么：从 ReAct 到编排</h2><p>很多人吵这个词，是因为 &quot;loop&quot; 这个词其实裹着至少 5 种不同的东西。我在上一篇公众号文章里梳理过，这里再重复一遍背景。</p><p>Addy Osmani 把这个历史讲得很清楚：</p><table><thead><tr><th>阶段</th><th>时间</th><th>形态</th><th>谁在驱动</th></tr></thead><tbody><tr><td>ReAct 循环</td><td>2022</td><td>学术 while 循环，一个模型一个循环</td><td>人盯着</td></tr></tbody></table><p>| AutoGPT | 2023 | 给目标让它自己 prompt | 著名地空转 |<br>| Ralph Loop | 2025 | bash 单行，每次重置上下文到锚定文件 | 终端开着 |<br>| &#x2F;goal 产品化 | 2026 春 | 小模型验证停止条件 | 人启动一次 |<br>| 编排式 Loop | 2026 现在 | Loop 监督 Loop，调度+持久化 | 基础设施时间 |</p><p>最早的 Ralph Loop 是 Geoffrey Huntley 在 2025 年 7 月发布的，朴素得过分：一个 bash one-liner 把同一个 prompt 反复管道给 agent。但它只花 297 美元就构建出了一个完整的编程语言。Ralph 真正的创新是纪律，每次迭代都把上下文重置回固定的锚定文件，而不是让对话无限增长。</p><p>到了 2026 年，Codex 和 Claude Code 都内置了 <code>/goal</code> 命令，这就是产品化的 Ralph 循环。跑到一个可验证的停止条件成立为止，由一个独立的小模型来判断&quot;做完了没&quot;。写代码的 agent 不批改自己的作业，这是 loop 第一次有了 split verifier。</p><p>Boris 和 Steinberger 真正在说的是再上一层的&quot;编排式 Loop&quot;。和 Ralph 比，它把 loop 当成工作的单位而不是某个任务，让 loop 之间互相监督、并发地跑，靠调度而不是人工启动来发起，最关键的一点是把状态显式存到 git 里，崩溃可以恢复。</p><p>一句话总结：Ralph 假设你的终端开着；2026 版本的 Loop 假设你的终端关着。</p><hr><h2 id="03-我自己的-loop-it：把这套东西塞进一个-Skill"><a href="#03-我自己的-loop-it：把这套东西塞进一个-Skill" class="headerlink" title="03 我自己的 loop-it：把这套东西塞进一个 Skill"></a>03 我自己的 loop-it：把这套东西塞进一个 Skill</h2><p>理论看完，问题来了：我怎么在自己的项目里跑一个 loop？</p><p>我做了一套叫 <strong>goal-workflow</strong> 的开源工作流，托在 GitHub：<a href="https://github.com/smallnest/goal-workflow">smallnest&#x2F;goal-workflow</a>。一行命令装：</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">npx skills add smallnest/goal-workflow</span><br></pre></td></tr></table></figure><p>整个 pipeline 是这样的：</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-to-spec (可选) → /to-issues → /loop-it (→ /goal → /review-it → /note-it → /ship-it)×N</span><br></pre></td></tr></table></figure><p>前三步还得我亲自上：<code>/prd</code> 和我聊一遍，把脑子里的需求整成 PRD；<code>/prd-to-spec</code> 可选，把 PRD 变成技术设计；<code>/to-issues</code> 把 PRD&#x2F;SPEC 拆成一堆带 acceptance criteria 和 dependencies 的 issue 卡，自动 push 到 GitHub。</p><p>然后 <code>/loop-it</code> 接过去，进入 loop。每个 issue 走完整 4 步：</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></pre></td><td class="code"><pre><span class="line">/goal ← 实现</span><br><span class="line">/review-it ← 自我代码评审</span><br><span class="line">/note-it ← 记录设计决策</span><br><span class="line">/ship-it ← 提 commit、PR、merge、关 issue</span><br></pre></td></tr></table></figure><p>写这套东西时，我把 Addy Osmani 那张表和 Boris 的&quot;五条建议&quot;翻来覆去看了好几遍。最后落地的几个关键点都是冲着 loop engineering 那几个老坑去的。</p><p>第一件事是磁盘里的 state file。每个 loop 都需要一个仓库外的记忆。我用一个 <code>.loop-state.json</code>：</p><figure class="highlight json"><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></pre></td><td class="code"><pre><span class="line"><span class="punctuation">&#123;</span></span><br><span class="line"> <span class="attr">&quot;version&quot;</span><span class="punctuation">:</span> <span class="number">1</span><span class="punctuation">,</span></span><br><span class="line"> <span class="attr">&quot;repo&quot;</span><span class="punctuation">:</span> <span class="string">&quot;baidu/nettools&quot;</span><span class="punctuation">,</span></span><br><span class="line"> <span class="attr">&quot;total_issues&quot;</span><span class="punctuation">:</span> <span class="number">8</span><span class="punctuation">,</span></span><br><span class="line"> <span class="attr">&quot;issues&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span></span><br><span class="line"> <span class="attr">&quot;23&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;status&quot;</span><span class="punctuation">:</span> <span class="string">&quot;shipped&quot;</span><span class="punctuation">,</span> <span class="attr">&quot;branch&quot;</span><span class="punctuation">:</span> <span class="string">&quot;feat/issue-23-config&quot;</span><span class="punctuation">,</span> <span class="attr">&quot;attempts&quot;</span><span class="punctuation">:</span> <span class="number">1</span> <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line"> <span class="attr">&quot;24&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;status&quot;</span><span class="punctuation">:</span> <span class="string">&quot;shipped&quot;</span><span class="punctuation">,</span> <span class="attr">&quot;branch&quot;</span><span class="punctuation">:</span> <span class="string">&quot;feat/issue-24-codec&quot;</span><span class="punctuation">,</span> <span class="attr">&quot;attempts&quot;</span><span class="punctuation">:</span> <span class="number">1</span> <span class="punctuation">&#125;</span><span class="punctuation">,</span></span><br><span class="line"> <span class="attr">&quot;25&quot;</span><span class="punctuation">:</span> <span class="punctuation">&#123;</span> <span class="attr">&quot;status&quot;</span><span class="punctuation">:</span> <span class="string">&quot;in_progress&quot;</span><span class="punctuation">,</span> <span class="attr">&quot;phase&quot;</span><span class="punctuation">:</span> <span class="string">&quot;review&quot;</span><span class="punctuation">,</span> <span class="attr">&quot;attempts&quot;</span><span class="punctuation">:</span> <span class="number">1</span> <span class="punctuation">&#125;</span></span><br><span class="line"> <span class="punctuation">&#125;</span></span><br><span class="line"><span class="punctuation">&#125;</span></span><br></pre></td></tr></table></figure><p>每次状态翻页就立刻写盘。崩溃了？重新跑 <code>/loop-it</code>，它读 state file，跳过已 shipped 的，从断点继续。这一招看起来傻得不行，但每个跑长链路 agent 的人都掉过同一个坑：没有磁盘记忆的 loop 一崩就归零。<br>![image-20260611042827942.png<img src="/2026/06/17/loop-engineering-batch-8-issues-kuiniu-tool/image-20260611042827942.png" class=""></p><p>第二件事是拓扑排序，让依赖显式化。<code>/to-issues</code> 切 issue 的时候会自动写出 <code>Dependencies: #3, #5</code> 这种 metadata。<code>/loop-it</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></pre></td><td class="code"><pre><span class="line"> Found 8 open issues (topological sort):</span><br><span class="line"> #23: 创建配置格式与 GPU 拓扑校验 (无依赖)</span><br><span class="line"> #24: 实现 codec 扩展 (依赖 #23)</span><br><span class="line"> #25: 实现 Sender/Receiver 接口与 UDP 实现 (依赖 #23, #24)</span><br><span class="line"> #26: 实现客户端同号卡探测逻辑 (依赖 #23, #24, #25)</span><br><span class="line"> #27: 实现服务端 GPU 收包 + CPU 回包 (依赖 #23, #24, #25)</span><br><span class="line"> #28: 实现 bitflip 检测 (依赖 #25)</span><br><span class="line"> #29: 实现丢包和时延统计输出 (依赖 #25)</span><br><span class="line"> #30: 命令行入口与构建集成 (依赖 #23~#29)</span><br></pre></td></tr></table></figure><p>不是拍脑袋按 issue 编号顺序跑，而是真按依赖关系一路推过去。环也能检测出来，按编号打破。</p><p>第三件事是 split verifier。每个 issue 实现完一定得走 <code>/review-it</code>，换一个干净的上下文，让另一个 agent 拿着 spec 和测试去挑刺，最多迭代 2 轮，再才能进 <code>/ship-it</code>。这是抄 Boris 的：&quot;loop 的可信度只取决于它检查自己工作的能力。&quot;<br>![image-20260611042939259.png<img src="/2026/06/17/loop-engineering-batch-8-issues-kuiniu-tool/image-20260611042939259.png" class=""></p><p>第四件事是分级错误恢复。跑 loop 一定会撞墙，build 挂、测试红、merge conflict、rate limit、CI 红，没一个能躲。每种我都给了固定的恢复策略和最大重试次数：</p><table><thead><tr><th>错误类别</th><th>信号</th><th>恢复</th><th>上限</th></tr></thead><tbody><tr><td>build_failure</td><td>编译错误、type 错误</td><td>读错误、改代码、再 build</td><td>3</td></tr><tr><td>test_failure</td><td>断言失败</td><td>读输出、改实现、再测</td><td>3</td></tr><tr><td>lint_failure</td><td>lint 红</td><td><code>lint --fix</code>、再 lint</td><td>2</td></tr><tr><td>merge_conflict</td><td>CONFLICT 标记</td><td>rebase main、解、push</td><td>2</td></tr><tr><td>ci_failure</td><td><code>gh pr checks</code> 失败</td><td>读 CI 日志、本地修、push</td><td>2</td></tr><tr><td>rate_limit</td><td>secondary abuse</td><td>等 60s</td><td>3</td></tr><tr><td>unknown</td><td>其他</td><td>标记 failed、跳过</td><td>0</td></tr></tbody></table><p>撞死了不会无限重试，标记 <code>failed</code>、保留分支不删（让我事后看）、写检查点、跑下一个。</p><p>最后一件事是每一步都打 checkpoint：<code>pending → in_progress → goal_done → review_done → note_done → shipped</code>。每次状态翻页都写盘。中间断电下次接得上。这点是 ralph loop 没有的，ralph 假设你终端开着，loop-it 假设你笔记本盖着。</p><p>我实现的这个<code>loop-it</code> 相比较Boris说的工作流，还属于一个比较简单的，Boris说的Loop中的逻辑完全由Agent决定，而我实现的<code>loop-it</code>基本上是一个比较明确的工作流，按照github issues顺序去执行，虽然issues之间可能有依赖，但是在loop之前，<code>to-issues</code>已经把它们编排好了。而且<code>loop-it</code>是一个agent驱动去执行的，Boris的工作流可能是几百个Agent去执行，更宏大。 </p><p>轻量级有轻量级的好处，使用起来更轻巧，也可以及时的让人类进行切入，token花费也少，下面是我昨天使用这种方式的一个实战，这也是我在Loop Engineering方向的一个探索，没有固定答案，只有摸索和经验的总结。</p><hr><h2 id="04-实战：一小时批量实现-kuiniu-的-8-个-feature"><a href="#04-实战：一小时批量实现-kuiniu-的-8-个-feature" class="headerlink" title="04 实战：一小时批量实现 kuiniu 的 8 个 feature"></a>04 实战：一小时批量实现 kuiniu 的 8 个 feature</h2><p>正如 Matthew Berman 说的，&quot;nobody knows but him and boris.&quot;Loop Engineering 现在还没一个清晰的公认定义，但已经有不少人在解读和实践。我自己在 goal-workflow 里实现的 <code>loop-it</code> 算是其中一种轻量解读，加了点 harness engineering 的约束，走顺序迭代而不是 Claude Code workflow 那种宏大的多 agent 编排，省钱省心。</p><p>OK 现在回到开头那个 case。</p><p>百度内部多年沉淀的高性能网络监控工具集 <a href="https://github.com/baidu/nettools">nettools</a> 这个月在密集开源，bitflip、baize、lidar 都已经放出来了。下一个准备开源的是 <strong>kuiniu（夔牛）</strong>，专门做 GPU 网络的丢包和时延探测，每个 GPU 8 张卡 8 个 IP，通过 GPU 收发包来探测。</p><p>这是一个有清晰约束的工程问题，正好适合 loop。</p><p>![image-20260611043211480.png<img src="/2026/06/17/loop-engineering-batch-8-issues-kuiniu-tool/image-20260611043211480.png" class=""></p><h3 id="Step-1：写一份-PRD（人肉-30-分钟）"><a href="#Step-1：写一份-PRD（人肉-30-分钟）" class="headerlink" title="Step 1：写一份 PRD（人肉 30 分钟）"></a>Step 1：写一份 PRD（人肉 30 分钟）</h3><p>跑 <code>/prd kuiniu</code>，和 Claude 聊清楚几件事：</p><ul><li>同号卡探测（卡 i 探卡 i）</li><li>发包 GPU、收包 CPU 的不对称路径</li><li>payload 必须携带源目 IP&#x2F;Port</li><li>重点是丢包率和时延</li><li>复用 baize 已有的 codec&#x2F;bitflip 检测能力</li></ul><p>输出一份 <code>tasks/prd-kuiniu.md</code>。</p><h3 id="Step-2：拆-issue（人肉-5-分钟过审）"><a href="#Step-2：拆-issue（人肉-5-分钟过审）" class="headerlink" title="Step 2：拆 issue（人肉 5 分钟过审）"></a>Step 2：拆 issue（人肉 5 分钟过审）</h3><p>跑 <code>/to-issues</code>，自动拆出 8 个：</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></pre></td><td class="code"><pre><span class="line">#23 kuiniu: 创建配置格式与 GPU 拓扑校验</span><br><span class="line">#24 kuiniu: 实现 codec 扩展 — payload 携带源目 IP 和端口</span><br><span class="line">#25 kuiniu: 实现 Sender/Receiver 接口与 UDP 实现</span><br><span class="line">#26 kuiniu: 实现客户端同号卡探测逻辑</span><br><span class="line">#27 kuiniu: 实现服务端 GPU 收包 + CPU 回包</span><br><span class="line">#28 kuiniu: 实现 bitflip 检测</span><br><span class="line">#29 kuiniu: 实现丢包和时延统计输出</span><br><span class="line">#30 kuiniu: 命令行入口与构建集成</span><br></pre></td></tr></table></figure><p>每个卡片都自带 acceptance criteria、dependencies、type、priority。push 到 <a href="https://github.com/baidu/nettools/issues?q=is:issue%20state:closed">baidu&#x2F;nettools</a>。</p><h3 id="Step-3：-loop-it（人肉-3-秒）"><a href="#Step-3：-loop-it（人肉-3-秒）" class="headerlink" title="Step 3：/loop-it（人肉 3 秒）"></a>Step 3：<code>/loop-it</code>（人肉 3 秒）</h3><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">/loop-it</span><br></pre></td></tr></table></figure><p>剩下的全是 loop 的事。我去喝杯枸杞茶。</p><h3 id="一小时后检查进度"><a href="#一小时后检查进度" class="headerlink" title="一小时后检查进度"></a>一小时后检查进度</h3><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></pre></td><td class="code"><pre><span class="line">━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</span><br><span class="line"> Loop Complete — Summary</span><br><span class="line">━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</span><br><span class="line"> ✅ Shipped: 8 issues (#23, #24, #25, #26, #27, #28, #29, #30)</span><br><span class="line"> ⏭️ Skipped: 0 issues</span><br><span class="line"> Blocked: 0 issues</span><br><span class="line"> ❌ Failed: 0 issues</span><br><span class="line"> Total: 8 issues</span><br><span class="line">━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</span><br></pre></td></tr></table></figure><p>8 个 issue 全 closed，PR 全 merge 进 main。中间循环跑 <code>/goal → /review-it → /note-it → /ship-it</code> 共 32 次小循环，加上 review 阶段的修复迭代，实际触发的 agent turn 接近 60 次。<code>/review-it</code> 在 #25 和 #27 上分别挑出了一些边界 case 没处理，loop 自己改完又跑了一遍 review 才进 ship。</p><p>整个过程我没有 prompt 任何一步。我只在第二天打开 GitHub 看了眼 PR 列表，扫了下 review 笔记，确认每个 PR 的设计决策合理之后，那些代码就已经在主干上了。</p><p>跑完这一晚我才信一件事：loop 的难点不是 loop 本身，是放进去那个能说&quot;不&quot;的东西。没有真正检查的 loop，只是 agent 在反复自我同意。</p><p>最后冷静一句：不是所有任务都值得 loop。CI 分诊、依赖升级、lint-fix、强测试覆盖的 issue-to-PR（比如这次的 kuiniu）适合先上手；架构重写、认证支付、生产部署暂时不要碰。</p><hr><p><strong>项目链接</strong>：</p><ul><li>goal-workflow: <a href="https://github.com/smallnest/goal-workflow">github.com&#x2F;smallnest&#x2F;goal-workflow</a></li><li>kuiniu (夔牛) — loop-it 实战产物: <a href="https://github.com/baidu/nettools/issues?q=is:issue%20state:closed">baidu&#x2F;nettools</a></li><li>Addy Osmani 原文: <a href="https://addyosmani.com/blog/loop-engineering/">Loop Engineering</a></li><li>Matt Van Horn 长读: <a href="https://x.com/mvanhorn/article/2063865685558903149">WTF Is a Loop? Steinberger vs. Cherny</a></li></ul>