Claude Code 四类 Loop
Anthropic 工程师视角下的 Claude Code 循环分类：turn-based、goal-based、time-based、proactive，分别对应手动提示、目标验收、时间排程和事件触发四种运行方式。
简介
Claude Code 四类 Loop 是 Delba de Oliveira 在 Anthropic 技术指南《Getting started with loops》中给出的实务分类，用来解释开发者如何从“直接 prompt”迁移到“设计 loop”。它把 Claude Code 中的循环能力拆成四种模式：turn-based、goal-based、time-based、proactive。这个分类的价值在于，它不把 loop 简化为某一个命令，而是把循环设计拆成三个问题：谁触发、谁判断完成、什么时候停止。
在这个框架里，turn-based 是最基础的人工触发循环：用户输入一个 prompt，Claude 收集上下文、执行动作、验证结果并回传。goal-based 则把任务目标和停止条件显式写给 /goal，由评估者模型检查是否达成。time-based 由时间触发，例如每 5 分钟检查 PR、处理 review 和 CI 失败。proactive 则由外部事件流触发，例如反馈频道出现 bug、依赖需要升级、迁移任务进入队列。
这个概念补充了 Loop Engineering 的触发器维度。此前知识库已经把 Loop 拆成触发器、目标、工具、记忆、验证、预算六模块，但“触发器”仍偏抽象；四类 Loop 给出更可操作的路由：一次性协作从 turn-based 起步，可量化目标用 goal-based，周期巡检用 time-based，连续事件流用 proactive。不同类型对应不同风险、成本和人类介入方式，不能混用。
关键信息
- 类型：Claude Code 工作流分类 / Loop Engineering 实务框架
- 四种模式：turn-based / goal-based / time-based / proactive
- 核心区分：触发方式、停止条件、验证机制、人类介入程度
- 适用场景：代码修改、性能优化、PR/CI 巡检、Slack 摘要、bug 分流、依赖升级、迁移任务
- 相关概念：Claude Code、Loop Engineering、Goal 提示语、Skill、状态文件
核心特性
1. Turn-based：每个 prompt 都是一个手动循环
Turn-based 是 Claude Code 的默认协作形态。用户发出 prompt 后，Claude 自行读取上下文、调用工具、执行修改、做验证并回传结果。它看似不是“自动循环”，但本质上仍然包含“理解目标 → 行动 → 验证 → 汇报”的闭环。
要提升 turn-based 的完成率，关键不是把 prompt 写得更长，而是把“好结果如何验证”写进项目环境。文章建议把前端变更的验收流程写进 SKILL.md：启动开发服务器、直接交互、检查 console 无新增错误、跑 Chrome DevTools MCP 性能追踪等。这样每个手动 prompt 都能触发同一套验证纪律，而不是依赖模型临场想起要检查什么。
2. Goal-based：目标和评估者驱动的多轮循环
Goal-based 用 /goal 触发，适合成功条件可量化的任务。典型示例是：/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries。这里同时写清了目标（首页 Lighthouse 分数）、指标（90+）和最大回合数（5 次）。当 Claude 想停止时，评估者模型检查条件是否达成；未达成就继续迭代。
它与 Goal 提示语 的关系很紧密：goal-based 不是“让 AI 多努力”，而是让 AI 知道完成证明是什么。测试通过数、覆盖率、Lighthouse 分数、构建成功、截图对比等都适合作为完成指标；“体验更好”“优化一下”“代码更优雅”则不适合直接交给 /goal，除非先转成可验收 rubric。
3. Time-based：周期性触发的本机或云端 routine
Time-based loop 由时间触发，例如 /loop 5m check my PR, address review comments, and fix failing CI。它适用于周期性检查：早上摘要 Slack、监控排程 job、定期检查 PR、持续处理 review comment、定时生成运营报告等。
关键边界是运行位置：/loop 跑在本机，电脑关机就停；如果要云端持续运行，应使用 /schedule 建 routine。这个区别决定了任务的可靠性预期。如果只是个人工作台提醒，本机 loop 足够；如果是组织级监控、CI triage 或跨时区持续任务，就必须进入云端排程与权限治理。
4. Proactive：事件触发且无人介入的持续工作流
Proactive loop 面向持续进入的事件流，例如 bug 分流、依赖升级、迁移队列、客户反馈处理。文章给出的复合例子是：每小时用 /schedule 检查 project-feedback 频道，用 /goal 定义每个 bug 要达到 triaged/actioned/responded，再由 dynamic workflows 派多个 agent 并行 explore，最后 auto mode 让 routine 不停下问权限。
它是四类中自动化程度最高、风险也最高的一类。因为它会派出大量子代理，token 用量可观，还可能接近客户反馈、生产 issue、依赖变更等高影响面任务。正确做法不是一开始全量上线，而是先选小范围 pilot，确认事件分类、权限边界、验收标准、成本上限和人工收尾机制都稳定，再逐步扩大。
不同素材中的观点
- 2026-07-08-abmedia-claude-code-four-loop-types：这篇素材提供了四类 Loop 的原始分类，并强调每一类都要从触发、停止条件、适用场景和用量管理四个面向设计。其核心贡献是把 “loop” 从单个
/loop命令扩展为完整的 Claude Code 工作流路由：人工触发用 turn-based，可量化目标用 goal-based，周期任务用 time-based，事件流任务用 proactive。
实用信息
选型判断表
| 任务形态 | 推荐 Loop | 关键设计 |
|---|---|---|
| 一次性改代码、写文档、处理明确请求 | turn-based | 在 Skill/项目说明中写入验证步骤 |
| 性能分数、测试通过、覆盖率、构建成功 | goal-based | 目标 + 指标 + 最大回合数 + 完成证明 |
| 周期性巡检、定时报表、Slack/PR/CI 摘要 | time-based | 本机 /loop 或云端 /schedule，外加状态文件 |
| bug 分流、依赖升级、迁移队列、连续反馈 | proactive | 事件触发 + goal 验收 + 多 agent 探索 + pilot + 人工收尾 |
常见误区
- 把所有自动化都写成
/loop，忽略/goal和/schedule的不同职责。 - 给 goal-based 任务写“做得更好”这种无法验证的目标。
- 在 time-based loop 里不写状态文件，导致每轮都从头分析。
- 把 proactive 任务直接开 auto mode，却没有小范围 pilot、预算上限和人工收尾。
- 只看模型能力，不看任务失败后的影响面；涉及金钱、生产环境、对外消息和客户可见结果时应遵守 Loop 工作流风险分级。