Claude Code团队最近在官方博客中，正式给“循环”下了定义，并拆分出四种典型类型：回合制循环、目标循环、时间循环和主动循环。文章给出的核心判断是，循环的关键不在于让 AI 一直运行，而在于它是否能在合适的时候停下来。
这一话题近期在 AI 圈持续升温。文中提到，从 OpenClaw 之父、目前在 OpenAI 主攻下一代个人智能体的 Peter Steinberger，到 Claude Code 创造者 Boris Cherny，再到将这一趋势命名为“循环工程”的谷歌工程师 Addy Osmani，多位业内人士都把注意力放到了 loops 上。
Cherny表示，自己现在几乎不再亲手写提示词，而是让一个智能体替他给 Claude 写提示词，他本人只与那个“协调一切”的新 Claude 对话。他还说，十年之后，循环以及类似功能会成为他最为自豪的工作成果之一。
Steinberger的说法更直接。他认为，与其继续给编程智能体写提示词，不如设计一套专门喂给它们提示词的循环。他还在 X 上演示了自己的做法：让 Codex 每 5 分钟醒一次，自动维护代码仓库、分派任务，并让部分工作自主落地。
Claude Code团队这次的官方表述，把这股讨论拉回到了工程层面。按照其定义，所谓循环，就是智能体一轮又一轮重复执行工作，直到触发停止条件。四种循环，本质上也是四种不同的停止方式。
四种循环，对应四种停止条件
Claude Code团队是从“怎么触发、怎么停止、使用什么原语、适合什么任务”几个维度来拆分循环的。
回合制循环
第一种是回合制循环（turn-based）。这种模式下，控制权始终在人工手里。用户发出一句提示词，AI 执行一轮，用户检查结果后，再决定是否发出下一句提示词。它更适合零散、短时、没有固定流程的任务。
如果想减少来回检查的次数，文中提到的做法是，把平时手动验收的步骤写进一个 SKILL.md 文件，让 AI 自行核验。检查标准越量化，AI 就越容易自己判断任务是否完成，人工盯防也会更少。
目标循环
第二种是目标循环（/goal）。先设定明确目标，例如“把首页 Lighthouse 分数提升到 90 以上，最多尝试 5 次”。每次 Claude 认为可以停下时，都会由一个评估器模型根据既定标准进行判断。若未达标，就打回继续执行；若达标，或者已用完预设轮数，循环才结束。
文中强调，测试通过数、分数阈值这类可量化标准尤其有效，因为模型不必自己揣测“是不是差不多了”，评估器会替它做出判断。这能减少过早停手的情况，也让循环的收尾更干净。
时间循环
第三种是时间循环（/loop 和 /schedule）。这种模式由时间间隔触发，逻辑类似闹钟或定时任务。适合任务本身不变、但输入不断更新的场景，例如每天早上汇总 Slack 消息，或者定时检查一个 PR 是否收到了评审、CI 是否失败。
使用 /loop 可以按间隔重复运行同一条提示词；如果希望在设备关机后继续执行，则可以通过 /schedule 将循环迁移到云端。原文将这套逻辑与程序员熟悉的 cron 定时任务作了类比。
主动循环
第四种是主动循环（proactive）。它由事件或时间触发，可以在无人值守的情况下持续运行。结合 auto mode 和动态工作流后，系统可以把长流程串起来，例如每小时扫描一次反馈频道，收到 bug 报告后自动分诊、修复并回复，全程不再向用户反复索取权限。
单个任务达到目标后就退出，但整条例行任务会一直运行，直到用户手动关闭。文中认为，它更适合 bug 上报、问题分类、依赖升级这类源源不断且边界清晰的工作。
按照这篇官方博客的归纳，四种循环说到底就是四种“什么时候该停”的回答：由人判断、由评估器判断、由时间判断，或者由事件判断。
Agent SDK的底层机制并不复杂
Claude Code团队还在官方 Agent SDK 文档中给出了更底层的解释。整个智能体循环的内核是：Claude 先评估提示词，再调用工具执行操作，拿回结果后再次评估，如此往复；直到某一轮不再调用任何工具，循环才结束，并输出最终答案。
按文中说法，所谓自主智能体，本质上就是这样一个反复闭环的过程。
变化不在循环本身，而在停止条件和验证
文章也没有把“设计循环”描述成一场从 0 到 1 的革命。定时任务、编排（orchestration）、反馈循环，这些思路本来就存在。Claude这次做的，更像是把分散的方法统一命名，并整理为一套分类标准。
真正发生变化的地方，在于“停止条件”的重要性被提到了前面。
在 Claude Code官方总结的一系列实战技巧中，被单独标出来、并称为“最有价值的一条”的，是验证（verification）：给 Claude 一种能自己检查产出的方式。
文中举的类比很直白：如果让工程师做网页却不给浏览器，他就无法在每次修改后立刻看到结果；给了浏览器，他就能边做边看，直到满意再交付。模型循环的威力，也正来自这种自我闭环能力。
在这个过程中，提示词并没有消失，但它退到了循环系统中的一个组件位置。更核心的问题变成了停止条件设计、验证器设计、token 预算控制，以及多轮执行策略。
没有闸门的循环，既强大也危险
文章同时提醒，循环并不意味着可以把 AI 放着连续运行一整天。首先遇到的是成本问题。不设上限的循环，可能迅速消耗 token。
文中提到，据报道，Steinberger自称是“手握无限 token 的男人”，因为免费 token 是他在 OpenAI 工作的福利之一，但普通用户并没有这样的条件。
另一个更隐蔽的问题，是智能体可能陷入“看似在推进、其实原地打转”的死循环。例如它反复修改同一个文件，却始终没有新增通过的测试；甚至可能在错误方案上越做越完整。
工程社区对这一点的共识，在文中的表述很明确：循环很强，但如果没有闸门条件（gating condition），风险也很高。
文章援引Reddit工程讨论，总结了设计循环前必须先想清楚的三类闸门：
- done 条件，而且必须是机器可判定的，例如测试全部通过，或者某个 spec 项被关闭；
- 硬上限，包括最大轮数和最大花费，用来防止成本失控和无限循环；
- 无进展检测，一旦发现它反复处理同一批文件却没有新增通过测试，就强制停止。
官方还给出了一整套控制成本的做法：
- 小任务不要勉强上多智能体；
- 能用更便宜、更快的小模型时，不必全部使用最强模型；
- 大规模运行前，先拿一小部分任务试跑；
- 确定性的工作优先交给脚本，因为跑脚本通常比让模型逐步推理更便宜；
- 例行任务不要设置得比实际需要更频繁。
因此，循环更像是一套“如何把 AI 管住”的工程设计，而不是把 AI 放出去随意运行。它目前更适合边界清晰、结构化的任务，而不是强调自由发挥的工作。
AI编程的重心正在变化
文章最后给出的判断是，这一轮变化真正改变的，是编程工作的重心：从内容设计，转向行为系统设计。
过去需要设计的是一次指令该怎么写；现在要设计的是整套行为机制，包括它如何触发、如何验证、如何停下。
Claude Code官方也给出一个入门方法：回看自己每天重复在做的事情，找出其中一个瓶颈环节，然后问自己三个问题——验证能不能写出来，目标是不是足够明确，工作是否按固定节奏出现。
只要这三个问题里有一个答案是肯定的，文中认为，就可能已经找到了第一个适合交给循环的任务。
按这篇文章的总结，AI 编程过去更看重提示词技巧，现在更看重谁能搭出一套系统：它能自己验证，也知道什么时候该停。提示词不会立刻消失，但关注点正在转向循环设计。
参考资料包括 Claude 官方博客《getting-started-with-loops》、Claude Code Agent SDK 文档、《Claude Code power user tips》以及 Reddit 相关工程讨论。本文来自微信公众号“新智元”，作者为元宇。