四种 Loop 分别什么时候用:Claude Code 官方的 loop 入门指南

本文原题《Getting started with loops》,出自 Claude Code 官方团队(@ClaudeDevs),执笔 @delba_oliveira。眼下海外 AI 工程社区围绕「设计 loop,而不是给 coding agent 写 prompt」讨论得很热,但「loop 到底是什么」众说纷纭——这篇是官方团队自己给出的定义和分类。中文翻译、重排、5 张配图本地化:Yaqin Hei(非原创,已保留原文出处)。

译者的话:为什么翻这篇

前几天我刚翻完 Karpathy 那篇《Loop Engineering》(站内有全文),那篇解决的是「为什么该造 loop」——你才是瓶颈,把自己从循环里挪出去。但读完不少人卡在下一步:道理懂了,具体我该搭哪一种?

这篇正好补上。它把 loop 拆成四种形态——回合制、目标制、定时制、主动制——每一种都写清楚三件事:谁来触发、什么时候停、适合什么活儿。对我最实在的改变,是它把我起一个自动化任务的第一个判断,从「要不要上 loop」(一个太粗的二选一)换成了「这活儿属于四种里的哪一种」。一旦归了类,触发方式和停止条件几乎是自动确定的,连 token 怎么省都跟着清楚了。

而且它的态度很克制——反复在说「不是所有任务都需要复杂的 loop,先从最简单的方案开始」。这句话对现在动不动就想上「全自动多 agent」的氛围,是一剂很及时的解药。如果你手边有个反复要做、又有明确「做完」标准的活儿,读完直接跳到文末那张决策表,对号入座就能开跑——最轻的那一种(回合制)你其实现在就在用,只是没意识到而已。

---

以下是正文

现在关于「设计 loop」而不是给你的 coding agent 写 prompt,讨论非常多。如果你花点时间去翻社交媒体,想搞清楚一个 loop 到底是什么,你会撞见一堆互相打架的答案。

在 Claude Code 团队,我们把 loop 定义为:agent 不断重复一轮又一轮的工作,直到某个停止条件被满足。我们按几个维度,把 loop 分成几类:

• 它怎么被触发
• 它怎么被停下
• 它用的是 Claude Code 的哪个原语(primitive)
• 它最适合哪一类任务

下面会讲清楚几种主要的 loop 类型、各自什么时候用,以及怎么在守住代码质量的同时管好 token 消耗。不是所有任务都需要复杂的 loop——先从最简单的方案开始,这些模式要有选择地用。

回合制 loop(Turn-based)

回合制 loop:每一回合由你来指挥;当 Claude 判断任务完成——或者 effort 预算用尽时,退出。

• 由谁触发: 一条用户 prompt。
• 停止条件: Claude 判断自己已经完成任务,或者需要更多 context。
• 最适合: 较短的、不属于某个常规流程或计划表的任务。
• 怎么管好消耗: 把 prompt 写具体,并用 skill 强化验证环节,减少来回的回合数。

你发的每一条 prompt,都启动了一个手动的 loop——每一回合都由你来指挥。Claude 收集 context、采取行动、检查自己的工作,不到位就再来一轮,然后给你回复。我们把这叫 agentic loop。

举个例子,让 Claude 做一个点赞按钮。它读你的代码、改好、跑测试,然后把一个它认为能用的东西交回给你。接着你手动检查它的工作,再写下一条 prompt。

你可以强化其中的验证环节:把你手动检查的那几步,编码成一个 SKILL.md,让 Claude 能端到端地检查更多自己的工作。这里面应该包含工具或 connector,让 Claude 能看到、度量或直接操作结果。检查越是量化,Claude 就越容易自我验证。

比如,你的 SKILL.md 文件里可以这样写:

---
name: verify-frontend-change
description: 任何 UI 改动在宣布完成前,先端到端验证一遍。
---

# 验证前端改动
绝不能只凭一次成功的编辑,就把 UI 改动报告为完成。要像一个人类
reviewer 那样去验证它:

1. 启动 dev server,在浏览器里打开被改的页面。

2. 直接和这个改动交互。对于新加的控件(按钮、输入框、开关):
   点它,确认状态如期变化,并截下前后对比图。

3. 检查浏览器 console:零新增的报错或警告。

4. 用 Chrome Devtools MCP,跑一次 performance trace,审计 Core Web Vitals。

任何一步失败,就修掉问题,再从第 1 步重跑——绝不交回只验证了一半的工作。

目标制 loop(/goal)

目标制 loop:每次 Claude 想停,Evaluator 模型都拿你的条件核一遍;没达标就打回重做,直到目标达成或跑满你设的次数。

• 由谁触发: 一条实时的手动 prompt。
• 停止条件: 目标达成,或者到达最大回合数。
• 最适合: 有可验证退出标准的任务。
• 怎么管好消耗: 设一个具体的完成标准和明确的回合上限,比如「跑满 5 次就停」。

有时候,一个回合不够用,尤其是更复杂的任务。agent 在能够迭代的时候表现更好。你可以用 /goal 定义清楚「什么算做完」,来延长 Claude 持续迭代的时间。

当你定义了成功标准,Claude 就不用自己去判断怎样才算「够好」、从而过早结束 loop。每次 Claude 想停下来,一个 evaluator 模型都会拿你的条件核一遍,然后把它打回去继续干,直到目标达成、或者到达你定义的次数。

这也是为什么确定性的标准——比如通过测试的数量、或者越过某个分数阈值——会如此有效。

举个例子:

/goal 把首页的 Lighthouse 分数提到 90 或以上,跑满 5 次就停。

