目录
一、起源：一条推文引爆AI圈
2026年6月7日，OpenClaw（GitHub历史上涨星最快的开源Agent项目）创始人 Peter Steinberger 在X上发了一条推文，只有两句话：
“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” — Peter Steinberger, 2026年6月7日
24小时内，这条推文获得了 800万次浏览。紧接着，Anthropic负责Claude Code的 Boris Cherny 在一个播客中说了一段同样震撼的话：
“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” — Boris Cherny, Anthropic Claude Code 负责人
这段演讲片段被上传到X后，不到24小时获得近70万次播放。
随后，Google Chrome工程负责人、Google Cloud AI总监 Addy Osmani 发表了一篇系统性长文，正式将这个概念命名为 Loop Engineering（循环工程），并系统拆解了它的五大构建模块。
三个不同公司的顶级从业者，在同一周得出几乎一样的结论——这绝非巧合。AI编程的范式正在发生根本性的转变。
二、什么是Loop Engineering
Addy Osmani给出了精确的定义：
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. — Addy Osmani, Google
翻译过来就是：循环工程就是用你自己设计的系统，取代你作为”给Agent写提示词的人”的角色。
在过去两年中，使用AI编程的方式很简单——你写一个好的Prompt，喂入足够的上下文，读返回结果，再输入下一条指令。Agent是工具，你是全程握着它的人。
Loop Engineering要改变的就是这个模式。现在，你构建一个小系统，这个系统会自动发现工作、分配任务、检查结果、记录进度、决定下一步做什么——然后让这个系统去驱动Agent，而不是你亲自去驱动。
从”驾驶员”到”设计师”
旧模式：Prompt Engineering
你发一个指令，AI执行一段；你看看结果，不满意再换个说法。你的注意力全程在线，你就是那个驾驶员。
瓶颈：人类注意力有限，AI执行能力无限。当模型输出速度远超人类处理速度时，人成了整个流程的瓶颈。
新模式：Loop Engineering
你设计一个循环流程，它会自动地、一遍又一遍地去问AI：”目标是什么？进展到哪一步了？下一步该干嘛？”你只需要在开始时定义好目标，在结束后接收结果。
本质：从”每一次交互的参与者”转变为”循环系统的设计者”。
它和Cron Job有什么区别？
很多人第一反应是”这不就是定时任务吗？”但关键区别在于 决策点。
传统的Cron Job执行的是死板的脚本——如果A网站改版了，脚本就挂了，只知道报错。而一个设计良好的Loop，它的每一步执行什么、怎么执行，都是由模型根据当前状态 实时决定 的。它不是在执行固定脚本，它是在”思考”然后”行动”。
三、为什么是现在
任何技术趋势的爆发都不是空穴来风。Loop Engineering的成熟需要三个条件同时具备：
上下文窗口够大了
现在有些模型的上下文能达到百万token级别，可以一次性”看”完一个中小型项目的代码库，或者记住很长一段任务历史。这是它能理解复杂任务、进行多步工作的基础。
推理成本下来了
让AI模型多跑几轮、多想几次，是要烧钱的。但现在API调用成本持续下降，多跑几轮从”奢侈消费”变成了”可接受的运营成本”。
编程Agent本身能用了
模型变聪明了，能处理的编程任务更复杂了，能从自己的错误中学习恢复了。当单次AI执行就能干很多活的时候，瓶颈就从”怎么写好Prompt”转移到了”怎么设计让AI持续高效工作的系统”。
AI工程的四次跃迁
四、五大构建模块
Addy Osmani指出，一个完整的Loop需要 五个核心部件，加上一个记忆系统。Claude Code和OpenAI Codex都已经实现了这全部五个模块。
| 模块 | 在Loop中的职责 | Claude Code | Codex |
|---|---|---|---|
| Automations（自动化） | 心跳机制：定时发现和分诊任务 | Scheduled tasks、/loop、/goal、hooks、GitHub Actions |
Automations tab、Triage inbox、/goal |
| Worktrees（工作树） | 隔离机制：并行Agent互不干扰 | git worktree、--worktree、subagent isolation |
内置worktree支持 |
| Skills（技能） | 知识机制：项目规范和约定的编码 | SKILL.md 文件 |
SKILL.md 文件 |
| Plugins/Connectors（插件/连接器） | 连接机制：接入真实工具和环境 | MCP servers + plugins | Connectors (MCP) + plugins |
| Sub-agents（子Agent） | 分离机制：实现者与检查者分离 | .claude/agents/、agent teams |
.codex/agents/ (TOML配置) |
| State/Memory（状态/记忆） | 记忆机制：跨会话持久化进度 | Markdown (AGENTS.md) 或 Linear (MCP) |
Markdown 或 Linear (connector) |
1. Automations — 心跳机制
Automations是让Loop真正成为”循环”而非”一次性运行”的关键。它定义了任务的调度方式：是每天定时运行，还是某个事件触发时启动？
两个原语特别重要：/loop 按固定频率重复运行；/goal 持续运行直到你写的条件为真——而且每轮结束后，由一个 独立的小模型 来判断是否完成，写代码的Agent不能给自己的作业打分。
2. Worktrees — 隔离机制
两个Agent同时改同一个文件，是灾难的开始。Git Worktree为每个Agent提供独立的、互不干扰的工作目录，共享同一个仓库历史。一个Agent的修改 物理上不可能 触碰另一个Agent的文件。
3. Skills — 知识机制
Skills是解决”每次都要重新解释项目”问题的方案。它是一个 SKILL.md 文件，里面写着项目的构建步骤、代码规范、常见陷阱——Agent每次启动时先读这个文件，就像新员工入职先读手册一样。
没有Skills，Loop每轮都要从零推导你的项目；有了Skills，知识会在循环中 复利式积累。
4. Plugins & Connectors — 连接机制
一个只能看文件系统的Agent是极其有限的。Connectors（基于MCP协议）让Agent能读写Issue Tracker、查询数据库、调用Staging API、在Slack中发消息。这是让Loop从”告诉你它想做什么”变成 “自己动手做完并通知你” 的关键。
5. Sub-agents — 分离机制
Loop中 最有价值的结构设计：让写代码的Agent和检查代码的Agent是不同的”人”。写代码的模型太容易给自己的作业打高分了。第二个Agent用不同的指令（有时用更强的模型）来审查，能抓住第一个Agent”说服自己”的那些问题。
6. State/Memory — 记忆机制
模型的上下文窗口是有限的，聊着聊着就忘了前面。记忆系统（一个Markdown文件或Linear看板）把关键进度、状态、犯过的错记录在外部存储中。每次循环开始，Agent先读取状态文件，知道自己从哪来、到哪去。Agent会忘记，仓库不会。
五、四种核心循环模式
不同的任务类型适合不同的循环架构。以下是2026年工业界最常见的四种模式：
1. Retry Loop（重试循环）
最简单的模式。Agent尝试做一件事，检查是否成功，不成功就换种方式重试。
适用：短任务，有明确的通过/失败标准。如”让所有测试通过”。
注意：避免用同一种方式无限重试。如果连续失败，需要换策略。
2. Plan-Execute-Verify（计划-执行-验证）
双层架构：外循环生成高层计划，内循环逐步执行并验证。如果某步失败，外循环根据新状态 动态修订 后续计划。
适用：多步骤复杂任务，如重构模块、搭建新服务。
注意：避免对错误计划过度坚持——发现计划有误时，要敢于重规划。
3. Explore-Narrow（探索-收敛）
Agent同时探索多条解决路径，根据中间结果收敛到最有希望的一条。
适用：调试未知错误、探索陌生API、性能优化。
注意：并行探索很烧Token，需要尽早剪枝。
4. Human-in-the-Loop（人机协同）
Agent自主运行，遇到歧义或需要决策时暂停，等人输入后继续。
适用：需求无法完全预先指定的任务，生产环境变更。
注意：如果Agent每个小决策都来问人，就失去了自动化的意义。
双层循环架构详解
在复杂任务中，平铺的ReAct循环暴露了根本缺陷：每一步都是局部最优决策，缺乏全局视野。Plan-Execute双层循环是目前工业界处理复杂任务的主流方案：
- 外循环（Planner）：LLM生成高层计划（步骤列表，带依赖关系）。Planner不参与执行，仅负责战略。
- 内循环（Executor）：逐步执行，每步后将结果反馈给外循环。若某步失败，外循环根据新状态动态修订剩余计划。
这本质上是Plan-and-Solve的增强版，加上ReWOO的核心思想——把观测（Observation）与推理（Reasoning）脱钩，避免上下文被中间结果污染。社区报告数据显示，双层循环能将 无效工具调用减少40-60%，复杂多步任务的成功率提升约25%。
六、一个完整的Loop长什么样
把五大模块拼在一起，一个典型的生产级Loop是这样的：
每日CI自动修复Loop
触发：每天早上6点，Automation自动启动。
发现：调用Triage Skill，读取昨天的CI失败日志、未关闭的Issue、最近的Commit，将发现写入Markdown状态文件。
执行：对每个值得修复的问题，打开一个隔离的Worktree，派遣一个Sub-agent去起草修复方案。
验证：第二个Sub-agent（使用更强的模型）审查修复方案，对照项目Skills和现有测试进行验证。
闭环：通过Connectors自动创建PR、更新Linear工单、在Slack频道通知团队。Loop处理不了的问题进入Triage收件箱，等待人工处理。
记忆：状态文件记录了什么被尝试过、什么通过了、什么还开着——明天早上的运行会从今天停下的地方继续。
注意你实际做了什么：你设计了一次，之后再也不需要手动Prompt任何步骤。这就是Steinberger所说的核心观点，而且同样的Loop在Claude Code和Codex中都能运行，因为五大模块是通用的。
七、风险与陷阱
Loop Engineering不是银弹。Addy Osmani本人也强调了对Token成本的谨慎态度，并指出了三个随着Loop变好反而 更尖锐 的问题。
风险1：Token烧钱黑洞
Reddit上有开发者晒账单，一晚上Loop自动运行，几百美元的Token费就没了。对于个人开发者或小团队，一定要设置硬性的预算上限，初期建议手动触发，别轻易无人值守运行。
风险2：理解债务（Comprehension Debt）
代码被Loop自动生成、自动合并，但没有人真正读过它、理解它。短期内效率飞起，但长期来看，你对系统如何工作积累了大量的”不理解”。有报告显示，随着AI采用率提高，开发者人均bug数上升了54%，近三分之一的代码是无人审查就进入生产环境的。
风险3：认知投降（Cognitive Surrender）
当Loop跑得太顺，你会越来越依赖它，越来越不愿意深入理解代码细节。Addy Osmani称之为”认知投降”——同样的动作（设计Loop），如果你带着判断力去做，它是解药；如果你用它来逃避思考，它就是加速剂。
风险4：目标模糊是致命的
Loop适合处理”目标清晰、可验证”的任务。如果你想用它来”优化用户体验”或”提升代码质量”，大概率会翻车。AI不知道”更好”是什么标准，它可能会在模糊指令下无休止地运行。
适合上Loop的任务
- 重复性高：每天、每周都要做的
- 规则明确：输入、输出、成功标准都很清楚
- 有可靠的验证方式：最好能用自动化测试、类型检查、编译来验证结果
最好别碰的任务
- 探索性、创造性强的：产品早期原型、艺术创作、战略构思
- 目标极其模糊的：”优化用户体验”、”提升代码质量”
- 后果严重且难以回滚的：核心金融系统、关键基础设施的改动
八、落地指南：如何开始你的第一个Loop
黄金法则：从最小、最安全的Loop开始
先找一个痛点最明显的重复性任务，设计一个简单的循环，加上最严格的预算限制和人工审核环节，小范围跑起来。看看效果，踩踩坑，积累经验。不要一上来就搞全自动、无人化的复杂流程。
第一步：定义清晰的目标
在写任何Loop逻辑之前，先写下”完成”长什么样。”所有测试通过且无lint错误”是终止条件；”代码看起来不错”不是。同时定义失败条件：”10次迭代无进展，升级为人工审查”。
第二步：编写SKILL.md
把你的项目规范、构建步骤、代码风格、”我们不用这种方式因为上次出了事故”——全部写进SKILL.md。这是Loop的知识基础，写一次，每次循环都受益。
第三步：配置验证子Agent
创建一个专门的审查Agent配置，用更强的模型、更严格的指令。确保”写代码的人”和”检查代码的人”不是同一个Agent。这是你能放心让Loop无人运行的前提。
第四步：设置状态文件
创建一个Markdown文件作为Loop的”记忆”。每次循环开始时读取，结束时更新。内容包括：已完成的步骤、当前状态、遇到的问题、下一步计划。
第五步：设置预算上限
无论是Token预算还是迭代次数上限，一定要有硬性限制。初期建议：
- 最大迭代次数：10-20轮
- 每次迭代的工具调用预算：5-10次
- 总Token预算：根据你的承受能力设定
- 人工审核：初期每个PR都要人工review
30天 rollout 路线图
| 阶段 | 时间 | 目标 |
|---|---|---|
| 第1周 | Day 1-7 | 写第一个 /goal，让Agent自动修复一个已知Bug。观察它怎么工作，记录问题。 |
| 第2周 | Day 8-14 | 编写SKILL.md，配置验证子Agent。让Loop处理”让所有测试通过”类任务。 |
| 第3周 | Day 15-21 | 设置第一个Automation，每天自动分诊CI失败。开始积累状态文件。 |
| 第4周 | Day 22-30 | 评估效果，优化Loop配置。逐步放宽人工审核频率，建立信任。 |
九、未来展望
Loop Engineering标志着AI应用从”手工作坊”进入”小工厂”时代的转折点。我们不再是亲自抡大锤的工匠，而是开始设计机床和流水线的工程师。
但正如Addy Osmani所说：
“Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.” — Addy Osmani, Google
设计Loop是更难的Prompt Engineering，不是更容易的。Cherny的观点不是说工作变简单了，而是说 杠杆点移动了——从”怎么写好一条Prompt”变成了”怎么设计一个让AI持续高效工作的系统”。
Loop不会删除你的工作，它会改变你的工作。验证仍然在你，理解仍然需要你，判断力永远不可替代。但如果你能聪明地使用它——它能把你的精力从重复劳动中解放出来，聚焦在真正有创造性的工作上。
写在最后
Loop Engineering不是魔法，不是银弹，更不是让你变懒的借口。它是一个强大但需要精心驾驭的工具。用得好，它是解放；用不好，它可能给你埋下意想不到的巨坑。
在这个AI快速迭代的时代，保持独立思考和清醒判断，可能比掌握任何一个新名词都重要。
