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