Loop Engineering 就是反复做这件事

回顾一下自己是如何用AI的：

你让 AI 写一段代码。它写完了。你跑了一下测试，报错了。你把报错信息贴回去，它改了。你再跑，又报错了。你再贴回去，它再改。终于，测试通过了。

这个过程你一定不陌生，它几乎成了每个用 AI 写代码的人的日常。每一轮，都是你亲手把信息喂给 AI，等它响应，检查结果，发现问题，再喂回去。你是一个手动驱动循环的齿轮。

这个循环本身并不复杂。复杂的是你一直在手动推它。

如果你能把循环的每一步（发现问题、提取信息、反馈给 AI、验证结果）都交给系统自动完成呢？你不再需要坐在屏幕前一遍遍复制粘贴报错信息，只需要在开始时设计好这个循环，然后让它自己跑。

2026 年 6 月初，几条发言把这个概念推到了风口上。6 月 2 日，Claude Code 负责人 Boris Cherny 在 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." 五天后的 6 月 7 日，现任职于 OpenAI 的 Peter Steinberger 在 X 上发推——"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents"——24 小时内突破 500 万浏览量。同一天，Google 的 Addy Osmani 发表博文，正式将概念命名为 Loop Engineering。

三天之内，这条推文被转发了上万次。但评论区最有意思的一条是："所以 Loop 到底是什么？"概念的热度和清晰度之间存在巨大落差。

这篇文章试图填上这个落差。我们会从你每天都在做的那个循环出发，由浅入深，分三层讲清楚：Loop Engineering 是什么、怎么设计一个 Loop，以及作为管理者，你该不该现在就投入。

第一层 直觉建立：从手工作坊到自动化工厂

四次抽象跃迁

要理解 Loop Engineering，最清晰的方式是回溯 AI 编程的演进路径。这条路径上有四次关键的抽象跃迁，每一次都解决了一个具体问题，同时也暴露了下一个层次的问题。

第一次跃迁：Prompt Engineering——学会跟机器说话

最早的时候，问题是：AI 能力很强，但你得会说它才听得懂。同样一个需求，有人说"帮我写个登录页面"，有人说"用 React + TypeScript 写一个包含邮箱验证和 OAuth 的登录组件，样式参考 Tailwind 默认主题"——得到的代码质量天差地别。

于是人们开始研究怎么写好 Prompt。少样本示例（Few-shot）、思维链（Chain of Thought）、角色设定（"你是一个资深前端工程师"）——这些技巧的核心，都是在解决同一个问题：如何更精确地把你的意图传递给 AI。

Prompt Engineering 解决的是"表达"问题。但很快，一个更深层的问题暴露了。

第二次跃迁：Context Engineering——让机器看到足够多的东西

你写了一个完美的 Prompt，AI 也给出了不错的代码。但你很快发现：它不知道你的项目用了哪个版本的框架，不知道你已有的工具函数怎么调用，不知道你们团队的代码规范是什么。它给出的代码，单看没问题，放进项目就报错。

问题出在上下文。AI 不是看不懂你的指令，是看不到你的项目。

Context Engineering 应运而生。它的核心是：在 AI 开始工作之前，把所有相关的背景信息送到它眼前。 项目结构、依赖版本、代码规范、历史变更——这些不是写在 Prompt 里的，而是通过文件系统、代码索引、RAG 检索等方式动态注入的。

Google 的 Addy Osmani 对此有一个总结："Context engineering is about making sure the model has the right information at the right time." Claude Code 的 Boris Cherny 也说过类似的话：他们花在优化上下文上的时间，远多于优化 Prompt 本身。

Context Engineering 解决了"信息可见性"问题。但还有一个问题没解决：谁来驱动这个过程？

第三次跃迁：Harness/Hammer Engineering——给 AI 套上缰绳

有了好的 Prompt 和充分的上下文，AI 写代码的成功率大幅提升。但人们很快撞上了新的墙：AI 一次生成的代码，很少能一次通过。它需要反复修改、反复验证。而每一次"修改、验证、再修改"的循环，仍然是你手动驱动的。

2025 年中到 2026 年初，一批工程团队开始系统性地解决这个问题。他们的思路是：与其让人类每次手动把 AI 的输出喂进验证流程，不如写一个脚本，自动完成"AI 生成、验证、反馈、再生成"的循环。 这个脚本就是 Harness——一条套在 AI 身上的缰绳。

Harness Engineering（有时也叫 Hammer Engineering）的核心是设计一个"驱动层"：一个外层脚本或框架，负责调用 AI、执行验证、收集结果、决定是否继续循环。你不再手动跑每一轮，而是写好驱动逻辑，让 Harness 替你跑。

这个概念的正式命名来自 2026 年 2 月。HashiCorp 联合创始人 Mitchell Hashimoto 在《My AI Adoption Journey》一文中首次系统提出了 Harness Engineering 的框架；一周后的 2 月 11 日，OpenAI 官方工程博客正式采用了这个术语。但 Harness 的思想先驱可以追溯到更早：2024 年，SWE-agent 就让 AI 自主在沙箱中浏览代码仓库、编辑文件、运行测试，形成一个闭环；Aider 支持把 lint 错误和测试失败自动反馈给模型，实现"改了再验、验了再改"的自动循环；Devin 的演示更是把这种模式推到了极致，一个 AI 软件工程师，在云端自主完成从理解需求到提交代码的全流程。这些项目是 Harness 思想的先驱实践，只是当时还没有一个统一的名字。

这些项目的共同特征是：它们都把 AI 放进了一个自动循环里，而不是让人在终端里手动来回复制粘贴。LangChain 2026 年 2 月的实验数据也印证了 Harness 的价值：使用 GPT-5.2-Codex 模型，从裸调用换成带 Harness 的架构，Terminal Bench 2.0 的通过率从 52.8% 跳到 66.5%，模型没变，但驱动方式变了，结果就变了。

但 Harness Engineering 有一个根本局限：每个 Harness 都是为特定任务量身定制的。 你的 Harness 懂怎么跑测试，但不懂怎么查日志；另一个 Harness 会做代码审查，但不会做部署。它们是脚本，不是框架。你需要为每种任务写一套新的驱动逻辑，维护成本随任务类型线性增长。

更重要的是，Harness 缺乏一个统一的设计语言。不同团队写出来的 Harness 长得完全不一样，有的是 Python 脚本，有的是 Shell 循环，有的是 YAML 配置。没有共识，没有模式，没有方法论。你很难把一个团队的经验迁移到另一个团队。

第四次跃迁：Loop Engineering——从脚本到系统

