2026-07-07，Claude Code 团队在 X 上发了一篇长文——《Getting started with loops》。这不是一篇"AI 又要变天了"的公关稿，而是 Anthropic 第一次把"循环到底该怎么设计"这件事，拆成了一份可以照着做的工程指南。

官方文章标题页：Different types of loops in Claude Code and when to use them

为什么这篇东西值得读

过去半年，"Loop Engineering（循环工程）"这个概念在 AI 编程圈子里吵翻了天。Google 工程师 Addy Osmani 整理了它，PSPDFKit 创始人 Peter Steinberger 喊出了 “别再手动 prompt coding agent 了，去设计提示 agent 的循环”，Claude Code 负责人 Boris Cherny 在红杉 AI Ascent 大会上说了一句很直的：“Loop 是未来。”

但如果你在 X 上花时间搜"什么是 loop"，会得到一堆互相矛盾的解释。

现在，@ClaudeDevs 终于给出了官方答案。

官方定义：一句话

Loops are agents repeating cycles of work until a stop condition is met.

（循环就是 agent 重复执行工作周期，直到某个停止条件被触发。）

就这么简单。但整篇文章的精髓在于——他们没有停留在定义上，而是把循环按照四个维度彻底拉平，防止你把不同概念混在一起：

1. How they are triggered —— 怎么被叫醒
2. How they are stopped —— 怎么停下来
3. What Claude Code primitive is used —— 用哪个原语实现
4. What type of task fits each —— 适合什么任务

这四条线一拉开，之前所有模糊讨论瞬间清晰了。

四种循环原语，逐一拆解

1. Turn-based loops：轮次制循环

这是最朴素、也是你最常用的一种。

触发方式： 你的 prompt。每一条指令都会启动一个 agentic loop。

停止条件： Claude 判断任务完成，或者需要更多上下文。

适用场景： 短任务、探索性工作、不在固定流程里的活。

怎么控制用量： 写更精确的 prompt，用 skill 提升验证能力来减少轮次。

Turn-based 循环的完整流程：Your prompt → Gather context → Take action → Verify the work → Response。循环在 Claude 判断完成或预算耗尽时退出。

每次你给 Claude 一个 prompt，它就会走完这个闭环：收集上下文 → 行动 → 验证结果 → 需要就重来 → 回复你。你就是调度者，手动批准每一轮。

举个例子：让 Claude 创建一个点赞按钮。它会读代码、改代码、跑测试，然后把一个它认为能用的结果交给你。你再检查，再写下一个 prompt。

提升质量的关键技巧： 把你手动的验证步骤编码成一个 SKILL.md，让 Claude 能端到端地自检。官方给的例子是一个前端验证 skill：

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---

# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone.
Verify it the way a human reviewer would:

1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly.
   For a new control (button, input, toggle):
   click it, confirm the expected state change, and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.

If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

注意最后一句：任何一步失败，修掉问题从第 1 步重跑——不要交回半成品。

而且验证越量化越好。Lighthouse 分数？测试通过数？type-check 零错误？这些比"看起来没问题"靠谱一万倍。

2. Goal-based loops（/goal）：把停止条件交出去

单轮不够用怎么办？尤其是复杂任务，agent 多试几次通常效果更好。

触发方式： 手动实时 prompt。

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

适用场景： 有可量化验收标准的任务。

怎么控制用量： 设定明确的完成标准 + 轮次上限，比如 stop after 5 tries。

Goal-based 循环机制：Claude 工作 → Evaluator model 检查条件 → 未达标则送回继续，达标或达上限则结束

这里的设计很有意思——引入了一个独立的 evaluator model（评估模型）。每次 Claude 想停下来的时候，不是自己说了算，而是由另一个模型检查你的条件是否满足，不满足就被打回去继续干。

这就是为什么确定性的验收标准特别有效。比如"通过多少个测试"、“分数超过多少”，这种布尔/数值判断远比主观的"够好了吧"可靠。

实际用法：

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

一条命令，目标、阈值、上限全写清楚。Claude 不需要猜"什么才算好"，评估模型也不需要做主观判断——数字到了就是到了。

3. Time-based loops（/loop 和 /schedule）：把触发交出去

有些工作是重复性的——任务不变，只有输入在变。比如每天早上汇总 Slack 消息。还有些任务依赖外部系统：PR 可能收到 review comment，CI 可能失败。

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

停止条件： 你取消，或者活干完了（PR 合了、队列空了）。

适用场景： 周期性工作、对接按自己节奏变化的外部系统。

怎么控制用量： 设长一点间隔；优先事件驱动而不是时间驱动。

用法很简单：

/loop 5m check my PR, address review comments, and fix failing CI

但官方特意加了一条非常实在的提醒：

/loop runs on your computer, so if you turn it off, it stops.
（/loop 跑在你电脑上。关机就停。）

想要不依赖你的电脑持续运行？那就用 /schedule 把循环搬到云端——目前标注为 research preview。

4. Proactive loops：全自动模式

这是最激进的形态。

触发方式： 事件或定时，不需要人在场。

