2026 年 7 月 7 日，Anthropic 在 Claude 官方博客（claude.com/blog）发布了 Loop Engineering 指南"Getting Started with Loops"，作者 Delba de Oliveira 和 Michael Segne。这是 Boris Cherny（Claude Code 负责人）六周前说"I don't prompt Claude anymore, I write loops"之后，Anthropic 第一次给出循环类型的正式分类、工程实践指导和代码质量保障框架。核心是一个四象限分类——turn-based、goal-based、time-based、proactive——和一条贯穿性原则：循环输出质量取决于它周围的系统，不是模型本身。
本文与此前发布的「当 Loop 成为工程单位」互为补充——那篇做架构层和控制论映射，这篇拆解官方指南的具体工具和工程实践。
分类逻辑：你交出什么
指南的核心是四种循环类型。分类的轴不是复杂度递增，而是你向机器交出了什么控制权：
| 循环类型 | 触发方式 | 停止条件 | 适用场景 | Claude Code 工具 |
|---|---|---|---|---|
| Turn-based | 用户 prompt | Claude 判断完成 | 短任务、非定期 | SKILL.md 自验证 |
| Goal-based | 手动 prompt | 目标达成或轮次上限 | 有可验证退出条件 | /goal |
| Time-based | 时间间隔 | 你取消或任务完成 | 重复性工作、外部系统 | /loop、/schedule |
| Proactive | 事件/调度，无实时人工 | 每个子任务目标达成后退出 | 持续流式工作 | 上述全部 + dynamic workflows |
Turn-based：把验证编码成 Skill
每一次 prompt 都是一个循环。Claude 读代码、改文件、跑测试、把结果交回来——然后你手动检查，写下一个 prompt。这就是 turn-based loop，所有人都在用的默认模式。
指南给的关键升级：把手动检查步骤编码成 SKILL.md。不是让 Claude"检查一下"——而是写一个结构化的验证流程，包含工具和连接器，让 Claude 能看到、测量、交互结果。
指南给了一个完整的 SKILL.md 示例：
---
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.
注意最后一句——"do not hand back partially verified work"（不要交回部分验证的工作）。这不是建议，是硬性约束。SKILL.md 定义的不只是检查清单，是 Claude 的行为边界。
验证步骤越量化，Claude 自验证越可靠。 "检查性能"是模糊的。"跑 Chrome DevTools 性能 trace，审计 Core Web Vitals"是量化的。量化的验证步骤可以被可靠执行，模糊的不行。
Goal-based：确定性的停止条件
当你明确知道"完成"长什么样时，定义一个目标让 Claude 迭代：
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
架构：每次 Claude 想停下来，一个独立的 evaluator model 检查目标条件——不满足就打回去继续。Claude 不能自己决定"差不多了"。
指南明确说了为什么确定性条件比模糊条件有效：
"This is why deterministic criteria, such as number of tests passed or clearing a certain score threshold, are so effective."
测试通过数、分数阈值——这些是可以被无歧义检查的。"让代码质量更好"是不行的。
stop after 5 tries 不是建议，是保险丝。 没有 max turns 的 goal-based loop 是一个可能永不停止的 token 焚烧炉。
Time-based：匹配间隔与变化频率
/loop 5m check my PR, address review comments, and fix failing CI
/loop 在本地跑——电脑关了就停。/schedule 在云端跑——不依赖你的机器。
指南在 token 管理部分给了一个关键原则："Don't run routines more often than you need to: Match the interval to how often the thing you're watching changes."（不要比需要的更频繁地运行：把间隔匹配到你监视的东西的变化频率。）
PR review 的平均响应时间是分钟到小时级。5 分钟检查一次可能太频繁。但如果你的 CI 每 2 分钟跑一次，5 分钟检查就有道理。
Proactive：组合系统
最激进的形态。指南的完整例子：
/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.
四个原语组合：
/schedule（research preview）提供时间触发/goal提供停止条件- dynamic workflows 编排多 agent（triage、fix、review）
- auto mode 让 routine 不停下来问人
指南对 proactive loop 的 token 管理建议："Pilot before a large run: Dynamic workflows can spawn hundreds of agents. Gauge usage on a smaller slice of the work first."（大规模运行前先试点：dynamic workflows 可以生成数百个 agent。先在一小片工作上评估用量。）
代码质量保障：四条原则
指南的"Maintaining code quality"部分值得逐条分析。核心论点：循环输出质量取决于它周围的系统。 四条具体原则：
1. 保持代码库本身干净。 Claude 遵循代码库中已有的模式和约定。如果代码库是混乱的，循环的输出也会是混乱的——循环放大已有模式，不管是好是坏。
2. 给 Claude 自验证的手段。 用 skills 编码"好的标准是什么"。这直接呼应 turn-based 部分的 SKILL.md——不是让 Claude 猜你想 要什么，而是明确写出来。
3. 让文档容易获取。 框架和库的文档包含最新的最佳实践。Claude 能读到文档就能遵循，读不到就靠训练数据（可能过时）。实践中：把项目依赖的关键文档放在 MCP server 或 CLAUDE.md 可引用的位置。
4. 用第二个 agent 做代码审查。 一个拥有 fresh context 的 reviewer 比主 agent 自己检查更少偏差——它不受主 agent 推理过程的影响。指南提到可以用内置的 /code-review skill 或 Code Review for Github。
第五条隐含在段落之后："When an individual result doesn't meet the standard, don't stop at fixing the individual issue, try to encode it to improve the system for all future iterations."（当某个结果不达标时，不要只修这一个问题——把它编码进系统，改善未来所有迭代。）这跟 Lean 的"五问"精神一致：修问题不如修系统。
Token 管理：七个杠杆
指南的"Managing token usage"部分是实操性最强的段落。七个具体杠杆：
| 杠杆 | 说明 |
|---|---|
| 选对 primitive 和模型 | 小任务不需要多 agent 或循环。有些任务可以用更便宜更快的模型 |
| 定义清晰的停止条件 | 对"完成"的描述越具体，Claude 到达解决方案越快（但不能太快） |
| 大规模运行前先试点 | Dynamic workflows 可以生成数百 agent。先小规模评估用量 |
| 确定性工作用脚本 | 跑脚本比推理便宜。PDF skill 可以预置一个填表脚本而不是每次重新推导 |
| 不要过度频繁运行 | 间隔匹配变化频率 |
| 审查用量 | /usage 按 skill/subagent/MCP 拆分用量；/goal 不带参数显示轮次和 token；/workflows 显示每个 agent 的 token |
| 模型和 effort level | "Your model and effort level choices are among the biggest levers on what a loop costs." |
最后一条——模型和 effort level 是成本的最大杠杆。一个 proactive loop 的 routine 部分（固定流程的 triage、格式化、路由）可以用小模型，只有判断类工作（评估、决策）用大模型。指南的建议："Routing routines to smaller, faster models and using the most capable model for judgment calls."（把 routine 路由到更小更快的模型，把最有能力的模型留给判断类调用。）
工程判断
把指南的框架落到真实工程实践，有几个判断值得记录。
从 turn-based 开始，有选择地升级
指南明确说了："Not all tasks require complex loops; start with the simplest solution and use these patterns selectively."
升级路径：日常开发保持 turn-based + 编码验证 skill → 某个任务让你觉得"我在重复"时升级到 goal-based → 发现自己在固定时间做同一件事时升级到 time-based → 有明确的持续工作流时才上 proactive。
停止条件决定循环质量
一个循环的质量不取决于它跑得多快或用什么模型，而取决于停止条件能不能被可靠检查。
最差：模糊的（"让代码更好"）。中等：规则但脆弱的（"lint 通过"——不覆盖逻辑正确性）。最好：确定性可量化的（"全部测试通过 + Lighthouse ≥ 90 + bundle size ≤ 200KB"）。
停止条件写不好时，不要用 goal-based——用 turn-based，人做最后一道验证。
evaluator 和 executor 必须分离
Anthropic 的 goal-based loop 用独立 evaluator model——不是让 Claude 自己判断做完了没有。独立 evaluator 基于预设条件逐一检查，不依赖主 agent 的自我评估。同一个 agent 既执行又评估会产生确认偏差。
组合循环的可靠性是乘积不是平均值
proactive loop 看起来是 /schedule + /goal + workflow + judge 的叠加。但组合系统的可靠性是各组件可靠性的乘积。以最简串联模型估算，四个 90% 可靠的组件组合后约 65%。实际工程中 schedule 层和 goal 层存在冗余，固定流程可以降级运行，落地可靠性通常高于乘积估算——但设计时仍应以串联假设做底线规划。
把修复编码进系统
当循环产出不达标时，不要只修这一个问题——把它编码进 SKILL.md 或停止条件，改善未来所有迭代。指南的原话："don't stop at fixing the individual issue, try to encode it to improve the system for all future iterations."
数据来源与声明： 本文基于 Anthropic 官方博客"Loop engineering: Getting started with loops"（claude.com/blog/getting-started-with-loops，2026 年 7 月 7 日，作者 Delba de Oliveira 和 Michael Segne）的完整公开内容撰写，同时参考了 Anthropic "Build Agents That Run for Hours" workshop（Ash Prabaker & Andrew Wilson，2026 年 5 月）、Addy Osmani "Loop Engineering" 博客（2026 年 6 月）、Boris Cherny 公开访谈。不构成投资建议。文中引用的 Anthropic 指南内容截至 2026 年 7 月 12 日。