细拆Claude Code官方Loop架构

2026年6月30日，Anthropic 的 Claude Code 团队在官方博客发表《Loop engineering: Getting started with loops》，作者 Delba de Oliveira 和 Michael Segner，首次将 Agent Loop 系统化地拆成四档：Turn-based、Goal-based、Time-based、Proactive。这不是一次产品发布——这是把五个已有功能放进了同一个坐标体系，并给出了可直接复制的组合模板。

如果说这之前，行业里的"Agent Loop"还是一个模糊的共识（Simon Willison 提过，社区靠 Ralph Wiggum 技巧搞过夜跑），那么这篇博客之后，Loop Engineering 有了一套可讨论、可设计、可渐进交付的共享词汇。

● ● ●

一、先澄清两个 Loop

在深入四档之前，必须区分两个容易混淆的概念：

• Agent Loop（单数）：Claude 回答一次 prompt 的底层执行引擎。读上下文 → 调用工具 → 拿到结果 → 再评估 → 重复，直到输出不含 tool call 为止。这是 SDK 文档里描述的循环，每一条 prompt 都在跑它。这是 "the engine"。

• Loops（复数）：用户侧设计的调度模式。怎么触发、什么时候停、最多跑几轮。这是 "the patterns"。四档 Loop 讨论的就是这个层面——你不在设计引擎，你在设计围绕引擎的控制系统。

官方博客给 Loop 的定义只有一句话："Loops as agents repeating cycles of work until a stop condition is met."——Agent 重复执行工作周期，直到满足停止条件。

这句话里最重要的词不是 "repeat"，是 "stop condition"。

● ● ●

二、四档控制权：一张表看清你交出了什么

Claude Code 团队用四个维度给每一档 Loop 定标：谁触发、怎么停、用什么功能实现、适合什么任务。但更深一层，每一档的本质是你交出了一个原属于人的控制权。

四档控制权架构

这四档不是从"半自动"到"全自动"的线性升级。每一档交出的是不同性质的控制权，而且后一档必须以所有前档的稳定运行为前提。

● ● ●

三、逐层拆解

第一档：Turn-based —— 交出验收权

你还在发 prompt，但你不再亲自验收结果了。

Turn-based 就是你现在使用 Claude Code 的默认模式：你发 prompt → Claude 读代码、改文件、跑测试 → 它觉得搞定了就交回来 → 你验、你再发下一条。

关键改进：把人工验收步骤编码进 SKILL.md，让 Agent 在你不在场时也能自检。

官方博客给的例子非常具体：

# 验证前端改动
永远不要仅仅因为编辑成功就报告 UI 改动完成。
像人类审查者一样验证：
1. 启动 dev server，在浏览器打开编辑后的页面
2. 直接操作改动：点击按钮、确认状态变化、截图前后对比
3. 检查浏览器控制台：零新增错误或警告
4. 使用 Chrome DevTools MCP，运行性能追踪并审计 Core Web Vitals
如果任一步骤失败，修复问题并从步骤 1 重新运行

这里的信号是："代码改了"不等于"任务完成"。Turn-based 的升级方向，是把人类脑子里的验收 Checklist 显式化，变成 Agent 可以自己执行的验证流水线。越量化越好——"零控制台错误"比"页面看起来没问题"可靠得多。

交出验收权的前提：你能把验收标准写成一串确定性的、Agent 可执行的检查步骤。如果你自己都说不清"怎么算合格"，那这一档的升级空间就还没打开。

第二档：Goal-based —— 交出停止权

你不再拍板"够了，停"。你把停的条件写进系统，让系统来判断。

这是整个 Loop 架构里最精妙的设计。/goal 命令的核心不是你给了一个目标——是你给了一个可被外部模型评估的退出条件。

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

流程是这样的：

Worker（执行模型）
  ↓ 执行任务
  ↓ 生成 Transcript（工具调用的完整记录）
  ↓
