Claude Code Loop Engineering 深度解读：从写 Prompt 到设计 Loop

Anthropic Claude Code 团队官方循环设计指南全解析

引言：Agent 工程的重心正在转移

2026 年 6 月 30 日，Anthropic Claude Code 团队的 Delba Oliveira 在官方博客发布了一篇题为 Getting Started with Loops 的文章^1^，系统拆解了 Claude Code 团队是如何设计 Agent 循环（Loop）的。7 月 7 日，该团队在 X 上进一步分享了这份指南的核心要点^2^，引发了开发者社区的广泛讨论。

这份指南的意义远不止于介绍几个新命令。它揭示了一个正在发生的范式转移：Agent 工程的重心，正在从「写好指令（Prompt）」转向「设好规则（Loop）」。

传统 Agent 开发的思路是不断打磨 Prompt，试图用一段完美的指令覆盖所有可能的情况。但 Loop 的设计思路恰好相反：Prompt 不需要完美，系统才需要。只要把验证条件定义清楚、停止边界设好、工具链搭好，Agent 自己会迭代到对为止。

本文基于 Claude Code 团队官方原文^1^{及相关深度解读}2^，系统梳理四种循环类型的设计哲学、三大工程原则，以及它们对 AI 工程实践的深远影响。

核心定义：什么是 Loop？

Claude Code 团队给出了一个非常工程化的定义：

Loop 是 AI Agent 不断重复执行工作周期，直到满足某个预设的停止条件。

这个定义看似简单，但背后蕴含着一个关键的设计思路转变：Loop 不是让 Agent 更努力地工作，而是给它一个可以自我评估、自我纠正的框架。

Claude Code 团队从四个维度对 Loop 进行分类：

触发方式：谁或什么启动了循环？
停止条件：什么情况下循环结束？
底层原语（Primitive）：使用了哪个 Claude Code 内置基础能力？
适用场景：什么类型的任务最适合这种循环？

下面逐一拆解四种循环类型。

四种循环类型详解

四种循环类型关系图

图 1：四种循环类型按 2×2 矩阵排列，展示了回合制→目标循环→时间循环→主动循环的演进路径。蓝色=回合制，紫色=目标循环，绿色=时间循环，橙色=主动循环。

3.1 回合制循环（Turn-based Loop）

属性	说明
类型	基础模式
触发方式	用户输入 Prompt
停止条件	Claude 自行判断任务完成，或需要更多上下文
适用场景	短期任务、探索性工作、非固定流程
Token 控制	写更具体的 Prompt，通过 Skills 强化验证步骤

每次你给 Claude Code 发送一个 Prompt，实际上就启动了一个由你手动指挥的循环 。Claude 收到指令后，收集上下文、采取行动、检查结果、在需要时重复、最后回复你。这个过程被称为 Agentic Loop。

但这里有一个容易被忽视的问题：Claude 判断「任务完成」的标准，和你的预期之间往往存在差距。你觉得有些东西还没做好，但它觉得已经可以交差了。这个差距，就是回合制循环最大的短板。

怎么缩小这个差距？Claude Code 团队的答案不是靠 Prompt 去描述你该怎么做，而是靠 SKILL.md 去定义做完之后必须验证什么。

下面是一个来自官方文档的典型示例：

markdown 复制代码

---
name: verify-frontend-change
description: 在宣布完成之前，端到端验证任何 UI 更改。
---

# 验证前端更改

绝不能仅仅因为代码修改成功，就报告 UI 更改已完成。
必须像人类代码审查员那样进行验证：

1. 启动开发服务器，并在浏览器中打开修改后的页面。
2. 直接与更改后的内容交互。对于新增的控件（如按钮、输入框、开关）：
   点击它，确认状态如预期般改变，并在操作前后截图。
3. 检查浏览器控制台：确保没有新增任何错误或警告。
4. 使用 Chrome DevTools MCP，运行性能追踪并审核 Core Web Vitals。

如果任何一个步骤失败，请修复问题并从步骤 1 重新开始------
绝对不要把只验证了一半的工作交回给我。

这个 SKILL.md 本质上是一个可执行的验收清单。它把你脑子里那些隐性的判断标准，翻译成了 Agent 可以自动执行的检查步骤。验证越具象、越可量化，Agent 就越不容易跑偏。

3.2 目标循环（Goal-based Loop）

属性	说明
类型	进阶模式
触发方式	手动输入 `/goal` 指令
停止条件	目标达成，或达到最大尝试轮次
适用场景	具备可验证退出标准的复杂任务
Token 控制	设定具体完成标准 + 明确轮次上限

