吵了一周的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 步重跑，不要交回只验证了一半的工作。

• • 触发方式：实时的手动指令。
• • 停止条件：目标达成，或者达到最大轮数上限。
• • 适用场景：有可验证退出标准的任务。
• • 用量管理：设定具体的完成标准和明确的轮数上限，比如试 5 次就停

有时候一轮是不够的，尤其是更复杂的任务。agent 能迭代的时候表现更好。用 /goal 定义清楚做完是什么样，就能延长 Claude 持续迭代的时间。

当你把成功标准定义清楚，Claude 就不用自己去判断够不够好，也就不会提前结束循环。每次 Claude 想停下来，都会有一个评估模型对照检查你的条件，不达标就把它送回去继续干，直到目标达成，或者跑满你设定的轮数。

这也是为什么确定性的标准特别有效，比如通过的测试数量，或者超过某个分数阈值。

例如：

/goal 把首页的 Lighthouse 分数提到 90 以上，试 5 次就停。

• • 触发方式：设定的时间间隔。
• • 停止条件：你手动取消，或者工作完成（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-reviewskill，或者 GitHub 版的 Code Review。

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

管住 token 用量

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

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

总结一下：

循环类型你交出去的什么时候用用什么轮次循环检查你还在探索或做决定自定义验证 skills目标循环停止条件你知道做完是什么样/goal定时循环触发时机工作在项目之外按排期发生/loop、/schedule主动循环提示词本身工作周期性出现、定义清晰

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

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

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

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

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

我是洞见，下次见。