Harness 是"我为这个任务写一个脚本"，Loop 是"我设计一个通用系统让任何任务都能跑"。 这就是核心区别。

Loop Engineering 的出现，正是为了解决 Harness Engineering 留下的两个问题：通用性和方法论。

它做了一次关键的抽象：不再问"这个任务需要什么样的脚本"，而是问"一个能自主运行的循环，由哪些要素构成？"

这个抽象的结果，是 Loop 的五要素模型——Automations、Worktrees、Skills、Connectors、Sub-agents。我们会在第二层详细拆解。这里只需要理解一点：Harness 是脚本思维，Loop 是系统思维。 Harness 解决的是"这个任务怎么自动跑"，Loop 解决的是"怎么设计一个通用的、可复用的、可维护的自动循环"。

用 Addy Osmani 的话说："Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

四次跃迁对比

一个类比：手工作坊到自动化工厂

如果用一个更直观的类比来理解四次跃迁：

Prompt Engineering 是手工作坊。师傅（你）亲口告诉学徒（AI）每一步该怎么做。学徒聪不聪明，很大程度上取决于你交代得清不清楚。好的师傅能带出好的学徒，但产出完全依赖师傅的指令质量。

Context Engineering 是标准化车间。你不再只是口头交代，而是把图纸、工艺卡、质量标准都摆在工作台上。学徒来了，所有参考资料都在手边，不需要反复问你"这个零件的公差是多少"。信息标准化了，产出也更稳定。

Harness Engineering 是半自动产线。你给车间装了一台自动检测机，零件加工完，机器自动检测，不合格的自动退回重做。但你只装了这一台：检测机能跑测试，但不能查日志；能验证功能，但不能审查代码风格。每换一个工序，你就得加装一台新机器，调试一套新参数。车间越来越忙，你的维护工作也越来越重。

Loop Engineering 是自动化工厂。你不再是一台台加装机器，而是设计了一整套流水线系统：原材料进来，经过加工、检测、返工、再检测，合格品出来。更关键的是，这条流水线是模块化的，检测模块可以替换，加工模块可以插拔，不同任务只需要调整配置，不需要从零搭建。你的工作从"加装机器"变成了"设计系统"。

每一次跃迁，都不是否定前一次，而是在前一次的基础上叠加。自动化工厂仍然需要标准化的工艺卡（Context Engineering），仍然需要清晰的加工指令（Prompt Engineering），也仍然需要自动检测机（Harness Engineering）。只是，你不再需要站在产线旁边，一台台加装和维护机器了。

为什么是现在？

一个自然的问题是：这个想法并不新鲜，自动化测试、CI/CD、定时任务，这些不都是"循环"吗？为什么偏偏是现在，Loop Engineering 成了一个独立的概念？

要回答这个问题，需要看到一条更长的技术验证链。

2022 年底到 2024 年初，AI 编程工具的主战场还在 Prompt Engineering。ChatGPT 出圈后，人们忙着研究怎么写更好的指令，涌现了各种技巧——思维链、少样本示例、角色设定。GPT-4 的发布更是证明了好的 Prompt 能显著提升代码质量。但一个共识也在形成：光靠写好 Prompt，解决不了 AI 看不到项目全貌的问题。

2025 年中，Context Engineering 成了新焦点。Shopify CEO Tobi Lütke 公开推动了这个概念的流行；Cursor 的 Composer 模式、Claude 的 CLAUDE.md 文件、Windsurf 的 Cascade，这些工具的核心创新都不是"更好的 Prompt"，而是"更好的上下文注入"；Anthropic 也在 2025 年 9 月正式发布了 Context Engineering 最佳实践。AI 终于能看到你的项目结构、代码规范和依赖关系了。但每一轮"改了、验了、再改"的循环，还是你在手动推。

2026 年 2 月，Harness Engineering 正式命名。Mitchell Hashimoto 在《My AI Adoption Journey》中首次系统提出框架，OpenAI 官方工程博客一周后正式采用。但 Harness 的思想先驱早已在跑，SWE-agent、Aider、Devin 在 2024 年就验证了一个关键假设：AI 放进自动循环里，真的能跑通。 Harness 时代把它们从"有趣的项目"变成了"可复现的方法"。但问题也暴露了：每个 Harness 都是定制的，不可复用，不可组合。

2026 年 6 月 2 日，Boris Cherny 在 Acquired Unplugged 活动上说了那段话："My job is to write loops." 五天后的 6 月 7 日，Steinberger 的推文和 Osmani 的博文同日引爆全网。Loop Engineering 正式从一个零散的想法，变成了一个有名字、有框架、有讨论的概念。

与此同时，工具链和成本条件也已成熟。Claude Code、Codex、Cursor Agent 等工具把文件操作、终端执行、代码索引整合到了统一界面里。Token 价格比两年前降了两个数量级。模型能力也到了一个临界点，Claude Opus 4.8、GPT-5.5、Gemini 3.1 Pro 在代码修改任务上的成功率，让"让 AI 自主循环"从理论可能变成了工程可行。Claude Code 已经贡献了 GitHub 上约 4% 的公开 commit；Boris Cherny 自己过去 30 天的战绩是 259 个 PR、497 次 commit、4 万行新增代码，100% 由 Claude Code 编写。他甚至在 2025 年 11 月删了自己的 IDE，至今没重新打开过。

三线交汇，模型能力、工具链、成本，加上三年多的技术验证链，Loop Engineering 的时机到了。

第二层 机制拆解：设计一个 Loop 到底要做什么

第一层我们建立了直觉：Loop Engineering 是从"手动推循环"到"设计自动循环系统"的跃迁。但直觉只是起点。如果你真的要设计一个 Loop，需要回答一个具体的问题：一个能自主运行的循环，到底由哪些零件组成？

Addy Osmani 在他的博文中给出了一个答案：Loop 的五要素模型。这五个要素不是随意罗列的，每一个都对应着 Loop 运行中一个真实存在的瓶颈。理解瓶颈，就理解了要素存在的理由。

五要素拆解

1. Automations：让循环自己启动

Loop 的第一个瓶颈是启动。如果你每次都要手动触发，"好了，现在让 AI 跑一轮"，那你还是那个齿轮。Automations 解决的就是这个问题：让循环在没有人类干预的情况下自己启动。

Automations 有两种典型形态：

• 定时触发（Heartbeat）：每隔固定时间跑一轮。比如每天凌晨 2 点，AI 自动扫描所有依赖的安全漏洞，发现新 CVE 就自动升级并跑测试。你早上起来看到的不是一堆待处理的告警，而是一份"已修复 + 测试通过"的报告。
• 事件触发（Webhook）：当某个事件发生时启动循环。比如 GitHub 收到一个 Issue，自动触发一个 Loop：AI 读取 Issue，定位相关代码，生成修复，跑测试，提交 PR。整个过程不需要你点任何按钮。

