过去两年，跟编程类AI智能体打交道的方式其实很固定：写一段不错的提示词，给够上下文，看它返回什么，然后再敲下一句。整个过程里，你的手一直握在方向盘上，一回合接着一回合。
最近一个新词冒了出来——Loop Engineering，中文可以叫"循环工程"。它说的是一件挺朴素的事：你不再亲自给智能体发每一条指令，而是去搭建一套能替你发指令的系统。
带火这个说法的是Google工程师Addy Osmani，背后还有两个人的观点在呼应。一个是Peter Steinberger，他说"你应该去设计那些会提示智能体的循环"；另一个是Anthropic旗下Claude Code的负责人Boris Cherny，他的原话更直白——"我现在已经不再给Claude发提示词了，我写的是循环。"
这句话其实点出了整件事的核心：让人去提示智能体的环节，被一套系统接管了。你从那个敲键盘的操作员，变成了设计这套系统的人。
先搞清楚它到底指什么
Loop Engineering可以这样理解：把提示智能体的那个人换成一套系统，由系统来干你原本手动干的活。
这里的循环是一个会反复执行的目标。你只定义一次目的，智能体就持续迭代，直到任务真正完成。期间它自己去找活、自己动手、自己核对结果、把进度记下来，再决定接下来做什么。你做的，是让这套系统去戳智能体，而不是自己一下一下地戳。
有个对比能帮你理解这个层次关系。编程智能体在每一回合里本来就跑着一个内循环：它先想该做什么，然后采取行动（调用工具、改文件、跑测试），观察结果，再回过头根据新状态继续想。这个"感知—推理—行动—观察"的圈，就是智能体本身的运转方式。
Loop Engineering站在这个圈的上面一层。你不再亲手把每一回合掰过来掰过去，而是搭一个外循环：它按时间表运转，会派生出小助手，给自己投喂任务，跨越很多个内循环持续往前推，中间不需要你一直坐在座位上盯着。
用一句话概括就是：循环工程做的，是搭一套按时间表、对着目标去提示智能体的系统，取代你手动敲每一条提示词。撬动点从"单条提示词写得好不好"，转移到了"这套生成并验证提示词的系统设计得好不好"。
下面这张图能帮你看清内循环和外循环的关系。智能体自己在每一回合里跑着"推理—行动—观察"的内循环，而循环工程做的，是在外面再套一层会自动触发、验证、决定继续还是停下的外循环。
从提示词工程，一路走到循环工程
把视角拉远一点，这其实是这几年逐渐垒起来的第三层。每一层都把里面那层包住，撬动点也一点点远离最原始的模型调用。
最里面是提示词工程，你优化的是单条指令怎么措辞，工作的最小单位是你亲手敲的那一回合。外面一层是上下文工程，你管的是窗口里还该放些什么——文档、历史记录、工具定义，也就是围绕单个回答的那些条件。再往外才是循环工程，你设计的是一套系统，由它决定何时提示、提示什么，以及返回的结果能不能接受，工作的单位变成了横跨很多回合的自运转循环。
需要说清楚的是，提示词工程并没有消失。循环本身就是由一条条提示词搭起来的，循环里塞进一句糟糕的提示词，只会让糟糕的活产出得更快。上下文工程也一样重要，每一回合还是得把对的文件、历史和工具摆到模型面前。循环工程额外加上去的，是套在这一切外面的自动控制结构。
Boris Cherny提醒过的一句话值得记住：他想说的从来不是写代码这件事变简单了。真正发生的，是最有价值的事情挪了位置——从写提示词，挪到了设计循环。一个设计精良的循环能把一个优秀工程师的产出放大；可一个设计糟糕的循环，也会同样快地把一个错误判断放大，而且盯着它的人还更少。
Ralph：这个想法在有名字之前
在"循环工程"这个词出现之前，有个叫Ralph的玩法。2026年初，Geoffrey Huntley描述了一种做法：把编程智能体丢进一个最普通的while循环里，对着一份写好的需求文档反复投喂同一段提示词，让它挑一个任务实现掉，然后开一个全新的实例，把一模一样的提示词再喂一遍，如此反复，直到活干完。
他用《辛普森一家》里的角色Ralph Wiggum给它命名，因为这套方法用他的话说，是"在一个不可预测的世界里笨拙地保持确定"。它看着蠢得不像能成，但它真的成了。
不那么显而易见的关键在于上下文重置。一段很长的智能体会话会越跑越糊涂，窗口被旧的推理、走过的弯路、过时的文件内容塞满。Ralph直接绕开了这个问题：每一轮都是一个全新的智能体，带着干净的上下文，去读仓库当前的状态和磁盘上的任务清单，干完恰好一件事，提交，退出。
智能就藏在清晰、颗粒度足够细的需求和可验证的结果里，靠一个模型污染不了的外部记忆，一遍遍地施加上去。
可以说，Loop Engineering就是把Ralph做成了产品。那个while循环变成了定时自动任务，上下文重置变成了独立工作区和子智能体，"全部任务完成"的判断变成了由另一个模型来打分的目标条件。形状一样，只是锋利的毛刺被磨掉了。
一个能跑起来的循环，需要哪几样东西
一个真正能运转的循环，大致要凑齐6样能力，再加一个存放状态的地方。不同工具里叫法略有差别，能力是一回事。
第一样是定时自动任务。它是循环的心跳——一个会周期性触发的扳机，不用你开口就把活翻出来。在OpenAI的Codex里有专门的Automations标签页，你选好项目、要跑的提示词、跑的频率，以及是在本地代码还是后台工作区里跑。有发现的运行进到一个待处理收件箱，啥也没发现的就自己归档。Claude Code则通过/loop命令把一段提示词按间隔排进日程，比如每个工作日早上九点跑一次。
第二样是工作区隔离。一旦你同时跑不止一个智能体，文件就会开始打架，这跟两个工程师不打招呼就往同一行代码上提交是一样的麻烦。git的worktree能解决这事：每个智能体在自己的分支、自己的目录里干活，谁也碰不到谁的文件，历史记录却是共享的，最后像普通PR那样合并分支就行。
第三样是技能（Skills）。它让你不必每开一次会话就重新解释一遍项目背景。智能体每次都是冷启动，碰到你没交代的地方，它会自信地猜一个。技能就是把这份"意图"写在外面：项目约定、构建步骤、"这块我们不那么做，因为之前出过一次事故"。没有技能，循环每跑一圈都得从零把你的项目重新推导一遍；有了技能，知识就能跨越多次运行慢慢积累。
第四样是连接器。只能看到本地文件的循环是个很小的循环。连接器建立在MCP协议之上，让智能体能读你的工单系统、查数据库、调一下预发布环境的接口，或者往群里丢条消息。这是"这是修复方案"和"自己开好PR、关联好工单、等CI变绿再到群里@一声"之间的区别。
第五样是子智能体。循环里最有用的一个结构性动作，是把"写代码的"和"做检查的"拆开。让写代码的模型去给自己的作业打分，它会过于宽容。换一个带着不同指令、有时甚至是不同模型的智能体来审，常常能逮住第一个智能体把自己说服过去的那些问题。常见的搭配是：一个负责探索，一个负责实现，一个对照需求做验证。
最后一样——记忆。它可以是一个markdown文件，一块Linear或GitHub的看板，任何活在单次对话之外、记着"什么做完了、接下来做什么"的东西。这听上去简单到不像个要点，但它是所有长时间运转的循环都依赖的那个诀窍。模型在两次运行之间会忘掉一切，所以状态必须存在磁盘上，而不是上下文窗口里。智能体会忘，仓库不会。
把停止条件写成一份合约
循环里被讨论得最多的一个能力，是Claude Code的/goal：它会跨回合一直干，直到你写下的某个条件被可验证地满足为止，而且每一回合之后，会有另一个更小的模型来判断是否完成——写代码的那个，不负责给自己判分。
但一个目标的好坏，取决于证明它达成的证据。"把结账流程做得更好"这种说法，没给循环任何可以拿来给自己打分的东西，于是它想停就停了。
跑长时间无人值守智能体的实践者们，慢慢都收敛到了同一个做法：把停止条件当成一份合约来写，而不是一个愿望。这份合约要讲清楚四件事——期望的最终状态、证明成功所需的证据、绝不能违反的约束，以及一个硬性的回合数或预算上限。
举个对比就清楚了。弱的写法是"提升测试覆盖率"，强的写法是"src/billing的覆盖率达到或超过90%"；弱的证据是"看起来做完了"，强的证据是"npm test返回0，且覆盖率报告确认了这个数字"；约束那一栏不能空着，得写上"不许动公开API，不许删已有测试"；预算也得封顶，"跑满25个回合或花掉5美元就停，哪个先到算哪个"。
智能体始终是那个执行者，你要做的，是写好它在宣称完成之前必须通过的那道验收测试。
串起来看，一个循环长什么样
把这些拼到一起，单独一个对话窗口就变成了一个小小的控制台。下面这个形状很适合当你的第一个循环，而且在Codex和Claude Code里都能跑，因为底层能力是一致的。
每个工作日早上，一个定时任务在仓库上跑起来，它的提示词调用一个负责分诊的技能。这个技能去读昨天的CI失败记录、未关闭的工单和最近的提交，把发现写进记忆文件。对于每一条值得动手的发现，主流程开一个隔离的工作区，派一个子智能体去起草修复方案。接着第二个子智能体对照项目技能和已有测试审一遍这份草稿。连接器开好PR、更新工单。循环搞不定的，就留在待处理收件箱里等你。
那个状态文件是整件事的脊梁。它记着试过什么、什么通过了、什么还开着，于是明天早上的运行能从今天停下的地方接着往下走。回头看你实际干了啥：你只设计了一次系统，上面那些步骤没有一个是你手动提示的。这就是循环工程的全部意义。
如果这是你的第一个循环，可以从更小的地方起步。一个每天早上把CI失败分诊进markdown文件、完全不动代码的定时任务，已经能帮你省掉一桩重复的杂事，还能让你观察这个循环的脾气，再决定要不要放心让它去开PR。
信任是一级一级挣来的。最低一级是纯手动，你一回合一回合地提示。往上是分诊级，定时跑一下，把发现写进文件，不碰代码，由你来读和处理。再往上是草稿级，循环在隔离工作区的分支上起草修复，每个PR都由你审、由你合。更高一级，验证型子智能体先把PR过一道再送到你面前，你做的是批准，过滤交给验证者。最高一级才是自动合并，依赖更新、格式修正、不稳定测试重试这类低风险的改动在变绿后自动合并，你审的是日志，而不是每一处改动。每往上爬一级，都该等当前这级稳定产出你本来就会亲手做的活之后再说。
让循环盯着依赖升级和安全补丁
把上面这些拼起来，落到一个具体的团队身上是什么样，看一个常见的场景就清楚了。
设想一个五六个人的SaaS小团队，主力产品是一个Node后端加React前端的项目，依赖了上百个第三方包。他们一直被同一类杂事拖着：依赖库隔三差五就发安全补丁，Dependabot每天开一堆升级PR堆在那里没人看；偶尔某个补丁带来破坏性改动，跑挂了测试又没人及时发现；季度安全审计时，又得手忙脚乱地补一堆早该打的补丁。这类活每一件都不难，但加起来很耗人，还偏偏没人愿意天天做。
他们决定用一个循环把这摊事接管掉，搭法大致是这样。
每天凌晨两点，一个定时任务在仓库上跑起来，提示词调用一个写好的技能，这个技能里记着团队的约定：哪些包可以放心升小版本、哪些核心库（比如支付相关的）一律只起草不自动合、提交信息要怎么写。技能先去拉一遍依赖的安全公告和待处理的升级，把"该升哪些、各自风险多大"整理进一个记忆文件。
对每一个值得动手的升级，循环开一个隔离的工作区，派一个子智能体在自己的分支上把版本号改掉、装好依赖、跑完整测试套件。改完之后，换另一个子智能体来审：它对照技能里的规范看这次改动有没有碰不该碰的东西，再确认测试和类型检查全绿。审过了，连接器就去把PR开好，关联上对应的安全公告编号，并在团队群里留一句简短的说明。
到了早上，工程师打开电脑，看到的已经是一摞跑过测试、写好说明的PR。低风险的补丁，按团队设定的规则在CI变绿后自动合并，他们只在日志里抽查；碰了核心库或者测试挂了的，循环不会硬来，会把它留在待处理收件箱里，配上失败的测试信息，等人来拍板。
这个循环跑顺之后，团队实际省掉的，是每天那段"翻一遍升级列表、逐个判断要不要合"的零碎时间，安全补丁的平均处理周期也从原来的好几天压到了一天以内。更关键的是，他们只设计了一次这套系统，之后每天它都在替团队把这件重复的活做掉。这正好落在前面那张成熟度阶梯靠上的位置——验证交给子智能体过滤，人只在边界情况和最终合并处出手。
为什么有人愿意这么折腾
因为支点变了。
在手动提示词那个阶段，一个会措辞的开发者能拿到更好的结果。到了循环工程这个阶段，杠杆藏在系统架构里——触发器的质量、目标条件的精确程度、验证环节的设计。一个搭好一次的循环，每跑一次都在产生复利式的回报。
这件事谈不上取代开发者，更像是抬高了开发者做的事情的层次。会写最好提示词的人，未必是在智能体时代跑得最快的那批；跑得快的，会是那些能设计出最好循环的人。
哪些场景适合用，哪些场景别硬上
适合塞进循环的，是那些重复发生、且结果可验证的活。每天的CI失败分诊、依赖版本升级、不稳定测试的重试、把一个模块迁移到新接口同时保证已有测试全绿——这些任务有清晰的成功标准，一个模型能拿测试、类型检查、构建结果当证据来判断自己做得对不对，特别适合交给一个跑在时间表上的循环。
不太适合的，是那些一次性的、探索性的、或者高度依赖你个人判断的活。需求本身还没想清楚的时候，方向上有重大取舍要拍板的时候，或者根本没有一个干净的验收测试能让循环对着自己打分的时候，硬套一个循环，往往只会让一个错误的方向被更快地推下去。这种时候，你亲手一回合一回合地带着智能体走，依然是最有效的。
还有一点：循环工程目前仍处在很早的阶段，token的开销也会大幅波动。一个每回合都跑验证模型的定时循环，烧起token来可以很快。比较稳妥的做法是从慢一点的频率和收得很紧的目标条件开始，盯几天成本，等它确实产出了你愿意合并的活，再往上加码。
循环解决不了的那些问题
循环改变了工作的方式，但它不会把你从工作里删掉。有三个问题，会随着循环变得更好而变得更尖锐。
一是验证，责任始终在你身上。一个无人值守地运转的循环，同时也是一个无人值守地犯错的循环。你把验证型子智能体从写代码的那个拆出来，就是为了让循环口中的"完成"有点分量。但即便如此，"完成"也只是一个声明，不是一份证明。你要交付的是你确认过能跑的代码，所以对已合并改动的人工复核，无论验证者多强，都得留在环里。
二是理解欠债会涨得更快。循环把你没亲手写的代码交付得越快，仓库里实际存在的东西和你真正理解的东西之间的差距就越大。一个顺滑的循环只会让这道缝隙裂得更快，除非你去读它产出了什么。
三是放弃思考是那种很舒服的失败方式。当循环自己跑起来，人很容易就不再有自己的看法，它返回什么就接受什么。设计循环这件事，在你带着判断去做时是解药，在你为了逃避思考去做时是催化剂。同样一个动作，结果相反。
所以，比较稳的态度是：把循环搭给那些重复的、可验证的活，把直接控制权留给那些你的判断本身就是价值的部分。搭这个循环的时候，把自己当成一个打算继续当工程师的人，而不只是那个负责按下启动键的人。
提示词工程没有过时，亲手带着智能体干活在很多时候依然好用。Loop Engineering加上来的，是一层新的手艺：当单个智能体不再是瓶颈的时候，你该如何去设计那套替你提示它、验证它、在合适的时候喊停的系统。
相关阅读: harness 怎么训练 harness
你的智能体为什么总是忘记你说过的话
智能体开始进入「复盘 — 评测 — 改进」的循环