Evaluator（评估模型，默认 Haiku）
  ↓ 目标是否满足？
  ↓ 满足 → 停止
  ↓ 不满足 → 下一轮

这里有一个关键设计：Worker 和 Evaluator 是分开的。 Claude（Worker）不能自己判断"差不多了，停吧"——每次它想停，都交给另一个独立的 Evaluator 去检查条件。这解决了一个根本问题：让同一个模型既干活又判定自己干没干完，本质上是利益冲突。

Worker-Evaluator 分离架构

这个 Worker/Evaluator 分离的模式正在成为多个 Agent Runtime 的设计共识："Generation handles exploration, Evaluation handles convergence. The two should not be mixed."

Evaluator 不能跑命令、不能读文件——它只看 Transcript 里已有的工具输出。所以如果 Claude 没把测试结果打印在对话里，Evaluator 就没法判断。这意味着你的 Goal 条件必须是能从 Transcript 里推理的东西：npm test 的 exit code 是 0、Lighthouse 分数 ≥ 90、queue 为空……但不能是"代码看起来很优雅"。

Goal-based 最重要的不是 Goal，是 Exit Condition + 安全阀。

官方建议的安全阀：

• 显式轮次上限（stop after 5 tries）
• 确定性标准（tests passed, lint clean, score threshold）
• 禁用模糊词（"nicely"、"as much as possible"、"尽量"、"优化"——这些词在 Goal 里全是 bug）

你可以随时跑 /goal（不带参数）查看当前运行的轮数、Token 消耗和 Evaluator 的判定原因。

第三档：Time-based —— 交出启动权

没人发 prompt 的时候，Agent 该做什么？

前两档解决的还是"一个 Prompt 之内"的问题：怎么验证、怎么停止。第三档开始讨论一个本质不同的问题：如果没有人启动这一轮对话，Agent 是否应该有自己醒来做事的能力？

Time-based Loop 回答的是这个。

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

这里的关键洞察是：被调度的不是一个 shell 脚本，而是一整段推理过程。 传统的 cron job 醒来跑一段固定脚本然后退出。Time-based Loop 醒来后跑的是完整的 Agent 行为：读取环境 → 理解变化 → 决策 → 调用工具 → 验证 → 停止。调度的粒度从"执行"变成了"认知"。

有两条路径：

• /loop：本地运行，关电脑就停。适合你在工作时让它盯着 PR、CI 这些需要异步关注的事。可以不设固定间隔让 Claude 自定节奏（/loop 不加参数），或者指定分钟级轮询。
• /schedule：云上运行（Anthropic 基础设施），支持 cron 定时、API 触发、GitHub webhook 事件触发。电脑关了也不会停。需要付费计划。

交出启动权前必须回答的三个问题（来自社区实践总结）：

1. 01外部信号变化的频率是多少？别用 30 秒轮询去盯一个一天才变一次的东西。
2. 02能不能容忍空跑？——多少次空跑之后应该暂停。
3. 03最大处理深度是多少？——如果一次触发出了一串连锁变化，边界在哪。

第四档：Proactive —— 交出派发权

连"这段工作该谁做、怎么做"的决策也开始进入系统。

Proactive 不是第五个功能——它是把前三档 + Auto mode + Dynamic Workflows 组合成一个持续运行的无人值守流水线。

官方给的典型堆栈：

/schedule 每小时：检查 #project-feedback 里的 bug 报告
/goal: 本轮发现的所有报告完成分类、处理和回复之前不要停
修复 bug 时，使用动态工作流在三个并行 worktree 中探索解决方案
再由 judge 对抗性审查

这条命令实际上构建了一个小型操作系统：

1. 01/schedule决定什么时候醒来
2. 02/goal决定每个任务什么时候算完
3. 03SKILL.md存储验收标准（比如"bug fix 必须通过关联测试"）
4. 04Dynamic Workflows编排多个子 Agent 并行探索方案 + judge 审查
5. 05Auto mode去掉工具调用的确认弹窗，不中断流水线

