Loop入门>这是Claude官博发的一篇文章，介绍 Claude Code 里的loop是怎么玩的。

现在有很多讨论都在说，与其给你的编程 agent 写 prompt，不如去“设计循环”。但如果你在 X 上花点时间想弄清楚 loop 到底是什么，会发现大家给出的答案并不一致。

在 Claude Code 团队里，我们把 loop 定义为：agent 会重复执行一轮又一轮工作，直到满足停止条件。我们会根据几个维度，把循环分成不同类型：

* 它们如何被触发* 它们如何停止* 使用了哪种 Claude Code 基础能力* 最适合哪类任务

下面会介绍几种主要的循环类型、各自适合什么场景，以及如何在管理 token 用量的同时保持代码质量。不是所有任务都需要复杂循环；先从最简单的方案开始，只在合适的时候选择性使用这些模式。

回合式循环

**触发方式：** 用户的一条 prompt。**停止条件：** Claude 判断任务已经完成，或者需要更多上下文。**最适合：** 较短的任务，尤其是不属于固定流程或定时任务的工作。**用量管理方式：** 写更具体的 prompt，并通过 skills 改进验证步骤，减少交互轮次。

你每发出一条 prompt，都会启动一个由你逐轮指挥的手动循环。Claude 会收集上下文、采取行动、检查自己的工作；如果需要，就重复这些步骤，最后给出回复。我们把这称为 agentic loop，也就是智能体式循环。

比如，你让 Claude 创建一个点赞按钮。它会阅读你的代码、做出修改、运行测试，然后交付一个它认为可以工作的结果。接着你手动检查它的工作，再写下一条 prompt。

你可以把自己手动检查的步骤编码成一个 `SKILL.md`，从而改进验证环节，让 Claude 能够更端到端地检查自己的工作。这个 skill 应该包含必要的工具或 connector，让 Claude 能够看到、测量或直接与结果交互。检查越量化，Claude 就越容易自我验证。

例如，你可以在 `SKILL.md` 文件里写：

```markdown---name: verify-frontend-changedescription: Verify any UI change end-to-end before declaring it done.---

验证前端修改

不要只因为代码修改成功，就报告 UI 修改已经完成。要像人类 reviewer 一样验证它：

1. 启动开发服务器，并在浏览器里打开被修改的页面。

2. 直接与这次修改交互。对于新的控件，比如按钮、输入框、开关：点击它，确认预期的状态变化，并截取操作前后的截图。

3. 检查浏览器控制台：不能出现新的错误或警告。

4. 使用 Chrome DevTools MCP，运行一次性能 trace，并审计 Core Web Vitals。

如果任何一步失败，修复问题并从第 1 步重新执行。不要交付一个只被部分验证过的结果。```

目标式循环：`/goal`

**触发方式：** 实时手动 prompt。**停止条件：** 目标达成，或者达到最大回合数。**最适合：** 有可验证退出标准的任务。**用量管理方式：** 设置具体完成标准和明确的回合上限，比如“最多尝试 5 次”。

有时候，单个回合并不足够，尤其是面对更复杂的任务时。Agent 如果能够不断迭代，效果会更好。你可以用 `/goal` 定义“完成”到底长什么样，从而延长 Claude 持续迭代的时间。

当你定义好成功标准后，Claude 就不需要自己判断什么叫“够好”，也不容易过早结束循环。每次 Claude 试图停止时，一个评估模型都会检查你的条件；如果目标还没达成，就把它送回去继续工作，直到目标完成，或者达到你设定的回合上限。

这也是为什么确定性的标准特别有效，比如通过多少个测试，或者达到某个分数门槛。

例如：

```bash/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.```

意思是：把首页 Lighthouse 分数提高到 90 分或以上，最多尝试 5 次。

时间式循环：`/loop` 和 `/schedule`

**触发方式：** 指定的时间间隔。**停止条件：** 你取消它，或者工作完成，比如 PR 已合并、队列已清空。**最适合：** 周期性工作，或者与外部环境、外部系统交互的任务。**用量管理方式：** 设置更长的间隔，或者基于事件而不是固定时间作出反应。

有些 agentic 工作是周期性的：任务本身不变，只是输入在变化。例如，每天早上总结 Slack 消息。还有一些工作依赖外部系统，而和外部系统交互的简单方式之一，就是定期检查它，然后根据变化采取行动。例如，一个 PR 可能收到代码评审意见，或者 CI 可能失败。

