【翻译】循环（loops）入门指南

循环（loops）入门指南

原文链接：claude.com/blog/gettin...

原文作者：Delba de Oliveira、Michael Segner

了解 Claude Code 团队如何定义智能体循环（agentic loops），并获得从回合制循环到基于目标的、基于时间的以及主动式循环的实用指南------以及每种循环的适用时机。

现在关于"设计循环（loops）"而不是给你编码智能体写提示词（prompt）的讨论很多。如果你在 X 上花些时间试图明确循环究竟是什么，你会看到多种不同的答案。

在 Claude Code 团队，我们把 循环定义为智能体重复执行工作周期，直到满足某个停止条件。我们根据以下几点把循环划分为几种不同类型：

它们如何被触发
它们如何被停止
使用哪种 Claude Code 原语（primitive）
每种循环最适合哪类任务

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

回合制循环（Turn-based loops）

触发方式：用户提示词。
停止条件：Claude 判定它已完成任务或需要额外上下文。
最适合用于：不属于常规流程或时间安排的较短任务。
用量管理方式：编写具体的提示词，并使用技能（skills）改进验证，以减少回合数。

你发送的每一条提示词都会启动一个手动循环，由你指挥每一个回合。Claude 收集上下文、采取行动、检查自己的工作、必要时重复，并给出回复。我们把这称为智能体循环（agentic loop）。

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

你可以通过把手动步骤编码为一份 SKILL.md 来改进验证环节，让 Claude 端到端地检查更多自身工作。这应当包括让 Claude 能够看见、测量或交互该结果的工具或连接器。检查越具量化性，Claude 就越容易自我验证。

例如，在你的 SKILL.md 文件中可以指定：

markdown 复制代码

---
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-based loop，/goal）

触发方式：实时手动提示词。
停止条件：达成目标，或达到最大回合数。
最适合用于：具有可验证退出条件的任务。
用量管理方式：设定具体的完成条件与显式回合上限，例如"5 次尝试后停止"。

有时单个回合是不够的，对于更复杂的任务尤其如此。智能体在能够迭代时表现更好。你可以通过用 /goal 定义"完成"的样子来延长 Claude 持续迭代的时间。

当你定义了成功条件，Claude 就不必自行判断什么是"足够好"而过早结束循环。每次 Claude 尝试停止时，一个评估模型（evaluator model）会检查你的条件，并把它送回去继续工作，直到目标达成或达到你设定的回合数。

这就是确定性条件（例如通过的测试数量，或达到某个分数阈值）如此有效的原因。

例如：

markdown 复制代码

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

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

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

某些智能体工作是周期性的：任务不变，只有输入变化。例如，每天早上汇总 Slack 消息。另一些工作依赖外部系统，而与这类系统交互的一种简单方式是按间隔检查它并对变化做出反应。例如，一个 PR 可能收到代码审查或 CI 失败。

对于这些场景，你可以用 /loop 触发 Claude 何时运行，它会在一个间隔上重复执行一条提示词。例如：

markdown 复制代码

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

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

主动式循环（Proactive loops）

触发方式：事件或时间安排，实时无人参与。
停止条件：每个任务在达成其目标时退出。例程本身会一直运行，直到你关闭它。
最适合用于：定义良好的周期性工作流：bug 报告、issue 分诊、迁移、依赖升级等。
用量管理方式：把例程路由到更小、更快的模型，并把最有能力的模型用于需要判断的决策。

上述原语，连同其他 Claude Code 特性如 自动模式（auto mode） 和 动态工作流（dynamic workflows）（研究预览），可以组合成一个用于长期运行的循环。

例如，要处理传入的反馈，你可以使用：

/schedule（研究预览）运行一个检查新报告的例程
/goal 定义"完成"的样子，并用 技能（skills） 文档化如何验证它
动态工作流 编排智能体对每条报告进行分诊、修复并审查该修复
自动模式 让例程无需停下来请求许可即可运行

把它们组合起来，一条提示词可以长这样：

markdown 复制代码

/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 一种验证自身工作的方式 ：用技能（skills）为你和你的团队编码"好"的样子。
让文档触手可及：框架和库的文档包含最新的最佳实践。
使用第二个智能体做代码审查 ：拥有全新上下文的审查者偏见更少，且不会受主智能体推理的影响。你可以使用内置的 /code-review 技能或 GitHub 的代码审查（Code Review）。

当某个结果未达到标准时，不要止步于修复这一个别问题，而应尝试将其编码下来，以改进系统在所有未来迭代中的表现。

管理 token 用量

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

为任务选择正确的原语和模型：较小的任务不需要多个智能体或循环。某些任务可以使用更便宜、更快的模型。
定义清晰的成功与停止条件：具体说明"完成"的样子，以便 Claude 更快到达解决方案（但不要太快）。
在大规模运行前先试点：动态工作流可能产生数百个智能体。先在工作的一个较小切片上衡量用量。
用脚本处理确定性工作：运行脚本比推理各个步骤更便宜。例如，一个 PDF 技能可以附带一个填表脚本，让 Claude 每次直接运行，而不是重新推导代码。
不要比需要的更频繁地运行例程：让间隔与你所观察对象的变化频率相匹配。
审查用量 ：/usage 命令按技能、子智能体和 MCP 拆分近期用量；不带参数的 /goal 显示到目前为止的回合数与 token 用量；/workflows 显示每个智能体的 token 用量，你可以随时停止某个智能体。

入门

总结一下：

循环类型	你交出去的	适用时机	可选用
回合制（Turn-based）	检查环节	你在探索或做决策时	自定义验证技能
基于目标（Goal-based）	停止条件	你知道"完成"长什么样时	`/goal`
基于时间（Time-based）	触发条件	工作在项目之外按时间安排发生时	`/loop`、`/schedule`
主动式（Proactive）	提示词	工作是周期性且定义良好时	上述全部，加上动态工作流

要开始使用循环，看看你已经在做的工作。挑出一个你是瓶颈的任务，并问自己能交出去哪一部分：你能把验证检查写下来吗？目标是否足够清晰？工作是否按时间安排到达？

一旦有了想法，就运行循环，观察结果------比如它在哪里停滞或过度扩张------并不要害怕对它进行迭代。

如需更多信息，请阅读 Claude Code 文档中关于并行运行智能体的部分，以及 loop、schedule、goal 和动态工作流（dynamic workflows）页面。

本文由 Delba de Oliveira 与 Michael Segner 撰写