循环工程Loop engineering的核心是从手动提示AI智能体转变为设计出能够自动提示它们的系统。本文将详细解释这一概念的内涵、构成智能体循环的五大核心模块外加记忆Claude Code和OpenAI Codex如何实现每个模块一个真实的端到端循环案例以及随着循环能力提升而愈发尖锐的风险。引言从手动提示到系统设计在过去大约两年的时间里你从编码智能体身上获取价值的方式很简单写一个好提示prompt提供足够的上下文阅读返回结果然后输入下一步指令。你全程手握工具一回合接一回合地操作。然而从2026年6月起这种模式开始发生转变。“循环工程”一词应运而生它精准地捕捉到了价值杠杆点的根本性迁移你不再是那个直接向智能体发号施令的人而是转而成为设计那个发号施令系统的架构师。这一说法由谷歌工程师Addy Osmani推广开来呼应了Peter Steinberger的观点——“你应该设计出能提示你智能体的循环”以及Anthropic Claude Code负责人Boris Cherny的评论——他的工作重心已经从直接提示模型转向编写循环。尽管这项技术仍处于早期阶段其Token经济成本可能剧烈波动且验证难度前所未有但构成循环的各个模块如今已内置于你日常使用的产品中。因此无论你是否全面采用理解这一模式都至关重要。本指南将为你拆解循环工程的真实含义它与提示工程Prompt Engineering、上下文工程Context Engineering的区别在概念诞生前就已证明其可行性的“拉尔夫技巧”Ralph Technique构成一个完整循环的五大核心模块外加记忆Claude Code和OpenAI Codex如何分别实现这些模块如何编写一个智能体无法伪造的停止条件一个安全采用循环的成熟度阶梯一个真实循环的端到端全景以及随着循环能力提升失败模式会变得更加尖锐而非简单化如果你使用智能体进行编码那么这就是你技艺的下一层境界。1. 循环工程的真实含义循环工程的本质是用一个系统取代你自己来向智能体发出提示。这里的“循环”指的是一种递归式的目标你只需定义一次目标智能体便会不断迭代直至工作真正完成。你不再需要在每次收到回复后手动输入下一条指令。取而代之的是一个小型系统会自动发现任务、分发任务、检查结果、记录已完成的工作并决定下一步该做什么。你让这个系统去“戳”智能体而不是自己亲自动手。最有助益的心智模型是一个编码智能体在每一次交互回合中其内部已经运行着一个循环。它会思考要做什么采取行动调用工具、编辑文件、运行测试观察结果然后基于新的状态再次进行推理。这个“感知-推理-行动-观察”的周期就是智能体的内在循环。而循环工程则位于这个内在循环之上一层。你不再手动操控每一个回合而是构建一个外部循环。这个外部循环可以按计划运行、生成助手、自我供给任务并在你无需亲自坐镇的情况下持续驱动多个内在循环的运转。一句话定义循环工程就是构建一个能按计划、围绕目标自动向你的智能体发出提示的系统而不是每次都手动输入提示。价值杠杆点从单个提示的质量转移到了生成和验证提示的系统设计上。早期采用者感到惊讶的是这已不再是“自己动手丰衣足食”的时代。一年前“循环”还意味着一堆只有你自己懂、且需要永久维护的Bash脚本。而到了2026年年中这些功能模块已经内置于产品之中。Peter Steinberger列出的循环所需清单几乎与OpenAI Codex应用的功能完全吻合也与Anthropic的Claude Code高度一致。一旦你注意到不同工具间的结构如此相似你就会停止争论哪个智能体更好转而开始设计一个无论使用哪个工具都能有效工作的循环。循环工程是你可能已经接触过的两个概念的“智能体化”延伸。如果你来自“氛围编程”vibe coding那么循环工程就是当这些“氛围”需要在无人值守、甚至你合上笔记本电脑后依然能持续运行时所必需的东西。如果你读过关于Claude Code多智能体团队开发的文章那么循环工程就是将这些智能体编排成一个自运行周期的纪律。2. 从提示工程到循环工程将循环工程视为近几年逐步构建起来的技术栈中的第三层会很有帮助。每一层都包裹着其内部的一层并且每一层都将价值杠杆点从原始的模型调用中进一步向外移动。层级优化对象工作单元提示工程如何措辞单条指令你手动输入的一个回合上下文工程窗口中还有什么文档、历史、工具定义围绕单次回答的环境条件循环工程决定何时提示、提示什么以及结果是否可接受的系统跨越多个回合的自运行周期提示工程永远不会消失。循环本身就是由提示构建而成的循环内部一个草率的提示只会更快地产生草率的工作。上下文工程同样不会消失循环在每个回合仍然必须将正确的文件、历史和工具定义呈现在模型面前。循环工程所增加的是围绕这一切的自主控制结构。如果说“智能体框架”harness负责运行单个智能体那么循环工程则是让这个框架按计时器运行、生成助手并自我供给任务。⚠️杠杆点转移了但工作并未变简单Boris Cherny的观点并非编码变简单了而是你能做的最高价值的事情已经从编写提示转向了设计循环。一个设计精良的循环能成倍放大优秀工程师的能力而一个设计糟糕的循环则会以同样快的速度放大错误的决策并且在此过程中你的监督更少了。若想深入了解与智能体逐回合协作的日常技艺请参阅我们对AI编码智能体的对比分析。当你发现单个智能体不再是瓶颈时循环工程就是你的下一个目标。3. “拉尔夫技巧”循环的起源在“循环工程”这个名词出现之前就已经有了“拉尔夫”Ralph。2026年初Geoffrey Huntley描述了一种在普通while循环内运行编码智能体的方法让智能体针对一份书面规范反复接收相同的提示让它挑选一个任务并实现然后启动一个全新的实例再次喂给它完全相同的提示。如此往复直到工作完成。他将其命名为“拉尔夫”灵感来自《辛普森一家》的角色拉尔夫·维古姆Ralph Wiggum因为在他看来这种技巧在一个不可预测的世界里展现了一种确定性的简单。它看起来笨到不可能成功却偏偏有效。其非显而易见的洞见在于上下文重置。长时间的智能体会话会随着窗口被旧的推理、死胡同和过时的文件内容填满而性能下降。“拉尔夫”则完全规避了这一点每次迭代都是一个拥有干净上下文的新智能体它从磁盘上读取代码库的当前状态和任务列表只执行一个工作单元提交更改然后退出。智能并不依赖于一次英雄式的长跑而是依赖于清晰、细粒度的规范和可验证的结果并通过一个模型无法污染的外部记忆反复应用。“拉尔夫循环”每次新鲜上下文只处理一个任务while !done run agent Read spec state Do one task Test commit Reset context磁盘上的任务列表是唯一能在重置后幸存的记忆。在其最原始的形式中“拉尔夫循环”不过是几行Shell脚本。智能体本身提供智能而循环只提供持久性和每次通行时的全新起点。# 原始的“拉尔夫循环”相同提示新鲜上下文直至完成while!grep-qALL TASKS DONESTATUS.md;do# 每次通行都是一个拥有空上下文窗口的全新智能体claude-pRead PLAN.md and STATUS.md. Pick the next unchecked task, implement it, run the tests, commit on success, and update STATUS.md. Then stop.\--dangerously-skip-permissionsdone# PLAN.md 和 STATUS.md 是持久记忆。智能体在两次通行之间会忘记一切# 文件则会记住哪些工作已完成。上面的内容如果你看得比较懵懂我们用一个更形象的例子来讲解拉尔夫技巧核心思想用“笨办法”解决AI的“健忘”和“钻牛角尖”问题想象一下你让一个AI助手帮你完成一个大项目比如“开发一个待办事项App”。如果你一次性把所有要求告诉它然后让它从头干到尾可能会出现以下问题AI会“健忘”随着对话越来越长AI的“上下文窗口”被填满它可能会忘记最初的需求或者被自己之前错误的推理带偏。AI会“钻牛角尖”如果它在某个小问题上卡住了比如一个bug它可能会在接下来的几十次尝试中反复纠结于这个点越陷越深无法自拔。状态混乱AI内部的“思考状态”会变得非常混乱难以保证最终结果的可靠性。“拉尔夫技巧”就是为了解决这些问题而生的。它的精髓在于“重启”和“外部记忆”。具体是怎么操作的我们可以把它想象成一个非常有条理、但有点死板的实习生。准备两份文件外部记忆PLAN.md这是项目总计划书。里面清晰地写着所有要做的任务比如创建项目骨架实现添加待办事项功能实现删除待办事项功能编写单元测试部署到服务器STATUS.md这是任务进度表。它会实时更新哪些任务完成了比如创建项目骨架实现添加待办事项功能实现删除待办事项功能…给AI下指令永远不变的提示“你好请读取PLAN.md和STATUS.md。从STATUS.md里找到第一个还没打勾[ ]的任务只做这一件事。完成后运行测试如果成功了就在STATUS.md里给它打勾[x]然后立刻停止工作。”启动“拉尔夫循环”那个while循环第1次电脑启动一个全新的、脑子完全空白的AI。AI读取PLAN.md和STATUS.md发现全是[ ]于是它开始做“创建项目骨架”。完成后它更新STATUS.md然后退出。第2次电脑再次启动一个全新的、脑子完全空白的AI。AI读取PLAN.md和STATUS.md发现第一项是[x]第二项是[ ]于是它开始做“实现添加待办事项功能”。完成后更新文件退出。第3次、第4次…如此循环往复。何时停止当AI读取STATUS.md时发现所有任务都打上了[x]它就知道工作完成了整个循环就结束了。为什么叫“拉尔夫”它“笨”在哪里“有效”又在哪里“笨”因为它看起来效率很低。每次都要启动一个新AI都要重新读一遍计划和状态。就像一个实习生每次只被允许做一件事做完就要“失忆”下次再来又要从头看文档。这不符合我们人类高效协作的直觉。“有效”永不健忘因为每次都从干净的PLAN.md和STATUS.md读取信息所以永远不会偏离最初的计划。永不钻牛角尖如果某次AI没完成好任务比如测试没通过它就不会更新STATUS.md。下一次循环启动的新AI会看到任务还是[ ]于是会重新尝试而不是在上次失败的地方继续浪费时间。结果可验证每一步的成功与否都由“是否能通过测试并更新状态文件”来客观衡量而不是由AI自己说了算。简单可靠整个逻辑就是一个简单的while循环没有复杂的内部状态管理非常稳定。总结来说“拉尔夫技巧”就是利用外部文件作为“大脑”而让AI只充当一个“手脚”——每次只执行一个明确、微小、可验证的动作。通过无数次这种“笨拙”的重复最终可靠地完成复杂任务。这正是它在充满不确定性的AI世界里展现出的“确定性的简单”。循环工程就是产品化的“拉尔夫”“拉尔夫”是一个概念验证它证明了你不需要一个聪明的框架只需要持久性、一个外部状态文件和可验证的停止标准。循环工程正是当这些理念被内置于工具中时所发生的事情while循环变成了一个计划自动化任务上下文重置通过工作树worktree和子智能体sub-agent实现而“ALL TASKS DONE”检查则变成了由另一个独立模型评分的/goal条件。形状相同但棱角更少。4. 五大核心模块外加记忆一个能工作的循环需要五样东西以及一个用于记住状态的地方。不同工具对这些模块的命名略有差异但能力是相同的。以下是清单以及这些模块如何融入一个自运行周期的示意图。自动化Automations能按计划触发并自行进行任务发现和分类。工作树Worktrees确保并行工作的两个智能体不会互相覆盖对方的文件。技能Skills将项目知识记录下来避免智能体在每次会话中都靠猜测。插件与连接器Plugins and connectors将智能体接入你已在使用的工具。子智能体Sub-agents让一个智能体负责构思另一个负责检查。第六部分是记忆Memory一个Markdown文件、一个Linear或GitHub看板任何存在于单次对话之外、能记录已完成和待办事项的地方。这听起来简单到微不足道但却是所有长期运行智能体所依赖的诀窍。模型在两次运行之间会忘记一切因此状态必须存储在磁盘上而不是上下文窗口里。智能体会遗忘但代码库不会。一个智能体循环的解剖图自动化按计划触发发现并分类任务子智能体起草变更验证者子智能体进行检查连接器打开PR和工单进入下一周期磁盘上的记忆持久化状态令人欣慰的是到了2026年年中你已无需从零开始组装这一切。Claude Code和OpenAI Codex都内置了这五大模块及持久记忆虽然命令名称不同但结构一致。接下来的章节将逐一介绍每个模块的功能以及两大主流工具如何实现它们以便你能设计出一个在工具切换时依然健壮的循环。如果你想了解跨多个自主智能体拆分工作的具体工具机制我们关于OpenAI Codex子智能体和自主编码团队的指南深入探讨了编排层。5. 自动化循环的心跳自动化是让循环成为一个真正的“循环”而不仅仅是一次性运行的关键。它是循环的“心跳”一个无需你主动询问就能自动浮现任务的重复触发器。循环中的其他一切都是对自动化所发现内容的响应。在OpenAI Codex中Codex应用有一个“Automations”自动化标签页你可以在此选择项目、要运行的提示、运行频率以及是在本地检出checkout还是后台工作树中运行。发现任务的运行会被放入一个“Triage”分类收件箱未发现任务的运行则会自动归档。OpenAI内部使用自动化来处理常规工作如问题分类、警报监控、总结CI失败原因和撰写提交简报。自动化可以调用一项“技能”skill从而使重复性指令易于维护你只需触发一个命名好的技能而不是将一大段指令粘贴到一个无人会更新的日程表中。在Claude Code中Claude Code通过调度和钩子hooks达到同样的目的。/loop命令可以在一个时间间隔内调度重复提示它会将你的频率转换为cron作业并确认一个作业ID钩子会在智能体生命周期的特定点触发Shell命令你还可以将整个流程推送到GitHub Actions使其在你关闭笔记本电脑后继续运行。第二个会话内的原语最接近循环工程/goal会持续工作跨越多个回合直到你编写的某个条件被明确证实为真。并且在每个回合之后一个独立的、更小的模型会检查你是否已完成从而确保编写代码的智能体不是给自己打分的那个。# Claude Code: 每个工作日早上9点运行一次重复的分类提示/loopRead yesterdays CI failures and open issues, write findings to TODO.md, and draft fixes for anything labeled quick-win--schedule0 9 * * 1-5# Claude Code: 运行直到一个可验证的停止条件成立/goalAll tests in test/auth pass and lint is clean# OpenAI Codex: 持久化的长期目标 (CLI 0.128.0)codex /goalMigrate the billing module to the new pricing API, keep all existing tests green截至2026年年中的现状Claude Code在v2.1.139版本2026年5月11日中发布了/goal目前运行在2.1.x系列上默认模型为Opus 4.8并支持编排大型子智能体集群的动态工作流。OpenAI Codex也在CLI 0.128.0中加入了匹配的/goal功能。这一能力已经足够真实以至于从业者报告称智能体可以在单个目标上无人值守地工作数十小时这也使得下面提到的停止条件成为你所编写的最重要的东西。⚠️警惕Token账单一个在每个回合后都运行验证模型的计划循环会快速消耗Token其用量会因自动化触发频率和生成的子智能体数量而剧烈波动。请从较慢的频率和严格的goal条件开始观察几天的成本只有在循环产生的工作确实被你合并后再考虑扩大规模。两种工具的形态是相同的定义一个自主任务赋予其运行节奏然后让发现结果主动来找你而不是你自己四处检查。特别是/goal原语已成为2026年讨论最多的智能体原语正是因为它能让循环在没有人类介入的情况下自行判断是否完成。像写合同一样编写停止条件而不是许愿一个目标的好坏取决于证明其达成的证据。“让结账流程变得更好”无法为循环提供任何自我评估的依据因此它会在自己感觉良好时就停止。那些运行长时间、无人值守智能体的实践者们都收敛到了同一个解决方案明确指定期望的最终状态、证明成功的必要证据、不得违反的约束条件以及回合数或预算的硬性上限。智能体只是执行者你则要编写它在被允许声称“完成”之前必须通过的验收测试。合同字段弱化版本可验证版本最终状态“提高测试覆盖率”“src/billing的覆盖率需达到或超过90%”证据“看起来完成了”“npm test退出码为0且覆盖率报告确认了该数字”约束未说明“不得触碰公共API或删除现有测试”预算无限制“在25个回合或5美元后停止以先到者为准”让循环值得信赖的三大改变Claude Code团队围绕三个习惯来构建可靠的循环保留错误以便循环能从中学习而非重复犯错将验证构建到循环内部而不是事后附加并将失败的测试或红色CI视为让智能体保持诚实的信号。一个没有失败证据对抗的循环总会认为自己成功了。6. 工作树实现无冲突的并行智能体一旦你运行不止一个智能体文件冲突就开始了。两个智能体写同一个文件就如同两个工程师在没有沟通的情况下向同一行代码提交更改一样令人头疼。Git工作树worktree解决了这个问题它是在自有分支上的一个独立工作目录共享相同的代码库历史因此一个智能体的编辑根本无法触及另一个智能体的检出checkout。Codex直接内置了工作树支持因此多个线程可以同时访问同一个代码库而不会互相干扰。Claude Code则通过git worktree、一个--worktree标志用于在自有检出中打开会话以及一个可应用于子智能体的isolation: worktree设置来提供相同的隔离效果确保每个助手都能获得一个在完成后会自动清理的全新检出。在底层它就是普通的Git。如果你想看看工具封装的机制可以手动运行两个工作树每个都是自有分支上的一个真实目录因此两个智能体可以并行构建而你则像处理任何其他PR一样合并这些分支。# 从同一个代码库为每个智能体创建两个隔离的检出gitworktreeadd../app-fix-login-bfix/login-flakegitworktreeadd../app-bump-deps-bchore/bump-deps# 智能体A在../app-fix-login中工作智能体B在../app-bump-deps中工作。# 两者都无法触及对方的文件历史是共享的。# 当每个分支都通过测试后合并并清理其工作树gitmerge fix/login-flakegitworktree remove../app-fix-login# Claude Code会为每个子智能体自动执行相同的操作# .claude/agents/fixer.md - isolation: worktree你依然是天花板工作树消除了机械性的冲突但并未消除审查瓶颈。你阅读和批准合并工作的带宽决定了你实际能运行多少个并行智能体而不是工具能为你生成多少个工作树。十个你无法审查的智能体所产生的变更远不如两个你能审查的要好。7. 技能与记忆告别对项目的反复解释“技能”Skill是你避免在每次会话中都反复解释相同项目上下文的方法。两种工具都使用相同的格式一个包含SKILL.md文件用于存放指令和元数据的文件夹以及可选的脚本、引用和资产。当你用$或/skills调用Codex时或者当任务与技能描述匹配时Codex就会运行该技能这也是为什么一个简洁、直白的描述胜过一个巧妙的描述。Claude Code的工作方式也完全相同。当你想在多个代码库间共享技能或将几个技能打包在一起时你可以将它们打包成一个插件技能是创作格式插件是分发方式。技能之所以故意做得小巧而直白是有原因的。以下就是一个真实的例子一个分类技能供早上的自动化任务按名称调用这样重复性指令就存在于版本控制中而不是被粘贴到一个日程表里。# .claude/skills/triage-ci/SKILL.md --- name: triage-ci description: Read overnight CI failures and open issues, then write a prioritized findings list to TODO.md. Read-only on code. --- 1. Run gh run list --status failure --limit 20 and read the logs. 2. Cross-reference open issues with gh issue list --label bug. 3. Group failures by root cause, not by individual test. 4. Append findings to TODO.md under ## Open, newest first. 5. Label anything fixable in one file as quick-win. 6. Do NOT edit application code. This skill only triages.技能是让你的意图不再被反复消耗的地方。智能体每次会话都是从零开始的它会用自信的猜测来填补你意图中的任何空白。技能就是将这些意图明确地书写在外部约定、构建步骤、“我们不这样做是因为那次事故”。没有技能循环会在每个周期都从零开始重新推导你的整个项目。有了技能知识就能在多次运行中不断累积。记忆是技能的近亲也是任何运行时间超过单次对话的循环的脊柱。技能保存的是持久性知识我们如何构建、我们的约定是什么。记忆保存的是变化的状态尝试了什么、什么通过了、什么还开着。它可以是一个Markdown文件、一个Linear看板或一个GitHub问题列表。唯一的前提是它必须存在于上下文窗口之外因为模型在两次运行之间会忘记一切。明天早上的运行会读取状态文件并恰好从今天停止的地方继续。机制保存内容存放位置技能持久的项目知识和约定代码库中的SKILL.md记忆变化的状态已完成、待办Markdown文件或问题看板连接器对外部工具和数据的访问MCP服务器配置插件与连接器让循环触及你的真实工具一个只能看到文件系统的循环是微不足道的。基于模型上下文协议MCP构建的连接器能让智能体读取你的问题跟踪器、查询数据库、调用预发API或在Slack中发送消息。Codex和Claude Code都支持MCP因此你为其中一个编写的连接器通常也能在另一个中工作。这正是一个只会说“这里有修复方案”的智能体与一个能自动打开PR、关联工单并在CI通过后通知频道的循环之间的区别。如果你是MCP新手我们的MCP开发者指南涵盖了连接器的构建和安全保障这一点在循环能够无人值守地在你的真实环境中行动时至关重要。8. 子智能体分离创造者与检查者在循环中最有用的结构性举措就是将编写代码的智能体与检查代码的智能体分开。编写代码的模型在给自己打分时过于宽容。一个拥有不同指令有时甚至是不同模型的第二智能体能捕捉到第一个智能体自我说服而忽略的问题。在Codex中你可以在.codex/agents/目录下将子智能体定义为TOML文件每个文件包含名称、描述、指令以及可选的模型和推理强度。你的安全审查员可以是一个高强度的强模型而你的探索者则可以是一个快速的只读模型。Codex会在你请求时生成子智能体让它们并行运行并将结果汇总成一个答案。Claude Code在.claude/agents/中以相同方式处理子智能体并通过智能体团队在它们之间传递工作。两者通常的分工是一个智能体负责探索一个负责实现一个负责对照规范进行验证。# .codex/agents/verifier.toml name verifier description Adversarial reviewer. Gates a draft before it reaches a human. model gpt-5.5 reasoning_effort high instructions Run the full test suite and lint before forming any opinion. Check the diff against CONVENTIONS.md and the issues acceptance criteria. Reject anything that is not verifiably done: no green tests, no approval. Report findings as a short PASS/FAIL list with the evidence for each. 为何在循环内部这种分离至关重要循环在你不在场时运行因此一个你真正信任的验证者是你能够放心离开的唯一理由。这也是Claude Code的/goal在底层所做的事一个全新的模型来判断循环是否完成而不是由那个执行工作的模型来判断。创造者-检查者的分离甚至被应用到了停止条件本身。子智能体确实会消耗更多Token因为每个都会运行自己的模型和工具调用所以要把它们用在值得付费获取第二意见的地方。若想了解将多个智能体组织成一个审查团队的完整机制请参阅我们关于Claude Code智能体团队的指南。9. 一个端到端的循环长什么样将各个模块组合起来单一线程就变成了一个小型控制面板。以下是一个作为首个循环非常有效的结构并且由于原语相同它能清晰地映射到Codex和Claude Code上。一个自动化任务在每个工作日早上于代码库上运行。它的提示会调用一个分类技能。该技能会读取昨天的CI失败、开放问题和最近的提交然后将发现结果写入一个记忆文件或Linear看板。对于每个值得处理的发现线程会打开一个隔离的工作树并派遣一个子智能体去起草修复方案。第二个子智能体会根据项目技能和现有测试来审查该草案。连接器会打开PR并更新工单。循环无法处理的任何事项都会落入你的分类收件箱。状态文件是整个事情的脊柱。它会记住哪些尝试过、哪些通过了、哪些还开着因此明天早上的运行能恰好从今天停止的地方继续。看看你实际做了什么你只设计了一次系统。你并没有手动提示其中任何一个步骤。这正是循环工程的全部意义所在无论你是在Codex还是Claude Code中运行它都是同一个循环。# .claude/agents/reviewer.md (检查者与创造者分离) --- name: spec-reviewer description: Reviews a draft change against project skills and tests. model: opus # 用于验证者的强模型 isolation: worktree # 全新检出无冲突 --- You are an adversarial reviewer. Run the test suite, check the diff against CONVENTIONS.md, and reject anything that is not verifiably done. # TODO.md (记忆在每次运行后幸存) ## Open - [ ] flaky test in test/auth/login.spec.ts (CI run #4821) ## Done - [x] bump axios to patched version (PR #312, merged)如果你是第一次构建循环可以从比这更小的规模开始。一个每天早上自动将CI失败分类到Markdown文件的单一自动化任务不自动合并就已经能移除一项重复性杂务并让你在信任它去开PR之前先观察循环的行为。采用循环的成熟度阶梯你不会直接跳到自动合并的循环。要一级一级地赢得信任只有在当前级别产生的工作是你本来就会手动完成的情况下才向上攀登。每个级别只增加一项新能力并在有证据表明你可以放手之前始终保持人工介入。级别循环能做什么人工仍在路径中0. 手动你逐回合提示智能体每个回合1. 分类计划运行将发现结果写入Markdown文件不修改代码你阅读并处理这些发现2. 起草循环在隔离的工作树分支上起草修复方案你审查并合并每个PR3. 已验证的PR验证者子智能体在PR到达你之前进行把关你批准验证者过滤4. 自动合并低风险类别依赖升级、lint、重试不稳定测试在CI通过后自动合并你审计日志而非每个变更10. 循环工程无法解决的风险循环改变了工作方式但并未将你从工作中剔除。有三个问题实际上会随着循环的完善而变得更加尖锐而非更容易。循环工程的部分要义就在于围绕这些问题进行设计。1. 验证责任仍在你身上一个无人值守运行的循环也是一个在无人看管下犯错的循环。你将验证者子智能体与创造者分离的全部原因就是为了使循环所说的“已完成”具有实际意义。即便如此“已完成”也只是一个声明而非证明。你的工作是交付经过你确认能正常工作的代码这就是为什么无论验证者多么优秀对已合并变更的人工审查都必须保留在循环中。2. 理解债务加速累积循环交付你未曾编写代码的速度越快代码库中存在的代码与你实际理解的代码之间的差距就越大。一个顺畅的循环只会让这个差距加速扩大除非你去阅读循环所产生的内容。这与AI辅助编程一直存在的“理解债务”comprehension debt是同一个问题只是被加速了。3. 认知投降是最舒适的失败当循环能够自行运行时人们很容易放弃自己的判断全盘接受它返回的任何结果。当你带着判断力去设计循环时它是解药当你用它来逃避思考时它就成了加速器。同样的行动却导致相反的结果。两个人可以构建完全相同的循环却得到截然相反的结局一个人在自己深刻理解的工作上加速前进另一个人则完全回避对工作的理解。循环本身无法分辨其中的差异但你能。⚠️构建循环但保持工程师身份循环工程仍处于早期阶段直接手动提示智能体依然有效。目标是取得平衡为那些重复性、可验证的工作建立循环而在你的判断力就是价值所在的环节保留直接控制权。要像一个打算始终担任工程师的人那样去构建循环而不仅仅是一个按下“开始”按钮的人。安全维度值得单独关注一个拥有连接器访问权限的自主循环可能会触及生产系统。我们的AI智能体安全指南涵盖了在让循环无人值守地运行于真实基础设施之前所需的防护栏、权限和审计日志。11. 为何选择Lushbinary进行智能体工程循环工程威力强大但设计一个既能交付可靠代码又不会悄然累积风险的循环确实非常困难。这需要优秀的技能创作、一个值得信赖的验证者、合理的节奏与成本控制以及能让循环安全接触真实系统的安全管道。Lushbinary自GPT-4时代起就在医疗健康、金融科技、SaaS和电子商务领域构建生产级AI集成和智能体工作流。我们在智能体工程设置方面能为你带来循环与框架设计我们为你设置可在Codex和Claude Code间通用的自动化、工作树、技能、连接器以及创造者-检查者子智能体拆分。技能与记忆创作我们捕获你的约定、构建步骤和项目知识让循环停止猜测开始累积。验证器与评估设计我们构建可验证的停止条件和对抗性审查智能体让“完成”二字名副其实。成本与节奏调优我们监控Token使用情况并调整日程确保循环能自给自足而不是给你带来意外的账单。安全与AWS基础设施包括连接器权限、审计日志以及在AWS上部署生产环境所需的、满足无人值守循环要求的防护措施。免费的智能体工作流咨询想应用循环工程又不想面对失控的Token账单或未经审查的合并吗Lushbinary将审查你当前的智能体设置为你量身定制一个适配你代码库的循环并推荐安全运行所需的验证和成本控制措施——无需承担任何义务。12. 常见问题解答FAQ什么是循环工程循环工程是一种实践即设计一个能按计划向AI智能体发出提示的系统而不是每次都手动输入提示。你定义一个递归目标为智能体提供一种发现任务、执行任务、验证结果并记住已完成事项的方法然后让该系统驱动智能体。该术语由Addy Osmani于2026年6月推广其思想基础来自Peter Steinberger和Anthropic的Boris Cherny。循环工程与提示工程有何不同提示工程优化的是你手动输入的单条指令一次一个回合。循环工程优化的是自主系统该系统决定提示什么、何时提示以及结果是否可接受。提示工程将智能体视为你手中的工具循环工程则将其视为一个具有记忆、调度、评估和编排能力的长期运行进程。什么是“拉尔夫技巧”拉尔夫·维古姆循环“拉尔夫技巧”由Geoffrey Huntley于2026年初提出以《辛普森一家》角色拉尔夫·维古姆命名。它在一个普通的while循环内运行一个编码智能体针对一份书面规范反复提供相同的提示让智能体完成一个任务并提交然后启动一个拥有干净上下文的新实例再次提供相同的提示如此重复直到满足成功标准。其智能来源于清晰的规范、可验证的结果以及一个外部状态文件而非一次长时间的会话。循环工程正是将这一理念内置于Claude Code和Codex等工具中其中while循环变成了计划自动化而完成检查则变成了可验证的目标条件。智能体循环的构建模块有哪些一个实用的循环包含五个模块加一个记忆存储用于发现和分类的计划自动化、用于避免并行智能体冲突的Git工作树、用于捕获项目知识的技能、用于将智能体接入你真实工具的插件和MCP连接器以及用于分离创造者与检查者的子智能体。第六部分是磁盘上的持久记忆一个Markdown文件或问题看板它能在多次运行之间幸存下来。Claude Code和OpenAI Codex支持循环工程吗是的。两者都提供了核心原语。Claude Code有/loop用于重复计划提示有/goal用于运行直到可验证条件成立还有钩子、子智能体和工作树隔离。OpenAI Codex有Automations用于非提示的重复工作有/goal命令于2026年4月30日在Codex CLI 0.128.0中添加内置工作树、技能和TOML定义的子智能体。两者的连接器都基于MCP构建。循环工程的风险有哪些一个无人值守的循环也是一个在无人看管下犯错的循环。主要风险包括弱验证智能体在没有证据的情况下声称完成、理解债务代码交付速度超过你的理解速度和认知投降不加判断地接受循环返回的任何结果。缓解措施包括使用独立的验证者子智能体、对已合并代码进行人工审查以及让工程师始终参与设计和审查流程。参考文献https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/https://www.runoob.com/ai-agent/loop-engineering.htmlhttps://www.runoob.com/claude-code/claude-code-tutorial.htmlhttps://www.runoob.com/codex/codex-tutorial.htmlhttps://muximxc.github.io/loop-engineering-guide/