Automations 是 Loop 的"心跳"，没有它，Loop 就是一个需要人工启动的脚本，跟 Harness 没有本质区别。

2. Worktrees：让循环不会踩自己的脚

Loop 的第二个瓶颈是隔离。当 AI 自主修改代码时，它可能同时影响多个功能。如果所有修改都在同一个分支上进行，一个改坏就会污染整个工作区。更麻烦的是，如果你想让 AI 同时修三个 bug，它们之间可能互相冲突。

Worktrees 借用了 Git 的 worktree 概念：为每个任务创建一个独立的工作区，互不干扰。 AI 在 worktree A 上修 bug A，在 worktree B 上修 bug B，两个修改并行进行，互不影响。修完之后，各自跑测试，各自提交 PR，最后由人类决定是否合并。

这听起来像是 Git 分支的常规操作，但关键区别在于：分支的创建和切换是由 Loop 自动管理的，不需要你手动 git checkout -b。 你只说"修这三个 bug"，Loop 自己分配 worktree、自己切换、自己合并。

Worktrees 是 Loop 的"隔离舱"，没有它，并行任务会互相踩踏，Loop 跑得越快，混乱越大。

3. kills：让循环越来越懂你的项目

Loop 的第三个瓶颈是项目知识。每次循环启动时，AI 都需要理解你的项目规范、技术栈偏好、代码风格。如果这些信息每次都要从零注入，Loop 的效率会极低，就像一个新员工每天上班都要重新学习公司规范一样。

Skills 是项目知识的固化载体。它把"我们用 Jest 做测试"、"API 响应遵循 { code, data } 格式"、"数据库迁移必须走 Flyway"这些隐性知识，显式地存储在 Loop 可以随时调用的地方。常见的 Skills 实现形式包括：

• CLAUDE.md / AGENTS.md：项目根目录的 Markdown 文件，记录项目规范和约定。AI 每次启动时自动读取。
• 自定义指令集：针对特定类型任务（如"写 API 接口"、"做数据库迁移"）的标准化步骤和检查清单。
• 示例代码库：AI 可以参考的"正确写法"样本，避免每次都从零摸索。

Skills 是 Loop 的"肌肉记忆"，没有它，Loop 每一轮都在重新学习，效率无法累积。有了它，Loop 越跑越懂你的项目，越跑越快。

4. Connectors：让循环能触碰真实世界

Loop 的第四个瓶颈是行动能力。AI 可以生成代码，但如果它不能执行测试、不能操作 CI/CD、不能读写数据库，那它就只是一个"能写代码但不能验证代码"的文本生成器。每一轮循环的"验证"环节，还是得你手动来做。

Connectors 是Loop 与外部工具的接口。它们让 AI 能够：

• 执行终端命令（运行测试、启动服务、查看日志）
• 读写文件系统（修改代码、生成配置）
• 调用 API（触发 CI/CD、更新 Jira、发送 Slack 通知）
• 访问数据库（查询数据、验证迁移结果）

Connectors 是 Loop 的"手和脚"，没有它，Loop 只能"想"不能"做"，仍然是一个需要人类替它动手的半成品。

5. Sub-agents：让循环自己检查自己

这是 Loop 最容易被忽略、也最危险的瓶颈。如果 AI 既写代码又审代码，那它就是在自己给自己打分，它看不到自己的盲点。更具体地说：一个 AI 刚花十分钟写了一段复杂的逻辑，你让它"检查一下有没有 bug"，它大概率会说"看起来没问题"，因为它刚写完，对自己写的代码有天然的确认偏误。

Sub-agents 的核心思想是制造者与检查者的分离。一个 Agent 负责生成代码（Builder），另一个 Agent 负责审查代码（Reviewer）。它们使用同一个模型，但带着不同的指令和上下文：

• Builder 的上下文：需求描述 + 项目规范 + 代码库
• Reviewer 的上下文：Builder 的产出 + 测试结果 + 代码审查清单

这种分离不是多余的，它模拟了真实工程团队中的 Code Review 机制。你不会让写代码的人自己审自己的 PR，同样，你也不应该让生成代码的 Agent 自己审查自己的产出。

但 Maker-Checker 有一个被忽视的盲区：如果 Builder 和 Reviewer 用的是同一个底模，它们的盲区高度重合。 Builder 看不出来的 off-by-one 错误，Reviewer 也大概率看不出来。有人实测过：让 Agent A 写代码、Agent B 验收，结果 B 把 A 的"看上去对其实有边界错误"的代码全都标了 PASS。两个 LLM 一起自我感觉良好。

解决思路有两条：用不同模型当 Checker（比如 Builder 用强模型，Reviewer 用另一个厂商的模型），或者用规则引擎和单元测试当硬验收，不依赖 LLM 的判断力。

Sub-agents 是 Loop 的"质检员"，没有它，Loop 就是一个没有质量把关的流水线，速度越快，次品越多。

第六个要素：Memory——跨循环的记忆

Addy Osmani 的五要素模型覆盖了 Loop 运行中的核心组件，但在实践中还有一个要素经常被提及：Memory——跨循环的记忆。

为什么需要 Memory？因为 Loop 不是跑一次就结束的。它可能每天跑一次，持续运行几周甚至几个月。在这个过程中，它需要记住：

• 上次跑到哪了：昨天扫描到第 47 个文件，今天从第 48 个继续
• 什么方案失败了：上次尝试用方案 A 修复 bug #123，测试没通过，这次应该换方案 B
• 项目的变化：上周重构了用户模块，相关的测试用例需要更新

没有 Memory 的 Loop，就像一个每天失忆的员工——每天重新学习、重复犯错、从零开始。有了 Memory，Loop 才能真正"越跑越聪明"。

Memory 的实现方式目前还在探索中。最简单的形式是文件持久化——把状态写到本地文件，下次循环时读取。社区里流行的 Ralph Loop 就是这种极简实现：一行 Bash 死循环，状态存文件而非 LLM 内存。更复杂的形式包括向量数据库检索、会话历史压缩等。Memory 不是五要素之一，但它是让 Loop 从"能跑"变成"跑得好"的关键变量。

Loop 的解剖结构

五要素模型回答的是"设计 Loop 需要哪些零件"，但 Loop 运行时到底经历了什么？每一轮循环内部，信息是怎么流动的？这需要从另一个视角来看。

