现在很多人都在谈论"设计循环"而不是给编程智能体写提示词。如果你花点时间在 X 上试图搞清楚循环到底是什么，你会看到多种不同的答案。

在 Claude Code 团队中，我们将循环定义为智能体重复执行工作周期，直到满足停止条件为止。我们根据以下几种维度对不同类型的循环进行分类：

• 触发方式
• 停止方式
• 使用了 Claude Code 的哪种原语
• 每种循环最适合哪类任务

我们将介绍主要的循环类型、每种循环的使用时机，以及如何在管理 token 用量的同时保持代码质量。并非所有任务都需要复杂的循环；从最简单的方案开始，有选择地使用这些模式。

回合制循环

• 触发方式：用户提示词。
• 停止条件：Claude 判定自己已完成任务或需要更多上下文。
• 最佳适用场景：较短的、不属于常规流程或计划的任务。
• 用量管理方式：编写具体的提示词，并利用技能改进验证，以减少回合数。

你发送的每一条提示词都会启动一个手动循环，由你引导每一回合。Claude 收集上下文、执行操作、检查自己的工作、必要时重复，然后给出响应。我们称之为智能体循环。

例如，让 Claude 创建一个点赞按钮。它会读取你的代码、进行修改、运行测试，然后交回一个它认为能用的结果。然后你手动检查工作，并写下下一条提示词。

你可以通过将手动检查步骤编码为 SKILL.md 文件来改进验证环节，这样 Claude 就能端到端地检查更多自己的工作。该文件应包含能让 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 就不需要自行判断什么是“足够好”并提前结束循环。每次 Claude 试图停止时，评估模型会检查你的条件，然后将其送回继续工作，直到目标达成或达到你定义的轮数。

这就是为什么确定性标准（例如通过的测试数量或达到特定分数阈值）如此有效。

例如：

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

基于时间的循环（/loop 和 /schedule）

• 触发方式：指定的时间间隔。
• 停止条件：你取消它，或工作完成（PR 合并、队列清空）。
• 最适合用于：重复性工作，或与外部环境/系统交互。
• 使用管理：设置更长的间隔，或基于事件而非时间来做出反应。

某些智能体工作是重复性的：任务保持不变，只有输入发生变化。例如，每天早上汇总 Slack 消息。其他工作则依赖于外部系统，与之交互的一个简单方法是以一定间隔检查系统状态并对变化做出反应。例如，一个可能收到代码审查请求或 CI 失败的 PR。

对于这些情况，你可以通过 `/loop` 来触发 Claude 运行，该命令会按照时间间隔重复执行某个提示。例如：

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

`/loop` 在你的本地计算机上运行，因此如果你关闭电脑，它就会停止。你可以通过 `/schedule` 创建例程，将循环移至云端。

主动循环

• 触发方式：事件或计划，无需实时人工参与。
• 停止条件：每个任务在目标达成后退出。例程本身会一直运行，直到你将其关闭。
• 最适合用于：明确定义的重复性工作流：错误报告、问题分类、迁移、依赖升级等。
• 通过将路由任务分配给更小、更快的模型，并使用最强大的模型进行判断决策，来管理用量。

上述基础功能，以及 Claude Code 的其他特性（如自动模式和动态工作流（研究预览）），可以组合成一个循环，用于长时间运行的工作。

例如，为了处理收到的反馈，你可以使用：

1. `/schedule`（研究预览）来运行一个检查新报告的任务
2. `/goal` 来定义完成的标准，以及用技能文档化如何验证它
3. 动态工作流来编排智能体，这些智能体负责分诊每一份报告、修复问题并审查修复
4. 自动模式，这样任务运行时就无需停下来请求许可

综合起来，一个提示词可能如下所示：

/schedule every hour: check #project-feedback 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 能更快（但不要太快）找到解决方案。
• 在大规模运行前先小规模试点：动态工作流可能生成数百个智能体。先对工作的一小部分进行用量评估。
• 对确定性工作使用脚本：运行脚本比推理出步骤更便宜。例如，一个 PDF 技能可以内置一个表单填写脚本，让 Claude 每次直接运行，而无需重新推导代码。
• 不要比实际需要更频繁地运行例程：将间隔时间设置为你所监控对象的变化频率相匹配。
• 查看使用情况：`/usage` 命令可按技能、子智能体和 MCP 细分最近的使用情况；不带参数的 `/goal` 会显示到目前为止的回合数和模型 token 使用量；`/workflows` 显示每个智能体的模型 token 使用量，你可以随时停止某个智能体。

入门指南

总结如下：

要开始使用循环，先看看你已经在做的工作。选一个你成为瓶颈的任务，问自己哪个部分可以交接出去：你能写出验证检查吗？目标是否足够清晰？工作是否按计划进行？

一旦有了想法，就运行循环，观察结果——比如它在哪些地方卡住或过度延伸——不要害怕迭代改进。

更多信息，请阅读 Claude Code 文档中关于并行运行智能体、以及循环、计划、目标和动态工作流的相关页面。

本文由 Delba de Oliveira 和 Michael Segner 撰写

用 Claude 改变你的组织运作方式