Loop Engineering：当写 Prompt 的能力不再重要，设计循环的能力才重要

一个引爆开发者社区的观点

2026 年 6 月，三句话在开发者社区同时炸开。

PSPDFKit 创始人 Peter Steinberger 发了一条冲过八百万浏览的推文："你不该再去 prompt 编程 agent，你该去设计那些 prompt agent 的循环。"

Claude Code 负责人 Boris Cherny 在接受访谈时说："我不再手动 prompt Claude 了。我有循环在后台跑，它们负责 prompt Claude 并决定下一步做什么。我的工作就是写这些循环。"

几天后，Google Cloud AI 总监 Addy Osmani 把这件事写成了一篇文章，给了它一个正式的名字——Loop Engineering（循环工程）。

这个命名迅速被社区接受。截至 2026 年 7 月，GitHub 上名为 loop-engineering 的仓库已经积累了 210+ star，包含 7 个生产级别的模式、3 个 CLI 工具、安全指南和真实失败案例。不到两个月，这个概念从一个论坛讨论变成了有完整工程体系支撑的实践范式。

四次范式跃迁：人一步步把操作权交出去

要理解 Loop Engineering 为何此刻爆发，需要先看清开发者与 AI 的关系在过去两年里经历了什么。

阶段	时间	核心技能	开发者角色
Prompt Engineering	2023-2024	写出精准的 prompt	指令发出者
Context Engineering	2024-2025	设计模型看到的信息环境	上下文架构师
Harness Engineering	2025-2026	配置 agent 的运行环境	环境搭建者
Loop Engineering	2026	设计自动运行的闭环系统	系统设计者

每一次跃迁，开发者都往上退了一层。从"写每一条指令"到"设计写指令的系统"，人不站在操作台前了，而是站在设计台后面。

Loop 到底是什么？

Addy Osmani 给出的定义很直接：

Loop Engineering 就是把你——那个不断 prompt agent 的人——替换成一个系统，由这个系统去 prompt agent。

这里的"循环"是一个递归目标：你定义一次目的，AI 持续迭代直到任务真正完成。循环不再是你每次看完输出后敲下一条指令，而是一套自动化系统去发现工作、分派任务、校验结果、记录进度、决定下一步。

Osmani 把它总结为一个公式：

Loop = Trigger + Task Policy + Execution + Verification + Persistent State + Stop/Retry/Escalation

其中最关键的是 Verification 和 Persistent State。没有可靠验证的循环只是空转，没有状态记忆的循环每次都得从头再来。

五大组件 + 一个记忆

Osmani 将完整的 Loop 拆成六个要素，而 Claude Code 和 OpenAI Codex 已经全部内置：

1. Automations（自动化）

让系统主动寻找工作而非被动等待指令。每天早上分析前一天的 CI 失败记录，每晚检查依赖漏洞，定期扫描未处理的 issue——agent 从"等待指令"变成了"主动发现工作"。

2. Worktrees（工作树）

当多个 agent 并行时，Git Worktree 为每个任务创建独立的工作目录，避免文件冲突。一个 agent 的修改不会污染另一个 agent 的检出，直到合并时才碰头。

3. Skills（技能）

把项目知识、团队规范和最佳实践写成 SKILL.md 文件，agent 每次运行时自动读取。写一次，每次运行都生效。没有 Skills 的循环，每个周期都在从零重新推导整个项目。

4. Plugins & Connectors（插件与连接器）

基于 MCP 标准，让 agent 能连接 GitHub、Linear、Slack、数据库、监控系统。一个循环如果只能访问文件系统，能干的事极其有限；接上真实系统后，它能自动创建 PR、更新工单、发通知。

5. Sub-agents（子智能体）

将"执行者"和"检查者"分离。负责写代码的模型对自己的作业往往过于宽容，而另一个拥有不同指令的 agent 能发现前者因自我合理化而忽略的问题。这是循环在无人值守时保持可靠性的关键。