大多数现代 AI 编程 Agent 的循环逻辑，都可以追溯到 2022 年 Princeton 和 Google 联合提出的 ReAct 模式（Reason + Act）。它的核心思想很简单：让模型交替进行推理和行动。 模型先想清楚该做什么（Reason），然后执行一个动作（Act），观察结果，再想，再做，循环往复。

在代码生成的场景下，ReAct 模式展开来就是：理解目标、写代码、跑代码观察输出或报错、分析哪里出了问题、修改代码重新运行、重复直到测试通过或任务完成。

这个"推理、行动、观察、再推理"的循环，就是 Loop Engineering 的运行时骨架。但骨架只是起点，一个真正能跑的 Loop，需要在骨架上装配五个关键组件。

组件一：Goal——目标定义

Loop 需要知道"完成"长什么样。没有终止条件，Agent 要么永远跑下去，要么在某个随机的时刻停下来，两者都是灾难。

好的目标定义有三个特征：

• 具体到可以评估："让所有单元测试通过"是好的目标，"让代码更好"不是
• 尽可能拆成可测试的子任务："修复用户无法保存含撇号的公司名"比"修复保存 bug"更可操作
• 限定范围，防止过度扩展：明确哪些文件可以改、哪些不能碰

目标定义的质量直接决定了 Loop 的效率。一个模糊的目标会让 Agent 在错误的方向上浪费大量 token；一个精确的目标则能让每一轮迭代都朝着正确的方向收敛。

组件二：Tools——工具集

Loop 只有在 Agent 能与真实环境交互时才有意义。如果 Agent 只能生成文本而不能执行代码、不能读写文件、不能运行测试，那它就只是一个"纸上谈兵"的循环，每一轮都在猜测，而不是在验证。

对于编程 Agent，典型的工具集包括：代码执行（运行代码，获取 stdout/stderr）、文件系统访问（读、写、修改文件）、终端/Shell（执行命令行操作）、搜索与文档查找（查找 API 文档、错误解释）、测试运行器（验证代码正确性）。

工具集的质量直接决定 Loop 的能力上限。一个只能读写文件的 Agent，和一个能执行代码、查询数据库、调用 API 的 Agent，在同样的循环逻辑下，产出天差地别。正如 MindStudio 的文章所说："如果 Agent 不能运行自己写的代码，Loop 就只是在猜。"

组件三：Context——上下文管理

每一轮循环都会产生新的上下文：写过的代码、遇到的报错、做过的决策。如果不加管理，你会很快撞上两个问题：

• Token 溢出：上下文窗口被塞满，模型开始"遗忘"早期的关键信息
• 信息淹没：大量无关的历史细节占据了注意力，模型反而看不清当前要解决的核心问题

好的上下文管理包括三种策略：

• 压缩历史：把前几轮的完整交互记录，压缩成一段简短的工作记忆。比如："尝试了方案 A（失败：TypeError），尝试了方案 B（失败：同类错误），尝试了方案 C（部分成功：错误解决但第 47 行测试仍失败）。"这段话比三轮完整的对话记录有用得多。
• 结构化日志：用固定格式记录每一轮的动作和结果，而不是让模型从自由文本中提取信息。
• 按需刷新：在关键观察之后重新加载上下文，而不是一直带着可能已经过时的信息往前跑。这在多人协作的代码库中尤其重要——你不知道 Loop 运行期间有没有人改了同一个文件。

组件四：Termination Logic——终止逻辑

Loop 必须知道什么时候停下来。这包括三类条件：

• 成功条件：测试通过、输出匹配预期、用户确认
• 失败条件：达到最大迭代次数、连续多次无进展、工具调用失败
• 升级路径：卡住时移交给人类或另一个更强大的 Agent

终止逻辑是 Loop 最容易被忽视的组件。很多人在设计 Loop 时，花大量时间优化 Prompt 和上下文，却只给终止逻辑留一行"测试通过就停"。

一个好的终止逻辑需要回答：如果 Agent 连续 5 轮修改同一行代码但测试仍然失败，该怎么办？如果 Agent 的修改让之前通过的测试开始失败，该怎么办？如果 Agent 消耗的 token 已经超过了预算的 80% 但只完成了一半任务，该怎么办？这些问题的答案，就是终止逻辑的设计依据。

还有一个更棘手的问题：软目标怎么办？ "写测试、通过测试"这种硬目标很容易写终止条件。但很多场景的目标本身就是软的："把这篇文章写得让人愿意读完"、"判断这个方案值不值得做"、"输出一份让老板满意的周报"。有人试过用 LLM 当 judge 给软目标打分（>0.7 就停），但两个 LLM 互打分会漂移，上午 0.85，下午同样的输出 0.6。软目标的终止条件目前没有好解法，一个务实的做法是：如果目标不可验证，就显式标注"这是计划级/我无法验证"，不让 Loop 假装"完成了"。

组件五：Error Recovery——错误恢复

错误是 Loop 中的常态，不是异常。一个好的 Loop 不是"不出错"，而是"出错后知道怎么办"。

错误恢复需要区分两类问题：

• 可恢复错误：语法错误、缺少 import、类型不匹配，这些可以通过修改代码解决
• 硬阻塞：缺少凭据、未定义的行为、需求不明确，这些 Agent 自己解决不了，需要升级给人类

更关键的是，Loop 需要避免一种最危险的错误恢复模式：用同样的方式重试同样的失败。 一个 Agent 在第 3 轮和第 5 轮用了完全相同的修改策略，两次都失败了，然后在第 7 轮又用同样的策略，这不是恢复，是空转。真正的错误恢复意味着：每次失败后，策略必须有所调整。 换一种修法、缩小修改范围、回滚到上一个已知正确的状态、或者干脆承认这个任务需要人类介入。

组件六：Guardrails——护栏

把 Guardrails 从 Termination Logic 和 Error Recovery 中拆出来单独讲，是因为它管的不只是"什么时候停"和"出错怎么办"，还有一层更隐蔽的问题：怎么防止 Loop 在看起来正常的情况下悄悄失控。

护栏分两类，管的事完全不同：

资源类护栏：迭代次数封顶、token 预算上限、无进展检测（连续 N 轮输出无变化则暂停）。这些应该焊死在 Loop 框架里，不留开关。理由很简单：资源红线没有商量的余地。我就见过有人忘了启用可插拔的预算限制，一晚上烧了几十美元的测试 token。

认知类护栏：不让 AI 胡编、不让它遗忘关键上下文、不让它污染自己的记忆。这些更适合做成可插拔的独立层，因为认知红线需要随项目迭代调整，今天认为安全的输出范围，明天可能不够。

两类护栏的分歧点在于：资源类该写死，认知类该可插拔。把两者混在一起，要么全写死导致改不动，要么全可插拔导致忘了开。