回合制循环解决的是 Agent 怎么干活，但更复杂的任务还需要解决另一个问题：**Agent 怎么知道自己什么时候真的干完了？**这就是目标循环要解决的问题。

使用 /goal 指令，你给 Claude 设定的是一个具体的、可验证的目标，而不是一个模糊的期望。例如：

bash 复制代码

/goal 将主页 Lighthouse 分数提升到 90 分或以上，尝试 5 次后停止。

如果只是说「请优化主页性能」，Claude 会根据自己的判断决定优化到什么程度算够好了。这个判断通常是保守的------它倾向于早点交差。而「Lighthouse 分数到 90 分」的判断是客观的，没达到就继续。

这里有一个很容易被忽视但极其关键的设计细节 ：目标循环的工作原理不是让 Claude 更加努力，而是引入了一个独立的评估层（Evaluator Model）。每次 Claude 尝试停止时，一个独立的评估模型会检查目标条件，没达标就驳回继续工作。

这个评估层是全新的上下文，它不受主 Agent 推理过程的影响。这很关键------Agent 在执行任务时会产生某种思维惯性，认为自己做的修改都是合理的。一个独立的评估者正好打破这个惯性。这个设计跟人类团队的 Code Review 逻辑完全一致：写代码的人自己是审不出所有问题的，必须要一个没参与写代码的人来审。

目标循环的核心优势在于：可量化的完成标准比任何精心措辞的 Prompt 都可靠。不是 Prompt 写得不够好，而是 Prompt 再怎么好，最终的「够好了」仍然依赖 Agent 自己的主观判断。而数字不会通融------90 分就是 90 分，少一分都不行。

3.3 时间循环（Time-based Loop）

属性	说明
类型	定时模式
触发方式	设定的时间间隔
停止条件	手动取消，或工作彻底完成（PR 合并、队列清空）
适用场景	周期性重复工作、外部系统交互
Token 控制	设置更长时间间隔，优先使用事件触发

前两种循环都是你来触发。但如果 Agent 的工作需要跟外部系统交互呢？比如，你的 Pull Request 收到了新的审阅意见，或者 CI 跑失败了。这些事件发生在你不在电脑前的时候，等你回来再手动触发 Agent 处理，效率就太低了。

时间循环就是为这种场景设计的。/loop 指令让 Claude 定时重新执行任务：

arduino 复制代码

/loop 5m 检查我的 PR，处理评审意见，修复失败的 CI。

每 5 分钟，Claude 自动检查你的 PR 状态，发现问题就自己动手修。

/schedule 是 /loop 的云端版本，把定时任务从你的本地机器搬到服务器上运行。关了电脑也不会停。

Claude Code 团队的建议是：

尽量让时间间隔跟变化频率匹配，不要太频繁。如果你每 1 分钟轮询一次，大部分检查都是在空跑，什么都没变，白烧 Token。如果你的 PR 平均 3 小时才收到一次评审，那每 30 分钟检查一次已经足够快了。
能基于事件就别基于时间。如果你的代码仓库支持 Webhook 通知（PR 有新评论时推送事件），用事件触发远比定时轮询更高效。时间循环只是当你没有事件机制时的一个替代方案。

3.4 主动循环（Proactive Loops）

属性	说明
类型	组合模式
触发方式	事件或日程触发，无需人类实时参与
停止条件	每个子任务目标达成时退出；Routine 本身持续运行
适用场景	持续流入、定义清晰的重复工作流（Bug 报告、Issue Triage、迁移）
Token 控制	日常流程路由给更小/更快的模型，最强模型留给关键判断

主动循环不是一种全新的循环类型，而是前三种循环的组合包 。它把 /schedule（触发）、/goal（目标定义）、动态工作流（任务编排）和自动模式（免确认运行）串起来，构成一条完整的自动化流水线。

举一个官方原文中的例子：

bash 复制代码

/schedule 每小时：检查 project-feedback 频道中的 Bug 报告。
/goal：直到本次运行中发现的每个报告都经过分类、处理并回复才停止。
在修复 Bug 时，使用工作流在三个并行工作树中探索三种解决方案，
并让评审智能体进行对抗性审查。

这段指令相当于告诉 Claude 「我不参与了，每小时你自己看着办」。

从设计的角度来看，主动循环体现了一个关键的工程思路：复杂系统的可靠性不来自于某个厉害的组件，而来自于合理组合简单、可靠的组件 。/schedule 负责触发，/goal 负责边界，工作流负责分工，评审 Agent 负责质量。每个组件只做一件事，做好自己的事，组合起来就是一条能自主运行的流水线。

