循环工程入门

几个月前，开发者的夜晚往往是这样的：打开编码代理，输入指令，等待，阅读返回内容，将错误粘贴到聊天中，再次等待，稍作调整后重复，直到功能真正生效或到了睡觉时间。代理确实在做实际工作，但人类仍需全程陪同，就像驾驶一辆每三秒就需要扶一下方向盘的汽车。

如今，越来越多的工程师的夜晚已变得不同。他们写下一句指令，合上笔记本电脑，第二天早上回来时看到的是拉取请求草稿、分类的问题列表或绿色CI构建，以及代理尝试过程和原因的清晰记录。没有人站在旁边输入下一个提示。改变的不是模型，而是模型周围构建的系统。

这个转变的名称就是循环工程，它在2026年6月的一周内从小众术语变成了各大平台热议的话题。本文介绍该术语的起源、其衍生的研究、循环的构成以及如何构建一个小型循环。

循环工程的实际含义

循环工程是设计提示、检查、记忆和重新运行AI代理的系统，而不是由人来手动逐轮完成所有工作。工作单位不再是单个提示或单个对话，而是一个循环：模型执行行动、从环境获取反馈、利用反馈决定下一步行为，并持续进行直至满足真实的可检查条件。

这与它所取代的方式形成对比。链式操作按固定顺序执行：步骤A到B到C，各步骤固定。而循环是动态的：代理可能从A到B，发现B不成功后修改方法，然后才进入C，甚至完全回到A。循环持续直到任务真正完成、触发停止条件或代理确定无法继续。这与“问一次、得到答案、复制出来”的工作形态根本不同。

另一个值得思考的框架是“递归目标”概念：你定义目的——如“使测试套件通过”或“分类所有开放问题并修复简单的”——代理自行迭代：检查代码、进行更改、运行检查、读取结果、决定下一步。技能从写一句好提示转变为设计一个值得信赖并可以离开的循环。

术语几乎一夜之间成型

时间线是故事的一部分。2026年6月7日，开发者Peter Steinberger（OpenClaw代理项目）发布推文称相关技能已经改变：不应再对编码代理进行提示，而应设计代理为你提示的循环。该推文数天内获得超过650万次浏览，并主导了接下来一周的代理相关对话。

第二天，谷歌工程师兼作者Addy Osmani发表了题为“循环工程”的文章，将Steinberger的论断具体化为结构：自动化、工作树、技能、连接器和子代理，以及第六个基础组件——外部记忆。这篇文章将病毒式观点转化为可供他人构建和讨论的词汇。

不仅是外部人士如此主张。Anthropic Claude Code负责人Boris Cherny引用Osmani的话说：“我不再提示Claude了。我运行循环来提示Claude，并决定下一步做什么。我的工作是编写循环。”当最常用的编码代理构建者表示他不再直接提示代理时，这个想法显然已超越边缘观点。

时间线合理：到2026年中，编码代理已足够优秀，能够长时间无人值守运行，自行从错误中恢复，而无需每两三步就修正。当单个代理运行可长达一小时并触及数十个文件时，瓶颈不再是提示的精确性，而是你构建的循环是否能在整个小时（包括无人监督的部分）保持代理高效、受控并指向正确目标。

所处位置：提示、上下文、框架、循环

循环工程并非凭空出现，它是层层递进的最新一层，每一层包裹而非取代前一层。

提示工程最先出现，约2022-2024年，重点是措辞：为模型分配角色、分解任务、提供示例、要求逐步推理。它优化表达，天花板有限。

上下文工程随之而来，约2025年，焦点从词语本身转向模型响应时所见的一切：对话历史、检索文档、工具输出等。Shopify的Tobi Lütke在2025年中给出了一个定义：提供任务可能被模型解决所需的所有上下文。Anthropic在2025年9月将其形式化为在推理过程中策划和维护最佳可用令牌集。提示工程成为上下文工程的一个组成部分。

