一、引言：不是所有任务都需要复杂循环
原文链接：Getting started with loops
来源：Claude Blog / Anthropic · 作者：Delba de Oliveira、Michael Segner
发布时间：2026 年 6 月 30 日
在 X（原 Twitter）上搜 “agent loop”，你会看到至少五六种不同定义：有人把它等同于 ReAct 循环，有人把它说成 agentic workflow，还有人把任何"模型自己多跑几轮"都叫循环。Claude Code 团队在这篇文章里做的事情很朴素——把这个词的边界画清楚，并给出一个可操作的分类框架。
文章的核心判断只有一句：
循环 = 代理重复工作周期，直到满足停止条件。
围绕这句话，团队按四个维度对循环做了分类：如何触发、如何停止、用什么 Claude Code 原语、适合什么类型的任务。这四个维度组合出四种循环类型：轮次驱动（Turn-based）、目标驱动（Goal-based）、时间驱动（Time-based）、主动式（Proactive）。
这张图的关键不在四种类型本身，而在最底部那行箭头——从左到右，你交给 Claude 的东西越来越多，人工参与越来越少。这是本文要反复回到的一条主线：循环的复杂度不是目的，放手的程度才是。
二、四种循环：选型关键不是复杂度，而是你愿意交出哪一环
在逐个拆解之前，先用一张表把四种循环放在同一坐标系下对比。比"哪个更高级"更重要的问题是：每一级你交出了什么。
表里最值得盯的一行是最后一行"你交出什么"：
- 轮次驱动：你只交出"验证检查"——Claude 干完你自己查；
- 目标驱动：你交出"停止条件"——你定义"完成"长什么样，Claude 跑到满足为止；
- 时间驱动：你交出"触发器"——你设定时间，Claude 自己启动；
- 主动式：你交出"提示本身"——你只写一次例程，Claude 自主编排。
下面逐个看。
2.1 轮次驱动（Turn-based）：最熟悉的模式
这是所有人用 Claude Code 的默认形态：你输入一个提示（比如"创建一个 like button"），Claude 读代码、编辑、跑测试，然后返回它认为可用的结果。你手动检查，再写下一条提示。
它的停止条件是Claude 自己判断——它认为做完了就停，或者认为需要更多上下文就回来问你。这种模式下，循环的质量几乎完全取决于你能不能给 Claude 自验证的能力。
文章给的关键建议是：把人工验证步骤编码成 Skills。一个 SKILL.md 文件可以把"启动开发服务器 → 浏览器交互 → 检查控制台 → DevTools 性能追踪"这套流程固化下来，让 Claude 自己跑完这套检查再回报。验证要尽量量化：不是"看起来没问题"，而是"Core Web Vitals 达标、控制台无新错误"。
2.2 目标驱动（Goal-based）：定义"完成"的样子
当你知道任务"完成"长什么样时，就该上 /goal。它的机制很直接：你给一个目标和最大轮次上限，Claude 每次试图停止时，评估模型会检查条件是否满足——不满足就继续。
文章强调一条原则：确定性标准最有效。
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
这个例子好在哪？退出标准是"评分 ≥ 90"——一个机器可以客观判定的数字，而不是"页面性能变好"这种主观描述。轮次上限"5 tries"则是另一层保险：防止 Claude 在达不到目标时无限烧 Token。
2.3 时间驱动（Time-based）：应对外部系统
当工作不是你主动发起的，而是外部系统按节奏推过来的——CI 失败了、PR 有新评论了、依赖发布了新版本——时间驱动循环就有用武之地。
两个原语的差异在运行位置：
/loop在你的本地计算机运行，关机即停；/schedule把循环移到云端，关机也不影响。
/loop 5m check my PR, address review comments, and fix failing CI
文章给了一个容易被忽略的管理建议：设置较长间隔，或基于事件而非时间触发。原因很实际——如果你的 PR 十分钟才有一次新评论，每分钟跑一次循环就是在烧钱空转。
2.4 主动式（Proactive）：无人值守的例程
这是四种循环里最"放手"的一种。触发由事件或计划发起，没有实时人工参与；每个任务内部有自己的目标，任务之间由例程编排。适合周期性、定义良好的工作流：bug 报告分流、依赖升级、issue 分类。
它不是一种新原语，而是前面三种原语加上动态工作流（Dynamic Workflows）的组合。下一节会专门拆它的组合方式。
三、主动式循环：四种原语如何编排成一条流水线
主动式循环的难点不在某一个原语，而在怎么把它们串成一条能自己跑起来的流水线。文章给了一个完整案例——“每小时处理 bug 报告”——把它拆开看就清楚了。
四步的分工是这样的：
/schedule（触发层）：每小时检查#project-feedback频道的新 bug 报告。选/schedule而不是/loop，是因为这条例程需要在云端持续运行，本地机器关机不能打断它。/goal（标准层）：定义完成标准——“本次运行发现的每一条报告都要被分流、处理、回复”。配合 Skills 文档规定验证方式，确保"处理"不是嘴上说说。- 动态工作流（编排层）：修 bug 时，在三个并行 worktree 里探索三种解决方案，由一个 judge 代理做对抗式审查。这一层把"单线修复"变成"多方案竞争 + 独立审查"，质量天花板显著抬高。
- Auto mode（放手层）：例程无需人工许可自动运行。配合
/usage按技能、子代理、MCP 分解用量，随时审查开销。
这条例程的完整提示长这样：
/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.
注意这条提示里没有一句废话：触发、目标、编排策略、审查机制全在一句话里交代清楚。这正是主动式循环对提示工程的要求——你交出的是"提示本身"，所以这条提示必须自足到可以脱离你独立运行。
四、关键策略：让循环真正跑起来
循环不是配好原语就能跑好的。文章把实践建议收拢成五条，下面挑最关键的四条展开。
4.1 用 Skills 增强自验证能力
这是所有循环的地基。无论你用哪种循环，Claude 都需要能自己判断"我做得对不对"。文章给的 verify-frontend-change 示例是一条四步流程：启动开发服务器 → 交互测试 → 控制台检查 → DevTools 性能追踪，任一步骤失败就修复并从第一步重新跑。
这条策略的本质是：把团队的验收标准从"人脑里的经验"变成"Claude 可执行的检查清单"。验证越量化（截图前后对比、Core Web Vitals 评分、控制台错误数），循环的确定性越高。
4.2 确定性标准优先于主观判断
/goal 的成败几乎完全取决于退出标准写得好不好。文章给了一个明确的优劣对照：
- 好：
Lighthouse 评分 ≥ 90、测试通过数 = 全部——机器可以客观判定； - 差：
代码质量更好、看起来不错——需要主观解读，评估模型也只能猜。
这条原则的推论是：如果你的任务没有可量化的退出标准，就别上目标驱动循环。先退回轮次驱动，手动验证几轮，等你能把"完成"写成数字了再升级。
4.3 维护代码质量：循环放大一切
循环的一个隐藏特性是它会放大代码库的现状。代码库整洁，循环就稳定；代码库混乱，循环会把混乱放大十倍——因为 Claude 会遵循已有模式，包括坏模式。
文章给的四条代码质量建议：
- 保持代码库整洁：Claude 遵循已有模式和约定，烂模式会被复制；
- 给 Claude 自验证手段：用 Skills 编码团队标准；
- 文档易于访问：框架和库文档要包含最新最佳实践；
- 用第二个代理做代码审查：拥有新鲜上下文的审查者偏见更小，不受主代理推理过程影响。可以用内置
/code-review或 GitHub 的 Code Review 功能。
第四条特别值得注意——独立审查者比同一上下文里的自我审查更可靠，这在工程实践里是被反复验证的判断。
4.4 管理 Token 使用：复杂循环的隐性成本
主动式循环可能一次跑出数百个代理。文章给的六条成本控制建议：
- 选择合适的原语和模型：小任务不需要多代理或循环，部分任务可用更便宜的模型；
- 定义清晰的成功与停止标准：让 Claude 更快到达解决方案（但不要太早）；
- 大规模运行前先试点：动态工作流先在小切片上测试；
- 用脚本处理确定性工作：运行脚本比推理步骤便宜得多；
- 不要过度频繁运行例程：匹配被监控对象的变化频率；
- 审查用量：
/usage、/goal（无参数）、/workflows三个命令分别从不同维度拆解 Token 消耗。
最后一条是兜底——任何循环都应该有用量观察的出口，否则你不知道它什么时候开始烧钱。
五、“渐进式放手”：贯穿全文的进阶判断
把四种循环和五条策略放在一起看，有一条判断贯穿始终：循环的升级路径是"逐步交出控制权"，而不是"一上来就上最复杂的"。
这条阶梯的每一级都对应一种循环：
- 第 1 级 · 交出验证检查：你还在场，只是把"怎么查"交给 Claude。适合探索性任务、你还拿不准方向的场景。
- 第 2 级 · 交出停止条件：你定义"完成"长什么样，Claude 自己跑到满足。前提是你能把退出标准写成数字。
- 第 3 级 · 交出触发器：你设定时间或事件，Claude 自己启动。适合与外部系统交互的周期性工作。
- 第 4 级 · 交出提示本身：你只写一次例程，Claude 自主编排多代理。风险最高，必须先小切片试点。
这条阶梯的实践含义是：
不要跳级。 如果你的任务连"可量化的退出标准"都还没有，直接上主动式循环等于把一个你都无法判断对错的任务，交给一个无人值守的系统。
文章用一句话总结了这条原则：
从最简单的方案开始，选择性使用这些模式。
以及一条更重要的——系统性改进优先于个案修补：当个别结果不达标时，不要只修复那一个，而要改进整个系统（Skills、标准、文档）以提升所有未来迭代。循环是复利工具，它的价值在于让下一次比这一次更可靠。
六、总结：循环不是目的，放手才是
把这篇文章的要点收拢成三条判断：
- 选型看"你愿意交出哪一环"，而不是"哪个更高级"。轮次驱动交出验证、目标驱动交出停止条件、时间驱动交出触发器、主动式交出提示本身。交出得越多，自动化程度越高，对系统设计的要求也越高。
- 确定性标准是循环质量的硬上限。没有可量化的退出标准，就别上目标驱动以上的循环。先退回手动验证，等标准能写成数字再升级。
- 循环放大代码库现状。代码库整洁循环就稳定，混乱就被放大。独立审查、Skills 编码标准、文档可及性——这三件事是循环能跑好的地基，不是可选优化。
最后一条提醒来自文章的收尾，也是容易被忽略的一条：
运行循环后观察它在哪里停滞或过度延伸，然后持续改进。
循环不是配好就结束的。它是需要观察、迭代、系统性改进的活系统。你交出的是控制权，但不是责任。
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
