在 Claude Code 团队，循环 (Loops) 被定义为：AI 智能体不断重复执行工作周期，直到满足某个预设的停止条件。为了方便理解，根据以下四个维度，对循环进行了分类：
- 它是如何被触发的
- 它是如何停止的
- 它使用了哪种 Claude Code 基础指令 (primitive) (在这里指系统内置的基础命令或核心功能模块)
- 哪种类型的任务最适合它
接下来，将介绍这几种主要的循环类型、适用场景，以及如何在控制 Token 消耗的同时，保证产出的代码质量。需要注意的是，并不是所有任务都需要复杂的循环；建议从最简单的方案开始上手，然后根据实际情况灵活挑选这些模式。
回合制循环 (Turn-based loops)
┌─────────────┐
╭─▶│ Take action │──╮
╭╯ └─────────────┘ ╰╮
╭╯ ╰╮
╭╯ ▼
┌─────────┐ ┌────────────────┐ ┌─────────────────┐ ┌──────────┐
│ Your │ ──▶│ Gather context │ │ Verify the work │ ──▶ │ Response │
│ prompt │ └────────────────┘ └─────────────────┘ └──────────┘
└─────────┘ ▲ ╱
╰╮ ╭╯
╰╮ ╭╯
╰─────────────────────╯
Exits when Claude judges the task complete -- or the effort budget runs out.- 触发方式：用户输入提示词 (Prompt)。
- 停止条件：Claude 自行判断任务已经完成，或者它发现需要向用户索要更多上下文信息。
- 最佳适用场景：不属于常规流程或定时计划的、比较简短的任务。
- 如何控制消耗：编写非常具体的提示词，并通过技能 (Skills) 功能强化验证环节，从而减少来回交互的回合数。
发送给 AI 的每一个提示词，其实都开启了一个由用户手动主导的循环。在这个循环里，用户指挥着每一个回合：Claude 收集上下文、采取行动、检查自己的工作，必要时重复这些动作，最后回复。这被称为智能体循环 (agentic loop)。
举个例子：让 Claude 做一个“点赞”按钮。它会阅读代码、进行修改、运行测试，然后把它认为没问题的成果交还。接着，用户手动检查一遍它的工作，发现没问题或需要修改后，再写出下一条提示词。
实际上，可以把手动检查的这些步骤，写进一个名为 SKILL.md 的文件里。这样一来，Claude 就能端到端地自行完成更多检查工作。在这个文件里，应该提供各种工具或连接器，让 Claude 能够“看”到、衡量或与最终结果进行真实交互。验证的标准越量化、越具体，Claude 就越容易进行自我判断。
例如，可以在 SKILL.md 文件中这样规定：
---
name: verify-frontend-change
description: 在宣布完成之前，端到端验证任何 UI 更改。
---
# 验证前端更改 (Verifying frontend changes)
绝不能仅仅因为代码修改成功，就报告 UI 更改已完成。必须像人类代码审查员那样进行验证：
1. 启动**开发服务器 (dev server)**，并在浏览器中打开修改后的页面。
2. 直接与更改后的内容交互。对于新增的控件（如按钮、输入框、开关）：点击它，确认状态如预期般改变，并在操作前后截图。
3. 检查**浏览器控制台 (browser console)**：确保没有新增任何错误 (errors) 或警告 (warnings)。
4. 使用 Chrome 开发者工具的 **MCP (Model Context Protocol)**，运行性能追踪，并审核**网页核心性能指标 (Core Web Vitals)**。
如果任何一个步骤失败，请修复问题并从步骤 1 重新开始 —— 绝对不要把只验证了一半的工作交回。目标导向循环 (Goal-based loop /goal)
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries
tries to stop
╭ ─ ─ ─ ─ ─ ─ ─ ─ ╮
╭╯ ▼
┌──────────────┐ ┏━━━━━━━━━━━━━━━━━━━━━━━┓
│ Claude works │ ┃ Evaluator model ┃ ┌───────────────────────┐
│ on the task │ ┃ checks your condition ┃ ───▶ │ Loop ends │
└──────────────┘ ┗━━━━━━━━━━━━━━━━━━━━━━━┛ │ goal met, or the turn │
┃ │ limit is reached │
▲ ╭╯ └───────────────────────┘
╰ ─ ─ ─ ─ ─ ─ ─ ─╯
condition not met -- sent back to work- 触发方式：实时手动输入提示词。
- 停止条件：目标达成，或者达到了设定的最大尝试回合数。
- 最佳适用场景：具备可验证退出标准（能明确用客观数据判断对错）的任务。
- 如何控制消耗：设定非常具体的完成标准和明确的回合数上限，例如“尝试 5 次后停止”。
有时候，仅仅交互一个回合是不够的，特别是在处理复杂任务时。当 AI 智能体能够不断试错、迭代时，它们往往表现得更好。可以通过 /goal 指令定义最终完成的标准，从而让 Claude 有更长的时间去持续迭代。
明确定义成功标准后，Claude 就不需要自己去猜测什么是“足够好”并过早地结束工作。每次 Claude 试图停下来交差时，背后的评估模型都会检查设定的条件，如果不达标，它会被打回去继续干活，直到目标达成，或者达到了设定的尝试次数上限。
这就是为什么确定性的标准（比如通过了多少个测试用例，或者达到了某个具体的分数门槛）会如此有效的原因。
例如：
# 将主页的 Lighthouse 网页性能跑分提高到 90 分或以上，尝试 5 次后停止。
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.基于时间的循环 (Time-based loop /loop 和 /schedule)
- 触发方式：设定的时间间隔。
- 停止条件：手动取消它，或者工作彻底完成了（比如代码被合并了，任务队列清空了）。
- 最佳适用场景：周期性重复的工作，或者需要与外部环境、外部系统对接的任务。
- 如何控制消耗：设置更长的时间间隔，或者改为基于事件触发（而不是单纯按时间盲目运行）。
有些 AI 智能体工作是周期性的：任务本身一成不变，只是输入的数据变了。比如，每天早上汇总 Slack 聊天记录。另一些工作则依赖外部系统，与外部系统对接最简单的方式，就是每隔一段时间去检查一次，并根据变化做出反应。例如，监控一个可能会收到代码审查意见、或者未能通过 CI (持续集成) 的 PR (代码拉取请求)。
对于这些场景，可以使用 /loop 指令来触发 Claude，它会按照设定的时间间隔重复执行某条提示词。例如：
# 每 5 分钟检查一次 PR，处理最新的代码审查意见，并修复失败的持续集成测试。
/loop 5m check my PR, address review comments, and fix failing CI 需要注意的是，/loop 是在本地电脑上运行的，所以一旦关机或者退出，它就会停止。如果想把循环搬到云端全天候运行，可以使用 /schedule 指令来创建一个云端的例行程序 (routine)。
主动式循环 (Proactive loops)
╭┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╮
┆ RUNS IN THE CLOUD -- LAPTOP OPEN OR NOT ┆
┆ ┆
┆ ┌────────────────────────┐ ┆
┆ │ TRIGGER │ ┆
┆ │ /schedule │ ┆
┆ ╭─▶│ watches Slack or │──╮ ┆
┆ ╭╯ │ GitHub for bug reports │ ╰╮ ┆
┆ ╭╯ └────────────────────────┘ ▼ ┆
┆ ╭╯ ╰╮ ┆
┌────────────────┐ ┆ ┌────────────────────────┐ ┌────────────────────┐┆
│ You │ ┆ │ REVIEW │ runs until │ GOAL + CHECK │┆
│ decide what │ ◀───────────── │ Second agent │ you turn │ Main agent │┆
│ to merge │ ┆ │ reviews, then notifies │ it off │ loops until the │┆
│ │ ┆ │ you │ │ verification skill │┆
└────────────────┘ ┆ └────────────────────────┘ │ passes │┆
┆ ▲ │ ┆
┆ ╰╮ │ ┆
┆ ╰╮ ╭╯ ┆
┆ ╰╮ ┌────────────┐ ╭╯ ┆
┆ ╰─────│ Opens a PR │◀─────────╯ ┆
┆ └────────────┘ ┆
╰┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╯- 触发方式：事件触发或定时计划，全程无需人类实时参与。
- 停止条件：每个子任务在达成其具体目标时退出。但整个例行程序本身会一直运行，直到主动将它关闭。
- 最佳适用场景：定义清晰、源源不断的重复性工作流：比如用户漏洞报告 (bug reports)、工单分诊处理 (issue triage)、数据迁移、代码依赖项升级等。
- 如何控制消耗：将常规的、简单的流程分配给更小、更快的模型，把能力最强的大模型留给需要做复杂判断的环节。
上面提到的那些基础指令，结合 Claude Code 的其他进阶功能（比如自动模式 auto mode 和动态工作流 dynamic workflows），可以被组合成一个处理长期复杂任务的“超级循环”。
例如，为了处理不断涌入的用户反馈，可以这样搭配组合：
- 使用
/schedule（研究预览版）运行一个例行程序，定时检查有没有新的反馈报告。 - 使用
/goal定义任务完成的最终目标，并利用技能 (skills) 记录下应该如何验证结果。 - 利用动态工作流 (Dynamic workflows) 来统筹多个 AI 智能体，让它们分别负责给报告分类、修复问题，以及审查代码。
- 开启自动模式 (Auto mode)，这样整个流程就能全自动无缝运转，无需等待人工确认。
组合在一起，提示词可能如下：
# 每小时执行一次：检查 project-feedback 频道中的 bug 报告。目标：直到本次运行发现的所有报告都已被分类、处理并回复，才停止运行。在修复 bug 时，使用工作流在平行的工作区中探索三种不同的解决方案，并让一个专门作为“裁判”的模型对它们进行对抗性的严格审查。
/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.保持代码质量 (Maintaining code quality)
一个循环产出成果的质量，很大程度上取决于围绕它建立的外围系统。在设计这个系统时，请遵循以下原则：
- 保持代码库本身的整洁：Claude 会不知不觉地模仿代码库中已有的模式和规范。代码底子好，输出的质量就高。
- 提供自我验证的方法：通过 技能文档 (Skills) 功能，将“优秀代码标准”写成规则，让智能体自行对照验证。
- 让文档触手可及：各种编程框架和代码库的官方文档里，都藏着最新、最好的实践经验。确保 AI 能够轻松访问这些资料。
- 引入交叉代码审查：使用第二个没有被历史对话污染、拥有全新上下文的智能体来进行代码审查。它的偏见更少，也不会被主干智能体的思路干扰。可以使用内置的
/code-review技能，或者针对 Github 的专用审查工具。
当某一次执行的结果未达到标准时，不应仅仅停留在“把这个 bug 修好”，而应提炼失败教训并固化到规则中，从而在未来的迭代中改善整个系统。
控制 Token 消耗 (Managing token usage)
为了有效控制 Token 消耗，循环设计必须具备清晰的边界：
- 匹配适当的模型：简单任务不需要动用多个智能体或复杂的循环，使用更便宜、更快的模型即可高效解决。
- 设定明确的停止标准：非常具体地描述出“完成”的状态，帮助智能体更快收敛。
- 小范围测试：动态工作流可能会衍生出大量智能体。在大规模部署前，应先切出一小块工作进行测试，评估实际的资源消耗。
- 通过脚本固化确定性逻辑：直接运行一段脚本，比让大模型一步步去逻辑推理要便宜得多。例如，处理 PDF 的技能可以直接内嵌一个填写表单的脚本，每次让 Claude 跑这个脚本即可，避免每次重新推导。
- 合理的轮询频率：监控对象的更新频率决定了检查间隔。不要让 AI 频繁请求低频更新的数据源。
- 定期监控消耗情况：使用
/usage命令按技能、子智能体 (SubAgents) 和 MCP 拆解近期的消耗；使用不带参数的/goal查看执行回合数与消耗；通过/workflows监控每个智能体的消耗，并支持随时中断。
总结探索
总结不同循环类型的核心差异：
- 回合制 (Turn-based)：用户移交“检查工作 (The check)”，适用于探索或决策阶段，工具通常为自定义验证技能。
- 目标导向 (Goal-based)：用户移交“停止条件 (The stop condition)”，适用于明确知道“完成”标准的任务，工具为
/goal。 - 基于时间 (Time-based)：用户移交“触发器 (The trigger)”，适用于项目外按时间表发生的工作，工具为
/loop,/schedule。 - 主动式 (Proactive)：用户移交“提示词 (The prompt)”，适用于循环往复且定义极其明确的工作，使用以上全部指令及动态工作流。
在尝试循环时，可以先审视日常工作，寻找效率瓶颈，思考哪些部分能够交接给 AI：是否能写出自动验证的检查项？任务目标是否足够清晰？工作是否是定时发生的？
有了思路后，即可启动循环并观察结果。识别卡点与过度消耗的环节，不断迭代和优化设计。