循环工程：入门循环（Loops）

来源：本文翻译自 Anthropic 官方博客 Loop engineering: Getting started with loops，发布于 2026 年 6 月 30 日。作者：Delba de Oliveira、Michael Segner。

入门循环

目前有很多关于"循环工程"或"设计循环"的讨论，而不是编写提示词来驱动你的编程 agent。如果你在 X（Twitter）上花些时间试图弄清楚"循环"到底是什么，你会发现有多种不同的答案。

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

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

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

轮次式循环（Turn-based Loop）

触发方式：用户提示词。
停止条件：Claude 判断任务已完成或需要额外上下文。
最佳用途：不属于常规流程或计划的较短任务。
用量管理：编写精确的提示词，使用 skills 改进验证以减少轮次数。

你发送的每个提示词都会启动一个手动循环，由你引导每一轮。Claude 收集上下文、采取行动、检查工作、按需重复，然后返回结果。我们称之为 agent 循环。

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

你可以通过将手动步骤编码为 SKILL.md 来改进验证环节，让 Claude 能够端到端地自主检查更多工作。（关于在 skills、hooks 和 subagents 之间选择来实现此类自动化，请参阅我们的 Claude Code 引导指南。)

这应包含工具或连接器，让 Claude 能够查看、测量或交互结果。检查越量化，Claude 自我验证就越容易。

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

---
name: verify-frontend-change
description: 在宣布 UI 变更完成前进行端到端验证。
---

# 验证前端变更
永远不要仅凭成功的编辑就报告 UI 变更已完成。像人工审查者那样验证：

1. 启动开发服务器，在浏览器中打开编辑过的页面。
2. 直接与变更交互。对于新控件（按钮、输入框、开关）：点击它，确认预期的状态变化，截图记录前后对比。
3. 检查浏览器控制台：确保没有新增错误或警告。
4. 使用 Chrome Devtools MCP，运行性能追踪并审计 Core Web Vitals。

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

目标式循环（Goal-based Loop，`/goal`）

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

有时单轮不够，特别是对于更复杂的任务。Agent 在能够迭代时表现更好。你可以通过使用 /goal 定义"完成"的样子来延长 Claude 的迭代时间。

当你定义成功标准时，Claude 不必自行判断什么是"足够好"并提前结束循环。每次 Claude 尝试停止时，评估器模型会检查你的条件，并将其送回继续工作，直到目标达成或达到你定义的轮次上限。

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

例如：

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

时间式循环（Time-based Loop，`/loop` 和 `/schedule`）

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

有些 agent 工作是周期性的：任务不变，只有输入变化。例如，每天早上汇总 Slack 消息。其他工作依赖于外部系统，与之交互的一种简单方式是按间隔检查并响应变化。例如，一个可能收到代码审查或 CI 失败的 PR。

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

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

/loop 在你的电脑上运行，关闭即停止。你可以通过使用 /schedule 创建定时任务将循环迁移到云端。

主动式循环（Proactive Loop）

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

上述原语，连同 Claude Code 的其他功能如自动模式和动态工作流（研究预览），可以组合成一个长时间运行工作的循环。

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

/schedule（研究预览）运行一个检查新报告的定时任务
/goal 定义完成标准，skills 记录如何验证
动态工作流 编排 agent 对每个报告进行分诊、修复和审查
自动模式 让定时任务无需停下来请求权限即可运行

整合在一起，提示词可能长这样：

/schedule 每小时：检查 #project-feedback 频道的 bug 报告。
/goal：不停止，直到本次运行中找到的每个报告都被分诊、处理并回复。
修复 bug 时，使用工作流在并行工作树中探索三种方案，并让评审 agent 对它们进行对抗性审查。

保持代码质量

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

保持代码库本身的整洁：Claude 会遵循代码库中已有的模式和约定。
给 Claude 提供自我验证的方法：通过 skills 编码你和团队对"好"的定义。
让文档易于访问：框架和库的文档有最新的最佳实践。
使用第二个 agent 进行代码审查：拥有全新上下文的审查者偏见更小，不受主 agent 推理的影响。你可以使用内置的 /code-review skill 或 Code Review for Github。

当个别结果不符合标准时，不要止步于修复个别问题，尝试将其编码以改进系统，让所有后续迭代受益。

管理 token 用量

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

为任务选择合适的原语和模型：小任务不需要多个 agent 或循环。有些任务可以使用更便宜、更快的模型。
定义明确的成功和停止标准：具体说明完成的样子，让 Claude 能更快（但不过快）地找到解决方案。
大规模运行前先试点：动态工作流可以生成数百个 agent。先在较小的工作切片上评估用量。
对确定性工作使用脚本：运行脚本比逐步推理更便宜。例如，PDF skill 可以提供一个表单填充脚本，Claude 每次运行它，而不是重新推导代码。
不要过于频繁地运行定时任务：将间隔与你监控的事物变化频率匹配。
审查用量：/usage 命令按 skills、subagents 和 MCPs 分解最近的用量，无参数的 /goal 显示当前轮次和 token 用量，/workflows 显示每个 agent 的 token 用量，你可以随时停止某个 agent。

你的模型和 effort 级别选择是影响循环成本的最大杠杆之一。

入门总结

循环类型	你交出什么	使用场景	使用工具
轮次式	验证环节	你在探索或决策	自定义验证 skills
目标式	停止条件	你知道完成是什么样子	`/goal`
时间式	触发器	工作在项目外按计划发生	`/loop`、`/schedule`
主动式	提示词	工作是周期性且明确的	以上所有，加上动态工作流

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

有了想法后，运行循环，观察结果（比如在哪里卡住或过度展开），不要害怕迭代它。

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