Claude Code四种循环模式:回合制、目标、时间与主动式

claudedevs 发布于 2026-07-07 阅读 30

本文由Claude Code团队撰写,详细介绍了编程代理中的四种循环模式:基于回合的循环(手动提示,Claude自主完成)、基于目标的循环(/goal命令,直到满足退出条件)、基于时间的循环(/loop和/schedule定时触发)以及主动循环(事件或计划触发,自主运行)。

图像

现在有很多关于“设计循环”(而不是给编码智能体写提示)的讨论。如果你花些时间在 X 上试图弄明白循环究竟是什么,你会看到多种不同的定义。

在 Claude Code 团队,我们将循环定义为智能体重复工作周期,直至满足停止条件。我们根据以下因素对几种不同类型的循环进行分类:

  • 它们是如何触发的
  • 它们是如何停止的
  • 使用了哪种 Claude Code 原语
  • 每种循环最适合什么类型的任务。

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

回合制循环

图像

触发方式: 用户提示。

停止条件: Claude 判断任务已完成或需要更多上下文。

最佳用途: 不属于常规流程或日程的较短任务。

用量管理方式: 编写具体的提示,并通过 skills 改进验证,以减少回合数。

你发送的每个提示都会启动一个手动循环,由你主导每个回合。Claude 收集上下文、执行操作、检查工作、必要时重复,然后响应。我们称之为智能体循环。

例如,让 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)

图像

触发方式: 实时手动提示。

停止条件: 目标达成或达到最大回合数。

最佳用途: 具有可验证退出条件的任务。

用量管理方式: 设置具体的完成标准和明确的回合上限,例如“5 次尝试后停止”。

有时,单一回合是不够的,尤其对于更复杂的任务。当智能体能够迭代时,它们表现更好。你可以通过 /goal 定义“完成”的标准,从而延长 Claude 持续迭代的时间。

当你定义了成功标准后,Claude 就不需要判断什么是“足够好”并提前结束循环。每次 Claude 尝试停止时,评估模型都会检查你的条件,并让它回去继续工作,直到满足目标或达到你定义的回合数。

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

例如:

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

基于时间的循环 (/loop 和 /schedule)

触发方式: 指定的时间间隔。

停止条件: 你取消它,或者工作完成(PR 合并、队列清空)。

最佳用途: 用于重复性工作,或与外部环境/系统对接。

用量管理方式: 设置更长的时间间隔,或者基于事件而非时间来响应。

有些智能体工作是重复性的:任务保持不变,只有输入发生变化。例如,每天早上总结 Slack 消息。其他工作依赖于外部系统,与外部系统对接的一种简单方法是按时间间隔检查它,并对变化做出反应。例如,一个可能收到代码审查或 CI 失败的 PR。

对于这些情况,你可以使用 /loop 让 Claude 按时间间隔重新运行一个提示。例如:

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

/loop 在你的计算机上运行,因此如果你关闭它,它就会停止。你可以通过使用 /schedule 创建一个例程,将循环迁移到云端。

主动式循环

图像

触发方式: 事件或日程,无需实时人工参与。

停止条件: 每个任务在达成目标后退出。例程本身会一直运行,直到你关闭它。

最佳用途: 重复出现的、定义良好的工作流:Bug 报告、问题分类、迁移、依赖升级等。

用量管理方式: 将例程路由到更小、更快的模型,并使用最强大的模型进行判断决策。

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

例如,要处理传入的反馈,你可以使用:

  • /schedule(研究预览)来运行一个检查新报告的例程
  • /goal 来定义“完成”的样子,以及 skills 来记录如何验证
  • 动态工作流来编排智能体,对每个报告进行分类、修复和审查修复
  • 自动模式,使例程无需停下来请求许可即可运行

综合起来,一个提示可能如下所示:

/schedule every hour: 检查 project-feedback 频道中的 Bug 报告。/goal: 不要停止,直到此次运行中找到的每个报告都经过分类、处理并得到回应。修复 Bug 时,使用工作流在并行工作树中探索三种解决方案,并让一个裁判进行对抗性审查。

保持代码质量

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

  • 保持代码库本身整洁: Claude 会遵循你代码库中已有的模式和约定。
  • 让 Claude 能够验证自己的工作: 通过 skills 编码你和你的团队认为“良好”的标准。
  • 让文档易于获取: 框架和库的文档包含最新的最佳实践。
  • 使用第二个智能体进行代码审查: 具有新鲜上下文的审查者偏见较少,不受主智能体推理的影响。你可以使用内置的 /code-review skill 或 GitHub 的 Code Review 功能。

当单个结果不符合标准时,不要止步于修复单个问题,尝试将其编码到系统中,以改进所有未来的迭代。

管理 Token 用量

为了管理 Token 用量,循环应该有明确的界限:

  • 为工作选择合适的原语和模型: 较小的任务不需要多个智能体或循环。某些任务可以使用更便宜、更快的模型。
  • 定义清晰的成功和停止标准: 具体说明“完成”的样子,以便 Claude 能更快地得出结论(但不要过快)。
  • 在大规模运行前先试点: 动态工作流可能生成数百个智能体。先在一小部分工作上评估用量。
  • 对确定性工作使用脚本: 运行脚本比推理步骤更便宜。例如,一个 PDF skill 可以提供一个填表脚本,Claude 每次运行它,而不是重新推导代码。
  • 不要比所需的频率更频繁地运行例程: 将时间间隔与监控对象的变化频率匹配。
  • 审查用量: /usage 命令按 skills、子智能体和 MCP 细分最近用量;不带参数的 /goal 显示到目前为止的回合数和 Token 用量;/workflows 显示每个智能体的 Token 用量,你可以随时停止一个智能体。

入门指南

总结如下:

循环类型 你交接的内容 何时使用 使用工具
回合制循环 检查工作 你在探索或做决定时 自定义验证 skills
基于目标的循环 停止条件 你知道完成的标准是什么 /goal
基于时间的循环 触发条件 工作发生在项目外部并按计划进行 /loop, /schedule
主动式循环 提示 工作是重复性的且定义良好 以上所有,以及动态工作流

要开始使用循环,请审视你已经完成的工作。选择一个你自身成为瓶颈的任务,并思考你可以交接哪一部分:你能写出验证检查吗?目标是否足够清晰?工作是按计划到达的吗?

一旦你有了想法,运行循环,观察结果,比如它在哪里停滞或过度延伸,不要害怕对其进行迭代。

如需更多信息,请阅读 Claude Code 文档中关于并行运行智能体的说明,以及 loopschedulegoaldynamic workflows 页面。

本文由 @delba_oliveira 撰写

  • 原文链接: x.com/ClaudeDevs/status/...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论