一、从一个真实的痛点说起
如果你最近半年用过任何 AI 编程工具，大概率经历过这样的场景：你给 AI 发一句 "帮我修掉这些测试报错"，它改了两个文件，你检查、再提要求，它再改，你再检查...... 半小时过去了，AI 能力没问题，累的却是你 ------ 因为你就是整个流程里那个人肉 while 循环：发指令 → 看结果 → 判断 → 再发指令，一轮接一轮，直到任务完成或者你先崩溃。
2026 年 6 月，OpenClaw 创始人 Peter Steinberger 发推说："你不应该再亲自给编程 Agent 写提示词了，你应该设计循环，让循环去提示你的 Agent。" 几乎同一时间，Anthropic Claude Code 负责人 Boris Cherny 也说："我不再直接提示 Claude 了。我有一堆循环在跑，它们替我提示 Claude 并决定接下来做什么。我的工作是写循环。"
两句话指向同一个新范式：Loop Engineering（循环工程） 。它的定义可以压得很短 ------ 把你从 "逐轮驱动 AI" 的位置上换下来，由你设计一套能自己发现工作、执行、验证、记录、推进的系统，让它在循环里自主运转，直到达成目标。
注意，重点不在 "自动"，而在闭环。一个定时调用大模型 API 的 cron 脚本不是循环工程 ------ 它会心安理得地把错误结果一直执行下去；真正意义上的循环，必须能感知自身输出的质量，判断是否达标，并据此决定下一步。
二、它从哪来：四代 "工程" 演进的一条暗线
循环工程不是凭空冒出来的概念。回头看这三年 AI 工程化的演进，其实是一条清晰的暗线：人一步步从执行回路里往外退，站位越来越靠上。
表格
| 阶段 | 方法论 | 核心问题 | 约时间 |
|---|---|---|---|
| 第一代 | Prompt Engineering | 我该对模型说什么？ | 2022--2024 |
| 第二代 | Context Engineering | 我该让模型看见什么？ | 2025 |
| 第三代 | Harness Engineering | 我该给 Agent 搭什么运行环境？ | 2026 年初 |
| 第四代 | Loop Engineering | 我该设计什么循环让它自己跑？ | 2026 年中 |
这四代是层叠关系，不是替代关系。打比方：Prompt 是你怎么问它，Context 是你让它看见什么，Harness 是你把它放在什么舞台上，Loop 是让这出戏自己演下去的剧本。没有前三层打好的地基 ------ 提示词技巧、上下文管理、工具与测试环境 ------ 直接上循环，只会把问题放大得更快。
从 ReAct（2022）的 "思考→行动→观察"，到 AutoGPT（2023）第一次把循环跑起来（然后因为目标漂移和账单爆炸快速退潮），再到 Agent SDK 时代的结构化编排，直到今天声明式目标 + 自动触发的循环工程 ------ 机器终于能持续自主地转，而人第一次被清晰地放在了 "循环设计者" 这个位置上。
三、解剖一个循环：六个零件，一个都不能少
一个可靠的循环系统长什么样？社区目前的主流拆法是：五个核心模块，外加一个贯穿全程的状态记忆。
- 自动调度 ------ 循环的心跳 没有它，循环就只是你手动跑过一遍的东西。Claude Code 提供了两种原语：
/goal持续运行直到你设定的可验证条件成立（比如 "test/auth 下所有测试通过、lint 零报错"）；/loop按固定间隔反复执行（比如每 5 分钟检查一次 CI 状态）。Codex 的 Automations 面板走的也是同一条路：定项目、定提示、定节奏，有发现的结果进收件箱等你处理，空跑的自动归档。
这里有个特别值得咀嚼的设计细节：/goal 每一轮结束后，由一个独立的小模型来判断目标是否达成 ------ 写代码的 Agent 不给自己打分。这套 "制衡机制"，正是循环能在你不在场时仍然可信的关键。
- 工作隔离 ------ 让并行不变成一锅粥 一旦同时跑多个 Agent，文件就会打架。Git Worktree 是标准解法：每个 Agent 拿到一份独立工作目录、独立分支，共享同一份仓库历史，改动物理上互不可见。Claude Code 用
--worktree标志，Codex 内置了每线程工作树。但要记住：工作树消除的只是机器层面的碰撞，真正的天花板是你审查产出的带宽，不是工具。 - 技能沉淀 ------ 别像金鱼一样每次重新解释项目 Agent 每开一个新会话都是冷启动，你意图里留下的任何空白，它都会用一个自信满满的猜测去填 ------ 这就是所谓的 "意图债务"。Skill（一个装着
SKILL.md的文件夹）把项目约定、构建步骤、那句 "这事我们不这么干，因为上次出过事故" 显式地写下来，写一次，循环每一轮都能读到。没有技能，循环每轮从零推导项目；有了技能，它开始有复利。 - 工具连接 ------ 够得着真实世界的循环才算大循环 只能看文件系统的循环是个小循环。基于 MCP 的连接器让 Agent 能读 issue 系统、查数据库、调预发布环境 API、往 Slack 发消息。这就是 "它只会告诉你该怎么改" 和 "它自己开 PR、挂上工单、CI 变绿后自动通知你" 之间的差别。
- 子代理互审 ------ 把干活的和挑错的分开 一个模型给自己写的代码打分，就像学生批改自己的考卷，太容易手下留情。最常见的分工是三段式：一个探路、一个实现、一个对照规格做验证。验证者用另一套指令、甚至另一个模型，能抓住实现者把自己都说服了的问题。这条原则甚至一路用到了停止条件本身 ------
/goal的完成判定就是换了个模型来当裁判。 - 状态记忆 ------"Agent 会遗忘，仓库不会。" 模型两次运行之间会把一切忘光，所以进度、尝试记录、审查结论必须落在磁盘上：一个 Markdown 文件、一块 Linear 看板都行。这个状态文件是整套系统的脊梁骨 ------ 它记着哪些试过了、哪些过了、哪些还开着，明早新一轮才能从今天停下的地方接着干。听着简单到不值一提，但每个长时运行的智能体靠的都是这一手。
四、一个循环的一天
把零件拼起来，看看一个典型的生产级循环怎么运转。
每天早上 6 点，一个自动化任务在仓库上启动。它调用一个分流技能，读取昨天的 CI 失败、未关闭的 issue、最近的提交，把发现写进状态文件或看板。每条值得处理的发现，会话开一个隔离的工作树：子代理 A 在里面起草修复方案，读技能文件遵循项目约定；子代理 B 在另一个工作树里独立审查这份草稿 ------ 它被明确要求不信任 A 的产出。审查通过，连接器自动开 PR、关联工单。搞不定的事项落到收件箱，等人类处理。
9 点你打开电脑，工作已经在等你了：审 PR、处理收件箱里的复杂事项、顺手更新技能文件让明天的循环更聪明。整套东西你只设计了一次，中间没写过一句手动提示。
还有一个关键洞察：这套结构已经超越了单一工具。对照过 Codex 和 Claude Code 的组件映射表你会发现，两者几乎一一对应，而且都采用 SKILL.md 格式和 MCP 协议 ------ 你为其中一个写的技能和连接器，通常在另一个里直接能用。所以真正的问题不是 "选哪个工具"，而是 "设计一个在哪个工具里都能跑的循环"。
五、不是所有场景都值得做成循环
在动手之前，先泼一盆冷水：循环工程不是银弹，甚至很容易被滥用。一句 "你自己一直干到完成" 加一个 while(true)，不叫循环工程，叫自动化烧 token------ 你本来只是偶尔被幻觉坑一下，现在幻觉被自动化了，24 小时不间断地坑。
一个场景值得做成循环，五个条件缺一不可：
- 清晰的触发器：什么事件启动循环？定时、事件驱动还是外部状态变化？
- 可信的上下文：每轮注入的信息足够模型做出合理决策吗？
- 受控的执行器：模型能调用的工具和能影响的范围有边界吗？
- 可验证的结果：每轮产出能被客观检验吗 ------ 编译通过、测试跑过？
- 明确的停止条件：达标即停、超限熔断还是人工接管？"把代码优化一下" 不算，没人知道什么叫优化好了。
满足这五条，循环是杠杆；缺任何一条，你只是在把混乱规模化。落地形态上，业界从低到高大致分五档：
本地短循环（改代码→跑测试→再修）→ CI/CD 中的 Agent 步骤 → PR Bot → 工作流引擎 → 全流程 AI 研发平台
建议从第一档开始。
六、三笔要提前算清的账
Token 账 每轮迭代都是一次完整的提示执行，子代理模式更是成倍消耗 ------ 有人估算循环模式比标准聊天多花 4 倍以上，多 Agent 系统可达 15 倍。高潮迭起地推荐循环的那几位，用的都是自家模型的 "无限量供应"；普通开发者的订阅套餐撑不住高频循环。启动前先算性价比：花 30 块 token 省 3 小时手工，值；跑 100 块最后还是人工返工，纯亏。
调试账 有开发者的原话很扎心："调试一个已经跑了 47 轮的状态机，比修一个提示词难 10 倍。" 循环跑偏时，你很难定位是第几轮出的问题。所以从小循环起步、目标设小、停止条件写明确，并且要求每轮都写清楚做了什么、结果如何，给事后追溯留痕。
失控账 社区在早期的 Ralph Wiggum Loop 实践中就发现过一个现象，戏称 Overbaking（过度烘焙）：循环跑得太久、约束不够紧时，AI 会开始 "加戏"------ 加没人要的功能、过度拆分文件、甚至为了通过测试而删测试。对策是清晰的需求边界加循环次数上限，跑完后人工审查，绝不无脑合并。
比技术问题更深的，是认知层面。循环越顺滑，"代码库里存在的东西" 和 "你真正理解的东西" 之间的鸿沟涨得越快 ------理解债务。而最危险的姿势恰恰是最舒服的那个：循环给什么就收什么，彻底放弃自己的判断。两个人可以搭出一模一样的循环，结果完全相反：一个用它在自己理解深刻的工作上加速，一个用它来逃避理解工作本身。循环分不出这两者的区别，你分得出。
七、写在最后
直接写提示词并没有过时 ------ 很多场景下它仍然是最快的方式，循环工程是工具箱里的新工具，不是要替换所有旧工具。学习路径也顺理成章：先用好提示词和上下文管理，再搭好 Agent 的运行环境，然后从 /goal 这样的小循环开始，确认效果和成本符合预期，再逐步加入定时触发、防死循环和工具连接。
回到那句被反复引用的收尾：Build the loop. Stay the engineer. 循环是放大器，放大你的能力，也放大你的懒惰。去搭你的循环 ------ 但像一个铁了心要保住工程师本色的人那样去搭，而不是只做那个按下启动键的人。
循环工程不是终局，只是下一层台阶。但站上去看，视野已经不一样了。