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

2401_87662859

216人浏览 · 2026-06-24 21:41:43

2401_87662859 · 2026-06-24 21:41:43 发布

作者：逆境不可逃

技术永无止境

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

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

《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 范式演进链

阶段	交互方式	人的角色	核心技能
Prompt Engineering	一问一答，人写提示词 → AI 回复	提示词编写者	提示词设计
Context Engineering	精心构造上下文，让 AI 理解项目全貌	上下文设计师	信息组织
Harness Engineering	给 Agent 装上工具（MCP、hooks）	脚手架搭建者	工具集成
Loop Engineering	Agent 自主循环，人设计系统规则	AI 系统架构师	系统设计

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

2.3 一个直观的对比

传统的 Prompt Engineering 模式：

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

Loop Engineering 模式：

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

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

三、Loop Engineering 的六大核心组件

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

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

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

机制	说明	工具示例
`/loop`	定时重复运行指定 prompt	Claude Code 内建
`/goal`	持续运行直到可验证的完成条件成立	Claude Code 内建
`hooks`	生命周期关键节点触发（如提交前、保存时）	Claude Code hooks
`cron`	Unix 风格定时调度	跨平台
GitHub Actions	关掉电脑也能跑	CI/CD 集成

最值得关注的 `/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	有 Skill
每轮从零猜测代码风格	直接读取项目规范
可能触犯已知禁忌	避开历史踩坑记录
反复消耗 token 重推导	知识复利增长
行为不可预测	行为一致可控

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

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

`SKILL.md` — 指令 + 元数据
可选的脚本、参考资料、资源文件

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

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

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

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

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

连接器	能力
GitHub / GitLab	读仓库、开分支、开 PR、响应 webhook
Linear / Jira	自动更新工单状态、关联 PR
Slack / Discord	每日分诊摘要推送、异常升级告警
Sentry / Datadog	调查生产报错、自动草拟 hotfix

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

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

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

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

角色	职责	模型策略
Maker（生产者）	起草修复方案、写代码	可用快速/便宜的模型
Checker（验证者）	拿着 Skill 和测试用例审查代码	换不同模型，甚至更高推理强度的强模型

配置方式：

Claude Code：`.claude/agents/` 目录下定义，支持 Agent Teams（多 Agent 协作）
Codex：`.codex/agents/` 目录下用 TOML 文件定义

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

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

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

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

载体	适用场景
Markdown 文件（`STATE.md`）	个人/小团队，版本可控，高度可见
Linear 看板 / 数据库	企业级 Loop，跨仓库跨团队

记忆文件记录什么：

`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 工作流称为 "蜂巢"，分为三层：

层级	名称	机制	特点
第一层	`/loop` 本地循环	最小 1 分钟间隔，绑定会话	人在屏幕前，快速迭代
第二层	Routines 云端例程	关掉电脑继续跑	异步无人值守
第三层	`/batch` + Dynamic Workflows	成百上千 Worktree Agent 并行	大规模批处理

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

六、14 步构建路线图

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

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

步骤	问题	说明
1	任务是否重复发生？	一次性任务不值得建 Loop，手写 prompt 更快
2	验证能否自动化？	有测试套件、类型检查、linter 作为客观门禁吗？没有自动化门禁，Loop 毫无意义
3	Token 预算撑得住吗？	Loop 会反复读上下文、重试失败方案、走上分岔路——全都在烧 token
4	Agent 能跑自己的代码吗？	它需要日志、可复现环境、实际运行代码看结果的能力
5	你愿意 review 产出吗？	Loop 产出的是"草案"，不是"成品"，最终验证责任在你

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

阶段二：搭建（8 步）

步骤	动作	关键原则
6	先手动跑稳	在自动化之前，先把单次流程跑通、跑稳
7	沉淀为 Skill	把项目规范、风格指南、禁忌写成 Skill 文件
8	加状态文件	`STATE.md` 或 Linear 看板，记录断点和进度
9	设硬闸门	测试套件、linter、类型检查——不可绕过的自动化门禁
10	配 Automation	定时触发还是事件触发？选好心跳机制
11	上 Worktree	多 Agent 并行时物理隔离，互不干扰
12	接 Connectors	连接 GitHub、Slack、Jira，形成真正的"手"
13	拆 Sub-agents	Maker + Checker 分离，换不同模型交叉验证

阶段三：守住（1 步）

步骤	动作	说明
14	盯住每个被接受的改动的成本	定期复审权限范围、亲自读 diff、不让 Loop 碰核心架构

> 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 当毒药
加速深度理解的工作	逃避理解工作本身
放大你的判断力	替代你的判断力
处理重复性杂活，释放思考带宽	处理一切，包括你不理解的东西

缓解策略：

定期亲自写代码，保持手感
给自己设"Loop 假期"——每周有一天不看 Loop 的 PR
把 Loop 当成"实习生"而非"替身"

八、Loop Engineering 不等于 Prompt 已死

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

Osmani 本人的澄清：

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

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

	Prompt Engineering	Loop Engineering
杠杆点	单次交互的质量	系统的长期运转质量
可复用性	低（每次从头写）	高（Skill 持续积累）
适合解决的问题	一次性的、探索性的	重复性的、有明确判定标准的
人的精力投入	每次交互都高度投入	前期设计投入大，后期监督投入小