开始使用循环

现在大家都在讨论 “设计循环” 而不是单纯给编码智能体写提示词。如果你在 X 上花点时间试图弄清楚循环到底是什么，你会看到多种不同的答案。

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

• 触发方式

• 停止方式

• 使用的 Claude Code 原语

• 每种循环最适合的任务类型

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

回合制循环

• 触发方式：用户提示

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

• 最佳用途：不属于常规流程或日程的较短任务

• 用量管理：编写具体的提示词，并使用技能（skills）改进验证，以减少回合数

你发送的每个提示都会启动一个手动循环，由你引导每一轮。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. 
--- 

# 验证前端更改 
在声明 UI 更改完成之前，绝不能仅凭编辑成功就报告完成。应像人工审核员那样验证：

1. 启动开发服务器，在浏览器中打开已编辑的页面。

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

3. 检查浏览器控制台：确保没有任何新的错误或警告。

4. 使用 Chrome Devtools MCP 运行性能追踪并审计核心网页指标。

如果任何步骤失败，修复问题并从第 1 步重新开始 —— 不要交回部分验证的工作。

基于目标的循环 (/goal)

• 触发方式：实时手动提示

• 停止条件：达到目标 OR 达到最大回合数

• 最佳用途：具有可验证退出标准的任务

• 用量管理：设置具体的完成标准和明确的回合上限，如 “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 的其他功能，如 自动模式 和 动态工作流（研究预览版），可以组合成一个用于长期运行的循环。

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

• /schedule （研究预览版） 来运行一个检查新报告的例程

• /goal 来定义完成的标准，并用 技能 记录如何验证

• 动态工作流 来协调智能体，对每个报告进行分类、修复并审查修复

• 自动模式 使例程无需停下征求许可即可运行

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

/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 会遵循代码库中已有的模式和惯例。

• 让 Claude 能够验证自己的工作：通过技能（skills）为你和你的团队编码 “好” 的标准。

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

• 使用第二个智能体进行代码审查：具有新鲜上下文的审查员偏见更少，不受主智能体推理的影响。你可以使用内置的 /code-review 技能或 GitHub 的 Code Review。

当单个结果不符合标准时，不要只修复单个问题，尝试将其编码到系统中，以便改进所有未来的迭代。

管理 token 用量

为了管理 token 用量，循环应有明确的边界：

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

• 定义明确的成功和停止标准：明确 “完成” 的样子，以便 Claude 能更快（但不能太快）找到解决方案。

• 在大规模运行前先试点：动态工作流可能产生数百个智能体。先在小部分工作上评估用量。

• 对确定性工作使用脚本：运行脚本比推理步骤更便宜。例如，一个 PDF 技能可以提供一个表单填写脚本，Claude 每次运行该脚本，而不是重新推导代码。

• 不要比你需要的频率更频繁地运行例程：将间隔与你监控的事物变化频率相匹配。

• 审查用量：/usage 命令按技能、子智能体和 MCP 分解最近的用量；不带参数的 /goal 显示当前的回合数和 token 用量；/workflows 显示每个智能体的 token 用量，你可以随时停止一个智能体。

开始使用

总结：

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

一旦有了想法，运行循环，观察结果（例如它在何处停滞或过度），不要害怕迭代。

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

本文由 @delba_oliveira 撰写。