Loop Engineering：从提示 Agent 到设计循环

<blockquote><p>&quot;You shouldn&#39;t be prompting coding agents anymore. You should be designing loops that prompt your agents.&quot;<br>你不应该再提示编码 Agent 了。你应该设计循环来提示你的 Agent。</p><p>——Peter Steinberger, 2026 年 6 月 7 日</p></blockquote><p>第 10 章搭了 Agent 的运行环境——hooks、权限、沙箱、配置继承。第 11 章用 Kanban 管多个 Agent 的并行编排。但有一个更根本的问题还没回答：<strong>每次都是你在提示 Agent。你打字，它回话，你再打字。你不在，它就不动。</strong></p><p>2026 年 6 月，两条推文把这个矛盾推到了台前。Peter Steinberger（OpenClaw 作者）的那句话在 48 小时内获得 220 万次浏览。几天后，Boris Cherny（Anthropic Claude Code 负责人）在 WorkOS 的 Acquired Unplugged 活动上说了几乎同样的话：&quot;I don&#39;t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.&quot;</p><p><img src="/images/image-20260609032530128.png"></p><p>全网炸了。但没人说得清&quot;loop&quot;到底是什么。有人说是 Ralph Loop 的翻版，有人说是&quot;戴了顶帽子的 cron job&quot;，有人说&quot;prompt engineering 已死&quot;。一周之内，Reddit、Hacker News、X 上的讨论翻了几十页，最诚实的回答是 Matthew Berman 那句：&quot;Nobody knows but him and Boris.&quot;</p><p>Addy Osmani 随即发表了长文&quot;Loop Engineering&quot;，给了这个概念第一个完整的拆解。本章基于 Osmani 的框架，结合 Boris Cherny 的实践、Geoffrey Huntley 的 Ralph Loop 思想、以及 AlphaSignal 的四条件测试，回答三个问题：Loop Engineering 是什么？它和前十一章的方法论什么关系？你真的需要它吗？</p><span id="more"></span><h2 id="12-1-从提示-Agent-到设计循环"><a href="#12-1-从提示-Agent-到设计循环" class="headerlink" title="12.1 从提示 Agent 到设计循环"></a>12.1 从提示 Agent 到设计循环</h2><p>先把 Boris Cherny 的三阶段演化说清楚。</p><p><img src="/images/image-20260609032953539.png"></p><p>一年前，Cherny 的写代码方式和所有工程师一样：IDE + 自动补全。然后他开始同时跑五到十个 Claude 会话，手动提示每一个——这个修 bug，那个做 feature，还有一个跑测试。每一条指令都是他亲手打的。他的时间不再是写代码，而是在五个终端窗口之间切来切去，给每个窗口里的 Claude 写 prompt。</p><p>然后他停了。不是不用 Claude——而是不再自己打 prompt。他写了一组小程序，每个程序做三件事：找到该做的事、把事交给 Claude、检查做完了没有。这些程序按时间表运行——有的每分钟一次，有的每天一次，有的跑到达成某个条件才停。Cherny 把它们叫 loops。他的原话是：&quot;My job is to write loops.&quot;</p><p>结果：据 Cherny 自述，过去 30 天里他对 Claude Code 的 100% 贡献都由 Claude Code 自己写的，合并了 259 个 PR。他在 2025 年 11 月删掉了 IDE，到发稿时没再打开过。Yash Thakker 整理的补充数据：Anthropic 工程师实现每日代码产出 8 倍增长，Claude 编写了超过 80% 的已合并生产代码，开放式软件任务成功率 76%。</p><p>这就是 Loop Engineering——<strong>不再由人提示 Agent，而是设计自动提示 Agent 的系统。</strong> 你从循环里面的人，变成了循环的作者。</p><p>Cherny 不是说工程师过时了。他自己仍然决定做什么、和用户沟通、协调团队。工作没有消失。上升了一个高度——从写代码，到写那个写代码的东西。</p><h2 id="12-2-Loop-处在哪一层"><a href="#12-2-Loop-处在哪一层" class="headerlink" title="12.2 Loop 处在哪一层"></a>12.2 Loop 处在哪一层</h2><p>前十一章的方法论解决的是&quot;Agent 怎么做事&quot;。Loop Engineering 解决的是&quot;谁来提示 Agent 做事&quot;。这是一个不同的抽象层。</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">Loop Engineering (谁提示 Agent)</span><br><span class="line"> │</span><br><span class="line"> └── Harness Engineering (Agent 的运行环境)</span><br><span class="line"> │</span><br><span class="line"> └── 方法论层 (Agent 怎么做事)</span><br><span class="line"> │ Skills / SDD / Ralph Loop / gstack / Goal Workflow / autoresearch</span><br><span class="line"> │</span><br><span class="line"> └── 项目层 (做什么事)</span><br><span class="line"> goscapy / Web 应用 / 微服务...</span><br></pre></td></tr></table></figure><p>Harness 管一个 Agent 的运行环境——第 10 章拆过的 hooks、权限、沙箱。Loop 坐在 Harness 上面，加了三样东西：定时器（让 Agent 不等你就在跑）、子 Agent 派生（让一个 Loop 管多个 Agent）、自我驱动（让 Loop 自己决定下一步做什么）。</p><p>用 Osmani 的话说：Harness 让一个 Agent 安全运行，Loop 让一群 Agent 自己跑起来。</p><h2 id="12-3-Loop-的五个必需品-一个记忆"><a href="#12-3-Loop-的五个必需品-一个记忆" class="headerlink" title="12.3 Loop 的五个必需品 + 一个记忆"></a>12.3 Loop 的五个必需品 + 一个记忆</h2><p>Osmani 把它拆成了五样东西，加一个存记忆的地方。</p><p><img src="/images/image-20260609034910599.png"></p><h3 id="12-3-1-Automations——循环的心跳"><a href="#12-3-1-Automations——循环的心跳" class="headerlink" title="12.3.1 Automations——循环的心跳"></a>12.3.1 Automations——循环的心跳</h3><p>Automations 是让 Loop 成为&quot;Loop&quot;而非&quot;你手动跑了一次&quot;的东西。没有它，你只是用了一次 Agent。有了它，Agent 按节奏自己跑。</p><p>Codex 的实现是 Automations tab——选项目、写 prompt、选频率、选本地还是后台 worktree。找到问题的 run 进 Triage inbox，没找到的自动归档。OpenAI 内部用它做日常 issue 分诊、CI 失败摘要、commit 简报、最近引入的 bug 猎杀。Automation 还能调用 Skill——你写 <code>$skill-name</code>，不用把一大堆指令粘到没人会再更新的时间表里。</p><p>Claude Code 走了另一条路但到同一个地方：<code>/loop</code> 按节奏重跑，<code>/goal</code> 跑到条件满足为止，hooks 在 Agent 生命周期的关键点插入逻辑，GitHub Actions 让你合上笔记本它还在跑。</p><p><code>/loop</code> 和 <code>/goal</code> 是两种不同的自主原语。<code>/loop</code> 是时间驱动的——每 N 分钟跑一次。<code>/goal</code> 是条件驱动的——跑到&quot;test&#x2F;auth 里所有测试通过、lint 干净&quot;才停。两者都重要，覆盖不同的自主模式。</p><h3 id="12-3-2-Worktrees——并行不冲突"><a href="#12-3-2-Worktrees——并行不冲突" class="headerlink" title="12.3.2 Worktrees——并行不冲突"></a>12.3.2 Worktrees——并行不冲突</h3><p>两个 Agent 同时写同一个文件，和两个工程师 commit 同一行然后谁都不跟谁说话一模一样。Git worktree 解决这个问题——一个独立的工作目录在自己的分支上共享同一个仓库历史，一个 Agent 的编辑物理上不可能碰到另一个的 checkout。</p><p>Codex 内置了 worktree 支持，多个 thread 同时打一个仓库互不碰撞。Claude Code 提供三种隔离方式：<code>git worktree</code> 手动创建、<code>--worktree</code> 标志在独立 checkout 里开会话、<code>isolation: worktree</code> 让 subagent 自动获得可自动清理的独立 checkout。</p><p>但 Addy Osmani 在另一个文章里指出了一个更深的限制：<strong>你的审查带宽才是真正的上限</strong>。Worktree 消除了机械碰撞，但你一次能审查多少个 PR 决定了你实际能跑多少个 Agent，不是工具。</p><h3 id="12-3-3-Skills——停止每次重新解释项目"><a href="#12-3-3-Skills——停止每次重新解释项目" class="headerlink" title="12.3.3 Skills——停止每次重新解释项目"></a>12.3.3 Skills——停止每次重新解释项目</h3><p>Skill 是让你停止像金鱼一样每次会话重新解释项目的东西。没有 Skills 的 Loop 每次循环从零推导整个项目——构建命令、代码风格、那个因为某次事故才有的约定。有 Skills 的 Loop 复合增长——每次循环站在前一次的肩膀上。</p><p>第 2 章讲的 Skills 系统在这里有了新的位置：它不仅是 Agent 的能力单元，更是 Loop 内可复用的知识资产。<strong>Loop 内可复用的单元是 Skill 不是 prompt。</strong> 调用清晰命名 Skill 的 Loop 复合增长；每次从头推导的 Loop 只烧钱。</p><p>Skill 和 Plugin 是两件事。Skill 是编写格式——一个 <code>SKILL.md</code> 文件加可选的脚本和引用。Plugin 是分发方式——把多个 Skill 和 Connector 打包，让队友一键安装。在 Codex 和 Claude Code 里都一样。</p><h3 id="12-3-4-Plugins-和-Connectors——Loop-触达真实工具"><a href="#12-3-4-Plugins-和-Connectors——Loop-触达真实工具" class="headerlink" title="12.3.4 Plugins 和 Connectors——Loop 触达真实工具"></a>12.3.4 Plugins 和 Connectors——Loop 触达真实工具</h3><p>一个只能看文件系统的 Loop 是一个很小的 Loop。MCP 连接器让 Agent 读 Issue 追踪、查数据库、调 staging API、发 Slack 消息。Codex 和 Claude Code 都支持 MCP，所以你为一个写的 connector 通常另一个也能用。</p><p>没有 Connectors 的 Loop 能修代码，但修完就停在那了——它不知道该开 PR，不知道该关联哪个 Linear ticket，不知道 CI 绿了该 ping 谁。有 Connectors 的 Loop 是一条流水线：修完代码 → 开 PR → 关联 ticket → CI 绿了自动通知频道。区别不是 Agent 聪明了多少，是它能动手的范围大了多少。</p><p>第 10 章的 Harness Engineering 把 MCP 作为工具系统的一部分。在 Loop 的层面，Connectors 的角色更明确——Loop 跑的时候你不在旁边，如果它不能自己把结果送到该去的地方，你就得回来收尾，这违背了 Loop 的初衷。Connectors 让 Loop 从&quot;帮你干活的工具&quot;变成&quot;自己走完流程的同事&quot;。</p><h3 id="12-3-5-Sub-agents——写的和查的不是同一个"><a href="#12-3-5-Sub-agents——写的和查的不是同一个" class="headerlink" title="12.3.5 Sub-agents——写的和查的不是同一个"></a>12.3.5 Sub-agents——写的和查的不是同一个</h3><p>这是 Loop 中最有用的结构性设计。</p><p>写代码的模型给自己打分太客气了。它天然倾向于说&quot;我做完了&quot;。第二个 Agent 带着不同的指令，有时候用不同的模型，能抓住第一个 Agent 自己说服自己的东西。</p><p>Codex 的 subagent 在你要求时才生成，并行运行后折叠结果到一个回答。你在 <code>.codex/agents/</code> 定义自己的 Agent——每个有名字、描述、指令，可选模型和推理力度。这样你的安全审查员可以用强模型高推理力度，而探索者用快而只读的轻模型。</p><p>Claude Code 同样支持：<code>.claude/agents/</code> 定义 subagent，agent teams 在它们之间传递工作。常见的分工是：一个探索，一个实现，一个对照 spec 验证。</p><p>这个分工在 Loop 内为什么特别重要？<strong>Loop 跑的时候你不在旁边看。</strong> 一个你真正信任的验证者是你能走开的唯一理由。Subagent 烧更多 token——每个都做自己的模型推理和工具调用——所以把它们花在值得第二意见的地方。</p><p><code>/goal</code> 的评判模型也是 maker-checker 分离。Claude Code 每次 turn 后把目标条件和当前上下文发给一个小的快模型（很可能是 Haiku），它只做一件事：条件满足了没有？返回 yes&#x2F;no 加一条简短理由。干活的模型和验收的模型不是同一个——这个分离是 Loop 可信赖的基础。</p><h3 id="12-3-6-State——Agent-会忘记，仓库不会"><a href="#12-3-6-State——Agent-会忘记，仓库不会" class="headerlink" title="12.3.6 State——Agent 会忘记，仓库不会"></a>12.3.6 State——Agent 会忘记，仓库不会</h3><p>第六个东西不是&quot;必需品&quot;，但少了它 Loop 就是个失忆症患者。</p><p>一个 markdown 文件，或一个 Linear board，任何存在于单次对话之外、记录&quot;做完了什么、还剩什么&quot;的东西。Agent 每次运行之间忘记一切——上下文窗口是临时的。但 state 文件在磁盘上，不属于任何一次对话。明天早上的运行从今天停下的地方继续，不是从零开始。</p><p>一个 state 文件长这样：</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></pre></td><td class="code"><pre><span class="line"><span class="section"># CI Health Loop — State</span></span><br><span class="line"></span><br><span class="line"><span class="section">## 2026-06-08</span></span><br><span class="line"><span class="bullet">-</span> [x] flaky: test<span class="emphasis">_auth_</span>timeout — 隔离到 @slow 标记</span><br><span class="line"><span class="bullet">-</span> [x] broken: test<span class="emphasis">_payment_</span>webhook — 修复已合入 #1847</span><br><span class="line"><span class="bullet">-</span> [ ] flaky: test<span class="emphasis">_search_</span>index — 未复现，下次重跑</span><br><span class="line"></span><br><span class="line"><span class="section">## 2026-06-07</span></span><br><span class="line"><span class="bullet">-</span> [x] broken: test<span class="emphasis">_user_</span>export — 依赖版本回退，#1843</span><br></pre></td></tr></table></figure><p>每次 Loop 启动时读这个文件，知道什么做过了、什么还没做。每次 Loop 结束时写回去。第 10 章的 CLAUDE.md 和 progress file 解决的是 Agent 内部跨会话的记忆——同一个问题，内部版本。Loop 的 state 文件是外部版本——不在 Agent 的上下文里，在文件系统或项目管理工具里，谁都能读，下次运行接着来。</p><h2 id="12-4-Dynamic-Workflows：五个原语的确定性编排"><a href="#12-4-Dynamic-Workflows：五个原语的确定性编排" class="headerlink" title="12.4 Dynamic Workflows：五个原语的确定性编排"></a>12.4 Dynamic Workflows：五个原语的确定性编排</h2><p>上面五个原语是概念层。2026 年 6 月，Claude Code 引入了 Dynamic Workflows——一种用确定性 JavaScript 脚本编排 sub-agent 的方式，把这些概念落到了代码。</p><p><img src="/images/image-20260609035911439.png"></p><p>传统 sub-agent 调用是模型自主决策——&quot;你觉得还需要什么？&quot;。Dynamic Workflow 是确定性程序——&quot;先做 A，再做 B，如果 B 失败就做 C&quot;。每个 sub-agent 有独立的隔离上下文窗口，消除了主会话中的上下文膨胀和自我偏好偏差。</p><p>六种模式覆盖了常见的编排场景：</p><table><thead><tr><th>模式</th><th>逻辑</th><th>典型场景</th></tr></thead><tbody><tr><td>Fan-out &amp; Synthesize</td><td>多个轻量 Agent 并行，一个重量 Agent 聚合</td><td>分析 50 条日记、安全审查</td></tr><tr><td>Classify &amp; Act</td><td>先分类，再按类型执行不同操作</td><td>Issue 分诊</td></tr><tr><td>Pipeline (Draft → Check)</td><td>并行起草，然后检查</td><td>10 个 Agent 挖掘纠正，1 个聚类</td></tr><tr><td>Tournament</td><td>多个 Agent 出方案，judge 评分选一个</td><td>方案对比</td></tr><tr><td>Loop Until Done</td><td>循环到完成</td><td>定时日报</td></tr><tr><td>Deep Verification</td><td>提取每个断言，逐个验证</td><td>事实核查</td></tr></tbody></table><p>一个实战例子：让 Agent &quot;go through my last 50 sessions and mine them for the corrections I keep making&quot;。结果：49 个会话分析，86 个纠正挖掘，每个引用对照实际会话验证。产生的报告显示反复出现的纠正模式——AI slop、虚构词语、错误事实。</p><p>Artem Zhutov（Dynamic Workflows 的早期实践者）有一个重要观察：不要分离工作流和技能。把工作流自包含在技能内——skill.md 文件可以包含一个 JavaScript 文件编码工作流。工作实体是技能，工作流被带入技能。</p><h2 id="12-5-Loop-的历史演进"><a href="#12-5-Loop-的历史演进" class="headerlink" title="12.5 Loop 的历史演进"></a>12.5 Loop 的历史演进</h2><p>&quot;Loop&quot;这个词在 2026 年 6 月突然爆红，但它不是凭空冒出来的。从旧到新，五个阶段。</p><h3 id="Stage-1：ReAct-循环（2022）"><a href="#Stage-1：ReAct-循环（2022）" class="headerlink" title="Stage 1：ReAct 循环（2022）"></a>Stage 1：ReAct 循环（2022）</h3><p>2022 年的 ReAct 论文形式化了最基本的模式：模型推理、调工具、读结果、重复。一个模型，一个循环，一个人看着。这是学术的 while 循环。</p><h3 id="Stage-2：AutoGPT（2023）"><a href="#Stage-2：AutoGPT（2023）" class="headerlink" title="Stage 2：AutoGPT（2023）"></a>Stage 2：AutoGPT（2023）</h3><p>给模型一个目标，让它自己提示自己。AutoGPT 变得著名是因为它无限空转、什么都不做。这个失败给整个领域打上了&quot;Agent 是玩具&quot;的标签，一烙就是两年。</p><h3 id="Stage-3：Ralph-Loop（2025）"><a href="#Stage-3：Ralph-Loop（2025）" class="headerlink" title="Stage 3：Ralph Loop（2025）"></a>Stage 3：Ralph Loop（2025）</h3><p>第 4 章讲过 Geoffrey Huntley 的 Ralph Loop。它简单得不像话——一个 bash one-liner，把同一个 prompt 文件反复喂给 Agent。真正的创新是纪律：每次迭代把上下文重置到一组锚定文件，不让对话膨胀。Huntley 用它花了大约 297 美元构建了整个编程语言。</p><p>Ralph Loop 是 Loop Engineering 的直接前身。它的核心理念——自指涉、循环到对、固定锚定文件防止漂移——在今天所有的 Loop 实现中都能找到。</p><h3 id="Stage-4：-goal-产品化（2026-春）"><a href="#Stage-4：-goal-产品化（2026-春）" class="headerlink" title="Stage 4：&#x2F;goal 产品化（2026 春）"></a>Stage 4：&#x2F;goal 产品化（2026 春）</h3><p>第 8 章讲过 &#x2F;goal 的趋同演化——Codex、Claude Code、Hermes、Antigravity 四家几乎同时推出。&#x2F;goal 把 Ralph Loop 产品化了：停止条件变成了一等公民（不是&quot;我觉得做完了&quot;，是&quot;所有测试通过&quot;），评判模型负责验收（不是自己给自己打分），预算变成了可配置参数。</p><h3 id="Stage-5：编排式-Loop（2026-现在）"><a href="#Stage-5：编排式-Loop（2026-现在）" class="headerlink" title="Stage 5：编排式 Loop（2026 现在）"></a>Stage 5：编排式 Loop（2026 现在）</h3><p>这是 Boris Cherny 和 Peter Steinberger 实际在做的，也是真正的新东西。四个变化：</p><ol><li><strong>Loop 变成了工作单元</strong>，不再是单个任务。</li><li><strong>Loop 开始监督其他 Loop</strong>，并发地、按时间表地。</li><li><strong>调度取代了人工启动</strong>——Loop 跑在基础设施时间上，不是你的注意力时间上。</li><li><strong>持久化变成显式需求</strong>——git-backed state 和 crash recovery，因为这些东西必须扛过重启。</li></ol><p>Ralph 假设你的终端一直开着。2026 年的版本假设你合上了笔记本。第 4 章的 Ralph Loop 是 Stage 3——单 Agent 的自主循环。本章的 Loop Engineering 是 Stage 5——多 Agent 的编排式循环，跑在 Harness 上面，用 Skills 知识武装，通过 Connectors 触达真实工具。</p><h2 id="12-6-一个完整-Loop-的样子"><a href="#12-6-一个完整-Loop-的样子" class="headerlink" title="12.6 一个完整 Loop 的样子"></a>12.6 一个完整 Loop 的样子</h2><p>把五个必需品加上记忆拼在一起。</p><p>每天早上，一个 automation 在你的 repo 上运行。它的 prompt 调用一个 triage skill，读取昨天的 CI 失败、open issue、最近的 commit，把发现写入一个 markdown 文件或 Linear board。对每个值得处理的发现，Loop 开一个 isolated worktree，派一个 sub-agent 起草修复。第二个 sub-agent 对照项目 skills 和已有测试审查那个草稿。Connectors 让 Loop 开 PR、更新 ticket。处理不了的进 triage inbox 给你。State file 是整个东西的脊柱——它记住尝试了什么、通过了什么、还剩什么，明天早上从今天停下的地方继续。</p><p>回头看：你设计了一次。你没有提示任何一个步骤。这就是 Steinberger 的主张变成现实的样子。而且不管你坐在 Codex 还是 Claude Code 里，Loop 的形状是一样的——因为五个原语是同样的五个原语。</p><h2 id="12-7-Boris-Cherny-的实践"><a href="#12-7-Boris-Cherny-的实践" class="headerlink" title="12.7 Boris Cherny 的实践"></a>12.7 Boris Cherny 的实践</h2><p>Cherny 在 WorkOS 的 Acquired Unplugged 活动上给出了他实际跑的几个 Loop。</p><p><strong>PR babysitter。</strong> 每隔几分钟检查所有 open PR——CI 失败、merge conflict、stale 分支——修安全的，推送更新，标记需要人工的。</p><p><strong>CI health。</strong> 监控 flaky 和 broken 测试，能复现就复现，能修就修或隔离，重跑 CI。</p><p><strong>Feedback clustering。</strong> 每 30 分钟拉新的 Twitter 反馈，按主题聚类，汇总自上次运行以来什么变了。</p><p><strong>Idea mining at scale。</strong> 几百个 Claude 同时读 Twitter、GitHub issue、Slack，找出下一步该做什么。大部分想法是烂的，但 Cherny 说大概 20% 是好的——这就是让它广撒网的意义。</p><p>最强的例子不是他自己的。他指向了 Jarred Sumner（Bun 创始人）做的 Robo Bun——一个有牙齿的生产级 Loop。有人提 GitHub issue → bot 自动触发 → 尝试复现 bug → 写 failing test → 修代码 → 开 PR。PR 必须包含一个在旧版本失败在新版本通过的测试。审查 bot 批评修复，修复 agent 回应，只有这时候人类才决定是否 merge。那不是&quot;让 Claude 修个 bug&quot;——它有证明门（proof gates）。</p><p>Cherny 把底层原语叫&quot;hill climbing&quot;（爬山）。给 Claude 一个目标和一个度量进展的方式，告诉它迭代到完成，它就去爬。Jarred 对它说&quot;make it faster than sharp&quot;，Claude 就跑 benchmark、找瓶颈、改代码、重跑、继续爬到目标。目标 + 度量 + 改变的能力 + 测量的能力 &#x3D; 自主改进循环。</p><p>他给无人值守 Agent 运行数小时或数天列了五条清单：auto mode 开权限让它别再问；dynamic workflows 让它编排成百上千个 Agent；&#x2F;goal 或 &#x2F;loop 让它持续跑；Cloud Claude Code 让你合上笔记本；<strong>最重要的是让它有端到端自我验证的方法</strong>。</p><h2 id="12-8-Peter-Steinberger-的实践"><a href="#12-8-Peter-Steinberger-的实践" class="headerlink" title="12.8 Peter Steinberger 的实践"></a>12.8 Peter Steinberger 的实践</h2><p>Steinberger 的 Loop 走了不同的路，但到同一个地方。他的方法论更简洁，一句话：<strong>每次你发现自己为 Agent 做重复的观察、判断、路由或验证，就建一个工具把那个活交给 Agent。把自己从反馈路径中移除。</strong></p><p>怎么发现这些时刻？Steinberger 的办法是：<strong>哪件事让你烦了，哪件事就该自动化。</strong> 烦躁说明你在做机器该干的活。</p><p>Steinberger 的 Loop 分两层。策略层是 <code>vision.md</code>——项目的宪法，Agent 读它来知道项目想要什么、拒绝什么、往哪推。没有这个文件，Loop 会优化向随机贡献者碰巧要求的东西。行为层是 <code>agents.md</code>，他写不变量。Agent 误解项目时，他不在 chat 里教训它——他把规则写进 instructions，让未来的会话自动继承。有个巧妙的转折：他不是自己写这些 instructions，而是让 Agent 为下一个 Agent 重写指导，然后定期问它文件里什么让人困惑，清理矛盾。Agent 改进控制未来 Agent 的指令。</p><p>他的几个 Loop 展示了范围：</p><ul><li><strong>Issue 和 PR reaper。</strong> Agent 读 vision.md，决定请求是否符合项目方向，然后评论、分组或关闭。至少每周重跑，token 充裕就每天。</li><li><strong>Maintainer report。</strong> 爬 Discord、issue、PR，关联投诉和进行中的工作，挑出人叫得最响的前五件事，对照 vision.md 筛选 Agent 能独立处理的，并行派发。</li><li><strong>Mantis，视频证明 Loop。</strong> Ping Agent 在 PR 上，它启动机器、录 bug 视频、修 bug、录修复视频。Agent 看视频验证，Steinberger 看视频按 merge。这是他整个工具箱里最干净的证明循环。</li><li><strong>Auto Review。</strong> commit 落地前，Codex 用新上下文调 Codex 跑多轮审查，修有效问题直到干净。一行 <code>agents.md</code> 指令触发。</li></ul><p>同一个模式每次重复：他是瓶颈，他烦躁了，他给 Agent 建了个工具让它自己做。</p><h2 id="12-9-Loop-无法替你做的事"><a href="#12-9-Loop-无法替你做的事" class="headerlink" title="12.9 Loop 无法替你做的事"></a>12.9 Loop 无法替你做的事</h2><p>Loop 改变了工作，它没有把你从工作中删除。三个问题随着 Loop 变好变得更尖锐，不是更轻松。</p><h3 id="验证仍然在你身上"><a href="#验证仍然在你身上" class="headerlink" title="验证仍然在你身上"></a>验证仍然在你身上</h3><p>12.3.5 讲了 maker-checker 分离，12.7 的 Robo Bun 展示了 proof gates。这些让 Loop 的&quot;做完了&quot;多少有点意义，但&quot;做完了&quot;终归是声称不是证明。Osmani 一直说同一句话：你的工作是交付你确认能用的代码。</p><h3 id="理解力衰退（Comprehension-Debt）"><a href="#理解力衰退（Comprehension-Debt）" class="headerlink" title="理解力衰退（Comprehension Debt）"></a>理解力衰退（Comprehension Debt）</h3><p>Loop 越快交付你没写的代码，仓库里存在的东西和你真正理解的东西之间差距越大。一个顺畅的 Loop 只是让这个差距长得更快，除非你读 Loop 产出的代码。</p><h3 id="认知投降（Cognitive-Surrender）"><a href="#认知投降（Cognitive-Surrender）" class="headerlink" title="认知投降（Cognitive Surrender）"></a>认知投降（Cognitive Surrender）</h3><p>Loop 自己跑着的时候，很自然地就停止形成意见，接受它返回的任何东西。Osmani 叫它 cognitive surrender。设计 Loop 用判断力是解药，用逃避思考是加速剂——同一个动作，相反结果。</p><p>两个人可以建完全相同的 Loop，得到完全相反的结果。一个用它加速自己深刻理解的工作。另一个用它避免理解工作本身。Loop 不知道区别。你知道。</p><h3 id="一个跑飞的-Loop"><a href="#一个跑飞的-Loop" class="headerlink" title="一个跑飞的 Loop"></a>一个跑飞的 Loop</h3><p>2023 年 AutoGPT 的空转是 Loop 失败最著名的例子。给它一个目标，它反复自我提示，既不报错也不推进，无限循环。GitHub 上几万颗星，但真正跑出结果的很少。这个失败给整个领域烙了将近两年的&quot;Agent 是玩具&quot;标签。</p><p>失败的原因很简单：没有 gate。AutoGPT 没有一个能自动说&quot;这条路走不通，停下来&quot;的机制。它能改代码、能读文件、能执行命令，但没有验证环节，所以它不知道自己做得对不对——于是就一直做下去。12.3.5 讲的 maker-checker 分离和 12.11 讲的 Gate，要解决的正是这个问题。没有验证的 Loop 不是自主循环，是 token 焚烧炉。</p><h2 id="12-10-你真的需要-Loop-吗？"><a href="#12-10-你真的需要-Loop-吗？" class="headerlink" title="12.10 你真的需要 Loop 吗？"></a>12.10 你真的需要 Loop 吗？</h2><p>AlphaSignal AI 在一周的 Loop 狂热后发了一篇冷静的分析。四个条件逐一检查，全部满足才值得。</p><p><img src="/images/image-20260609040705671.png"></p><p><strong>条件 1：任务重复。</strong> Loop 把设置成本分摊到多次运行。一次性的工作，好 prompt 更快更便宜。如果工作不是每周重复，你没有 Loop，你有一个跑了一次的脚本。</p><p><strong>条件 2：验证自动化。</strong> Loop 需要一个能不用你就在场就拒绝差工作的东西——测试套件、类型检查器、linter、build。没有自动检查 &#x3D; 你还是坐在那里读每个 diff，这正是 Loop 本该消除的活。</p><p><strong>条件 3：Token 预算能吸收浪费。</strong> Loop 重读上下文、重试、探索都烧 token，不管这次跑有没有交付东西。这个技术随预算缩放——对 token 几乎免费的人来说它显而易见，对按量计费的人来说它鲁莽。Uber 烧完了年度 AI 预算后对每人每工具月费设了 1500 美元上限。成本中心已经从&quot;写代码&quot;转移到了&quot;管 Agent Loop&quot;。</p><p><strong>条件 4：Agent 已有资深工程师的工具。</strong> 日志、复现环境、运行自己写的代码并看到哪里坏了。没有这些，Loop 在盲迭代。</p><p>四个都回答 yes，值得建。缺一个，你在自动化一个还没准备好被自动化的流程。</p><p>好的首个 Loop：CI 失败分诊、依赖升级 PR、lint-and-fix、flaky test 复现、有强测试代码的 issue-to-PR。坏的第一个 Loop：架构重写、认证&#x2F;支付代码、生产部署、模糊的产品工作、&quot;完成&quot;靠判断的任务。</p><p>如果你是按量计费的独立开发者，等等再说。如果你是团队有自动化测试和能吸收浪费的 token 预算，从小开始。</p><h2 id="12-11-最小可行-Loop"><a href="#12-11-最小可行-Loop" class="headerlink" title="12.11 最小可行 Loop"></a>12.11 最小可行 Loop</h2><p>如果你过了四条件测试，先建最小的那个。四个部分，不要 swarm。</p><p><strong>一个 Automation。</strong> <code>/loop</code> 在 Claude Code，或 automation 在 Codex——按节奏触发、条件停止。两个工具也都暴露了 <code>/goal</code>，它跑到声明的条件为真。</p><p><strong>一个 Skill。</strong> 一个 <code>SKILL.md</code> 存储项目上下文——Agent 不然会每次运行从零推导的东西。</p><p><strong>一个 State 文件。</strong> Markdown 文件或 Linear board，记录做完了什么和接下来做什么，让明天的运行恢复而非重启。Osmani 的规则：Agent 会忘记，仓库不会。</p><p><strong>一个 Gate。</strong> 测试、类型检查或 build，自动拒绝差的工作。这是决定 Loop 帮你还是只花钱的部分。</p><p>顺序很重要：先手动跑通一次 → 转成 Skill → 包进 Loop → 调度执行。一个长期运行的高层 spec（<code>VISION.md</code> 或 <code>AGENTS.md</code>）让 Agent 每次运行时重新读到，防止长 Loop 偏离目标。</p><p>度量每个被接受的变更的成本，不是消耗的 token 或尝试的任务数。</p><h3 id="动手：一个-CI-健康检查-Loop"><a href="#动手：一个-CI-健康检查-Loop" class="headerlink" title="动手：一个 CI 健康检查 Loop"></a>动手：一个 CI 健康检查 Loop</h3><p>用 Claude Code 建一个每 10 分钟检查 CI 的最小 Loop。</p><p><strong>第一步：写 Skill。</strong> 创建 <code>.claude/skills/ci-health.md</code>：</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></pre></td><td class="code"><pre><span class="line">---</span><br><span class="line">name: ci-health</span><br><span class="line"><span class="section">description: 检查 CI 状态，修复失败测试，隔离 flaky 测试</span></span><br><span class="line"><span class="section">---</span></span><br><span class="line"></span><br><span class="line"><span class="section">## 项目上下文</span></span><br><span class="line"><span class="bullet">-</span> 测试命令：npm test</span><br><span class="line"><span class="bullet">-</span> Lint 命令：npm run lint</span><br><span class="line"><span class="bullet">-</span> CI 配置：.github/workflows/ci.yml</span><br><span class="line"></span><br><span class="line"><span class="section">## 规则</span></span><br><span class="line"><span class="bullet">-</span> 只修复有明确错误信息的失败测试</span><br><span class="line"><span class="bullet">-</span> Flaky 测试打 @flaky 标记隔离，不删除</span><br><span class="line"><span class="bullet">-</span> 不动认证和支付相关代码</span><br><span class="line"><span class="bullet">-</span> 修复后必须跑通完整测试套件</span><br></pre></td></tr></table></figure><p><strong>第二步：写 State 文件。</strong> 创建 <code>ci-health-state.md</code>：</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></pre></td><td class="code"><pre><span class="line"><span class="section"># CI Health Loop — State</span></span><br><span class="line"></span><br><span class="line"><span class="section">## 待处理</span></span><br><span class="line">&lt;!-- Loop 每次运行时往这里写发现 --&gt;</span><br><span class="line"></span><br><span class="line"><span class="section">## 已处理</span></span><br><span class="line">&lt;!-- 修完的移到这里，记录 PR 号 --&gt;</span><br></pre></td></tr></table></figure><p><strong>第三步：启动 Loop。</strong> 在 Claude 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></pre></td><td class="code"><pre><span class="line">/loop</span><br><span class="line">Prompt: 用 ci-health skill 检查项目 CI 状态。读 ci-health-state.md 了解之前做过了什么。有失败测试就修，修完跑测试确认。修不了的写到 state 文件的待处理部分。每次运行结束前更新 state 文件。</span><br><span class="line">Interval: 10 minutes</span><br></pre></td></tr></table></figure><p>这就是全部。一个 Skill、一个 State 文件、一条 <code>/loop</code> 命令。跑起来之后观察几轮，确认它做对了再放手。Gate 是测试套件本身——修完必须跑通，跑不通它不会标记为完成。</p><h2 id="12-12-It-s-just-a-cron-job-with-a-hat-on"><a href="#12-12-It-s-just-a-cron-job-with-a-hat-on" class="headerlink" title="12.12 &quot;It&#39;s just a cron job with a hat on&quot;"></a>12.12 &quot;It&#39;s just a cron job with a hat on&quot;</h2><p>对 Loop 最犀利的一句质疑只有四个词：&quot;Cronjobs have funny re-branding rn.&quot;——定时任务现在有了个搞笑的新名字。</p><p>这个质疑值得正面回答，因为它对了一半。对的一半：调度层确实是 cron。Boris Cherny 的 Loop 字面意义上就跑在 cron 上。Claude Code 的 <code>/loop</code> 底下就是 cron。如果你的 Loop 定义是&quot;按时间表运行的东西&quot;，那没错，1975 年就发明了。</p><p>Cron 从来没有的部分是中间那个东西。Cron job 跑固定脚本。Loop 跑一个模型——它看当前状态，决定下一步做什么，做了，检查是否成功，决定是否继续。决策是 Agent 的，不是你的，不是硬编码的分支。堆起来，让一个 Loop 调度和监督其他 Loop，给它们持久的共享状态——你就有了一些 cron 无法表达的东西。</p><p>诚实的说法：<strong>Loop 是 cron 触发 + 一个每次触发后看情况决策的 AI</strong>。真正要花心思的工程，是确保那个 AI 不会跑下悬崖。</p><h2 id="12-13-Loop-与全书方法论的对接"><a href="#12-13-Loop-与全书方法论的对接" class="headerlink" title="12.13 Loop 与全书方法论的对接"></a>12.13 Loop 与全书方法论的对接</h2><p>Loop Engineering 不是孤立的概念。前十一章的方法论在 Loop 里各有各的位置。</p><table><thead><tr><th>方法论</th><th>在 Loop 中的角色</th></tr></thead><tbody><tr><td>第 2 章 Skills</td><td>Loop 内可复用的能力单元——没有 Skills 的 Loop 每次从零推导</td></tr><tr><td>第 3 章 SDD</td><td>Loop 的 Gate 之一——规格一致性检查</td></tr><tr><td>第 4 章 Ralph Loop</td><td>Loop Engineering 的 Stage 3 前身——自指涉、循环到对</td></tr><tr><td>第 5 章 gstack</td><td>Loop 的审查流水线——角色化门控</td></tr><tr><td>第 7 章 autoresearch</td><td>完整的 Loop 实现——多 Agent 轮转 + 双轨门禁</td></tr><tr><td>第 8 章 Goal Workflow</td><td>&#x2F;goal 是 Loop 的条件驱动原语</td></tr><tr><td>第 10 章 Harness</td><td>Loop 坐在 Harness 上一层的抽象</td></tr><tr><td>第 11 章 Kanban</td><td>Loop 运行的可视化追踪——每个卡片对应一个正在跑或等审查的 Loop 实例</td></tr></tbody></table><p>一个完整的 AI 研发体系可以这样看：Harness 提供安全运行环境，方法论提供做事的方法，Kanban 提供可视化编排，Loop 提供自主驱动力。四层拼在一起，你不在的时候 Agent 也能安全、正确、持续地工作。</p><h2 id="12-14-本章小结"><a href="#12-14-本章小结" class="headerlink" title="12.14 本章小结"></a>12.14 本章小结</h2><p>五个原语——Automations、Worktrees、Skills、Connectors、Sub-agents——加一个记忆，搭出一个可信赖的自主循环。Loop 的难度不在 Loop 本身，在于里面放一个能说&quot;不&quot;的东西。没有检查的 Loop 不是自主循环，是 token 焚烧炉。</p><p>两个人建完全相同的 Loop，可以得到完全相反的结果。差异不在工具，在于你是否理解你在自动化什么。Cherny 的观点不是工作变容易了——是杠杆的支点移动了。</p>