组装视角

凌晨 2 点，Automation 的定时心跳触发了今天的巡检任务（Goal）。AI 被唤醒，从 Skills 和 Memory 中加载项目规范和历史状态（Context），通过 Connectors 访问代码库和终端（Tools），在独立的 Worktree 中开始工作。它修了一个 bug，跑测试，没通过。Sub-agent 的 Reviewer 角色介入，分析失败原因，把反馈传回 Builder。Builder 换一种修法，再跑测试，通过了。Termination Logic 判断循环可以结束，提交 PR。如果中途出了意外（比如连续 5 次失败），Error Recovery 机制启动：回滚变更，通知人类。

结合起来看：

• Automations 对应 Goal + Termination Logic（什么时候启动、什么时候停）
• Connectors 对应 Tools（能做什么）
• Skills + Memory 对应 Context（知道什么）
• Worktrees + Sub-agents 对应 Error Recovery（出错时如何隔离和纠正）
• Guardrails 贯穿所有组件（资源类守住底线，认知类防止跑偏）

这就是一个完整的循环。五要素是零件，解剖结构是流程，Loop 模式是不同的组合方式，接下来我们看这几种组合。

四种常见的 Loop 模式

理解了 Loop 的零件，下一个问题是：这些零件怎么组合？不同的任务需要不同的循环逻辑。目前社区中形成了几种常见的 Loop 模式，每种模式适用于不同的场景，也有各自的陷阱。

模式一：Retry Loop——最简单的循环

逻辑：AI 生成，验证，失败则反馈错误信息，AI 重新生成，再验证，直到通过或达到最大重试次数。

这是最原始的 Loop，也是大多数人第一次接触 Loop Engineering 时自然会想到的形式。它的核心是"错了就再来一次"。

适用场景：修 bug、修 lint 错误、修测试失败，目标明确、验证标准清晰的任务。

陷阱：Thrashing（空转）。如果 AI 的修改方向一直是错的，Retry Loop 不会自己发现，它只会一遍遍用同样的思路重试，消耗 token 却毫无进展。一个典型的信号是：连续三轮修改，测试失败的行号几乎没变。这时候应该中断循环，换一种思路，而不是继续重试。

实战建议：设置最大重试次数（通常 3-5 次），超过后自动切换到更保守的策略或请求人类介入。

模式二：Plan-Execute-Verify——先想再做再查

逻辑：AI 先制定计划（Plan），按计划逐步执行（Execute），执行完后验证整体结果（Verify），验证失败则回到计划阶段调整。

Retry Loop 的问题是"边做边想"，容易陷入局部最优。Plan-Execute-Verify 增加了一个"先想清楚"的阶段，让 AI 在动手之前先规划好步骤。

适用场景：跨多文件的重构、新功能开发、架构调整，需要多步操作、前后有关联的任务。

陷阱：Overfitting to Tests（过拟合测试）。AI 可能会为了让测试通过而"作弊"，比如直接 hardcode 测试用例的期望值，而不是真正修复逻辑。Verify 阶段如果只看测试是否通过，而不检查代码质量，就会放过这类问题。

实战建议：Verify 阶段不仅跑测试，还要做代码审查（用 Sub-agent 的 Reviewer 角色），检查实现是否合理，而不仅仅是结果是否正确。

模式三：Explore-Narrow——先广后深

逻辑：AI 先广泛探索代码库（Explore），理解整体结构和依赖关系，缩小范围定位到关键代码（Narrow），在关键代码上进行修改。

这个模式的洞察是：很多 bug 的根因不在报错的位置，而在看似无关的其他模块。如果 AI 一上来就盯着报错行改，很可能治标不治本。

适用场景：复杂的 bug 排查、性能优化、安全漏洞定位，根因不确定、需要先理解全局的任务。

陷阱：Context Drift（上下文漂移）。探索阶段如果耗时过长，AI 可能会"走神"，读了太多代码，忘了最初要解决什么问题。它的上下文窗口被大量无关信息占据，最终给出的方案反而不如直接从报错行入手。

实战建议：给探索阶段设置明确的时间或 token 预算，超时后强制进入 Narrow 阶段。同时在每一步都提醒 AI 当前要解决的核心问题。

模式四：Human-in-the-Loop——关键节点的人类把关

逻辑：Loop 自动运行，但在特定节点暂停，等待人类确认后再继续。比如：AI 生成方案，人类确认方向，AI 执行，人类确认结果，AI 提交。

这不是一种独立的模式，而是对以上任何模式的增强。它的核心思想是：不是所有决策都应该交给 AI。 在高风险节点（删除数据、修改核心逻辑、发布到生产环境），人类的判断仍然不可替代。

适用场景：几乎所有生产环境的 Loop 都应该至少在关键节点加入人类确认，尤其是涉及数据变更和发布操作的。

陷阱：Cognitive Surrender（认知投降）。这是 Human-in-the-Loop 最危险的陷阱，人类面对 AI 的方案，倾向于直接点"确认"，而不是认真审查。原因很简单：审查需要思考，点确认不需要。久而久之，Human-in-the-Loop 名存实亡，变成了"Human-watching-the-Loop"。

实战建议：在人类确认环节提供结构化的决策辅助，不是只问"确认吗？"，而是列出"这次修改了什么、影响了哪些模块、测试结果如何、有什么风险"，让人类做的是"判断"而不是"阅读理解"。

这四种陷阱看似各不相同，但它们有一个共同的根源：Loop 在没有人类判断的情况下做了不该做的事。 空转是 Loop 在没有判断方向对错的情况下继续跑；过拟合是 Loop 在没有判断实现质量的情况下只追求测试通过；漂移是 Loop 在没有判断信息相关性的情况下持续探索；认知投降是人类在放弃判断。记住这个统一视角，比记住每种陷阱的名字更重要，因为未来一定会出现新的陷阱，但它们的根因大概率还是同一个。

多 Agent 协作拓扑：四种模式之外的拼法

前面四种模式讲的是单个 Loop 的循环逻辑。但实际项目中，你经常需要多个 Agent 协作。怎么编排它们，取决于任务的特征。目前社区里常见的有六种拓扑，除了前面已经覆盖的顺序流水线和协调者-工作者模式，还有两种值得单独讲：

扇出合并

把一个任务拆成多个子任务，分发给多个 Agent 并行执行，最后合并结果。比如给文章纠错，找两个 Agent 各自挑刺，再合并去重，比单个 Agent 挑出来的问题更多。这个拓扑的适用场景是：任务可以自然拆分，且子任务之间互不依赖。

辩论对抗