+1: Persistent State（持久状态）

模型会遗忘，但代码仓库不会。循环必须把当前进度、已尝试的方案、未解决的问题写入外部存储——一个 Markdown 文件、一块 Linear 看板或者数据库。这是今天下午的循环能接上今天上午进度的原因。

/loop 和 /goal：两个值得关注的原语

Claude Code 和 Codex 都提供了两个关键命令：

• /loop：按时间节奏重复运行。比如每 10 分钟检查一次 CI 状态。它关心的是"多久再执行一次"。
• /goal：持续工作直到满足完成条件。比如"持续修复 auth 模块，直到所有测试通过且 lint 无错误"。每个回合结束后由另一个独立小模型判断目标是否达成。

/goal 更接近真正的闭环——它天然包含了持久目标、多轮执行、独立评估器、完成条件和自动停止。从 Loop Engineering 的视角看，/goal 比 /loop 更"Loop"。

一个真实的早晨循环

Addy Osmani 分享了他自己的日常循环配置：

每天一早，一个自动化任务在代码仓库上启动。它调用一个分诊技能，读取昨天的 CI 失败记录、未关闭的 issue 和最近的提交，把分析结果写入 Markdown 文件。对每一个值得处理的问题，循环创建独立的 worktree，派一个子 agent 起草修复方案，再派第二个子 agent 用项目规范和现有测试审查方案。连接器自动创建 PR 并更新工单。循环处理不了的，丢进收件箱等他亲自处理。

整个过程，没有一句 prompt 是他亲手敲的。 全是循环替他写的。

Stripe 的 1300+ PR/周流水线

Stripe 工程师 Steve Kaliski 在播客中透露了一个更惊人的数字：他们的一套叫 Minions 的流水线，每周合并超过 1300 个 pull request，没有一行是人手敲的。

这远超 vibe coding 的范畴。如果是逐轮对话，1300 个 PR 意味着一个人得在对话框里一个一个地去提示、一个一个地去验收——物理上不可能。Minions 能跑到这个规模，是因为人只设计了一次这条流水线，之后每一个 PR 都是自动触发、自动验收的。人只在末端做一件事：审核。

六个你必须面对的代价

循环不是免费的午餐。Osmani 在文章中系统性地列出了六个代价：

代价	描述
意图债	Agent 每轮冷启动，不知道项目规矩。解法是把规矩写成 Skills
验证债	循环能无人值守地跑，也能无人值守地错。"做完了"只是声明，不是证明
理解债	循环吐代码越快，你没亲手写也没真读懂的代码就堆得越高
认知投降	循环太顺，人就懒得较真——它递什么就收什么，判断权不知不觉交出去
编排税	循环能开很多条，但你的审查带宽是有限的。并行上限不是工具定的，是你的注意力定的
Token 成本	同一任务，loop 模式可能烧掉 prompt 模式的 20 倍 token。不算着来很容易超支

被高估的"循环"，被低估的"拓扑"

在 6 月底五源资本的一场闭门研讨中，一个观点格外尖锐：

"循环（loop）被高估了，拓扑（topology）被低估了。"

真实有价值的任务不是简单的"跑通一个测试"，而是螺旋式自我迭代与深度耦合拓扑结构的结合体。人类的真实工作——并行、异步、可被打断——很难被镜像成单个 agent 的任务。

这提醒我们：Loop Engineering 解决的是"怎么连续跑"的问题，但"往哪跑"——那个最开始的方向判断——依然需要人的品味和判断力。

写在最后

Loop Engineering 不会是最后一个"XX Engineering"。但它标志着一个重要的转折：工程杠杆点从"如何写好一条 prompt"转移到了"如何设计一套能自我运转的系统"。

Boris Cherny 说他的工作是写循环。Peter Steinberger 每天同时开着五六个 Codex 循环。Addy Osmani 把这一切系统化了。

而你，可能需要开始思考一个问题：你的第一条循环，准备写什么？