Claude Code 的 Dynamic Workflows（research preview）用 Claude 生成的 JavaScript 描述工作流，可以调用子 Agent、持久化状态、支持重放。这已经不是"一个 Agent 做一个任务"的模型了——这是一个持续运行的 Control Plane，它观察环境、发现事件、调度子 Agent、协调执行、验证结果、继续观察。

Proactive 五层组合

交出派发权的前提——四个约束层：

• Identity（身份隔离）：不同子 Agent 携带不同身份，不能都是用同一个 account
• Permission（权限最小化）：不是每个 Agent 都能 call 所有工具
• Audit（审计日志）：每一个决策都留痕
• Budget（预算上限）：Token、时间、调用次数、子 Agent 数量——全都有 cap

适合 Proactive 的工作：Bug 分类、依赖升级候选、Issue 归类、低风险文档更新、固定格式报告。不适合的：生产配置、计费逻辑、权限变更——这些往下调档，回到前三档逐项验证。

● ● ●

四、Loop Engineering 的本质是什么

看了这四档之后，最值得注意的一件事是：Claude Code 官方博客里出现最多的词，不是 "Autonomous"，而是 Verification、Goal、Schedule、Workflow、Permission、Review、Human Approval。

这不是一套"让 Agent 全自动"的路线图。恰恰相反——这是一套"控制权渐进移交"的路线图。 每一步都要求确保上一层的验证机制稳定后，再交下一层。

JIN 在他的分析文章里把这个框架重新命名为"四层 Runtime Control"，我认为这个视角比"四种 Loop"更准确：

四层控制权移交

• 第一层：先交出验证权
• 第二层：再交出继续权
• 第三层：再交出时间权
• 第四层：最后交出工作域的部分执行权

每一层的移交都以"下一层可以正常运行多久而不出错"作为上层的质量标准。

Addy Osmani 和 Claire Vo 在博客发布后也分享了他们的实践：Week 1 从一个低风险 PR 的 Turn-based 自检开始；Week 2 加入窄域 /goal；Week 3 引入 Time-based 轮询；Week 4+ 才考虑 Proactive。这和你迭代一个分布式系统的方式一模一样：先验证单节点的正确性，再加调度，再加编排。

Loop Engineering 真正重要的不是 /goal、/loop、/schedule 这几个命令怎么用。真正重要的是：Claude Code 开始把那些原本默认由人完成的控制动作——什么时候验证、什么时候继续、什么时候重跑、什么时候升级、什么时候停止——逐层拆解，变成了 Runtime 可以理解、执行和审计的接口。

这些原本散落在工程师本能、README Checklist 和口头交接里的东西，正在变成系统的一等公民。

谁验收、谁叫停、谁启动、谁派工——这些原来由人完成的动作，正在变成 Agent 的运行接口。这就是 Loop Engineering。

● ● ●

五、实用起点：不要一口气冲到 Proactive

不是所有任务都需要 Proactive Loop，大多数任务不需要。

官方和社区的共识选择路径：

核心原则：先硬编码验证，再加迭代，再加调度，最后加编排。 每加一层之前，确保前一层已经稳定运行过一段时间。

参考来源：

• Anthropic 官方博客: Loop engineering: Getting started with loops (2026.06.30, Delba de Oliveira & Michael Segner)
• Claude Code Docs: How the agent loop works (Agent SDK, code.claude.com)
• Claude Code Docs: /goal, /loop, /schedule, Dynamic Workflows (code.claude.com)
• claudefa.st: Claude Code Loops: Stop Prompting, Start Looping (2026.07.14)
• DevGENT: Claude Code Loop Design: Turn, Goal, Time, Proactive Patterns (2026.07.10)
• JIN / Medium: Claude Code's Official Loop Hierarchy: From Self-Verification to Lights-Out (2026.07.11)
• XiaoHu: Claude Code's Official Playbook: 4 Levels of Agent Loops to Unattended (2026.07.02)
• Simon Willison: Designing agentic loops (simonwillison.net)