Claude Code 里的四种循环类型，以及各自该在什么时候用

Claude Code 里的循环（loop）是什么？

Claude Code 里的循环，是指 Agent 反复执行"收集上下文、行动、检查结果"这一工作周期，直到满足停止条件为止。Claude Code 内置四种循环：轮次型（每次提示都是一次）、用 /goal 的目标型、用 /loop 和 /schedule 的时间型，以及无人值守运行的主动式例程。

在 X 上随便问十个人"什么是循环（loop）"，能得到十种不同的答案。Claude Code 团队自己给出的定义，来自 ClaudeDevs 最近发布的一篇文章，是目前最清晰的一种：循环就是智能体反复执行工作周期，直到满足某个停止条件。

不同循环类型之间的差异在于：怎么触发、怎么停止、由 Claude Code 的哪个原语驱动，以及各自适合哪类任务。Claude Code 内置了四种运行循环的方式——大多数场景下都不需要额外的编排系统。本文会逐一讲解这四种循环，以及在循环变得更长时如何保证质量、控制 token 消耗。（原始出处见 ClaudeDevs 原文；更通用、不绑定厂商的版本可参考《什么是 Loop Engineering》。）

轮次型循环（Turn-based）

• 触发方式： 用户输入的提示词。
• 停止条件： Claude 判断任务已完成，或需要你提供更多上下文。
• 最适合： 不属于常规流程或计划任务的较短任务。
• 控制方式： 写更具体的提示词，用 skills 增强自我验证，从而减少所需轮次。

这正是你每次给 Claude 下提示词时已经在运行的循环。Claude 收集上下文、执行操作、检查自己的产出、按需重复，再给出响应——这就是所谓的"智能体循环（agentic loop）"。比如让它加一个点赞按钮：它读代码、做修改、跑测试，然后交回一个它认为可行的结果。你手动检查结果，再写下一条提示词。

你可以把自己的人工审查清单固化成一个 skill，让 Claude 在交回结果前自己检查更多内容，来收紧这一验证环节。给它配上能真正看到、度量或操作结果的工具——检查项越量化，Claude 自我验证的可靠性就越高。例如一份 SKILL.md：

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

# Verifying frontend changes

Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would:

1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome DevTools MCP, run a performance trace and audit Core Web Vitals.

If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

目标型循环（/goal）

• 触发方式： 实时的手动提示词。
• 停止条件： 目标达成，或达到最大轮次上限。
• 最适合： 有可验证退出条件的任务。
• 控制方式： 设置明确的轮次上限，比如"最多尝试 5 次"。

单轮往往不够用，尤其是更复杂的任务。/goal 让 Claude 可以在一轮之外继续迭代——前提是你要先把"完成"的标准定义清楚，而不是让 Claude 自己单方面判断"差不多就行了"：

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

每次 Claude 想要停下来时，一个评估模型会检查你设定的条件，如果还没满足，就把任务打回去继续。这也是为什么"通过的测试数量""达到某个分数阈值"这类确定性的成功标准，效果远好于模糊的标准。

时间型循环（/loop 和 /schedule）

• 触发方式： 固定的时间间隔。
• 停止条件： 你手动取消，或底层工作本身完成（PR 合并、队列清空）。
• 最适合： 周期性工作，或需要对接项目之外的外部系统。
• 控制方式： 拉长检查间隔，或尽量改成事件触发而不是纯按时间触发。

有些工作是真正周期性的——比如每天早上总结一遍 Slack 消息。另一些则依赖于观察外部系统的变化——比如一个可能收到评审意见或 CI 失败的 PR。/loop 会按固定间隔重跑同一条提示词，来应对这两种情况：

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

/loop 是在你本地机器上运行的，所以你关掉它，它就停了。想把同样的逻辑搬到云端、不需要电脑一直开着运行，就用 /schedule 把它包装成一个例程（routine）。

主动式循环（Proactive loops）

• 触发方式： 事件或计划触发，实时过程中没有人参与。
• 停止条件： 每个具体任务在目标达成时退出；例程本身会持续运行，直到你手动关闭它。
• 最适合： 定义明确、持续出现的一类工作——缺陷分诊、迁移、依赖升级等。
• 控制方式： 把常规工作路由给更小、更快的模型，只在需要判断力的地方用最强的模型。

主动式循环把前面这些原语——再加上自动模式（auto mode）和动态工作流（dynamic workflows，研究预览版）——组合成一套可以无人值守运行的系统。以处理陆续涌入的缺陷报告为例，组合方式是这样的：

