📌 本文翻译自 Getting started with loops，作者 @delba_oliveira

1. 循环入门指南

最近大家都在说"设计循环"而不是给你的编码 Agent 写提示词。如果你花点时间在 X 上试着搞清楚循环到底是什么，你会看到多种不同的答案。

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

• 如何触发
• 如何停止
• 使用哪种 Claude Code 原语
• 每种类型最适合什么任务

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

1.1. 基于回合的循环

• 触发方式：用户提示。
• 停止条件：Claude 判断任务已完成或需要额外上下文。
• 最佳用途：不属于定期流程或计划的较短任务。
• 用量管理：编写具体提示并使用 Skill 改进验证，以减少回合数。

你发送的每条提示都会启动一个手动循环，由你逐回合引导。

1.1.1. Agent 循环的工作原理

Claude 收集上下文、采取行动、检查工作、必要时重复，然后回复。我们称之为 Agent 循环。

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

1.1.2. 用 SKILL.md 改进验证

你可以将手动步骤编码为 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.

1.2. 基于目标的循环（/goal）

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

1.2.1. 何时需要多回合迭代

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

当你定义了成功标准后，Claude 无需自行判断什么是"足够好"而过早结束循环。每次 Claude 试图停止时，一个评估器模型会检查你的条件，并将其送回工作，直到目标达成或达到你定义的回合数。

1.2.2. 确定性标准的重要性

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

例如：

/goal 将首页 Lighthouse 分数提升到 90 以上，尝试 5 次后停止。

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

• 触发方式：指定的时间间隔。
• 停止条件：你取消它，或工作完成（PR 合并、队列为空）。
• 最佳用途：适用于定期工作，或与外部环境/系统对接。
• 用量管理：设置更长的间隔，或基于事件而非时间来响应。

1.3.1. 定期工作：任务不变，输入在变

有些 Agent 工作是定期重复的：任务不变，只有输入在变。例如，每天早上汇总 Slack 消息。其他工作则依赖于外部系统，与之对接的简单方法就是按间隔检查并响应变化。例如，一个可能收到代码审查意见或 CI 失败通知的 PR。

对于这些场景，你可以使用 /loop 按间隔重新运行提示。例如：

/loop 5m 检查我的 PR，处理审查意见，修复失败的 CI

1.3.2. /loop 与 /schedule 的区别

/loop 在你的电脑上运行，所以如果你关机，它就会停止。你可以通过 /schedule 创建例行任务，将循环移到云端。

1.4. 主动循环

• 触发方式：事件或计划，实时无人参与。
• 停止条件：每个任务在目标达成时退出。例行任务本身一直运行到你关闭它。
• 最佳用途：持续不断的明确定义工作：Bug 报告、Issue 分类、迁移、依赖升级等。
• 用量管理：将例行任务路由到更小、更快的模型，用最强模型做判断。

1.4.1. 主动循环的触发与停止

上述原语以及其他 Claude Code 功能——如 auto mode 和 dynamic workflows（研究预览）——可以组合成用于长期运行的循环。

1.4.2. 组合原语构建长期运行

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

1. /schedule（研究预览）运行一个检查新报告的例行任务
2. /goal 定义"完成"的样子，skills 记录如何验证
3. Dynamic workflows 编排处理每个报告、修复它以及审查修复的 Agent
4. Auto mode 使例行任务无需停下来征求许可即可运行

综合起来，提示可能是这样的：

/schedule 每小时：检查 project-feedback 频道的 Bug 报告。/goal: 不要停止，直到本轮找到的每个报告都被分类、处理并回复。修复 Bug 时，使用 workflow 在三个并行工作树中探索解决方案，并由一个裁判进行对抗性审查。

1.5. 保持代码质量

1.5.1. 循环质量的基础

循环输出的质量取决于其周围的系统。设计系统时需注意：

• 保持代码库本身干净：Claude 遵循代码库中已有的模式和约定。
• 让 Claude 能验证自己的工作：通过 skills 为你和你的团队定义"好"的样子。
• 让文档易于获取：框架和库的文档应包含最新的最佳实践。
• 使用第二个 Agent 做代码审查：拥有新鲜上下文的审查者偏见更少，不易受主 Agent 推理的影响。你可以使用内置的 /code-review Skill 或 Code Review。

1.5.2. 从问题修复到系统改进

当单个结果不达标时，不要停留在修复单个问题上——尝试将其编码以改进整个系统，惠及所有未来的迭代。

1.6. 管理 Token 用量

1.6.1. 设置明确的边界

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

• 为任务选择合适的原语和模型： 小任务不需要多个 Agent 或循环。有些任务可以使用更便宜和更快的模型。
• 定义明确的成功和停止条件： 具体说明"完成"的样子，让 Claude 能更快（但不要太快）达成解决方案。
• 在大规模运行前先试点： Dynamic workflows 可以生成数百个 Agent。先在较小的工作量上评估用量。
• 确定性工作使用脚本： 运行脚本比一步步推理更便宜。例如，一个 PDF Skill 可以提供一个填写表单的脚本，供 Claude 每次运行，而非重新推导代码。

1.6.2. 审查与优化

• 不要比需要更频繁地运行例行任务： 将间隔与你监控对象的变更频率匹配。
• 审查用量： /usage 命令按 skills、子 Agent 和 MCP 细分近期用量；不带参数的 /goal 显示到目前为止的回合数和 token 用量；/workflows 显示每个 Agent 的 token 用量，你可以随时停止任何 Agent。

1.7. 开始使用

总结一下：

1.7.1. 从现有工作中找到切入点

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

1.7.2. 迭代改进

一旦你有了想法，运行循环，观察结果——在哪里停滞或过度扩展——不要害怕迭代它。

欲了解更多信息，请阅读 Claude Code 文档中的并行运行 Agent，以及 loop、schedule、goal 和 dynamic workflows 页面。

本文由 @delba_oliveira 撰写。