吵了一周的 loops，Claude 官方下场讲明白了

最近有一个很火的概念叫loop，中文叫循环编程，很多人围着 loop 这个概念争论不休

上周 AI Engineer 大会收官日，正反两方直接吵作一团。一边是 Ralph loop 的作者 Geoffrey Huntley，说自己已经不手写代码了，人的角色变成了火车司机，盯着机车别脱轨就行。另一边直接泼冷水，说吹得太猛了，大多数人的工程功底根本还没跟上这波热度。

吵成这样，多半说明一件事，这东西压根没有公认的定义。你去 X 上搜 loop 到底是什么，能搜出七八种答案，每个人说的都不是同一个东西。

然后 Claude Code 团队自己下场了。昨天凌晨，官方账号发了篇长文，把 loop 是什么、分几种、什么时候用哪种，一次性讲清楚了，一天不到阅读量就破了 300 万。

我把全文翻译了一遍，放在下面。翻的时候顺手对照了下自己的内容流水线，定时抓信源的任务、发布前的门禁脚本，原来都能在这套分类里找到位置。有几个组合玩法是我之前没想到的。

以下是正文。

最近很多人在聊，用编码 agent 不该再一条条写提示词，而是要去设计循环（loops）。但你要是真去 X 上搜一搜 loop 到底是什么，会发现答案五花八门。

在 Claude Code 团队，我们对 loop 的定义是，agent 重复执行一轮轮工作，直到满足某个停止条件。我们按几个维度把 loop 分成几种类型：

• • 怎么触发
• • 怎么停下来
• • 用的是哪个 Claude Code 原语（primitive，可组合的基础能力单元）
• • 各自最适合什么样的任务

这篇文章会讲清楚几种主要的 loop 类型、各自的适用场景，以及怎么在控制 token 用量的同时保住代码质量。不是所有任务都需要复杂的循环；先从最简单的方案开始，有选择地使用这些模式。

轮次循环（Turn-based loops）

• • 触发方式：用户的一条提示词。
• • 停止条件：Claude 判断任务已完成，或者需要补充上下文。
• • 适用场景：不属于常规流程、没有固定排期的短任务。
• • 用量管理：把提示词写具体，用 skills 强化验证环节，减少来回的轮数。

你发的每条提示词，都会启动一个由你逐轮把控的手动循环。Claude 收集上下文、动手执行、检查自己的工作，有需要就再来一遍，然后回复你。我们把这称为 agentic loop（智能体循环，agent 工作的基本节拍）。

举个例子，让 Claude 做一个点赞按钮。它会读你的代码、改代码、跑测试，然后把它认为能用的结果交回来。接着你人工检查，再写下一条提示词。

你可以把自己手动检查的步骤写成一份 SKILL.md，让 Claude 端到端地多检查一些自己的工作。里面应该包含能让 Claude 看到、度量、或者直接与结果交互的工具和连接器。检查越量化，Claude 越容易自我验证。

比如，你可以在 SKILL.md 里这样写：

---
name: verify-frontend-change
description: 任何 UI 改动，先端到端验证完才算做完。
---

# 验证前端改动

不要只因为编辑成功就上报 UI 改动已完成。要像人类审查者一样去验证它：

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

2. 直接和改动交互。新控件（按钮、输入框、开关）：点一下，确认状态变化符合预期，截取前后对比截图。

3. 检查浏览器控制台：不能有新的报错或警告。

4. 用 Chrome DevTools MCP 跑一次性能 trace，审计 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 消息。还有些工作依赖外部系统，和它们打交道最简单的方式，就是每隔一段时间去看一眼，对变化做出反应。比如一个 PR，可能收到 code review，也可能 CI 挂了。

这类工作可以用 /loop 触发，让 Claude 按间隔重复执行一条提示词。例如：

/loop 5m 检查我的 PR，处理 review 意见，修复挂掉的 CI

/loop 跑在你自己的电脑上，关机它就停了。想把循环挪到云端，可以用 /schedule 创建一个 routine（例行任务，云端定时运行的任务单元）。