四种循环对比总览

循环类型	你交出去什么	触发方式	停止条件	验证自动化程度	核心工具
回合制循环	检查动作	用户输入 Prompt	Agent 自行判断	全靠人	自定义验证 Skills
目标循环	停止条件	手动 `/goal` 指令	目标达成 / 达到轮次上限	部分自动化	`/goal`
时间循环	触发机制	时间间隔	手动取消 / 工作完成	全自动化	`/loop`, `/schedule`
主动循环	完整 Prompt 和运行规则	事件 / 日程	各子任务目标达成	流水线化	以上全部 + 动态工作流

三大工程原则

四种循环的拆解提供了操作手册------什么时候用什么。但 Claude Code 团队的这份指南里，还藏着三条更深层的设计原则，它们解释了为什么 Loop 能生效，而不仅仅是 Loop 怎么用。

三大核心原则卡片


01 验证闭环决定质量上限	02 停止条件比 Prompt 更重要	03 代码库就是质量基础设施
Loop 输出的质量取决于它周围的验证系统。验证越具象、越可量化，Loop 就越不容易跑偏。	别告诉 Agent 怎么做得好，告诉它什么叫达标。可量化的停止条件胜过任何精心措辞的指令。	干净的代码库是 Loop 高效工作的前提。把确定性工作脚本化，把推理能力用在真正需要判断的地方。

原则一：验证闭环决定质量上限

这份指南里有一句话值得反复琢磨：「循环输出的质量取决于它周围的系统。」

Loop 本身只是一个执行框架，它告诉 Agent 去干、检查、不行就再来。但如果检查这一步是糊弄的，Loop 做得越多错得越多。

验证系统的设计有三个层次：

层级	内容
L1	隐性判断 → 可执行检查项把人的隐性判断变成 Agent 可自动执行的检查步骤，如检查控制台错误、截图对比、性能审计
L2	独立评审者打破思维惯性引入全新区块上下文的评估模型，只看结果不看过程，不受主 Agent 推理链影响
L3	对抗性审查评审 Agent 专门来找漏洞：修复方案是否引入新问题？边界情况是否覆盖？测试用例是否充分？

四种循环的本质差异，就是验证自动化程度的不同。

**回合制循环：**验证全靠人，你手动检查 Agent 的输出
**目标循环：**验证部分自动化，可量化的标准由系统检查
**时间循环：**验证全自动化，Agent 自己检查、自己修复
**主动循环：**验证流水线化，多个 Agent 交叉验证

Loop 能不能跑稳，不取决于 Loop 本身，取决于你花了多少心思设计验证。

原则二：停止条件比 Prompt 更重要

有多少人写 Prompt 的时候，会在最后加一句「请确保质量足够好」？问题是，什么是「足够好」？Agent 想要交差，你说质量还不够好。你们之间没有一个共识，因为你没说清楚「好」到底指什么。

Claude Code 团队在设计 Loop 的停止条件时，分了明确的三个层级：

层级	内容
任务级	目标达成：Lighthouse 上 90 分了，测试全通过了，构建时间减少了至少 20%
资源级	最大轮次到了：尝试 5 次了，该停了
经济级	Token 预算耗尽：不用无限循环烧钱

这三层里，任务级的停止条件是唯一真正定义「完成」的 。它的设计原则很明确：必须是可量化的、可自动判断的，不能依赖 Agent 的主观评价。

「让代码质量变好」不是一个合格的停止条件，因为谁也判断不了什么叫「变好」。但「所有测试通过」是，「Lighthouse 分数 ≥ 90 分」是，「构建时间减少至少 20%」是。

这个原则挑战了一个写 Prompt 时的常见习惯：我们总喜欢在 Prompt 里描述质量的期望，而不是定义质量的度量。但 Loop 的设计思路刚好相反：别告诉 Agent 怎么做得好，告诉它什么叫达标。只要达标了就停，没达标就继续。

原则三：代码库本身就是质量基础设施

Claude Code 认为干净的代码库是 Loop 能高效工作的前提。这不是空话。

Agent 不是凭空理解你的项目的。它通过读取现有代码、分析文件结构、学习代码风格来建立上下文。如果代码库本身混乱------风格不统一、命名不规范、到处都是死代码------Agent 的理解就会出错，基于错误理解做出的修改自然好不到哪去。

更关键的是成本。Claude Code 团队明确区分了两种操作方式的成本差异：

