如何写高质量、低Token消耗的Loops，Claude官方教程来了

随着 AI Agent 越来越强，Loops 逐渐成为大热门，就像曾经的 Prompts，Skills。它们一次次预示着 AI 又迈上了一个新台阶。

眼下，AI 来到了“自动驾驶”时代，你设定好目的地（目标），它自己会规划路线、自己驾驶、观察路况、修正方向，直到把你送到地方，全程不需要你手动操作方向盘。

关于“设计循环（designing loops）而非给你的编码智能体写提示词”的讨论越来越多。如果你花点时间搞清楚一个循环到底是什么，会看到五花八门的答案。

Claude 开发者官方账号刚刚发布一篇 Loops 入门教程，教你怎么坐上 AI 自动驾驶仓。

在 Claude Code 团队里，循环（loop）定义为：智能体反复执行一段工作循环，直到某个停止条件被满足。

他们依据以下几个维度，把循环划分成了几种不同类型：

它们如何被触发

它们如何被停止

它们使用哪种 Claude Code 原语（primitive）

每种循环最适合哪类任务

主要的循环类型有哪些？各自的适用场景是什么？在控制 token 消耗的同时如何维持代码质量？这篇入门教程都给你讲明白了。

并非所有任务都需要复杂的循环，从最简单的方案入手，按需选用这些模式。

基于轮次的循环

触发方式（Triggered by）：用户提示词（prompt）。

停止条件（Stop criteria）：Claude 判断任务已完成，或需要更多上下文。

最适用于（Best used for）：较短、且不属于常规流程或排程的任务。

用量管理（Managed usage by）：撰写具体的提示词，并通过 skills 强化验证环节，从而减少所需的轮次。

你发出的每一条提示词都会启动一个手动循环，由你主导每一轮。Claude 会收集上下文、采取行动、自检工作、必要时重复，最后给出回应。

举个例子，让 Claude 创建一个点赞按钮。它会读取你的代码、做修改、跑测试，然后交还一个它认为能跑的东西。接下来你手动检查这版工作成果，再写下一条提示词。

你可以把“验证”这一步做得更强：把你那些手动步骤编码进 SKILL.md，让 Claude 能够端到端地自检更多工作。这应当包括让 Claude 可以看见、测量或与之交互最终结果的工具或连接器。检查越能量化，Claude 自检就越容易。

例如，你可以在 SKILL.md 文件里这样写：

基于目标的循环，/goal

触发方式：实时手动提示词。

停止条件：目标达成，或达到最大轮次数。

最适用于：具有可验证退出条件的任务。

用量管理：设定明确的完成条件以及显式的轮次上限，例如“在 5 次尝试后停止”。

有时候一轮并不够，尤其是更复杂的任务。智能体在能够迭代时表现会更好。你可以用 /goal 定义“什么算完成”，从而延长 Claude 的迭代过程。

当你定义了成功标准后，Claude 就不必自己判断什么叫“够好”而过早结束循环。

每次 Claude 试图停下时，一个评估模型（evaluator model）会检查你设定的条件，并把它打回去继续工作，直到目标达成或达到你设定的轮次上限。

这就是为什么确定性条件会如此有效。比如通过的测试数量、或越过某个分数阈值：

基于时间的循环，/loop 和 /schedule

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

停止条件：你手动取消，或工作完成（PR 合入、队列为空等）。

最适用于：周期性工作，或需要与外部环境/系统对接的场景。

用量管理：设置更长的间隔，或改为基于事件（event）响应而非基于时间。

有些 agentic 工作是周期性的，任务本身不变，只是输入在变。例如，每天早上汇总 Slack 消息。

另一些工作则依赖外部系统，对接它们的一种简单做法就是按时间间隔去检查、并对变化做出反应。例如，一个 PR 可能会收到代码评审意见或 CI 失败。

对这些场景，你可以用 /loop 控制 Claude 何时运行。它会在指定间隔上反复执行一段提示词。

例如：

/loop 跑在你自己的电脑上，所以一旦你关机，它就停了。你可以用 /schedule 创建一个 routine，把循环搬到云端运行。

主动式循环

触发方式：由事件或排程触发，过程中没有人在实时参与。

停止条件：每一个任务在其目标达成时退出；routine 本身则一直运行，直到你把它关掉。

最适用于：源源不断、定义良好的周期性工作：bug 报告、issue 分诊（triage）、迁移、依赖升级等。

用量管理：把 routine 路由到更小、更快的模型上，只在需要判断决策时调用最强大的模型。

上面提到的原语，再加上 Claude Code 的其他能力，例如 auto mode 和研究预览版 dynamic workflows（动态工作流），可以组合成一个用于长时间运行工作的循环。

例如，要处理源源不断反馈进来的意见，你可以这样组合：

用 /schedule（研究预览版）跑一个 routine，定期检查是否有新报告；

用 /goal 定义“什么算完成”，并用 skills 文档化如何验证它；

用 Dynamic workflows 编排多个 agent：分别负责分诊每份报告、修复问题、并复核修复；

用 auto mode 让 routine 不必停下征求许可而持续运行。

组合起来，一段提示词可以长这样：

代码质量、Token 消耗与快速上手

一个循环产出的质量，取决于围绕它搭建的整套系统。

在设计这套系统时：

保持代码库本身整洁：Claude 会沿用你代码库里已有的模式与约定。

给 Claude 一种自检的方式：用 skills 把“你和团队眼中什么样算好”编码下来。

让文档触手可及：框架与库的文档要随时能拿到最新最佳实践。

用第二个 agent 做代码评审：带着全新上下文的评审者偏见更少，不会被主 agent 的推理带偏。你可以用内置的 /code-review skill，或针对 GitHub 使用 Code Review。

当某一次产出不达标时，不要止步于修掉这一处个别问题，试着把它编码进系统里，让未来每一次迭代都受益。

为控制 token 消耗，循环应当有清晰的边界：

为任务选对原语和模型：较小的任务用不上多 agent 或循环；有些任务可以用更便宜、更快的模型。

定义清晰的成功与停止条件：把“什么算完成”说清楚，让 Claude 更快抵达答案（但别快得过头）。

大规模运行前先试点：Dynamic workflows 可能会派出几百个 agent。先用一小片工作量摸一摸用量。

确定性的工作用脚本：跑脚本比让模型推理每一步更便宜。例如，某个 PDF skill 可以附带一段填表脚本，让 Claude 每次直接运行，而不是每次重新推导代码。

别比实际需要更频繁地跑 routine：把间隔对齐到“你正在盯的那件事”实际变化的频率。

回顾用量：/usage 命令会按 skills、子 agent 和 MCP 拆解最近用量；不带参数的 /goal 会显示到目前为止的轮次数与 token 用量；/workflows 显示每个 agent 的 token 用量，且你随时可以停掉某个 agent。

要上手循环，先看看你已经在做的工作。

挑出你自己成了瓶颈的那一项任务，问问自己：你能把哪一块交出去？验证检查你能写下来吗？目标够清晰吗？这工作是按排程到来的吗？

有了想法之后，跑起循环，观察结果，看它在哪里卡住、在哪里做过头，然后反复迭代。

参考资料：

https://x.com/ClaudeDevs/status/2074208949205881033