别再逐条下达指令，学习为Agent设计"工作循环"，让AI编程助手自主实现任务闭环，显著提升开发效率。

核心内容：

1. 循环设计的核心定义与分类维度
2. 基于轮次与基于目标的两大循环模式详解
3. 如何通过技能文件与用量管理提升效率

当下许多开发者都在探讨"设计循环（loop）"的实践，而非仅仅为你的编程Agent编写提示词。如果你在X平台上花些时间想弄清循环的本质，你会发现众说纷纭、定义不一。

在Claude Code团队，我们对循环的定义非常直接：Agent反复执行工作周期，直到满足某个停止条件。根据以下几个维度，我们将循环划分为不同类型：

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

下面逐一介绍主要的循环类型及其适用场景，并探讨如何在管理Token用量的同时保持代码质量。需要提醒的是：并非所有任务都需要复杂的循环。建议从最简单的方案起步，有选择地应用这些模式。

基于轮次的循环（Turn-based loops）

• 触发方式：用户的一条提示词
• 停止条件：Claude判断它已完成任务或需要额外上下文
• 最佳适用场景：不属于常规流程或计划的较短任务
• 管理用量的方式：编写具体的提示词，并通过Skill改进验证步骤以减少轮次数

简单来说，你每次输入的提示词都相当于手动启动了一个循环圈，由你指挥每一轮执行。Claude收集上下文、执行操作、检查工作成果、必要时重复，然后给你回复。我们称之为Agent循环（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次后停止"

对于更复杂的任务，单轮循环往往不够。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 loops）

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

上述原语与Claude Code的其他功能（如Auto模式和动态工作流（Dynamic Workflows），研究预览）相结合，可以组合成一个用于长期运行工作的循环。

假设你要处理传入的反馈，可以这样组合：

1. /schedule（研究预览）运行一个检查新报告的例行任务
2. /goal 定义完成长什么样，Skills 记录如何验证
3. 动态工作流 编排多个Agent对每个报告进行分类、修复和评审
4. Auto模式 让例行任务运行时不需要停下来请求许可

将它们组合在一起，一条提示词可以是这样：

/schedule 每小时：检查 #project-feedback 中的bug报告。

/goal：不要停下来，直到本次运行发现的每个报告都已分类、处理和回复。

修复bug时，使用工作流在并行工作树中探索三个方案，

并让一个评审者对它们进行对抗性评审。

保持代码质量

循环输出的质量，最终取决于它周围系统的设计水平。在设计系统时，有几个要点值得留意：

• 保持代码库本身的整洁：Claude会遵循代码库中已有的模式和约定。
• 给Claude一种验证自身工作的方式：用Skill编码你和团队对"好"的定义。
• 让文档触手可及：框架和库的文档包含最新的最佳实践。
• 使用第二个Agent做代码评审：拥有全新上下文的评审者偏见更少，不会受主Agent推理的影响。你可以使用内置的 /code-review Skill或Code Review for Github。

当某个结果不符合标准时，不要只停留在修复单个问题——试着将其编码化，以便整个系统在未来所有迭代中都能做得更好。

管理Token用量

为了管理Token用量，循环应该具备清晰的边界：

• 为任务选择合适的原语和模型：较小的任务不需要多个Agent或循环。有些任务完全可以用更便宜、更快的模型完成。
• 定义明确的成功和停止标准：具体说明完成长什么样，这样Claude可以更快地抵达解决方案（当然也不能太快）。
• 大规模运行前先小范围试跑：动态工作流可以生成数百个Agent。先在一小部分工作上评估用量。
• 确定性工作用脚本：运行脚本比推理每个步骤便宜得多。例如，一个PDF Skill可以附带一个表单填写脚本让Claude每次运行，而不是每次重新推导代码。
• 不要比需要的更频繁地运行例行任务：让间隔匹配你监控的事物变化的频率。
• 查看用量：/usage 命令按Skill、子Agent和MCP分解最近的用量；无参的 /goal 显示当前轮次数和Token用量；/workflows 显示每个Agent的Token用量，你可以随时停止某个Agent。

总结一下

• 基于轮次 — 交出：验证检查 ／ 何时使用：你在探索或做决策 ／ 使用：自定义验证Skill
• 基于目标 — 交出：停止条件 ／ 何时使用：你知道完成长什么样 ／ 使用：/goal
• 基于时间 — 交出：触发时机 ／ 何时使用：工作按计划在你的项目之外发生 ／ 使用：/loop、/schedule
• 主动循环 — 交出：整个提示词 ／ 何时使用：工作是重复性且定义明确的 ／ 使用：以上所有，加上动态工作流

要开始使用循环，可以先回顾你已经在做的工作。找一个你成为瓶颈的任务，问问自己哪部分可以交出去：你能编写验证检查吗？目标够清晰吗？工作是按计划到来的吗？

一旦有了想法，就运行循环，观察结果——比如它在哪些地方卡住或做过头了——然后别怕，对它的设计进行迭代。

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

英文原文来自Claude code官方博客