官方给 loop 下了定义
「别再写 prompt 了，要设计 loop」传得很广，但十个人能给出十个答案。Claude Code 团队这篇博客把这个词收敛成一句定义，agent 反复做一轮又一轮的活，直到撞上一个停止条件，再按四个维度拆成从轻到重的四层。往上走一层，你交给循环的控制权就多一分。
先把 loop 这个词收敛成一句话
「别再写 prompt 了，要设计 loop」这句话最近传得很广，但它到底指什么，十个人能给出十个答案。Claude Code 团队这篇博客做的事很朴素：把这个被用滥的词收敛成一个能落地的定义，再拆成几类。
官方给 loop 的定义就一句话：agent 反复地做一轮又一轮的活，直到撞上一个停止条件。围绕这个定义，他们按四个维度给 loop 分类。
How triggered
How stopped
Which primitive
What task
按这四维分出来的，是从轻到重的四层 loop：Turn-based、Goal-based、Time-based、Proactive。官方在开篇留了一句话定基调：并非所有任务都需要复杂的 loop，先从最简单的方案起，按需选用（start with the simplest solution and use these patterns selectively）。往上走一层，你交给循环的控制权就多一分：从交出「那道检查」，到交出「停止条件」「那个触发」，最后交出「那句 prompt」。下面逐层看。
每发一句 prompt，其实就在跑一个 loop
这一层其实每个人天天在用。每发一句 prompt，就启动了一个手动 loop，每一轮都由人来指挥：Claude 收集上下文、动手、检查自己的产出、需要就再来一轮，然后把结果交回来。官方管这个最基础的循环叫 the agentic loop。
举例来说，让 Claude 加一个点赞按钮，它读代码、改文件、跑测试，然后把一个它认为能用的东西交回来；之后由人来手动检查，再写下一句 prompt。
这一层真正的干货，是怎么把「人来检查」这一步交给 Claude 自己做。官方的做法不是靠写更长的 prompt，而是把人工验收的步骤编码成一个 SKILL.md，让 Claude 端到端地检查自己更多的活。skill 里应当包含能让 Claude 看见、量度或与结果交互的工具或连接器，而且检查越量化，Claude 越容易自验。官方给的完整例子是一个叫 verify-frontend-change 的 skill，规则是绝不能只凭一次成功的编辑就把 UI 改动报成完成，得像人类 reviewer 那样验：
---
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.
四步分别是：起 dev server 并在浏览器打开改动的页面；直接与改动交互，新加的控件要点一下、确认状态如预期变化、截前后对比图；查浏览器 console，零新增报错；用 Chrome Devtools MCP 跑一次 performance trace 并审 Core Web Vitals。任何一步失败，就修好再从第一步重跑，不允许交回只验了一半的活。
用 /goal 把「做完」定义清楚
有时候一轮不够，任务越复杂越是如此，agent 能够迭代时表现更好。想让 Claude 迭代得更久，官方的原语是用 /goal 把「什么叫做完」定义清楚。
/goal 解决的是 agent 提前收工的问题。当由人来定义成功标准时，Claude 就不必自己去判断怎样算「够好了」而过早结束循环。机制上，每次 Claude 想停下来，一个 evaluator model 会核对你给的条件，不达标就把它打回去继续干，直到目标达成或到达你设定的轮数。正因如此，确定性的标准最有效，比如通过的测试数、或清过某个分数阈值。
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
把首页 Lighthouse 分数刷到 90 以上，试 5 次就停。既有可量化的完成标准（90 分），又有硬性的轮数上限（5 次）。
按间隔重跑，或者盯着外部系统的变化
有些 agent 工作是周期性的：任务本身不变，只有输入在变，比如每天早上总结一遍 Slack 消息。还有些工作依赖外部系统，而跟外部系统打交道的一个简单办法，就是按间隔去查一下、对变化做出反应，比如一个 PR 可能会收到 code review、也可能 CI 挂掉。
这一层的原语是 /loop，它按间隔重跑一句 prompt。
/loop 5m check my PR, address review comments, and fix failing CI
每 5 分钟检查一次我的 PR、处理 review 意见、修挂掉的 CI。
/loop 跑在你自己的电脑上，关机它就停；要把 loop 搬到云端，用 /schedule 建一个 routine（官方标注 /schedule 为 research preview）。前者是本机的临时循环，后者是常驻云端、不依赖你的机器开着的排期任务。
无人值守，把前三层组合成长跑
最重的一层是无人实时值守的循环。前面三层的原语，加上 auto mode、dynamic workflows（research preview）这些 Claude Code 能力，可以组合成一个用于长跑工作的 loop。
官方举的是处理用户反馈的例子，它把四样东西组合起来：
/schedule 定时跑（research preview）
跑一个 routine，检查有没有新的反馈报告。
/goal 定义什么叫做完
并用 skill 记录怎么验证。
dynamic workflows 编排
调度多个 agent，去分诊每条报告、修它、再 review 这个修复。
auto mode 不停下来问权限
让 routine 自己跑下去，不中途停问。
拼在一起，一句 prompt 可以长这样：
/schedule every hour: check #project-feedback 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.
每小时查 #project-feedback 里的 bug 报告；/goal 是这一轮找到的每条都 triage、处理、回复完才停；修 bug 时用一个 workflow 在三个并行 worktree 里探三个方案，再让一个 judge 对抗式地 review 它们。这一句里能看到四层是怎么叠起来的：/schedule 提供事件或排期触发，/goal 提供硬性完成标准，里头那个「三方案并行 + judge 对抗式 review」正是 dynamic workflows 干的编排活。
那句 prompt 里「workflow」那一格内部能摆出哪些形状（fan-out、tournament、对抗式验证等六种 pattern），是另一篇的主题。换句话说，dynamic workflows 是 Proactive loop 的一个部件，不是 loop 本身；本篇给的是包在它外面的那层壳。想看循环内一轮怎么把活分给多个 agent，读 《Dynamic Workflows 怎么用：六个 pattern 与三个失败模式》。
不管哪一层，质量和成本靠同一套纪律
loop 的产出质量，取决于它周围的这套系统；token 要控住，loop 就得有清晰的边界。这两件事贯穿四层，官方各给了一份清单。
怎么保住代码质量
| 做法 | 为什么 |
|---|---|
| 保持代码库本身干净 | Claude 会跟随代码库里已经存在的模式和约定 |
| 给 Claude 一个自验的办法 | 用 skill 把「什么叫好」为你和团队编码下来 |
| 让文档容易够到 | 框架和库的文档里有最新的最佳实践 |
| 用第二个 agent 做 code review | 带干净上下文的 reviewer 偏见更少，不会被主 agent 的推理带偏；可用内置 /code-review 或 Code Review for GitHub |
还有一条贯穿的原则：当某一条结果不达标时，别停在「把这一条修掉」，要试着把它编码进系统，让往后每一轮迭代都受益。这跟第一层把验收编成 skill 是同一个思路，单点问题要沉淀成系统改进。
怎么管 token
| 做法 | 要点 |
|---|---|
| 选对原语和模型 | 小任务不需要多个 agent 或多层 loop；有些任务可以用更便宜更快的模型 |
| 定清晰的成功和停止标准 | 把「做完」说具体，让 Claude 更早到达解，但也别太早收工 |
| 大规模跑前先试点 | dynamic workflows 能起几百个 agent，先在一小片工作上量用量 |
| 确定性的活用脚本 | 跑脚本比让模型推理便宜；如 PDF skill 自带填表脚本，每次直接跑而非重新推导代码 |
| routine 别跑得太勤 | 把间隔跟「你盯的那个东西实际多久变一次」对齐 |
| 看用量 | /usage 按 skill / subagent / MCP 拆解；/goal 不带参数显示轮数和 token；/workflows 显示每个 agent 的用量且可随时停 |
一张表：看你把哪一环交出去
官方最后用一张表把四层收口，核心是「你把哪一环交出去」。这也正是 hero 那张阶梯图的那一列：从交出检查，到交出停止条件、触发，最后交出整句 prompt。
| Loop | 你交出去的是 | 什么时候用 | 用哪个原语 |
|---|---|---|---|
| Turn-based | 那道检查 | 你在探索或做决定 | 自定义的验证 skill |
| Goal-based | 那个停止条件 | 你知道「做完」长什么样 | /goal |
| Time-based | 那个触发 | 工作发生在你项目之外、按某个排期 | /loop、/schedule |
| Proactive | 那句 prompt | 工作是重复且定义良好的 | 以上全部，外加 dynamic workflows |
官方给的起步方法也很具体：看看已经在做的活，挑一个自己正是瓶颈的任务，想清楚能把哪一环交出去：能不能写出那道验证检查、目标是否够清晰、这活是不是按排期来的。想清楚了就跑起来，观察它在哪里卡住、又在哪里越界，然后不断迭代。