定时制 loop(/loop 和 /schedule)

定时制 loop:按间隔重跑同一条 prompt,盯着外部系统的变化做出反应;/loop 跑在你电脑上,/schedule 把它搬去云端。

• 由谁触发: 一个指定的时间间隔。
• 停止条件: 你取消它,或者工作完成(PR 合并了、队列空了)。
• 最适合: 反复出现的工作,或者跟外部环境 / 系统打交道。
• 怎么管好消耗: 把间隔设长一点,或者改成按事件、而不是按时间来触发。

有些 agent 工作是反复出现的:任务本身不变,变的只是输入。比如每天早上总结一遍 Slack 消息。另一些工作依赖外部系统,而跟外部系统打交道的一个简单办法,就是按间隔去查它、并对变化做出反应。比如一个 PR,它可能收到 code review、也可能 CI 挂了。

对这些场景,你可以用 /loop 来触发 Claude 运行——它会按间隔重跑一条 prompt。比如:

/loop 5m 检查我的 PR,回应 review 意见,修复失败的 CI

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

主动制 loop(Proactive)

主动制 loop:整套跑在云端,笔记本开不开机都行;每个任务达成目标就退出,routine 本身一直跑到你关掉它为止。

• 由谁触发: 一个事件或计划表,过程中没有实时的人参与。
• 停止条件: 每个任务在目标达成时退出;routine 本身一直跑,直到你关掉它。
• 最适合: 源源不断、且定义清晰的工作流:bug 报告、issue 分诊、迁移、依赖升级等等。
• 怎么管好消耗: 把 routine 路由到更小更快的模型上,只在需要判断的关键处用最强的模型。

上面这些原语,加上 Claude Code 的其他能力——比如 auto mode 和 dynamic workflows(研究预览版)——可以组合成一个用于长时间运行的 loop。

比如,要处理源源不断进来的反馈,你可以这样搭:

1. 用 /schedule(研究预览版)跑一个 routine,检查有没有新的报告
2. 用 /goal 定义什么算「做完」,用 skill 记录怎么验证它
3. 用 dynamic workflows 编排一批 agent,去分诊每一条报告、修掉它、再 review 这个修复
4. 用 auto mode,让 routine 一路跑下去,不用停下来问权限

拼到一起,一条 prompt 可能长这样:

/schedule 每小时:检查 project-feedback 频道里的 bug 报告。/goal:在这一趟里找到的每一条报告,都分诊、处理、并回复完之前,不许停。修 bug 时,用一个 workflow 在三个并行的 worktree 里探索三种方案,再让一个 judge 来对抗式地 review 它们。

守住代码质量

一个 loop 输出的质量,取决于它周围的那套系统。设计这套系统时:

• 让代码库本身保持干净: Claude 会遵循你代码库里已经存在的模式和约定。
• 给 Claude 一个验证自己工作的办法: 用 skill 把「对你和你的团队来说什么算好」编码下来。
• 让文档容易够到: 框架和库的文档里,有最新的最佳实践。
• 用第二个 agent 做 code review: 一个 context 全新的 reviewer,偏见更少,也不会被主 agent 的推理带偏。你可以用内置的 /code-review skill,或者面向 GitHub 的 Code Review。

当某一次结果没达到标准,别停在「修好这一个问题」就完事——试着把它编码进系统里,让往后每一次迭代都受益。

管好 token 消耗

要管好 token 消耗,loop 得有清晰的边界:

• 给这活儿挑对原语和模型: 小任务不需要多个 agent 或多重 loop。有些任务可以用更便宜、更快的模型。
• 定义清晰的成功和停止标准: 把「什么算做完」说具体,让 Claude 能更早抵达答案(但也别太早)。
• 大规模跑之前先试点: dynamic workflows 能派生出成百上千个 agent。先在一小片工作上估一估消耗。
• 确定性的活儿用脚本: 跑一个脚本,比推理一遍每一步要便宜。比如一个 PDF skill 可以自带一个填表脚本,让 Claude 每次直接跑,而不是每次重新推导那段代码。
• 别把 routine 跑得比需要的更勤: 让间隔匹配「你盯着的那个东西多久变一次」。
• 复盘消耗: /usage 命令能按 skill、subagent、MCP 拆分最近的消耗;/goal 不带参数运行,会显示目前的回合数和 token 消耗;/workflows 能看到每个 agent 的 token 消耗,而且你随时可以停掉某个 agent。

上手:从你已经在做的活儿里挑一个

总结一下:

Loop 类型	你交出的是	什么时候用	用什么
回合制	那道检查	你在探索、在做决定	自定义验证 skill
目标制	那个停止条件	你知道「做完」长什么样	/goal
定时制	那个触发器	活儿在你项目之外、按计划表发生	/loop、/schedule
主动制	那条 prompt	活儿反复出现、且定义清晰	以上全部,再加 dynamic workflows

想上手 loop,就去看看你已经在做的活儿。挑一个你自己成了瓶颈的任务,问一句:哪一块我能交出去?你能不能写出那道验证检查?目标够不够清晰?活儿是不是按计划表来的?

一旦有了想法,就把 loop 跑起来,观察结果——它在哪里卡住、在哪里越界——然后别怕去迭代它。

想了解更多,可以读 Claude Code 文档里关于并行运行 agent 的部分,以及 loop、schedule、goal、dynamic workflows 这几个页面。

---

译自 Claude Code 团队(@ClaudeDevs)《Getting started with loops》,执笔 @delba_oliveira。翻译、重排、配图本地化:Yaqin Hei。延伸阅读:站内《Loop Engineering:Karpathy 方法论》。