一、从一个真实的痛点说起
如果你最近半年用过任何 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 是你怎么问它，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. 循环是放大器，放大你的能力，也放大你的懒惰。去搭你的循环 —— 但像一个铁了心要保住工程师本色的人那样去搭，而不是只做那个按下启动键的人。
循环工程不是终局，只是下一层台阶。但站上去看，视野已经不一样了。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
I. Starting with a real pain.
If you've used any of the AI programming tools in the last six months, you've probably experienced a scene like this: you've given AI a sentence saying, "Help me fix these tests and make mistakes," and it's changed two files, you check, you ask again, and it's changed, you check again... half an hour later, AI's ability is fine, and you're tired -- because you're the man in the whole process, who's the meat, wiye loop: give instructions, watch the results, judge the results, give the instructions, turn around until the job is done or you collapse.
In June 2026, the founder of OpenClaw, Peter Steinberger, said, "You shouldn't write prompt to the program Agent in person, you should design a loop that tells you Agent. "Almost at the same time, the director of Anthropic Claude Code, Boris Cherny, also said, "I no longer direct Claude. I've got a bunch of loops running, they've shown Claude for me and decided what to do next. My job is to write loops."
Two sentences point to the same new paradigm: Loop Engineering. Its definition can be very short -- you can switch from "Ai" on a wheel-by-wheel basis, and you can design a system that detects work, executes, validates, records, pushes it around the cycle until the goal is achieved.
Attention, the point is not "automatic," but in the ring. A Cron script calling LLM API on a regular basis is not a circulatory project - it will ably keep the wrong results running; the true cycle must be able to sense the quality of its output, judge whether or not it meets the standard and decide on next step accordingly.
ii. Where did it come from: a dark line that evolved from four generations of engineering.
Cyclical engineering is not a concept that comes out of space. Looking back at the evolution of the three years of AI engineering, it's actually a clear dark line: people step back from the execution circuit and the position is getting closer.
Table
These four generations are layers, not substitutes. Example: Prompt is what you ask it, Context is what you make it see, Harness is what you put on the stage, Loop is the script that lets this play go on. Without the first three layers of ground-based -- prompt techniques, context management, tools and testing environments -- it just goes up and down, and it just zooms in faster.
From React (2022), "Rethinking Action Watch," to AutoGPT (2023), which ran the cycle for the first time (and then because the target drifted and the bill exploded fast), to Agent SDK, which was structured until today's declared goal + auto-activated recycle engineering -- the machine was finally able to move on its own, and for the first time, it was clearly placed on the "cycle designer."
III. Anatomy of a cycle: six parts, not one less
What does a reliable cycle look like? The current mainstream approach in the community is five core modules plus a state memory throughout the process.
- Automatically dispatching-- circulation of heart beats without it, circulation is just something you've run over manually. Claude Code provides two original languages: /goal continues to run until the verifiable conditions you set are established (e.g. "test/mouth all tests passed, Lint zero error reported"); /loop repeats at fixed intervals (e.g. checking CI status every 5 minutes). Codex's Automations panels follow the same path: set the items, set the tips, set the rhythms, find the results in the inbox and wait for you to process them, and empty automatic files.
Here's a particular design detail worth chewing: after each round, a small stand-alone model is used to determine whether the target is achieved -- Agent, who writes the code, doesn't score himself. This set of checks and balances is the key to a cycle that remains credible when you're not there.
- Isolation of work -- so the parallel doesn't turn into a pot of porridge. Git Worktree is the standard solution: each Agent gets a separate working directory, an independent branch, shares the same warehouse history and changes the physical invisibility. Claude Code uses the --worktree sign, and Codex has a working tree per thread. But remember: the work tree eliminates only a collision at the machine level, and the real ceiling is the bandwidth you review the output, not the tool.
- Skilled deposition -- don't rephrase the project every time you start a new session like a goldfish, Agent. Every time you start a new session, you're going to leave a blank, it's going to fill it with a self-confident guess -- it's called "intentional debt." Skill wrote it out, wrote it once, and read it every cycle. Without skills, the cycle leads from zero to zero per round; with skills, it starts to yield dividends.
It's a tool connection -- it's a cycle that's enough for the real world to be a big cycle, and it's a little loop for the file system. MCP-based connectors allow Agent to read the issue system, check databases, adjust publish Environment API, and send messages to Slack. That's the difference between "it's only gonna tell you how to change" and "it's gonna start P.R., put on a bill of employment and automatically notify you when the CI turns green."
- Sub-agents review each other -- separate the work from the fault-picking, a model scoring the code that they write, just like students revise their papers, so easy to take mercy. The most common division of labour is a three-part approach: one search, one realization, one validation against specifications. By using another set of instructions, or even another model, a certifier can capture the problem that the achiever has convinced himself of. This principle is even applied to the cessation conditions themselves – /goal's completion decision is a model to be a judge.
"Agent will forget, the warehouse won't. " The model will forget everything between two operations, so progress, attempt recording, review conclusions must fall on disk: a Markdown file, a piece of Linear board. This state file is the backbone of the whole system -- it remembers what's tried, what's past, what's still on, and it's going to be back to where it stops today in the morning. It sounds so simple, but every AI agent that runs for a long time depends on that hand.
IV. A cycling day
Put the parts together and see how a typical production cycle works.
Every morning at 6 a.m., an automated mission started in the warehouse. It calls for a diversional skill to read yesterday's CI failed, unclosed issue, latest submission, write the discovery into a status file or board. In each case, it was worth dealing with: sub-agent A drafted a restoration programme and read skills documents followed the project agreement; sub-agent B independently reviewed the draft in another working tree - it was explicitly asked to trust A's output. Review passed, connectors automatically open PR, associated worksheets. Uncertainty lies in the inbox, waiting for humans to handle it.
You turn on the computer at 9 o'clock, and the job is already waiting for you: review PR, handle the complexities in the inbox, update the skill files to make the cycle smarter tomorrow. You only designed the whole package once, and there was no manual hint in the middle.
There is also a key insight: the structure has gone beyond a single tool. By comparing the components map of Codex and Claude Code, you will find that they are almost identical, and both are in SKILL.md format and MCP protocols -- you write skills and connectors for one of them, usually directly in the other. So the real problem is not "choose which tools," but "design a cycle in which tools can run."
Five: Not all scenes are worth the cycle.
Before doing so, pour a bowl of cold water: cycling works are not silver bullets, and can even be misused. One sentence, "You're on your own until you're done," plus a "wire" -- not circulatory engineering, token -- you're just once in a while in a hallucinogen, and now the illusion is automated, 24 hours in an uninterrupted pit.
A scene is worth a cycle, and five conditions are not necessary:
- Clear trigger: What trigger cycle? Time, event driven or external state change?
- Credible context: Is there enough information per round for rational decision-making?
- Controlled implementers: is there a boundary between the tools that models can call and the extent to which they can affect?
- Verifiable results: can each round of output be objectively tested - compiled, tested and run?
- Clear terms of cessation: stop, overmelt, manual take-over? Optimize the code.
Satisfied with these five, the cycle is leverage; without any one, you're just scaling up the mess. In the landing pattern, the industry is roughly in five stages, from low to high:
Local short cycle (recoded run test re-repair) →Agent step →PR Bot →workflow engine → process AI development platform in CI/CD
It is proposed to start with the first tranche.
Six, three counts to clear in advance.
The Token account is a complete hint for each rotational generation, and the sub-agent mode is more than multiplied -- some estimate that the cycle mode is more than four times more than standard chat, and more than 15 times more Agent systems. The few who are recommended for circulation in the climax, using the "infinite supply" of their own models; the subscription package of ordinary developers does not hold up the high frequency cycle. Pre-start value: 30 bucks token 3 hours manual, value; 100 bucks run and manual rework net loss.
The debugging account has the very strong saying of the developer: "The debugging of a 47-wheeled status machine is 10 times harder than repairing a prompt. " When the cycle runs out, it's hard to locate the rounds. So, starting with a small cycle, with small targets, with clear conditions for cessation, each round is required to be clear about what has been done, what has been done, and to leave a trace of what has happened.
The community found a phenomenon in the early Ralph Wiggum Loop practice, called Overbaking: When the cycle is running too long and tight enough, AI starts to "play" -- plus nobody's needed functionality, over-split files, and even delete tests for testing. The response is a clear demand boundary plus a maximum number of cycles, a manual review after running, and no brainless consolidation.
Deeper than the technical problem is the cognitive dimension. The smoother the cycle, the faster the gap between what exists in the code library and what you really understand -- understanding debt. And the most dangerous position is exactly the most comfortable one: to take whatever the cycle is, to give up completely. Two people can make the exact same cycle, with the opposite result: one accelerates with its own profound work, and one with its own escape from understanding the work itself. The cycle doesn't distinguish between the two, you know.
VII. At the end
prompt is not out of date -- it's still the fastest way in a lot of scenes, and revolving engineering is the new tool in the toolbox, not the replacement of all old tools. Learning paths are also logical: first with prompt and context management, then with Agent's operating environment, then with a small cycle like /goal, confirming that effects and costs meet expectations, then gradually adding time triggers, death-proof cycles and tool connections.
Back to the end of the quote: "Build the loop. Take your loop -- but do it like a man who wants to keep the engineer's face, not just the one who pushes the start button.
Cycle works are not final. They are just next steps. But look up, the vision is different.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.