Loop Engineering ：从提示词工程到循环工程，AI 编程的范式革命

作者：逆境不可逃

技术永无止境

希望我的内容可以帮助到你！！！！

大家吼 ! 我是 逆境不可逃 今天给大家带来文章

《Loop Engineering ：从提示词工程到循环工程，AI 编程的范式革命》

相关专栏 欢迎阅读

learn claude code

Hello-Agents学习记录

用AI学Agent

摘要：2026 年 6 月，一个由 Claude Code 之父 Boris Cherny、OpenClaw 创始人 Peter Steinberger 和 Google Cloud AI 总监 Addy Osmani 共同引爆的新概念——Loop Engineering（循环工程）席卷了 AI 编程圈。本文将从起源、核心组件、实践路线图和陷阱四个维度，全面解读这场"不再写提示词，而是设计循环"的范式转变。

一、一个引爆整个 AI 圈的瞬间

2026 年 6 月初，Anthropic 工程师、Claude Code 的创建者Boris Cherny在一次开发者大会上说了一句话，24 小时内播放量逼近 70 万次：

"我不再给 Claude 写提示词了。我有一堆 loop 在运行，它们自己提示 Claude、自己决定下一步该做什么。我的工作是写 loop。"

几乎同时，OpenAI 的Peter Steinberger（OpenClaw/"龙虾"创始人）发推，收获 830 万浏览：

"你不应该再给编程 Agent 写提示词了。你应该设计 loop，让 loop 替你去写。"

随后，Addy Osmani（Google Cloud AI 总监、前 Chrome 工程负责人）发表了长篇博客，系统性地将这个新范式命名为Loop Engineering，并拆解了它的六大组件、三大陷阱和完整的构建路线图。

这三个人的核心共识只有一个：

人的角色变了。不再是"提示词编写者"，而是"循环设计师——AI 系统架构师。"

二、什么是 Loop Engineering？

2.1 一句话定义

Loop Engineering 是一种系统方法论：设计一套能自己发现任务、分配任务、执行代码、验证结果、记录状态，并自主决定下一步的自动化循环系统，让 AI Agent 在人的监督下持续运转。

2.2 范式演进链

每一层都建立在上一层之上。Loop Engineering 不是否定提示词，而是把提示词从人的手里转移到循环里。

2.3 一个直观的对比

传统的 Prompt Engineering 模式：

人发现问题 → 人写提示词 → AI 生成代码 → 人审查 → 人提交 → 人关闭工单 ↑________________________↓ （人始终在回路中）

Loop Engineering 模式：

定时任务自动发现 → 分诊 Skill → 开 Worktree → Maker Agent 起草修复 → Checker Agent 审查 → 通过开 PR → 自动更新工单 → 搞不定的升级给人类 → 第二天从断点继续 ↑_____________________↓ （循环自动运转，人监督关键节点）

关键差异：人从"发动机"变成了"监督者"和"规则制定者"。

三、Loop Engineering 的六大核心组件

Addy Osmani 将完整的 Loop 拆解为五个构建块 + 一个外部记忆层，共六大板块：

板块 1：Automations（自动化 / 心跳）

> Loop 的"脉搏"——让系统按节奏自动触发，而不是靠人手动启动。

最值得关注的 `/goal`：它不是按时间触发，而是一直跑到你定义的条件成立为止。每轮结束由一个独立的判断模型（不是写代码的同一个 Agent）来判断——"写代码的 Agent 不是给自己打分的那个人"。

板块 2：Worktrees（工作树隔离）

> 当多个 Agent 并行工作时，物理隔离它们的文件系统。

问题：两个 Agent 同时改同一个文件 = 两个工程师不沟通就改同一行代码 → 必然冲突。

方案：用 Git Worktree 为每个 Agent 创建一个独立的工作目录和分支，互相不触碰。

• Claude Code：通过 `--worktree` flag 或 `isolation: worktree` 配置

• Codex（OpenAI）：原生内置 worktree 支持

> ⚠️Osmani 的重要提醒：worktree 只是消除了机械冲突，但你的代码审查带宽才是真正的并行上限。开 50 个 worktree 并行修 bug → 你需要 review 50 个 PR。

板块 3：Skills（技能 / 项目知识沉淀）

> 把项目规范、架构约定、历史踩坑记录写进 `SKILL.md`，Agent 每次读取，避免每轮"金鱼记忆"。

Skill 的本质：把"意图"写在 Agent 外部，让它成为持久可积累的资产。

一个标准的 Skill 文件夹包含：

• `SKILL.md` — 指令 + 元数据

• 可选的脚本、参考资料、资源文件

Claude Code 和 Codex 共享相同的 Skill 格式，跨工具复用。

> 💡Skill 是编写格式，Plugin 是分发方式。把多个 Skill 打包跨仓库共享，就是 Plugin。

板块 4：Plugins & Connectors（连接器）

> 让 Loop 不只是"看文件"，而是通过 MCP 协议接入真实工具链。

这就是"Agent 告诉你该怎么修"和"Loop 自己开 PR、关联工单、CI 绿了发频道通知"之间的天壤之别。

MCP（Model Context Protocol）是通用协议，为 Claude Code 写的 Connector 在 Codex 上通常也能直接用。

板块 5：Sub-agents（子 Agent — 执行者与审查者分离）

> Loop Engineering 中最重要的结构性设计。

Osmani 原话："写代码的模型给自己打分的时候太仁慈了。"

配置方式：

• Claude Code：`.claude/agents/` 目录下定义，支持 Agent Teams（多 Agent 协作）

