“设计循环”是个方便的说法，但实际上不同的人所指的内容略有差异。有时它仅指反复投递提示词，有时则指带着完成条件把工作交给 Claude，甚至还包括定时执行与自主的反复处理。2026年7月7日，Claude Code 团队在官方开发者账号 @ClaudeDevs 上发布了一篇回应这一模糊之处的讲解帖子（撰写：Delba Oliveira）。本文对其内容加以整理，并结合 Claude Code 官方文档补充规格层面的说明。
循环的定义 —— “反复进行工作的循环，直到满足停止条件”
Claude Code 团队将循环定义如下。
On the Claude Code team, we define loops as agents repeating cycles of work until a stop condition is met.
（在 Claude Code 团队，我们将循环定义为"智能体反复进行工作的循环，直到满足停止条件"。）
在此基础上，团队按以下三条轴线对循环进行分类。
- 如何被触发（触发方式）
- 如何停止（停止条件）
- 使用 Claude Code 的哪项功能（原语）
原帖提醒道：“并非每项任务都需要复杂的循环。先从最简单的方式入手，这些模式应有选择地使用。“以下依次来看四种循环类型。
结论 —— 四种循环类型及其使用场景
| 循环类型 | 触发方式 | 停止条件 | 适用的工作 |
|---|---|---|---|
| 基于轮次 | 用户的提示词 | Claude 判断已完成，或判断需要更多上下文 | 不属于例行业务或定时执行的、相对较短的工作 |
基于目标（/goal） | 实时的手动提示词 | 达成目标，或到达设定的最大轮次数 | 具有可验证结束条件的工作 |
基于时间（/loop、/schedule） | 指定的时间间隔 | 用户中断，或工作完成（PR 合并、队列清空等） | 定期发生的工作，以及与外部系统的交互 |
| 主动式 | 事件或计划表（无人实时介入） | 每个单独任务在达成目标时结束。例程本身则持续运行，直到被关闭 | 定义明确的反复业务，如缺陷报告、议题分诊、迁移、依赖更新等 |
基于轮次的循环 —— Claude Code 的基本形态
你发送的每一条提示词，都会启动一个手动的循环。Claude 收集上下文、采取行动、验证成果，必要时反复进行，最后作出回应。这一连串流程被称为智能体循环。
图1：基于轮次的循环（智能体循环）。当 Claude 判断任务完成，或 effort 的预算耗尽时退出。
例如，当你请求“做一个点赞按钮”时，Claude 会读代码、做编辑、运行测试，并返回它判断为可正常工作的结果。此后的确认与下一条提示词的编写，则由用户手动进行。
这一验证工序，可以通过将步骤明文化为 SKILL.md 来加以改进。若把原本靠手工进行的确认步骤写成技能，Claude 便能靠自身把更大范围的工作验证到底。帖子举的例子是这样一个技能：它不让 Claude 仅凭“编辑成功”就报告 UI 变更已完成，而是定义一套流程——启动开发服务器、实际操作变更、检查浏览器控制台是否有报错、测量 Core Web Vitals。据称，让 Claude 拥有能够查看和测量结果的工具与连接器，并让确认项尽量定量化，是让 Claude 更易于自我验证的诀窍。
基于目标的循环（/goal） —— 交出完成条件并托付
有些工作无法在一个轮次内完成。尤其是复杂的任务，Claude 能够反复进行时往往效果更好。/goal 通过定义“何为完成”，来延长 Claude 持续反复进行的时段。
图2：基于目标的循环。评估者模型每一轮确认条件，若未满足则送回继续作业。
只要事先定义好成功条件，Claude 就不必当场判断“这样是否足够”而过早地中断循环。每当 Claude 打算停止作业时，评估者模型都会确认所设定的条件，并将工作送回，直到目标得到满足或达到指定的轮次数。根据官方文档，该评估者默认使用如 Haiku 这类小型且快速的模型，仅针对对话记录进行判定（不会自行调用工具去确认），而评估所耗的 token 与主轮次的消耗相比通常可以忽略不计（参考资料 1）。
因此据称，诸如通过的测试数量、分数是否超过阈值这类确定性（deterministic）的条件较为有效。原帖举的例子如下。
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.基于时间的循环（/loop、/schedule） —— 定时执行并与外部系统联动
智能体的工作中，也有一些是定期发生的。例如每天早晨汇总 Slack 消息的工作，任务内容相同，只有输入发生变化。此外，也有依赖外部系统的工作，如 PR 收到评审意见、CI 失败等。在这类情形下，以固定间隔进行检查并对变化作出反应，便成了一种简单的界面。
图3：将基于时间的循环搬到云端的示例。触发、执行、评审全部作为 `/schedule` 的例程完结，用户只在最后作出合并的判断。
/loop 是以固定间隔重新执行提示词的命令。
/loop 5m check my PR, address review comments, and fix failing CI原帖表示：“由于 /loop 运行在用户的机器上，停止它循环便随之停止。若用 /schedule 创建例程，则可将循环搬到云端。“在官方文档中对二者加以比较，有如下差异（参考资料 2）。
云端（Routines，用 /schedule 创建） | /loop（本地） | |
|---|---|---|
| 执行环境 | Anthropic 的云端 | 自己的机器 |
| 是否需要机器处于开机状态 | 不需要 | 需要 |
| 是否需要保持会话开启 | 不需要 | 需要 |
| 对本地文件的访问 | 不可（干净的 clone） | 可以 |
| 最短间隔 | 1小时 | 1分钟 |
此外，原帖为 /schedule 注明了“research preview”。查阅官方文档，在会话内运行的 /loop 与 scheduled tasks 被介绍为 Claude Code v2.1.72 及以后版本的功能。另一方面，运行在 Anthropic 托管云端上的 Routines，目前仍被明确标注为 research preview（参考资料 3）。因此，最好将 /loop 与云端 Routines 理解为不仅在执行环境上有别，在稳定性的定位上也有所区分。
主动式循环（proactive loops） —— 上述各项的组合
在上述原语之外，通过组合 auto mode 与 dynamic workflows 等 Claude Code 的其他功能，可以将长时间的工作构成一个循环。dynamic workflows 是 Claude 编写 JavaScript 脚本来编排大量子智能体的功能；根据官方文档，它自 Claude Code v2.1.154 起，在全部付费方案以及 Anthropic API 等处可用（参考资料 4）。
例如，在处理收到的反馈时，原帖列举了如下组合。
/schedule—— 运行一个检查是否有新报告的例程/goal—— 将完成的定义及验证它的步骤，作为技能记录下来- dynamic workflows —— 指挥对各报告进行分诊、修复、评审的智能体
- auto mode —— 在不为请求许可而停下作业的情况下运行例程
将这些汇总起来，便成为如下这样的提示词。
/schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.如何保持代码质量
循环输出的质量，据称取决于围绕它的机制。作为设计时应考虑的要点，原帖列举了以下几条。
- 将代码库本身整理妥当：Claude 会遵循既有的模式与约定
- 给 Claude 提供能验证自身工作的手段：把以何为“好”作为技能明文化
- 让文档触手可及：使其能够参考框架与库的最新最佳实践
- 代码评审使用另一个智能体：拥有全新上下文的评审者偏见更少，不会被主智能体的推理所牵引。可以使用内置的
/code-review技能或面向 GitHub 的 Code Review - 当某个单独的结果未达标准时，不要只是权宜地修补，而应尝试改进机制本身，以惠及此后的每一次反复
如何管理 token 消耗
据称，要管理循环的 token 消耗，设立明确的边界十分重要。
- 选择与工作相称的原语与模型：小任务并不需要多个智能体或循环。有些任务用更便宜、更快的模型即可
- 明确定义成功条件与停止条件：把“完成”具体化，Claude 便能更早（但不至于过早）抵达解
- 大规模执行前先小规模试验：dynamic workflows 可能生成数百个智能体。先在部分工作上测量消耗量
- 确定性的工作使用脚本：运行脚本比每次都推理步骤更便宜。例如，PDF 操作的技能可以内附一个只需执行的表单填写脚本，而不必每次都让其重新推导代码
- 不要以超过必要的频率运行例程：让间隔与监视对象发生变化的频率相匹配
- 确认使用量：
/usage会按技能、子智能体、MCP 分别显示近期的使用量；不带参数的/goal会显示到目前为止的轮次数与 token 消耗；/workflows会显示各智能体的 token 消耗，且你随时可以停止某个智能体
第一步
原帖将四种循环类型总结如下。
| 循环类型 | 放手交出的 | 使用时机 | 使用的功能 |
|---|---|---|---|
| 基于轮次 | 确认作业 | 探索中、决策中 | 定制验证用技能 |
| 基于目标 | 停止条件的判断 | 已知“完成”的模样 | /goal |
| 基于时间 | 触发的时机 | 工作发生在项目之外、按计划表发生 | /loop、/schedule |
| 主动式 | 提示词本身 | 工作具有反复性且定义明确 | 上述全部，以及 dynamic workflows |
要开始使用循环，据建议可从你已在进行的工作中，挑一项你自己成为瓶颈的任务，并追问哪个部分可以放手交出——验证的检查你能自己写吗？目标够明确吗？工作是否按计划表发生？一旦确定了方针，便鼓励你实际运行循环，观察它在何处停下、在何处做过了头，并毫不客气地加以调整。
小结
- Claude Code 团队将循环定义为“智能体反复进行工作的循环，直到满足停止条件”，并按触发方式、停止条件、所用功能这三条轴线分为四种类型
- 基于轮次以一条提示词为单位，依 Claude 是否判断任务完成而停止。将验证明文化为
SKILL.md，自我验证的范围便会扩大 - 基于目标（
/goal）交出完成条件，由评估者模型（默认是小型且快速的模型）每一轮确认条件。条件越是确定性，效果越好 - 基于时间（
/loop、/schedule）以固定间隔执行。/loop与本地会话相绑定，而用/schedule创建的云端 Routines 无需机器处于开机状态。不过 Routines 目前仍被明确标注为 research preview，与/loop在稳定性的定位上有所不同 - 主动式循环在上述基础上组合 auto mode 与 dynamic workflows，构成无人实时介入的反复业务
- 并非每项任务都需要复杂的循环，推荐从最简单的方式入手
参考资料
- Keep Claude working toward a goal — Claude Code Docs。关于评估者默认使用小型且快速的模型（Haiku）（“sent to your configured small fast model, which defaults to Haiku”）、评估者不调用工具而仅针对对话记录进行判定、
/goal需要 v2.1.139 及以后版本等内容。（在基于目标的循环一节中引用。） - Run prompts on a schedule — Claude Code Docs。关于云端（Routines）、桌面端、
/loop的比较表，最短间隔（云端1小时、/loop1分钟），/loop需要 Claude Code v2.1.72 及以后版本等内容。（在基于时间的循环一节中引用。） - Automate work with routines — Claude Code Docs。关于明确标注 “Routines are in research preview. Behavior, limits, and the API surface may change.”（Routines 处于 research preview），运行在 Anthropic 托管的云端基础设施上、可由计划表、API、GitHub 事件触发、也可从 CLI 的
/schedule创建等内容。（在基于时间的循环一节中引用。） - Orchestrate subagents at scale with dynamic workflows — Claude Code Docs。关于 dynamic workflows 自 Claude Code v2.1.154 起、在全部付费方案以及 Anthropic API 等处可用等内容。（在主动式循环一节中引用。）
- Getting started with loops — @ClaudeDevs on X（2026年7月7日，撰写：Delba Oliveira） —— 本文的主要出处。所载图版均引用自该帖子（作图：Anthropic）
- Keep Claude working toward a goal — Claude Code Docs
- Run prompts on a schedule — Claude Code Docs
- Automate work with routines — Claude Code Docs
- Orchestrate subagents at scale with dynamic workflows — Claude Code Docs