让两个 Agent 分别扮演正方和反方，互相挑战对方的结论，期望通过对抗逼近更可靠的判断。听起来很美，但实战中有一个反直觉的失效模式：两个 Agent 互相说服，越聊越自信，最后一致同意一个错误的结论。对抗没有带来纠偏，反而带来了"双重确认偏误"。有人试过用辩论对抗做风险评估，结果比单 Agent 更糊涂。

这两种拓扑的对比说明一个道理：多 Agent 不等于多可靠。 协作拓扑选错了，Agent 越多越乱。扇出合并适合可拆分的任务，辩论对抗适合有明确事实标准的判断，但如果判断本身依赖主观评估，对抗反而会放大偏差。

Ralph Loop：极简主义的启示

在所有 Loop 实现中，有一个社区项目值得单独提一提：Ralph Loop。

它的核心代码大概长这样：

while true; 
do  
  claude "Fix the next failing test" 2>&1 | tee -a loop.log
  if npm test 2>&1 | grep -q "0 failing"; then
     echo "All tests passing!" | tee -a loop.log
     break  
  fi
  sleep 5
done

一行 Bash 死循环，状态存文件，没有向量数据库，没有 MCP 协议，没有 Sub-agent。它甚至不配被称为一个"框架"——它就是一个脚本。

但 Ralph Loop 的价值恰恰在于它的极简。它证明了一件事：Loop Engineering 不等于复杂工程。 你不需要等五要素全部就位才能开始。一个最简单的 Retry Loop，只要终止逻辑清晰，就能解决实际问题。

Ralph Loop 的启示是：先跑起来，再优化。 不要被五要素的框架吓到，你可以从 Ralph Loop 开始，体验 Loop 的体感，再根据实际痛点逐步添加 Automations、Worktrees、Skills 等组件。Loop Engineering 是一个渐进式的工程实践，不是一步到位的架构重构。

第三层 决策框架：Loop 是加速器还是麻醉剂

前两层我们回答了"Loop Engineering 是什么"和"怎么设计一个 Loop"。但如果你是技术管理者，你还有一个更根本的问题：我该不该现在就投入？

落地现状：三款产品的 Loop 能力对比

在进入决策框架之前，先看看 Loop Engineering 目前的产品落地情况。五要素和 Loop 模式讲的是"应该怎么设计"，但实际产品实现时，每个工具的 Loop 成熟度差异很大。目前最值得关注的三款产品，恰好代表了三种截然不同的 Loop 落地路径。

Claude Code：Loop 是一等公民。Boris Cherny 本人就是 Loop Engineering 概念的提出者，所以 Claude Code 的 Loop 实现最贴合概念原意。/loop 命令的三种模式（指定间隔、智能、维护）覆盖了从简单定时任务到自主巡逻的完整场景。/goal 命令更是把"跑到条件满足为止"做成了原生能力，一个独立的小模型检查你是否完成，生成代码的 Agent 不是给自己打分的 Agent。代价是模型绑定（仅 Claude 系列）和较高的 token 成本。

Codex：云端并行能力最强，但 Loop 需自行搭建。Codex 没有原生的 /loop 命令，它的 Loop 逻辑需要通过 Triggers 自动化流水线 + Agent Loop 自行搭建。但 Codex 的独特优势在于：云端沙箱可以同时跑几十个 Agent，不需要操心本地资源；Chronicle 功能定期截屏生成上下文记忆，是三款工具中最先进的 Memory 实现。代价是代码在 OpenAI 服务器上运行，对数据安全敏感的团队需要评估风险。

OpenCode：自由度最高，Loop 是自己组装的。OpenCode 没有任何原生的 Loop 支持，但它的架构为自行搭建 Loop 提供了最大的自由度：Plan/Build 双模式天然对应 Loop 的"规划"和"执行"阶段；LSP 深度集成提供精准的错误定位，比纯文本输出更适合 Loop 的验证环节；75+ 模型切换让你在简单任务用便宜模型、复杂任务用强模型，在成本和效果之间做精细权衡。但所有这些都需要你自己组装，OpenCode 更像是一套"Loop 的零件箱"，而不是一个"开箱即用的 Loop"。代价是配置功力要求高，没有 Claude Code 那种"输入 /loop 就跑起来"的体验。

成本公式：Loop 的经济学

Loop Engineering 不只是工程问题，也是经济问题。每一次循环都在消耗 token，而 token 是真金白银。在设计 Loop 之前，你需要算清楚一笔账。

基础公式：单次 Loop 成本 = 平均迭代次数 × 单次迭代 token 消耗 × token 单价 × 并行实例数

我们用一个具体场景来算：假设你的团队要修一批 bug，每个 bug 平均需要 3 轮迭代才能通过测试。每轮迭代平均消耗 50,000 token（包括上下文注入、代码生成、测试执行反馈）。使用 Claude Opus 4.8，输入 token 单价约 $15/百万，输出 token 单价约$75/百万。假设输入输出各占一半，平均 token 单价约 $45/百万。

• 单次迭代成本：50,000 × $45/1,000,000 = $2.25
• 单个 bug 的 Loop 成本：3 × $2.25 = $6.75
• 如果同时跑 5 个并行 Loop：$6.75 × 5 = $33.75

一天跑 20 个 bug，月成本约 $20,250。对比一个初级程序员的月薪（以硅谷中位数约 $8,000 计），Loop 的成本大约是一个初级程序员月薪的 2.5 倍，但 Loop 可以 24 小时不停歇地跑，实际产出可能远超一个人。

但这只是理想情况。现实中，Loop 经常会遇到 Thrashing（空转），一个 bug 可能需要 10 轮甚至 20 轮才能通过，成本线性飙升。如果终止逻辑设计不好，一个 Loop 可能跑了一整天都在原地打转，消耗了几百美元的 token，最后还是需要人类介入。

所以更现实的成本公式应该是：实际月成本 = 基础成本 × Thrashing 系数

Thrashing 系数取决于你的 Loop 设计质量——Skills 是否充分、终止逻辑是否清晰、Sub-agent 是否到位。一个设计良好的 Loop，Thrashing 系数可能在 1.5-2 之间；一个设计粗糙的 Loop，系数可能飙到 5 甚至 10。

但这里有一个容易混淆的地方：上面算的 $20,250/月是规模化场景的成本，一天修 20 个 bug、5 个并行 Loop。而大多数团队刚开始尝试 Loop 时，不会一上来就跑这么大规模。所以需要区分两个阶段：

试点阶段（1-2 个简单场景，如自动修 lint 错误、自动修测试失败）：月均成本通常在 $500-$2,000 之间。这个阶段的目标不是省钱，而是验证 Loop 在你的项目中能不能跑通、Skills 够不够用、终止逻辑需不需要调优。