主动循环（Proactive loops）

• • 触发方式：事件或排期，没有人实时盯着。
• • 停止条件：每个任务在目标达成时退出；routine 本身会一直跑，直到你把它关掉。
• • 适用场景：持续涌入的、定义清晰的工作流：bug 报告、issue 分诊、代码迁移、依赖升级等等。
• • 用量管理：把 routine 路由给更小更快的模型，关键判断才用最强的模型。

上面这些原语，加上 auto 模式、动态工作流（研究预览版）等其他 Claude Code 能力，可以组合成一个处理长期工作的循环。

比如，要处理源源不断的用户反馈，你可以：

1. 1. 用 /schedule（研究预览版）跑一个 routine，定期检查有没有新报告
2. 2. 用 /goal 定义做完是什么样，用 skills 写清楚怎么验证
3. 3. 用动态工作流编排 agent，对每个报告做分诊、修复、再审查修复结果
4. 4. 开 auto 模式，让 routine 不用停下来请求权限

拼起来，提示词大概长这样：

/schedule 每小时：检查 project-feedback 频道的 bug 报告。/goal：这一轮发现的每个报告都分诊、处理、回复完之前不要停。修 bug 时，用 workflow 在并行 worktree 里探索三种方案，让一个 judge 对抗性地审查它们。

保住代码质量

循环产出的质量，取决于它周围的系统。设计这套系统的时候：

• • 保持代码库本身干净：Claude 会遵循你代码库里已有的模式和惯例。
• • 给 Claude 自我验证的手段：用 skills 把你和团队心里什么算好的标准编码下来。
• • 让文档触手可及：框架和库的文档里有最新的最佳实践。
• • 用第二个 agent 做 code review：带着新鲜上下文的审查者偏见更少，不会被主 agent 的推理带偏。可以用内置的 /code-review skill，或者 GitHub 版的 Code Review。

当某次结果不达标时，别只修那一个问题，试着把它编码进系统里，让之后的每次迭代都受益。

管住 token 用量

要管住 token 用量，循环得有清晰的边界：

• • 选对原语和模型：小任务不需要多个 agent 或循环，有些任务用更便宜更快的模型就够了。
• • 定义清晰的成功和停止标准：把做完是什么样说具体，Claude 就能更早（但不至于过早）到达答案。
• • 大规模跑之前先试点：动态工作流可能孵出几百个 agent。先拿一小片工作试试水，估一下用量。
• • 确定性的活交给脚本：跑脚本比推理一遍步骤便宜。比如 PDF skill 可以内置一个表单填写脚本让 Claude 每次直接跑，而不是每次重新推导代码。
• • routine 别跑得比需要的更勤：间隔要和你盯的那个东西的变化频率匹配。
• • 复盘用量：/usage 命令按 skills、子 agent、MCP 拆解最近的用量；/goal 不带参数会显示目前的轮数和 token 用量；/workflows 能看到每个 agent 的 token 消耗，你随时可以停掉某个 agent。

上手

总结一下：

想开始用循环，先看看你手头已经在做的工作。挑一个你自己是瓶颈的任务，问问哪一块可以交出去：验证检查你写得出来吗？目标够清晰吗？工作是不是按排期来的？

有想法之后，把循环跑起来，观察结果，看它在哪里卡住、在哪里用力过猛，别怕反复调整。

想了解更多，可以读 Claude Code 文档里关于并行运行 agent 的部分，以及 loop、schedule、goal 和动态工作流的页面。

写在最后

看完这篇，我记住的其实就一句话：循环的核心不在循环，在停止条件。谁来判断做完了，谁就是这个系统里真正干活的人。以前是我自己盯，现在是把标准写下来，让评估器替我盯。

我流水线里那个发布前门禁脚本，说穿了就是给内容写的 stop condition，十几条检查全绿才放行。所以看到文里说，某次结果不达标，别只修那一个问题，要把它编码进系统，让之后每次迭代都受益，我是真有共鸣。提醒 AI 一百遍，不如写一条它绕不过的检查。

我是洞见，下次见。