• Codex：`.codex/agents/` 目录下用 TOML 文件定义

这就是你在 Loop 无人值守运行时敢离开电脑的唯一理由：有一个你真正信得过的验证者。

板块 6：Memory（外部记忆层）

> 跨会话的持久状态记录——整条流水线的"脊椎骨"。

Osmani 原话："Agent 会忘，但文件不会。记忆必须存在磁盘上，不能在上下文窗口里。"

记忆文件记录什么：

• `last_run` — 上次运行时间

• `in_progress` — 当前进行中的分支和状态

• `lessons_learned` — 历史踩坑记录

• `status` — 本轮分诊了多少问题、修复了几个、升级了几个

四、一个完整 Loop 的实际运转

（来自 Addy Osmani 实际使用的结构）

每天早上 → 定时任务自动在仓库上启动 ↓ 调用一个 triage skill（分诊技能） → 翻昨天的 CI 失败记录、Open Issue、最近提交 → 发现问题写入 STATE.md 或 Linear 看板 ↓ 对每个值得处理的问题： → 开一个隔离的 Worktree → Maker Agent A 起草修复方案 → Checker Agent B 拿着 Skill 和测试审查方案 ↓ 修复通过审查 → → Connector 自动开 PR → 自动更新工单 → CI 绿了发 Slack 通知 ↓ 搞不定的问题 → 进入 Triage 收件箱，等人处理 ↓ 第二天早上 → 从昨天断点继续

从发现 → 分配 → 修复 → 审查 → 开 PR，全程一个字都不用敲。

五、Boris Cherny 的"蜂巢"（THE HIVE）

Boris Cherny 将自己的 Loop 工作流称为"蜂巢"，分为三层：

三层递进，从"人在回路中"到"人偶尔看报告"，再到"纯系统自主运转"。

六、14 步构建路线图

Addy Osmani 给出了从 0 到 1 搭建 Loop 的完整路线图，分为三个阶段：

阶段一：评估（5 步）— 先问自己该不该建 Loop

>四个条件缺一不可。缺一个，Loop 的成本就会远超收益。

阶段二：搭建（8 步）

阶段三：守住（1 步）

>Osmani："像一个还要继续做工程师的人一样搭建 Loop，不要去做只会点'开始键'的人。"

七、三大陷阱——Loop 越强，风险越尖锐

Addy Osmani 用了和介绍六大板块相同的篇幅来强调这三个陷阱。这不是"免责声明"——这是核心内容。

陷阱 1：验证债务 — "完成了" ≠ 完成了

> Loop 说"完成了"只是一个声明，不是证明。

• 把 Maker 和 Checker 分开只是让"完成了"这句话稍微有点意义

• 自动化门禁（测试、lint、build）是必要条件，不是充分条件

• 最终责任仍然在你——"开发者的工作是发布你亲自确认能运行的代码"

缓解策略：

• 每个自动 PR 必须经过人类 review

• 定期故意破坏代码（Chaos Engineering），检验自动化门禁是否还能发现

• 不给 Loop 授予直接合并到主分支的权限

陷阱 2：理解债务 — 代码越多，理解越少

> Loop 产出代码的速度越快，仓库里"实际存在的东西"和"你真正理解的东西"之间的鸿沟就越大。

Osmani 原话："账单不在月底的 API 发票里，而在生产系统宕机时没人能读懂代码去修复它的那一天。"

缓解策略：

• 强迫自己阅读每一个自动 PR 的 diff

• 让 Loop 写详细的 commit message 和变更说明

• 锁定 Loop 的作用域——不碰高层架构和核心业务逻辑

陷阱 3：认知投降 — 最舒服的姿势最危险

> 当 Loop 自己撒欢跑时，人会本能地停止形成独立判断，直接收下它给的一切结果。

Osmani 原话："两个人可以搭完全一样的 Loop，得到完全相反的结果——一个人用它加速自己深度理解的工作，另一个人用它来逃避理解工作本身。Loop 分不清这两者的区别。你知道。"

缓解策略：

• 定期亲自写代码，保持手感

• 给自己设"Loop 假期"——每周有一天不看 Loop 的 PR

• 把 Loop 当成"实习生"而非"替身"

八、Loop Engineering 不等于 Prompt 已死

一个常见的误解是把 Loop Engineering 解读为"提示词工程已死"。这是错的。

Osmani 本人的澄清：

"搭好你的 Loop，但别忘了直接给你的 Agent 写提示词仍然有效。关键是找到正确的平衡。"

杠杆点转移了"Loop Design 比 Prompt Engineering 更难，而不是更简单。Cherny 的意思并不是工作变轻松了，而是。"

两者不是替代关系，是互补关系。

九、总结：Loop Engineering 的本质

Loop Engineering 的底层哲学其实非常古老——控制论和系统工程。

它的核心洞察只有一个：

让 Agent 自己跑起来，比手动给 Agent 写每一次提示词，杠杆更高。

但杠杆是一把双刃剑。如果底座不牢（没有自动化验证门禁、没有 Skill、没有 Maker/Checker 分离），Loop 只会以更快的速度放大错误。

Osmani 的最终忠告：

"像一个还要继续做工程师的人一样搭建 Loop。"

这不是工具的升级，这是角色的升级：

提示词编写者 → 上下文设计师 → 脚手架搭建者 → AI 系统架构师

Loop Engineering 的核心竞争力，不是你用了多少 Agent、开了多少个 Worktree——而是你设计的循环在多大程度上体现了你对系统的深刻理解和工程判断力。