停止条件： 单个任务目标达成后退出；整个例程一直跑到你主动关闭。

适用场景： 明确流程的重复工作流：bug 报告处理、issue 分诊、迁移、依赖升级等。

怎么控制用量： 把日常分诊路由到小模型/快模型，只在做判断时上大模型。

Proactive 云端例程全景图：/schedule 触发 → Main agent 执行+验证 → Second agent review → 开 PR → 你决定是否合并。全程在云端运行。

这张图信息量很大。注意几个关键点：

• RUNS IN THE CLOUD — LAPTOP OPEN OR NOT：云端运行，跟你的电脑无关
• TRIGGER 用 /schedule 监控 Slack 或 GitHub 的 bug report
• GOAL + CHECK：主 agent 干活 + 验证 skill 通过才算完
• REVIEW agent：第二个 agent 做 code review，然后通知你
• 最终 You decide what to merge：合并权始终在人手里

官方给了一个组合拳式的 prompt 示例：

/schedule every hour: check the project-feedback channel for bug reports.
/goal: don't stop until every report found this run is triaged,
       actioned, and responded to.
When fixing a bug, use a workflow to explore three solutions
in parallel worktrees and have a judge adversarially review them.

一行命令里塞进了调度器、目标循环、并行工作树、对抗评审——这就是 proactive loop 的完全体。

一张表看懂全部四种

官方最后给了这张总结表，值得截图保存：

循环类型	你交出去的是什么	什么时候用它	伸手去拿
Turn-based（轮流进行）	验证环节	你正在探索或做决定	自定义验证技能
Goal-based（以目标为导向）	停止条件	你知道"完成"是什么样子	/goal
Time-based（基于时间）	触发器	工作按计划在项目外发生	/loop、/schedule
Proactive（积极主动）	整套提示/指令	工作是重复性的且有明确流程	以上所有 + 动态工作流

质量靠系统设计，不靠模型聪明程度

官方在这点上态度非常明确：循环的输出质量取决于围绕它的系统设计，而不是模型的智商。 五条原则：

1. 保持代码库干净 —— Claude 会照着已有模式和惯例写代码。仓库越乱，diff 越乱。
2. 给 Claude 验证手段 —— 用 skill 编码"什么叫做好"，越量化越好。
3. 文档要好拿到 —— 框架和库的文档要有最新最佳实践。
4. 用第二个 agent 做 code review —— 新鲜上下文的审查者不会被主 agent 的思路带偏。内置 /code-review 或 GitHub Code Review 都能用。
5. 别只修单个 bug，要改系统 —— 某个结果不达标时，把经验编码进 skill/harness，让所有后续迭代都受益。

Token 用量管理：边界必须有

循环的成本是乘法，不是加法。官方给出的管理清单：

• 选对原语和模型 —— 小活不需要多 agent / 复杂循环，便宜快模型能干的别上贵的
• 写清成功和停止条件 —— 让 Claude 尽早找到解法（但也别太早）
• 大规模运行前先 pilot —— 动态工作流可能 spawn 几百个 agent，先在小范围测用量
• 确定性工作用脚本 —— 跑脚本比让模型逐步推理便宜得多。比如 PDF 表单填写，一次生成脚本反复用，不用每次重新推导
• 别跑太频繁 —— 间隔匹配你监控对象的变化频率就行
• 定期 Review 用量：
  • /usage —— 按 skill/subagent/MCP 拆解近期用量
  • /goal（无参数）—— 显示当前轮数和 token 用量
  • /workflows —— 显示每个 agent 的 token 用量，随时可以停

最后的建议：从你已经做的事开始

官方结尾没有画大饼，而是给了一个很务实的起步方法：

Look at the work you already do. Pick one task where you’re the bottleneck and ask which piece you could hand off:

• Can you write the verification check?（你能写出验证检查吗？）
• Is the goal clear enough?（目标够清晰吗？）
• Does the work arrive on a schedule?（工作是按计划来的吗？）

想好了就跑起来，观察哪里卡住了、哪里过度执行了，然后迭代。别怕改。

我的看法

这篇《Getting started with loops》之所以重要，不是因为发明了什么新概念——loop 这个想法社区已经讨论了大半年了——而是因为它第一次把"循环工程"从一句口号变成了一张有零件、有尺寸、有安装说明的图纸。

四种原语覆盖了从"我手动一步步来"到"云端全自动跑"的全部光谱。每一层都明确回答了三个核心问题：谁触发、谁停、谁来审。 这才是 loop engineering 的真正内涵——不是让 agent 无限跑下去，而是让它在一个有刹车、有护栏、有审计的系统里有节制地运转。

如果要用一句话总结全文的态度，大概是这样：

别先问"怎么让 agent 一直跑"。先问"它跑偏时谁能发现、跑贵时谁能停、做完时谁能验收"。

这三个问题有答案了，再去写那个循环。

---

参考来源：@ClaudeDevs《Getting started with loops》(2026-07-07)；Claude Code 官方文档 loop / schedule / goal / dynamic workflows 页面。