运行脚本 vs 逐步推理。 如果有一个 PDF 表单填充的脚本，Agent 只需要调一次脚本就完成了。如果没有脚本，Agent 需要每次重新推导表单填充的逻辑，这中间的 Token 消耗可能是几十倍的差距。

这个原则的深层含义是：别把所有事情都丢给 Agent 去推理。能做脚本的就写成脚本，能工具化的就工具化。Agent 的推理能力是稀缺资源，把它用在真正需要判断的地方，而不是用在可以标准化的重复性工作上。

Token 成本管理：六条实战建议

Claude Code 团队在指南中给出了六条控制 Token 消耗的具体建议^1^：

策略	具体做法
1. 选择合适的指令和模型	小任务不需要多个 Agent 或复杂 Loop，很多任务用更便宜、更快的模型就能完美解决。杀鸡焉用牛刀。
2. 定义明确的成功与停止标准	具体描述「完成」的状态，让 Claude 更快抵达解法，同时避免过早停止。
3. 大规模运行前先「试水」	动态工作流可能一次衍生出数百个 Agent。先用较小任务切片估算实际消耗量。
4. 用脚本处理确定性工作	运行脚本比让模型逐步推理便宜得多。例如 PDF Skill 内嵌填表脚本，每次直接运行而非重新推导。
5. 不要跑得太频繁	检查间隔应匹配被观察对象的变化频率。不要让 Agent 每秒刷一个一天才更新一次的页面。
6. 定期查看消耗	`/usage` 按 Skills、SubAgents 和 MCP 拆解近期消耗；`/goal` 展示当前轮次和 Token 用量；`/workflows` 展示每个 Agent 的具体消耗。

实践指南：如何开始你的第一个 Loop

Claude Code 团队建议从一个简单的问题开始：找一个你自己总是成为效率瓶颈的任务，然后问自己三个问题：

哪一部分检查可以交给 Agent？ ------ 能否写出自动验证的检查项？
目标是否已经清楚到可以被验证？ ------ 是否有可量化的完成标准？
这件事是否按某种日程或输入流反复发生？ ------ 能否用定时或事件触发？

有了初步想法以后，记住一个关键原则：从最简单的方案开始，不要一上来就搞复杂的 Loop。很多任务并不需要复杂的循环。Loop 不是加速器，而是放大器------如果你的基础流程有问题，Loop 只会放大这些问题。

推荐的学习路径：

先写一个 SKILL.md，把验证步骤固化下来，体验回合制循环的改进
尝试 /goal 指令，为某个具体任务设定可量化的停止条件
引入 /loop 定时任务，让 Agent 处理周期性工作
组合使用 ，将 /schedule、/goal、动态工作流串成主动循环

最后，Claude Code 团队反复强调一条最重要的经验：当某次执行结果不达标时，不要只修复这个单点问题。把这次失败编码进系统，让未来所有迭代都受益。不要只修 Prompt，要修系统。

总结：从「写指令」到「设规则」

Claude Code 团队的这份循环设计指南，传递了一个清晰的信号：Agent 设计的重心已经从指令层上移到了系统层。

传统的 Agent 开发思路是 Prompt 越写越长、越写越精妙，试图用一段完美的指令覆盖所有可能的情况。但 Loop 的设计思路反过来了：Prompt 不需要完美，系统才需要。只要你把验证条件定义清楚了、停止边界设好了、工具链搭好了，Agent 自己会迭代到对为止。

你在系统层面付出的每一分设计成本------验证步骤、停止条件、工具链------最终都会转化为 Agent 输出的可靠性。正如 Claude Code 负责人 Boris Cherny 所说：「我不再给 Claude 写 Prompt 了。我的工作是写 Loop，让 Loop 去决定该干什么。 」^3^

这不是一个工具的更新，而是一种工程思维的升级。

参考资料

Footnotes

Delba Oliveira / Claude Code Team, Getting Started with Loops . Anthropic 官方博客，系统介绍 Claude Code 四种循环类型的设计哲学与实践指南。原文发布于 2026 年 6 月 30 日，作者 @delba_oliveira ↩ ↩² ↩³
ClaudeDevs, X 平台帖子（2026年7月7日）. Claude Code 团队在 X 上发布的循环设计指南分享。x.com/ClaudeDevs/... ↩ ↩²
Boris Cherny, Anthropic 开发者大会演讲（2026年6月）. Claude Code 负责人在红杉活动中的发言，阐述 Loop Engineering 的核心理念。相关报道见各大科技媒体 ↩