1. /schedule（研究预览版）运行一个例程，定期检查是否有新报告。
2. /goal 定义"完成"是什么样子，skills 记录如何验证它。
3. 动态工作流编排多个智能体，分别负责分诊、修复、审查每一份报告。
4. 自动模式让例程不必在每一步都停下来请求许可。

组合到一起，一条提示词就能把整套流程搭起来：

/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 Code 循环与 Ralph Loop 的区别

Ralph Loop（又称"Ralph Wiggum"技巧）是 Claude Code 内置循环之外最知名的循环模式，两者很容易混淆：

两者也可以组合使用：用 Ralph 式的外部循环逐轮调用 Claude Code，在每一轮里再用 /goal 约束这单个任务的完成标准。

如何保证循环产出的质量

循环产出的质量，取决于它外层那套系统：

• 保持代码库本身干净——Claude 会遵循代码库里已经存在的模式和约定。
• 给 Claude 一种能自我验证的方式——把你和团队认可的"好"标准固化成一个 skill。
• 让文档触手可及——最新的框架与库文档能减少错误的猜测。
• 让第二个智能体来做代码审查——一个带着全新上下文的审查者不会被实现者自己的思路带偏。可以用内置的 /code-review skill，或 GitHub 的 Code Review。

当某一次结果没达到标准时，不要只修那一个问题，尽量把这次修复固化进系统，让后续每一轮都受益。

如何控制 Token 消耗

跑得更久的循环，需要明确的边界：

• 为任务匹配合适的原语和模型——小任务不需要多个智能体或整套循环，有些甚至可以用更便宜更快的模型。
• 设定清晰的成功和停止标准——足够具体，让 Claude 能尽快收敛，但也别设得太松而过早停止。
• 大规模运行前先小范围试跑——动态工作流可能一次拉起几百个智能体，先在一小部分工作上评估用量。
• 确定性的工作交给脚本——运行一段脚本，比每次都靠推理重新演绎同样的逻辑要便宜得多。
• 不要比实际变化频率轮询得更勤。
• 随时查看用量——/usage 会按 skill、子智能体和 MCP 拆分近期用量；不带参数的 /goal 会显示目前的轮次和 token 消耗；/workflows 会显示每个智能体的用量，随时可以停掉其中任意一个。

Claude Code 循环常见问题排查

• 循环停得太早，或者一直不停。 通常是成功标准太模糊。给 /goal 一个确定的检查条件（测试通过、分数达到阈值），再加上轮数上限，比如"最多尝试 5 次"。
• /loop 停止运行了。 /loop 在本地运行，电脑停下它就停了。需要持续运行的周期性工作，请用 /schedule 放进例程。
• Token 消耗一直上涨。 用 /usage 查看按 Skill、子 Agent 和 MCP 拆分的消耗；不带参数运行 /goal 查看目前的轮数和 Token；用 /workflows 查看并停止单个 Agent。轮询频率不要高于被观察对象实际变化的频率。
• 长时间运行后质量下降。 把检查标准写成 Skill，让 Claude 自我验证；再加一个上下文干净的审查 Agent（/code-review）。
• 大规模的主动式运行出错。 先在一小部分数据上试跑动态工作流，再放开让它生成大量 Agent。

该选哪一种？

• 轮次型——你交出去的是检查过程。适用于你还在探索或做决策的时候。对应机制：自定义验证 skills。
• 目标型——你交出去的是停止条件。适用于你清楚"完成"是什么样子的时候。对应命令：/goal。
• 时间型——你交出去的是触发时机。适用于工作发生在项目之外、按计划进行的时候。对应命令：/loop 或 /schedule。
• 主动式——你交出去的是整条提示词。适用于工作是周期性且定义明确的时候。对应机制：以上全部，加上动态工作流。

上手的方式，是回头看看你现在还在手动做的工作，挑一件事想想能交出去哪一部分：验证检查能不能写出来？目标是否清楚到可以提前定义？这项工作是否会按计划出现？跑起来之后，观察它在哪里卡住或做过头，再据此迭代。

更多细节可参考 Claude Code 关于并行运行智能体的文档，以及 /loop、/schedule、/goal 和动态工作流页面；也可以直接去 MCP.so 的循环工作流目录，找一条可以直接粘贴使用、适配上述任意一种模式的启动提示词。