规模化阶段（多场景并行，覆盖 bug 修复、功能开发、代码审查等）：月均成本 $5,000 起，上不封顶。这个阶段的目标才是用 Loop 替代重复性的人工劳动，实现成本节约。

决策参考：月均 API 费用超过 $1,000 的团队，可以从试点阶段开始，因为你的 token 消耗已经到了需要系统化管理的规模，Loop 的试点成本不会比你现在手动操作的浪费更多。月均低于$1,000 的团队，手动操作的成本还低于 Loop 的搭建成本，优先积累 AI 编程经验。

三大风险：Loop 越顺滑，危险越大

成本是显性的，风险是隐性的。Loop Engineering 最反常识的地方在于：Loop 跑得越顺滑，你可能越危险。 因为顺滑会给你一种"一切尽在掌控"的错觉，而实际上你可能正在失去对代码的理解和控制。

Addy Osmani 在他的博文中提出了三个关键风险概念。

风险一：Comprehension Debt——理解债务

Loop 替你写了大量代码，但你并没有真正理解这些代码。时间一长，你的代码库里有大量"你知道它能跑，但不知道它为什么能跑"的部分。

理解债务本身不会让系统崩溃——直到有一天你需要修改那些 Loop 生成的代码。这时候你会发现：你看不懂它，改不动它，甚至不敢动它。你欠下的"理解"债务，在需要变更时一次性偿还，利息极高。

真实场景：Loop 跑了一周，修了 30 个 bug，提交了 200 次代码变更。每个变更单独看都没问题，测试也通过了。但当你需要做一个涉及多个模块的架构调整时，你发现 Loop 生成的代码风格不一致、命名不规范、抽象层次混乱，你花了比手写多三倍的时间来理解和重构。

应对：Loop 生成的代码必须经过人类 Code Review，不能因为"测试通过了"就跳过；定期做"代码审计日"——不写新代码，专门阅读和重构 Loop 生成的代码；在 Skills 中强制规定代码风格和架构约定，减少 Loop 的"自由发挥"空间。

风险二：Cognitive Surrender——认知投降

你不再审查 Loop 的输出，只是机械地点"确认"。不是因为输出一定正确，而是因为审查太累了，而 Loop 的输出"看起来总是对的"。

认知投降是最隐蔽的风险，因为你不会意识到自己已经投降了。你仍然在"审批" Loop 的每一次产出，但你的审批已经变成了条件反射，就像每天早上刷手机，手指在滑动，但眼睛已经不在看了。

真实场景：你的 Loop 每天自动提交 5 个 PR，你每个都点了 Approve。前 20 个确实没问题。第 21 个有一个微妙的边界条件 bug，你没看出来。第 22 个引入了一个安全隐患，你还是没看出来。因为你的大脑已经建立了一个模式："Loop 的 PR = 没问题的 PR"。

应对：在人类确认环节提供结构化决策辅助，降低审查的认知负担；随机抽检：不审批每一个 PR，但随机抽取 20% 做深度审查，让"可能被抽到"的压力维持你的注意力；设置"红色按钮"：Loop 运行超过一定时间或消耗超过一定 token，自动暂停并强制人类审查。

风险三：Verification Gap——验证缺口

Loop 的验证手段覆盖不了所有可能的错误类型。测试能验证功能正确性，但验证不了性能退化、安全漏洞、用户体验退化。

Loop 的终止逻辑通常基于测试通过。但"测试通过"≠"代码没问题"，它只意味着"你想到要测的那些方面没问题"。你没测到的方面，Loop 不会主动告诉你。

真实场景：Loop 修了一个 API 的 bug，测试全部通过。但它不知道这个 API 的响应时间从 50ms 变成了 500ms，因为你的测试只验证了功能，没有验证性能。用户先于你发现了这个问题，在凌晨的报警短信里。

应对：在 Verify 阶段加入非功能性检查：性能基准测试、安全扫描、Linter 规则；建立"回归测试金字塔"：单元测试、集成测试、性能测试、安全扫描，每一层都作为 Loop 的终止条件之一；对于关键模块，设置"变更影响分析"——Loop 修改代码后，自动评估影响范围，超出阈值则暂停。

争议：真突破还是新瓶装旧酒？

在讨论 Loop Engineering 的风险和投入之前，有必要正视一个社区里的尖锐分歧：Loop Engineering 到底是真突破，还是新瓶装旧酒？

"真突破"派的论据

• Loop 的核心不是"循环"本身，CI/CD 也是循环，而是循环内部有一个能判断、能决策、能从失败中学习的 Agent。这是之前所有自动化框架都不具备的。Cron Job 不会在测试失败后自动换一种修法，但 Loop 中的 Agent 会。
• 从 Prompt Engineering 到 Loop Engineering 的四次抽象跃迁，每一次都改变了人与 AI 的协作关系。你从"操作机器的人"变成了"设计流水线的人"，这是质变，不是量变。
• LangChain 的实验数据是硬证据：同一个模型，换 Harness 架构，通过率从 52.8% 跳到 66.5%。模型没变，变的是循环设计。这证明"怎么设计循环"本身就是一个独立的技术变量。

"新瓶装旧酒"派的论据

• Agent Workflow、Harness、Orchestration，这些概念过去两年一直在做类似的事。从 Harness 到 Loop，间隔才几个月，概念消化不过来。
• 目前缺乏严格的"控制变量法"对比：用 Loop 和不用 Loop，在相同任务、相同模型、相同上下文的条件下，最终产出到底差多少？没有这样的实验数据。
• 很多号称"Loop Engineering"的实践，本质上就是一个 Bash 脚本 + while 循环。如果这就是 Loop，那 2010 年的运维工程师就已经在做 Loop Engineering 了。

我的判断

Loop Engineering 的真正价值不在于"循环"这个动作本身，而在于它第一次让人与 AI 的协作有了设计语言。就像 REST 之于 HTTP：HTTP 协议一直都在，但 REST 给了大家一套描述、讨论、复用 API 设计的通用语言。Loop Engineering 做的是同样的事，它把"我写了个脚本让 AI 跑"变成了一种有术语、有模式、有方法论的可复用实践。所以我的立场很明确：Loop Engineering 不是新瓶装旧酒，它是旧酒终于有了新瓶，而这个瓶子的形状，决定了未来所有人怎么喝这瓶酒。 模式本身比实现更重要。

组织准备度：什么时候该开始？

最后，回到管理者最关心的问题：我的团队现在该不该开始尝试 Loop Engineering？

