Claude Code 循环（Loops）入门：从 /goal 到 /schedule 的四种模式

最近，关于如何为编码智能体“设计循环（loop）”而不是仅仅编写提示词，讨论声量不小。如果你在 X 上花时间翻一翻，会发现关于“循环到底指什么”的答案五花八门，各有各的理解。

在 Claude Code 团队，我们把循环定义得很直白：

。然后，根据几个维度来区分不同类型——怎么触发、怎么停止、用了哪些 Claude Code 原语、以及每种循环最适合哪类任务。

下面会逐一介绍主要的循环类型、各自适用的场景，以及怎么在管理 token 用量的同时，还能维持代码质量。不过先提醒一句：不是所有任务都需要复杂循环，从最简单的方案开始，有选择地使用这些模式就好。

基于轮次的循环（Turn-based loops）

• 触发方式：
  用户提示词。

• 停止条件：
  Claude 判断任务已经完成，或需要更多上下文。

• 最适合：
  不属于固定流程或日程安排的短期任务。

• 用量管理：
  编写具体明确的提示词，并使用技能（skills）改进验证过程，从而减少交互轮数。

每个提示词发出去，都会启动一个由你逐轮引导的手动循环。Claude 收集上下文、采取行动、检查自己的工作，在必要时重复这些步骤，最后给出回复。这个机制被称为

。

举个例子，你让 Claude 创建一个点赞按钮。它会读取代码、完成修改、运行测试，然后交付一个它认为可以正常工作的结果。接下来，你手动检查结果，再编写下一条提示词。

你可以把自己的人工检查步骤写进 SKILL.md，以改进验证环节，让 Claude 能够端到端地检查更多自己的工作。技能中应包含相应的工具或连接器，使 Claude 能够查看、测量结果，或直接与结果交互。检查越量化，Claude 就越容易完成自我验证。

例如，你可以在 SKILL.md 文件中写入：

 复制代码---
name: verify-frontend-change
description: 在宣布完成之前，对任何 UI 更改进行端到端验证。
---# 验证前端更改绝不能只因为编辑成功就报告 UI 更改已经完成。要像人工审查者一样验证它：1. 启动开发服务器，并在浏览器中打开修改后的页面。2. 直接与改动交互。对于新增控件（按钮、输入框、开关）：点击它，确认发生预期的状态变化，并分别截取操作前后的画面。3. 检查浏览器控制台：不得出现新的错误或警告。4. 使用 Chrome DevTools MCP 运行性能追踪，并审计 Core Web Vitals。如果任何一步失败，请修复问题并从第 1 步重新执行；不要交付只完成了部分验证的工作。

基于目标的循环（Goal-based loop，/goal）

• 触发方式：
  实时输入的手动提示词。

• 停止条件：
  目标达成，或达到最大轮数。

• 最适合：
  具备可验证退出条件的任务。

• 用量管理：
  设置具体的完成标准和明确的轮数上限，例如“尝试 5 次后停止”。

有时候，一个轮次根本不够用，复杂任务尤其如此。智能体在能够迭代时表现更好。你可以使用 /goal 明确定义“完成”的样子，从而延长 Claude 持续迭代的时间。

当你定义成功标准后，Claude 就不必自行判断什么是“足够好”，也不会过早结束循环。每当 Claude 尝试停止时，评估模型都会检查你的条件；如果条件尚未满足，就会让它返回继续工作，直到目标达成或达到你设定的轮数。

这也是为什么确定性的标准格外有效，例如通过测试的数量，或达到某个评分阈值。

举个例子：

 复制代码/goal 将首页的 Lighthouse 得分提升到 90 分或以上，尝试 5 次后停止。

基于时间的循环（Time-based loop，/loop 和 /schedule）

• 触发方式：
  指定的时间间隔。

• 停止条件：
  由你取消，或者工作本身完成（例如 PR 已合并、队列已清空）。

• 最适合：
  重复性工作，或需要与外部环境、外部系统交互的任务。

• 用量管理：
  设置更长的时间间隔，或者改为根据事件而不是时间作出响应。

有些智能体工作会反复发生：任务保持不变，只有输入会变化。例如，每天早上汇总 Slack 消息。另一些工作依赖外部系统；与这类系统交互的一种简单方式，是定期检查，并根据发生的变化采取行动。例如，某个 PR 可能收到代码审查意见，或者 CI 可能失败。

