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

随着 AI Agent 越来越强Loops 逐渐成为大热门就像曾经的 PromptsSkills。它们一次次预示着 AI 又迈上了一个新台阶。眼下AI 来到了“自动驾驶”时代你设定好目的地目标它自己会规划路线、自己驾驶、观察路况、修正方向直到把你送到地方全程不需要你手动操作方向盘。关于“设计循环designing loops而非给你的编码智能体写提示词”的讨论越来越多。如果你花点时间搞清楚一个循环到底是什么会看到五花八门的答案。Claude 开发者官方账号刚刚发布一篇 Loops 入门教程教你怎么坐上 AI 自动驾驶仓。在 Claude Code 团队里循环loop定义为智能体反复执行一段工作循环直到某个停止条件被满足。他们依据以下几个维度把循环划分成了几种不同类型它们如何被触发它们如何被停止它们使用哪种 Claude Code 原语primitive每种循环最适合哪类任务主要的循环类型有哪些各自的适用场景是什么在控制 token 消耗的同时如何维持代码质量这篇入门教程都给你讲明白了。并非所有任务都需要复杂的循环从最简单的方案入手按需选用这些模式。基于轮次的循环触发方式Triggered by用户提示词prompt。停止条件Stop criteriaClaude 判断任务已完成或需要更多上下文。最适用于Best used for较短、且不属于常规流程或排程的任务。用量管理Managed usage by撰写具体的提示词并通过 skills 强化验证环节从而减少所需的轮次。你发出的每一条提示词都会启动一个手动循环由你主导每一轮。Claude 会收集上下文、采取行动、自检工作、必要时重复最后给出回应。举个例子让 Claude 创建一个点赞按钮。它会读取你的代码、做修改、跑测试然后交还一个它认为能跑的东西。接下来你手动检查这版工作成果再写下一条提示词。你可以把“验证”这一步做得更强把你那些手动步骤编码进SKILL.md让 Claude 能够端到端地自检更多工作。这应当包括让 Claude 可以看见、测量或与之交互最终结果的工具或连接器。检查越能量化Claude 自检就越容易。例如你可以在SKILL.md文件里这样写---name: verify-frontend-changedescription: 在声明完成之前验证任何端到端的UI更改。---# Verifying frontend changes切勿仅凭成功编辑就将UI更改报告为完成。按照人类审阅者的方式进行验证1.启动开发服务器在浏览器中打开编辑后的页面。2.直接与变化互动。对于新控件按钮、输入、切换单击它确认预期的状态更改并在之前/之后截图。3.检查浏览器控制台无新错误或警告。4.使用Chrome Devtools MCP运行性能跟踪并审核核心Web生命周期。如果任何步骤失败请修复问题并从步骤1重新运行——不要退回部分验证的工作。基于目标的循环/goal触发方式实时手动提示词。停止条件目标达成或达到最大轮次数。最适用于具有可验证退出条件的任务。用量管理设定明确的完成条件以及显式的轮次上限例如“在 5 次尝试后停止”。有时候一轮并不够尤其是更复杂的任务。智能体在能够迭代时表现会更好。你可以用/goal定义“什么算完成”从而延长 Claude 的迭代过程。当你定义了成功标准后Claude 就不必自己判断什么叫“够好”而过早结束循环。每次 Claude 试图停下时一个评估模型evaluator model会检查你设定的条件并把它打回去继续工作直到目标达成或达到你设定的轮次上限。这就是为什么确定性条件会如此有效。比如通过的测试数量、或越过某个分数阈值/goal 主页Lighthouse得分达到90分或以上尝试5次后停止。基于时间的循环/loop和/schedule触发方式指定的时间间隔。停止条件你手动取消或工作完成PR 合入、队列为空等。最适用于周期性工作或需要与外部环境/系统对接的场景。用量管理设置更长的间隔或改为基于事件event响应而非基于时间。有些 agentic 工作是周期性的任务本身不变只是输入在变。例如每天早上汇总 Slack 消息。另一些工作则依赖外部系统对接它们的一种简单做法就是按时间间隔去检查、并对变化做出反应。例如一个 PR 可能会收到代码评审意见或 CI 失败。对这些场景你可以用/loop控制 Claude 何时运行。它会在指定间隔上反复执行一段提示词。例如/loop 5分钟一次检查我的PR处理审核意见并修复失败的CI。/loop跑在你自己的电脑上所以一旦你关机它就停了。你可以用/schedule创建一个 routine把循环搬到云端运行。主动式循环触发方式由事件或排程触发过程中没有人在实时参与。停止条件每一个任务在其目标达成时退出routine 本身则一直运行直到你把它关掉。最适用于源源不断、定义良好的周期性工作bug 报告、issue 分诊triage、迁移、依赖升级等。用量管理把 routine 路由到更小、更快的模型上只在需要判断决策时调用最强大的模型。上面提到的原语再加上 Claude Code 的其他能力例如 auto mode 和研究预览版 dynamic workflows动态工作流可以组合成一个用于长时间运行工作的循环。例如要处理源源不断反馈进来的意见你可以这样组合用/schedule研究预览版跑一个 routine定期检查是否有新报告用/goal定义“什么算完成”并用 skills 文档化如何验证它用 Dynamic workflows 编排多个 agent分别负责分诊每份报告、修复问题、并复核修复用 auto mode 让 routine 不必停下征求许可而持续运行。组合起来一段提示词可以长这样/schedule 每小时查看项目反馈渠道中的bug报告。/goal: 在发现此运行的每个报告都经过分类、处理和响应之前不要停止。在修复错误时使用工作流在并行工作树中探索三个解决方案并让裁判对其进行对抗性审查。代码质量、Token 消耗与快速上手一个循环产出的质量取决于围绕它搭建的整套系统。在设计这套系统时保持代码库本身整洁Claude 会沿用你代码库里已有的模式与约定。给 Claude 一种自检的方式用 skills 把“你和团队眼中什么样算好”编码下来。让文档触手可及框架与库的文档要随时能拿到最新最佳实践。用第二个 agent 做代码评审带着全新上下文的评审者偏见更少不会被主 agent 的推理带偏。你可以用内置的/code-reviewskill或针对 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