现在大家都在谈论为编码 Agent「设计循环」，而不是简单地给它提示。如果你花些时间在 X 上试图弄清楚「循环」到底是什么，你会看到多种不同的答案。
在 Claude Code 团队，我们将循环定义为 Agent 重复执行工作，直到满足停止条件的过程。我们根据以下几个方面对不同类型的循环进行分类：
- 它们的触发方式
- 它们的停止方式
- 使用了哪种 Claude Code 原语
- 每种循环最适合什么类型的任务
我们将介绍主要的循环类型、每种循环的使用场景，以及如何在管理 Token 用量的同时保持代码质量。并非所有任务都需要复杂的循环；从最简单的方案开始，并有选择地使用这些模式。
回合制循环
- 触发方式：用户提示。
- 停止条件：Claude 判断任务已完成，或需要更多上下文。
- 最佳用途：不属于常规流程或计划的较短任务。
- 用量管理：编写具体的提示，并使用技能（Skills）改进验证步骤，以减少回合数。
你发送的每一个提示都会启动一个手动循环，由你指导每一步。Claude 收集上下文、执行操作、检查工作、必要时重复、然后回应。我们称之为 Agent 循环。
例如，让 Claude 创建一个点赞按钮。它会读取你的代码、进行编辑、运行测试，然后交回一个它 认为 可以工作的东西。然后，你需要手动检查工作，并编写下一个提示。
你可以通过将手动检查步骤编码为 SKILL.md 文件来改进验证步骤，这样 Claude 就可以端到端地检查自己更多的工作。这应包括允许 Claude 查看、测量 或 交互 结果的工具或连接器。检查越量化，Claude 就越容易进行自我验证。
例如，在你的 SKILL.md 文件中，你可以指定：
1---2name: verify-frontend-change3description: 在声明完成之前，端到端地验证任何 UI 变更。4---56# 验证前端变更7不要仅基于成功编辑就报告 UI 变更为完成。应像人类审查者一样验证它：891. 启动开发服务器，并在浏览器中打开已编辑的页面。10112. 直接与变更进行交互。对于新的控件（按钮、输入框、切换开关）：点击它，确认预期的状态变化，并对变更前后进行截图。12133. 检查浏览器控制台：确保没有出现新的错误或警告。14154. 使用 Chrome Devtools MCP，运行性能追踪并审计核心网页指标。1617如果任何步骤失败，请修复问题并从步骤 1 重新开始——不要交回未完全验证的工作。
基于目标的循环 (/goal)
- 触发方式：实时手动提示。
- 停止条件：达到目标 或 达到最大回合数。
- 最佳用途：具有可验证退出标准的任务。
- 用量管理：设定具体的完成标准和明确的回合上限，例如「尝试 5 次后停止」。
有时，单次回合是不够的，尤其是在处理更复杂的任务时。Agent 在能够迭代时表现更好。你可以通过定义「完成」的样子来扩展 Claude 持续迭代的时间，这需要使用 /goal。
当你定义了成功标准后，Claude 就无需自行判断什么「足够好」而过早结束循环。每当 Claude 尝试停止时，一个评估模型会检查你的条件，并让它返回工作，直到满足目标或达到你定义的回合数。
这就是为什么确定性标准（例如通过的测试数量或达到特定分数阈值）如此有效。
例如：
1/goal 让首页的 Lighthouse 得分达到 90 分或以上，尝试 5 次后停止。
基于时间的循环 (/loop 和 /schedule)
- 触发方式：指定的时间间隔。
- 停止条件：你取消它，或者工作完成（PR 合并、队列清空）。
- 最佳用途：适用于重复性工作，或与外部环境/系统交互。
- 用量管理：设置更长的时间间隔，或者基于事件而非时间来响应。
有些 Agent 工作是重复性的：任务保持不变，只有输入变化。例如，每天早上总结 Slack 消息。其他工作则依赖于外部系统，与之交互的一个简单方法是按时间间隔检查并响应变化。例如，一个可能收到代码审查或 CI 失败的 PR。
对于这些情况，你可以使用 \/loop`` 来触发 Claude 按时间间隔重新运行一个提示。例如：
1/loop 5m 检查我的 PR，处理审查意见，并修复失败的 CI
\/loop` 在你的电脑上运行，所以如果你关闭电脑，它就会停止。你可以通过使用 \/schedule\` 创建例程来将循环移至云端。
主动式循环
- 触发方式：事件或计划安排，无需实时人工参与。
- 停止条件：每个任务在达成目标后退出。例程本身会一直运行直到你关闭它。
- 最佳用途：针对定义明确的重复性工作流：Bug 报告、问题分类、迁移、依赖升级等。
- 用量管理：将例程路由到更小、更快的模型，并使用能力最强的模型进行判断决策。
上述原语，连同其他 Claude Code 功能如自动模式和动态工作流（研究预览版），可以被组合成一个用于长期运行工作的循环。
例如，为了处理传入的反馈，你可以使用：
- `/schedule`（研究预览版）来运行一个检查新报告的例程
- `/goal` 来定义完成标准，并使用技能来记录如何验证它
- 动态工作流 来编排 Agent，对每个报告进行分类、修复并审查修复
- 自动模式 使例程无需停止请示即可运行
综合起来，一个提示可能如下所示：
1/schedule 每小时：检查 project-feedback 频道中的 Bug 报告。/goal：不要停止，直到本次运行时发现的每个报告都被分类、处理并回复。修复 Bug 时，使用工作流在并行工作树中探索三个解决方案，并让一个评判者对立地审查它们。
保持代码质量
循环输出的质量取决于其周围的系统。在设计系统时：
- 保持代码库本身整洁：Claude 会遵循你代码库中已有的模式和约定。
- 让 Claude 能够验证自己的工作：通过技能为你和你的团队编码出「好的标准」。
- 让文档易于访问：框架和库的文档应包含最新的最佳实践。
- 使用第二个 Agent 进行代码审查：拥有新上下文的审查者偏见更少，且不受主 Agent 推理的影响。你可以使用内置的
/code-review技能或 GitHub 的 代码审查 功能。
当个别结果未达到标准时，不要止步于修复单个问题，尝试将其编码化，以改进所有未来迭代的系统。
管理 Token 用量
为了管理 Token 用量，循环应有明确的界限：
- 为任务选择合适的原语和模型：较小的任务不需要多个 Agent 或循环。有些任务可以使用更便宜、更快的模型。
- 定义明确的成功和停止标准：具体说明完成的样子，以便 Claude 能更快地找到解决方案（但也不要太快）。
- 在大规模运行前进行试点：动态工作流可能生成数百个 Agent。先在一小部分工作上评估用量。
- 对确定性工作使用脚本：运行脚本比推理执行步骤更便宜。例如，一个 PDF 技能可以附带一个填写表单的脚本，让 Claude 每次运行它，而不是重新推导代码。
- 不要比需要更频繁地运行例程：将时间间隔与你正在监控的事物的变化频率相匹配。
- 审查用量：
/usage命令按技能、子 Agent 和 MCP 细分最近用量；不带参数的/goal显示当前回合数和 Token 用量；/workflows显示每个 Agent 的 Token 用量，你可以随时停止一个 Agent。
入门指南
总结如下：
循环类型
你交出的控制权
使用场景
推荐工具
回合制
检查
你在探索或做决策
自定义验证技能
基于目标
停止条件
你知道完成的样子
/goal
基于时间
触发条件
工作在你的项目外部按计划进行
/loop
,
/schedule
主动式
提示
工作是重复性的且定义明确
以上所有，以及动态工作流
要开始使用循环，请审视你已经在做的工作。选择一个你成为瓶颈的任务，并思考你可以交出哪一部分：你能编写验证检查吗？目标是否足够清晰？工作是否按计划到达？
一旦你有了想法，运行循环，观察结果（比如它在哪卡住或过度扩展），并且不要害怕迭代。
有关更多信息，请阅读关于并行运行 Agent 的 Claude Code 文档，以及关于 loop、schedule、goal 和动态工作流的页面。
本文由 @delba_oliveira 撰写