针对这类任务，可以使用 /loop 触发 Claude 按照固定时间间隔重新运行提示词。例如：

 复制代码/loop 5m 检查我的 PR，处理代码审查意见，并修复失败的 CI。

/loop 在你的电脑上运行，因此关机后它也会停止。你可以使用 /schedule 创建例程，把循环迁移到云端。

主动式循环（Proactive loops）

• 触发方式：
  由事件或日程触发，无需人工实时参与。

• 停止条件：
  每项任务在目标达成时退出；例程本身会持续运行，直到你将其关闭。

• 最适合：
  持续出现、定义清晰的重复性工作，例如错误报告、Issue 分类、迁移、依赖升级等。

• 用量管理：
  将例程分配给更小、更快的模型；只有需要判断时，才使用能力最强的模型。

上面介绍的原语，还可以与 Claude Code 的其他功能组合，构成长时间运行的循环，例如自动模式（auto mode）和动态工作流（dynamic workflows，研究预览版）。

举个例子，要处理不断到来的反馈，可以使用：

• /schedule（研究预览版）运行一个检查新报告的例程；
• /goal 定义什么算完成，并用技能记录如何验证；
• 动态工作流编排多个智能体，对每份报告进行分类、修复并审查修复结果；
• 自动模式让例程持续运行，而不会停下来请求权限。

把这些组合起来后，提示词可以写成：

 复制代码/schedule 每小时执行：检查 project-feedback 频道中的错误报告。
/goal：在本轮发现的每份报告都完成分类、处理并获得回复之前，不要停止。
修复错误时，使用工作流在三个并行 worktree 中探索三种解决方案，
再让一个评审智能体以对抗式方式审查它们。

保持代码质量

循环输出的质量，取决于它周围的整个系统。设计这个系统时，有几点值得注意：

• 保持代码库本身整洁：
  Claude 会沿用代码库中已经存在的模式和约定。

• 让 Claude 能够验证自己的工作：
  通过技能写清楚你和团队眼中的“好结果”是什么。

• 让文档易于获取：
  框架和库的文档中包含最新的最佳实践。

• 使用第二个智能体做代码审查：
  拥有全新上下文的审查者偏见更少，也不会被主智能体的推理过程影响。你可以使用内置的 /code-review 技能，或 GitHub 的 Code Review。

当某次结果没有达到标准时，不要只修复眼前的单个问题；尝试把这次经验编码进系统，以改善今后的每一次迭代。

管理 token 用量

为了控制 token 用量，循环应当具有清晰的边界：

• 为任务选择合适的原语和模型：
  小任务不需要多个智能体或多层循环；有些任务可以使用更便宜、更快的模型。

• 定义清晰的成功标准和停止条件：
  明确说明什么算完成，使 Claude 更快抵达解决方案，但也不要让它过早停止。

• 大规模运行前先试点：
  动态工作流可能生成数百个智能体。先在较小范围的任务上测量用量。

• 用脚本处理确定性工作：
  运行脚本比逐步推理成本更低。例如，一个 PDF 技能可以自带表单填写脚本，让 Claude 每次直接运行，而不是重复推导代码。

• 不要以超过实际需要的频率运行例程：
  让执行间隔匹配被监控对象发生变化的频率。

• 查看用量：
  /usage 命令会按技能、子智能体和 MCP 细分近期用量；不带参数的 /goal 会显示目前的轮数和 token 用量；/workflows 会显示每个智能体的 token 用量，你也可以随时停止某个智能体。

开始使用循环

总结如下：

循环类型	你交出去的部分	适用场景	推荐使用
基于轮次	检查过程	你正在探索或作出决策	自定义验证技能
基于目标	停止条件	你清楚什么算完成	/goal
基于时间	触发条件	工作按照日程在项目外部发生	/loop、/schedule
主动式	提示词	工作重复发生且定义清晰	以上所有方式，以及动态工作流

要开始使用循环，先看看你已经在做的工作。挑一个你自己是瓶颈的任务，然后想想其中哪一部分可以交出去：你能否写出验证检查？目标是否足够清晰？这项工作是否按照某种日程出现？

有了想法之后，就运行这个循环并观察结果，例如它会卡在哪里、是否做过了头。不要害怕根据观察继续迭代。

如需了解更多信息，请阅读 Claude Code 文档中关于并行运行智能体的内容，以及 loop、schedule、goal 和动态工作流相关页面。

---

本文为原文中文翻译，版权归原作者所有。翻译仅用于学习与技术交流。