框架工程于2026年初出现，代理在真实生产环境中开始进行更长时间、更自主的多步骤工作。框架是代理的完整环境——脚手架、工具、约束和捕获错误的反馈循环。它使代理可靠而非仅仅有能力，并包含前两层：框架包含上下文，上下文包含提示。

循环工程位于三者之上。框架工程关注代理所需的环境，而循环工程关注更具体的问题：什么循环使代理朝着目标工作，循环何时停止？这些层次没有取代之前的层次。你仍需编写提示、策划上下文、构建框架。循环工程是将所有这些付诸行动并赋予节奏的部分。

术语背后的研究

循环工程容易被看作2026年6月一周内发明的事物，但其机制已有近五年历史，了解其谱系有助于真正理解而非重复趋势文章。

直接祖先是ReAct模式（Reason加Act），2022年由Yao等人提出。核心思想是推理步骤与行动步骤交错：模型思考、行动、观察结果、再次思考、再次行动。这种交错——推理、行动、观察、重复——是几乎所有现代编码代理仍在运行的基本循环。

一年后，2023年Shinn等人的Reflexion引入了记忆和自我批评。Reflexion代理运行三个不同角色：Actor进行工作，Evaluator对结果评分，Self-Reflection将口头经验写入情景记忆，代理在下次尝试时读取。这是循环在会话中可见改善的机制，无需重新训练模型。

Anthropic在2024年12月的《构建有效代理》指南中提到了另外两种模式：评估者-优化者模式，一个模型生成候选方案，另一个模型对照标准检查并反馈，直至通过；协调者-工作者模式，中央模型动态将大任务拆分为小任务，每个任务分配独立上下文窗口的工作者，然后合并结果。这些正是Osmani文章中“子代理”和“工作树”的形式化版本。

回顾这些研究的目的是说明“循环工程”是一个产品名称和集合性短语，而研究方向自2022年以来一直在积累成果。2026年6月的事件没有发明循环，而是给了普通开发者一个理由和词汇去有意识地构建循环。

循环的解剖结构

去掉包装后，一个真正可靠的循环通常具有相同的几个组件。

它需要一个具有可测试终止条件的目标。“让应用更好”使代理无法检查，要么永远运行，要么任意停止。“让认证模块的所有测试通过”是可机械检查的，这就是关键区别。

它需要一套与实际环境交互的工具：代码执行（查看是否运行）、文件系统访问（读写）、终端（命令）、测试运行器和linter（生成真实反馈）。循环的反馈仅与产生反馈的工具一样可靠。能推理但不能运行代码的代理只是猜测。

它需要上下文管理。每次迭代都会增加记录——代码、错误、决策——而上下文窗口大小固定。若不管理，长循环要么超出窗口，要么更严重的是，随着记录增长，注意力变得不集中，这就是所谓的上下文腐化。

它需要明确的终止和升级逻辑：真实成功条件、真实失败条件（最大迭代次数、令牌或时间预算、重复相同错误无进展）以及定义好的路径。

循环工程中的三大难题

上下文管理：循环在适当位置保留定义、目标和初始事实，同时过滤掉过时信息。常见失败是上下文增长到代理关注无关细节而忽略真正重要的事情。一种常见解决方法是摘要步骤，在每次迭代后压缩最相关的信息。

终止：循环何时停止？许多循环因终止条件模糊而永远运行，或因过度保守而提前停止。明确的可检查条件是唯一可靠的方法。当循环无法成功时，升级和责任转移是必要的。

验证：代理认为完成与实际情况是否完成之间存在差距。最有效的验证是工具化的：实际运行测试、检查语法、验证文件状态。人类复审在关键点仍然重要，但应尽可能机械化和检查化，以最小化依赖。

构建第一个循环

本文以简单伪代码示例结束（省略）。理解循环工程意味着从“问一次”的心态转向设计循环。技能从编写提示转变为设计值得信赖的循环，而这是一项完全不同的技能。