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

逆境不可逃2026-06-25 14:41

作者：逆境不可逃

技术永无止境

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

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

《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 持续积累）
适合解决的问题 一次性的、探索性的 重复性的、有明确判定标准的
人的精力投入 每次交互都高度投入 前期设计投入大，后期监督投入小

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

九、总结：Loop Engineering 的本质

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

它的核心洞察只有一个：

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

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

Osmani 的最终忠告：

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

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

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

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

热门推荐
01GitHub 镜像站点02如何新建文件夹？ 电脑新建文件夹的4种方法032026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片04AI科技热点日报 | 2026年07月01日05国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）06幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路08微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新092026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？10【解构】DeepSeek V4 发布：技术报告深度解读 + 横向对比六大开源模型，我们的判断是……