针对这类任务，你可以用 `/loop` 触发 Claude 运行，让它按固定间隔重新执行某条 prompt。例如：

```bash/loop 5m check my PR, address review comments, and fix failing CI```

`/loop` 运行在你的电脑上，所以如果你关机，它就会停止。你也可以通过 `/schedule` 创建一个 routine，把这个循环移到云端运行。

主动式循环

**触发方式：** 事件或日程安排，不需要人在实时参与。**停止条件：** 每个任务在目标完成后退出；routine 本身会一直运行，直到你关闭它。**最适合：** 定义清晰的周期性工作流，比如 bug 报告、issue 分诊、迁移、依赖升级等。**用量管理方式：** 把 routine 路由到更小、更快的模型上，把最强的模型用于需要判断的环节。

上面这些基础能力，再加上 Claude Code 的其他功能，比如 auto mode 和 dynamic workflows（研究预览版），可以组合成长时间运行的工作循环。

例如，为了处理不断进入的反馈，你可以这样设计：

* 用 `/schedule`（研究预览版）运行一个 routine，检查是否有新的反馈报告* 用 `/goal` 定义什么叫完成，并用 skills 记录如何验证* 用 dynamic workflows 编排多个 agent，让它们对每个报告进行分诊、修复并审查修复结果* 用 auto mode 让这个 routine 不会因为请求权限而停下来

组合起来，一条 prompt 可能长这样：

```bash/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.```

意思是：

每小时检查一次 `project-feedback` 频道里的 bug 报告。目标是：本次运行中发现的每一条报告都必须完成分诊、处理并回复，之后才能停止。修 bug 时，使用一个 workflow，在并行 worktree 中探索三种解决方案，并让一个评审模型以对抗方式审查这些方案。

保持代码质量

循环输出的质量，取决于它周围的系统。在设计这个系统时：

* **保持代码库本身干净。** Claude 会遵循你代码库里已有的模式和约定。* **给 Claude 一种验证自己工作的方式。** 用 skills 编码你和团队对于“好结果”的标准。* **让文档容易获取。** 框架和库的文档通常包含最新的最佳实践。* **使用第二个 agent 做代码评审。** 带着新上下文的 reviewer 偏见更少，也不会受到主 agent 推理过程的影响。你可以使用内置的 `/code-review` skill，或者 GitHub 的 Code Review。

当某一次结果没有达到标准时，不要只修这个单独问题。更好的做法是把它编码进系统里，让未来所有迭代都因此变得更好。

管理 token 用量

为了管理 token 用量，循环应该有清晰边界：

* **为任务选择合适的基础能力和模型。** 小任务不需要多个 agent 或复杂循环。有些任务可以使用更便宜、更快的模型。* **定义清晰的成功标准和停止标准。** 具体说明什么叫完成，这样 Claude 可以更快到达解决方案，但也不会过早停止。* **大规模运行前先试点。** Dynamic workflows 可能会启动数百个 agent。先在较小范围内估算用量。* **对确定性工作使用脚本。** 运行脚本比一步步推理更便宜。例如，一个 PDF skill 可以自带一个表单填写脚本，让 Claude 每次直接运行，而不是每次重新推导代码。* **不要让 routine 运行得比实际需要更频繁。** 间隔应该匹配你所观察对象的变化频率。* **查看用量。** `/usage` 命令会按 skills、subagents 和 MCPs 拆分近期用量；不带参数的 `/goal` 会显示目前为止的回合数和 token 用量；`/workflows` 会显示每个 agent 的 token 用量，并且你可以随时停止某个 agent。

入门方法

总结一下：

| 循环类型 | 你交给 Claude 的部分 | 适用场景 | 可以使用 || ----- | -------------- | -------------- | --------------------------- || 回合式循环 | 检查步骤 | 你还在探索或做决策 | 自定义验证 skills || 目标式循环 | 停止条件 | 你知道什么叫完成 | `/goal` || 时间式循环 | 触发器 | 工作会按日程发生在项目外部 | `/loop`、`/schedule` || 主动式循环 | prompt 本身 | 工作是周期性的，并且定义清晰 | 以上所有能力，以及 dynamic workflows |

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

一旦有了想法，就运行这个循环，观察结果：它会卡在哪里？它会不会做过头？然后继续迭代它。

想了解更多，可以阅读 Claude Code 文档中关于并行运行 agents 的内容，以及 loop、schedule、goal 和 dynamic workflows 相关页面。