夜雨聆风2026 年 6 月，硅谷 AI 圈突然冒出一个新词——Loop Engineering 。
源头是两句话。 Anthropic 的 Claude Code 负责人 Boris Cherny 说："我已经不再给 Claude 写 prompt 了。我跑了一堆循环，它们在替我 prompt Claude 。我的工作变成了写循环。"
OpenClaw 创始人、现在 OpenAI 的 Peter Steinberger 接得更快："你早就不该再亲自对 coding agent 下提示了。你应该设计循环系统，让它去提示你的 agent 。"
两句话，一个信号。
过去两年，整个行业都在教你"怎么写更好的 prompt"——提示词工程师甚至成了正经岗位。但此刻，站在 AI 编程最前沿的这群人，已经不用手写 prompt 了。
他们设计循环。让 agent 自主运转、自我迭代、直至目标完成。
这就是 Loop Engineering 。
从"手写 prompt"到"设计循环"：一场正在发生的范式转移
先还原一个典型场景。今天大多数开发者用 AI 编程的方式是：写一段 prompt → 看回复 → 发现不对 → 再写一段 prompt → 再看回复 → 再调整。人机之间，像在单向对话里来回踢皮球。
Loop Engineering 要替换的，就是这个循环本身。你不是坐在那亲手打字的人，你是搭建系统的人。
更确切地说，你搭建的是一个自动化的反馈回路。它自动发现任务、分派工作、验证结果、记录状态，然后决定下一步——每一步都不需要你亲自对着对话框打字。
这让我想起 Addy Osmani 在他那篇《 Loop Engineering 》博客里写的一句话。他是 Google 的工程总监，也是这个话题最有影响力的阐释者。他在开篇直接定义了这件事：
Loop engineering 是一个递归式的目标设定——你定义一个目的， AI 不断迭代直到完成。你设计系统，系统驱动 agent ， agent 产出的结果又被系统消化、评估、决定是否继续。你不是在写 prompt ，你在写那个写 prompt 的机制。
挺抽象。但拆开看，就是一个值得认真理解的新框架。
一个有效的 Loop ，需要六块积木
Osmani 把 Loop Engineering 拆成了五个组件，再加上第六个常被忽略的要素——状态记忆。这些组件不是理论，是已经在 Codex 和 Claude Code 里实装的能力。下面是每个组件的拆解。
1. Automations （自动化）——让循环"活"起来
这是 Loop 的心脏。一次性的单轮对话不是 Loop ，定时跑起来的才是。
在 OpenAI Codex 里， Automations 是个独立标签页。你选项目、写 prompt 、设频率——系统就按规矩跑。没发现问题，自动归档；发现了，扔进 Triage 收件箱。 OpenAI 内部用它做日常 issue 分类、 CI 失败汇总、 commit 简报生成。
Claude Code 这边，对应的原语是 /loop 和 /goal。前者按固定间隔跑（"每 5 分钟检查一次 PR 构建状态"），后者持续运行直到某个条件为真——"所有 auth 测试通过且 lint 干净"——然后停下。
关键在后者。/goal 的终止条件不是由执行 agent 自己判定的，是一个独立的小模型在每次迭代后做评估。制作者和裁判分离，这是设计上非常聪明的选择。
2. Worktrees （工作树）——并行不打架
Loop 一旦跑起来，你不会只跑一个 agent 。但多个 agent 写同一个目录，文件冲突就是必然结果。
Git worktree 解决了这个问题。它为每个 agent 创建独立的 working directory ，共享同一份 repo 历史，但物理上隔离彼此的修改。 Codex 内建了 worktree 支持， Claude Code 通过 --worktree 标志和子 agent 的 isolation: worktree 配置实现。
Osmani 提到过一个形象的类比： worktrees 消除了机械冲突，但人的 review 带宽仍然是你的瓶颈。 loop 可以帮你跑得更快，但它不能替你读代码。
3. Skills （技能）——把知识写下来，别让 agent 每次重新猜
Agent 每次冷启动都会用自信的猜测填补意图空白。一个开发团队的项目约定、架构决策、编码规范——如果不外化存储， agent 会在每一次对话中重新摸索，每次都走一遍弯路。
Skills 的形式极简单：一个 SKILL.md 文件，加一些脚本文档。 Codex 和 Claude Code 共用同一套格式。你写一遍， agent 就能读。
Osmani 把这叫作"intent debt"——意图负债。 agent 每次启动都会产生猜测成本， Skills 就是在还这笔债。
4. Plugins & Connectors （插件与连接器）——连接真实世界
一个只能读写文件系统的 loop 是被关在笼子里的。 Connectors 基于 MCP 协议打通了一切——GitHub issue tracker 、数据库、 staging API 、 Slack 频道。
这意味着 loop 不再是"跑完告诉我结果"，而是直接给你建好 PR ，关联 Linear 工单， CI 通过后自动通知频道。能做的事比你想象的多得多。
5. Sub-agents （子 agent ）——写代码的和审代码的分开
这是所有结构性设计里最有效的一条。写代码的 model 审查自己的作业时，总是太宽容。它知道自己"本意"是什么，所以看到有瑕疵的输出也容易放行。
解决方案？让另一个 agent 来审。
在两个工具里，实现方式分别是： Codex 的 .codex/agents/（ TOML 格式配置）和 Claude Code 的 .claude/agents/。你可以指定不同的模型和 reasoning effort——安全审查员用高配置，探索者用快速只读模型。
一位单独工作的开发者，搭配"写 agent + 审 agent + 规格校验 agent"三件套，能做到一个人撑起一个团队的生产力。前提是你真的看了它们的输出。
6. State （状态记忆）——第六块积木
模型在两次运行之间，什么都不记得。每一次循环启动都是从头开始。
所以记忆必须存在对话之外——存在磁盘上。一个 Markdown 文件、一个 Linear board 、任何能在循环间传续状态的地方。 Loop 记录的不仅是什么做完了，更重要的是什么做过了但没成功、什么还在等。
"The agent forgets, the repo doesn't."——Osmani 的原话，也是这条原则最干净的注脚。
一个完整的 Loop 日常长什么样？
早上定时任务触发 → Triage skill 读取前一日 CI 失败、开放 issue 、近期提交 → 状态写入 Markdown → 每个值得处理的问题在隔离 worktree 中派生子 agent 起草修复 → 第二个 agent 审查 → Connector 自动创建 PR 、更新工单 → 无法处理的事项进入收件箱等你决定 → 状态文件记录一切，次日续接。 你全程不需要给任何人发消息。
Loop 解决不了的三件事
Osmani 花了几乎同样多的篇幅写 Loop 能做什么，和不能做什么。篇幅不对等，但态度诚实。
1. 验证责任没法外包
无人值守的 loop 也会无人值守地犯错。"完成了"是 agent 的声明，不是证明。 Osmani 说得直接——"你的工作仍然是交付你确认能跑的代码。"Loop 帮你加速，但帮你承担不了这最后的责任。
2. 理解债务会加速积累
Loop 越快地产出你没写过的代码，你实际理解的东西和系统中真实存在的代码之间的差距就越大。 Osmani 称之为"comprehension debt"——理解债务。流畅的 loop 只会加速这一过程。
除非你读它产出的每段代码。
3. 认知投降是一种真实风险
当 loop 自主运转时，被动接受一切输出、停止思考的诱惑很大。放弃判断力比维护判断力容易得多。
但有趣的是， Osmani 指出了同一种行为的两种截然相反的结果：如果你带着判断力设计 loop ，它是高效的工程工具；如果你用它来逃避思考，它是认知能力的加速器。 Loop 自己不知道区别。你知道。
什么时候该用，什么时候不该用
技术社区的反应很真实。
AI 资讯机构 AlphaSignal 的总结很精辟： Loop Engineering 要在四个条件同时成立时才有正向效益——任务高度重复、验证已经自动化、团队 token 预算充足、 agent 具备完整工具权限。
说实话，这四个条件同时满足的门槛不低。当前最成熟的落地场景是： CI 故障排查、依赖更新、 Lint 修正、 Issue 转 PR 。架构重构、产品设计、需要深度判断力的事——还是该留在人类手里。
还有一个绕不开的现实： token 成本。每轮循环就是一次完整的 prompt 执行。 1 分钟间隔跑 8 小时， 480 次 API 调用。 Steinberger 说得直白："我是有无上限 token 额度的人。"——别忘了他是 OpenAI 员工。社区回复更扎心："一个月 20 美元的套餐？想都别想。"
GitHub 上已经有个 awesome-loop-engineering[1] 仓库在收集相关资源，感兴趣可以去看看实际案例。
所以， Loop Engineering 到底是什么
它不是某个产品的功能。不是 Claude Code 独有，不是 Codex 独有。它是一套工作的方法论——五个核心组件加一个记忆层，在不同工具里都能落地。 Boris Cherny 说杠杆点移动了，但工作没有变容易。你是从"写好 prompt"变成了"设计好 prompt 的系统"。
从 prompt engineer 到 meta-prompt engineer 。从用工具的人，到设计工具使用方式的人。
也许最准确的定义来自 Osmani 的收尾。他写道：
"Build the loop. But build it like someone who intends to stay the engineer."
建你的循环。但以一个打算继续做工程师的人的心态来建——不是只想按下"开始"然后走开的那种。
这个话题在社区里还会争论很久。但有一点可以肯定：提示词工程不是被"杀死"了，是被升维了。从写好一句话，到设计好一个系统。工作要求没有变低，杠杆点挪了个位置。
答案可能还真不在 loop 里。
参考链接
[1] awesome-loop-engineering: https://github.com/ChaoYue0307/awesome-loop-engineering
