原文标题Getting started with loops原文作者ClaudeDevs本文由 delba_oliveira 撰写原文链接https://x.com/ClaudeDevs/status/2074208949205881033最近关于如何为编码智能体“设计循环loop”而不是仅仅编写提示词有很多讨论。如果你花一些时间在 X 上试图弄清楚循环到底是什么会看到多种不同的答案。在 Claude Code 团队我们将循环定义为智能体反复执行工作周期直到满足停止条件。我们根据以下几个方面将循环分成不同类型如何触发如何停止使用哪一种 Claude Code 原语每种循环最适合哪类任务。下面会介绍主要的循环类型、各自适用的场景以及如何在管理 token 用量的同时维持代码质量。并非所有任务都需要复杂循环请从最简单的解决方案开始有选择地使用这些模式。基于轮次的循环Turn-based loops触发方式用户提示词。停止条件Claude 判断任务已经完成或需要更多上下文。最适合不属于固定流程或日程安排的短期任务。用量管理编写具体明确的提示词并使用技能skills改进验证过程从而减少交互轮数。你发送的每个提示词都会启动一个由你逐轮引导的手动循环。Claude 收集上下文、采取行动、检查自己的工作在必要时重复这些步骤最后给出回复。我们称之为智能体循环agentic loop。例如你让 Claude 创建一个点赞按钮。它会读取代码、完成修改、运行测试然后交付一个它认为可以正常工作的结果。接着你手动检查结果再编写下一条提示词。你可以把自己的人工检查步骤写进SKILL.md以改进验证环节让 Claude 能够端到端地检查更多自己的工作。技能中应包含相应的工具或连接器使 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 次后停止”。有时一个轮次不足以完成任务复杂任务尤其如此。智能体在能够迭代时表现更好。你可以使用/goal明确定义“完成”的样子从而延长 Claude 持续迭代的时间。当你定义成功标准后Claude 就不必自行判断什么是“足够好”也不会过早结束循环。每当 Claude 尝试停止时评估模型都会检查你的条件如果条件尚未满足就会让它返回继续工作直到目标达成或达到你设定的轮数。这就是为什么确定性的标准格外有效例如通过测试的数量或达到某个评分阈值。例如/goal 将首页的 Lighthouse 得分提升到 90 分或以上尝试 5 次后停止。基于时间的循环Time-based loop/loop和/schedule触发方式指定的时间间隔。停止条件由你取消或者工作本身完成例如 PR 已合并、队列已清空。最适合重复性工作或需要与外部环境、外部系统交互的任务。用量管理设置更长的时间间隔或者改为根据事件而不是时间作出响应。有些智能体工作会反复发生任务保持不变只有输入会变化。例如每天早上汇总 Slack 消息。另一些工作依赖外部系统与这类系统交互的一种简单方式是定期检查并根据发生的变化采取行动。例如某个 PR 可能收到代码审查意见或者 CI 可能失败。针对这类任务可以使用/loop触发 Claude 按照固定时间间隔重新运行提示词。例如/loop 5m 检查我的 PR处理代码审查意见并修复失败的 CI。/loop在你的电脑上运行因此关机后它也会停止。你可以使用/schedule创建例程把循环迁移到云端。主动式循环Proactive loops触发方式由事件或日程触发无需人工实时参与。停止条件每项任务在目标达成时退出例程本身会持续运行直到你将其关闭。最适合持续出现、定义清晰的重复性工作例如错误报告、Issue 分类、迁移、依赖升级等。用量管理将例程分配给更小、更快的模型只有需要判断时才使用能力最强的模型。上面介绍的原语还可以与 Claude Code 的其他功能组合构成长时间运行的循环例如自动模式auto mode和动态工作流dynamic workflows研究预览版。例如要处理不断到来的反馈可以使用/schedule研究预览版运行一个检查新报告的例程/goal定义什么算完成并用技能记录如何验证动态工作流编排多个智能体对每份报告进行分类、修复并审查修复结果自动模式让例程持续运行而不会停下来请求权限。把这些组合起来后提示词可以写成/schedule 每小时执行检查 project-feedback 频道中的错误报告。 /goal在本轮发现的每份报告都完成分类、处理并获得回复之前不要停止。 修复错误时使用工作流在三个并行 worktree 中探索三种解决方案 再让一个评审智能体以对抗式方式审查它们。保持代码质量循环输出的质量取决于它周围的整个系统。设计这个系统时请注意保持代码库本身整洁Claude 会沿用代码库中已经存在的模式和约定。让 Claude 能够验证自己的工作通过技能写清楚你和团队眼中的“好结果”是什么。让文档易于获取框架和库的文档中包含最新的最佳实践。使用第二个智能体做代码审查拥有全新上下文的审查者偏见更少也不会被主智能体的推理过程影响。你可以使用内置的/code-review技能或 GitHub 的 Code Review。当某次结果没有达到标准时不要只修复眼前的单个问题尝试把这次经验编码进系统以改善今后的每一次迭代。管理 token 用量为了控制 token 用量循环应当具有清晰的边界为任务选择合适的原语和模型小任务不需要多个智能体或多层循环有些任务可以使用更便宜、更快的模型。定义清晰的成功标准和停止条件明确说明什么算完成使 Claude 更快抵达解决方案但也不要让它过早停止。大规模运行前先试点动态工作流可能生成数百个智能体。先在较小范围的任务上测量用量。用脚本处理确定性工作运行脚本比逐步推理成本更低。例如一个 PDF 技能可以自带表单填写脚本让 Claude 每次直接运行而不是重复推导代码。不要以超过实际需要的频率运行例程让执行间隔匹配被监控对象发生变化的频率。查看用量/usage命令会按技能、子智能体和 MCP 细分近期用量不带参数的/goal会显示目前的轮数和 token 用量/workflows会显示每个智能体的 token 用量你也可以随时停止某个智能体。开始使用循环总结如下循环类型你交出去的部分适用场景推荐使用基于轮次检查过程你正在探索或作出决策自定义验证技能基于目标停止条件你清楚什么算完成/goal基于时间触发条件工作按照日程在项目外部发生/loop、/schedule主动式提示词工作重复发生且定义清晰以上所有方式以及动态工作流要开始使用循环先看看你已经在做的工作。挑一个你自己是瓶颈的任务然后想想其中哪一部分可以交出去你能否写出验证检查目标是否足够清晰这项工作是否按照某种日程出现有了想法之后就运行这个循环并观察结果例如它会卡在哪里、是否做过了头。不要害怕根据观察继续迭代。如需了解更多信息请阅读 Claude Code 文档中关于并行运行智能体的内容以及 loop、schedule、goal 和动态工作流相关页面。本文为原文中文翻译版权归原作者所有。翻译仅用于学习与技术交流。