这个问题不能简化成一张检查清单就打发了。因为 Loop Engineering 不是一个可以"装上去"的工具，它是一种工作方式的改变。就像从手动测试切换到 CI/CD，你不仅需要装一个 Jenkins，还需要改变团队对"什么叫完成了"的定义、对"谁负责质量"的预期、对"自动化到什么程度才算够"的判断。Loop Engineering 也是如此。

三个前置问题

问题一：你的团队现在用 AI 编程的痛点是什么？

Loop Engineering 解决的是"手动推循环"的痛点。如果你的团队目前用 AI 编程的主要痛点是"AI 写的代码质量不行"或"AI 不理解我们的业务逻辑"，那 Loop 不会帮你，它只会让你更快地得到质量不行、不理解业务的代码。Loop 是加速器，不是纠偏器。先解决方向问题，再解决速度问题。

问题二：你的团队有没有能力审查 AI 生成的代码？

这个问题听起来简单，实际上很微妙。很多团队认为"我们有 Code Review 流程，所以能审查 AI 代码"。但 AI 生成的代码跟人类写的代码有一个关键区别：人类写的代码，写的人能解释为什么这样写；AI 生成的代码，没有人能解释为什么这样写。 审查 AI 代码需要的是"读懂陌生代码并判断其正确性"的能力，这比审查同事的代码要求更高。如果你的团队目前对 AI 生成代码的审查还停留在"看看有没有明显 bug"的层面，那还没有准备好让 Loop 大规模跑起来，因为 Loop 生成的代码量会远超人工审查的吞吐能力。

问题三：你的团队愿意为"看不见的工作"和"看不见的账单"买单吗？

Loop Engineering 有两类成本很容易被忽略。

第一类是搭建和维护 Loop 本身的工作量——维护 CLAUDE.md、调试终止逻辑、处理 Loop 跑偏的情况、定期审计 Loop 生成的代码。这些工作不会产生可见的功能产出，但它们是 Loop 持续健康运行的前提。

第二类是AI 工具的订阅费用——这往往是一笔容易被低估的固定支出。Loop 跑起来之后，每个人的工具链成本会显著上升：

• Claude Code：Pro 套餐 $20/月，Max 套餐 $100-$200/月（含更高 token 额度），超出额度后按 API 计费
• Codex：Plus 套餐 $20/月，Pro 套餐 $200/月，超出额度后按 API 计费
• OpenCode：工具本身免费（MIT 开源），但模型调用需要自备 API Key 或订阅（BYOK），成本取决于你选择的模型

Loop 的真实月成本 = 订阅费 + API 超额费 + 人力维护成本

一个 5 人团队，如果每人用 Claude Max（$200/月），月订阅费就是 $1,000——这还没算 API 超额费用。三项加总才是你该看的数字。

很多团队在做预算时只算了 API 费用，忘了订阅费是"不管你用不用都得付"的固定成本。如果团队的文化是"只看产出、不看投入"，那 Loop 的维护工作和订阅账单都会被持续挤压，最终退化成无人照看的流水线。

准备度总表

判断规则：如果任何一个维度是"暂缓"，先解决那个项再开始。如果全部是"可以试点"，选一个最简单的场景（如自动修 lint 错误）做试点。如果有三个以上"就绪"，可以规划规模化部署。

从试点到规模化：三个容易踩的坑

坑一：场景跳跃。

试点场景是"修 lint 错误"，成功了，然后直接跳到"架构重构"。这两个场景的复杂度差了一个数量级，lint 错误的验证标准是确定性的（通过/不通过），架构重构的验证标准是模糊的（好不好用、可不可维护）。场景跳跃会导致 Loop 在新场景中大面积失败，团队信心受挫。场景扩展的步子要小，每次只增加一个不确定因素。

坑二：忽视理解债务的累积。

试点阶段 Loop 生成的代码量小，审查还能跟上。规模化后代码量暴增，审查开始积压，团队倾向于"测试通过了就先合进去，回头再审查"，但"回头"永远不会来。理解债务像信用卡账单，滚起来很快，还起来很痛。规模化之前，先建立"代码审计日"制度，每周固定半天，不写新代码，专门阅读和重构 Loop 生成的代码。

坑三：把 Loop 当成替代品而不是工具。

团队开始依赖 Loop 后，容易产生一种心态："反正 Loop 会修，我先不关心代码质量了。"这是认知投降的规模化版本。Loop 是工具，不是替代品，它帮你做重复性工作，但不帮你做判断性工作。在团队中明确 Loop 的边界，哪些决策由 Loop 做，哪些决策必须由人做，写进团队的工程规范里。

什么时候该停下来？

Loop 不是只能前进的。以下信号出现时，应该考虑暂停或回退：

• 理解债务增速超过审查速度：Loop 每天生成的代码量，超过团队每天能审查的代码量，这意味着代码库中未审查的部分在持续增长
• Thrashing 率持续超过 30%：三轮以上的循环占比超过 30%，说明 Loop 的 Skills 或终止逻辑需要调整，而不是继续跑
• 线上故障中 Loop 生成代码的占比上升：这是一个硬信号，Loop 生成的代码正在引入你审查不到的问题
• 团队对 AI 生成代码的信任度下降：如果团队开始回避审查 Loop 的 PR，或者对 Loop 的产出产生普遍的不信任，说明认知投降或验证缺口已经到了需要干预的程度

停下来不是失败。停下来是为了修复 Loop 的设计、补充 Skills、调整终止逻辑，然后重新开始。就像 CI/CD 的流水线出了问题，你不会让它继续跑，你会停下来修好再上线。Loop 也是一样。

收束

Loop doesn't know the difference. You do.

从你每天都在做的那个手动循环，到五要素模型、四种 Loop 模式、成本公式和三大风险，我们走了很长一段路。但所有这些内容，最终都指向 Addy Osmani 那句话。

Loop 不知道它修的是一个无关紧要的 typo，还是一个可能导致数据泄露的严重 bug。它不知道你点"确认"是因为认真审查过，还是因为习惯性地点了。它不知道测试通过了但性能退化了，它只知道"测试通过了"。

Loop 是一个加速器。它能让 AI 编程的效率提升一个数量级，Boris Cherny 一个月 4 万行代码就是证明。但加速器没有方向感。它可以让你跑得更快，也可以让你更快地跑向错误的方向。

所以 Loop Engineering 的终极问题不是技术问题，而是人的问题：你是否仍然理解你的代码？你是否仍然在审查，而不仅仅是审批？你是否仍然知道什么该自动化，什么不该？

设计你的 Loop，但设计它的时候，要像一个打算继续做工程师的人那样设计，而不是像一个打算把方向盘交出去的人。

Build the loop. But build it like someone who intends to stay the engineer.