Anthropic 官方拆解 Claude Code Loop 工程：4 层能力、2 起事故、30 轮卡住的根因

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 179 篇，AI 编程最佳实战「2026」系列第 61 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

封面图：Claude Code 四层 Loop 工程路线图与 2 起事故

上周 Anthropic 发了一篇叫 Getting started with loops 的文章，把最近很火的 Loop Engineering 拆成了 Claude Code 里可以直接用的四层能力。

当时很多人在传。但因为官方博客写得太克制，没真正讲清楚每层的版本要求和停止机制。

我把这篇文章、官方文档和社区一个月的反馈一起翻了一遍，想把几个容易忽略的边界补出来。

Agent 真正开始干活后，最贵的就不再是让它动起来。更难的是让它在对的地方停下来，并拿证据证明自己做完了。

下面这张图把官方四层 Loop 和每个控制点放到一起看：

说明：本文内容基于 Anthropic 官方博客 Getting started with loops、Claude Code 官方文档及 GitHub Issues（#58348、#64744）整理而成。文中的命令示例、版本要求和参数边界仅供参考，实际使用请以你的 Claude Code 版本和官方最新文档为准。 如果有实际落地经验，欢迎在评论区分享交流。

1. 什么是 Loop 工程

官方对 loop 的定义很朴素：Agent 重复执行一轮轮工作，直到满足停止条件

这里有三个关键问题：

• 谁来触发它
• 它怎么知道该停
• 这类任务该用 Claude Code 哪个原语

我自己的理解更土一点：Loop 工程就是把「我下一步该怎么催 AI」改成「我怎样设计一个 AI 会自己推进的系统」

这个变化很大

以前我们写 prompt，像是在旁边盯着实习生做事：读这个文件、改那段代码、跑一下测试、再给我看结果

Loop 工程更像搭一套班组制度：任务怎么来、谁先处理、怎么验收、失败怎么重试、什么时候升级给人

停止条件是整件事的核心

没有停止条件的 Loop，就是 Token 焚烧炉

没有验证步骤的 Loop，就是自动化产生幻觉

2. Claude Code 把它拆成了四层

官方把 Claude Code 里的 Loop 分成四层，从人盯人，到系统自动跑：

这张表可以当作 Claude Code 的自动化路线。别一上来就上最复杂的 Proactive loop：先从最小的一层开始，把能验证的东西写清楚，再逐步放权。

下面四节按层级展开。我会把每层最容易踩坑的那一处单独点出来，其他次要细节直接给命令或表格，不展开。

四层 Loop 控制点对照：触发器、停止方式、对应原语、对齐成本

3. 第一层：Turn-based，你每发一条 prompt 都已经在了

你每发一条 prompt，其实都启动了一个手动 Loop

Claude 会读上下文、动手改、跑检查、判断是否完成，然后把结果交回来

这就是最普通的 Agentic Loop

问题在于，这一层的验收主要还靠人

比如你让 Claude 做一个前端按钮。它改完代码、跑完测试，然后告诉你完成了。真正的验收还包括：页面能不能打开，按钮点了有没有变化，控制台有没有报错，手机端会不会挤爆布局，截图前后是否符合预期。

Anthropic 的建议是把这些人工检查步骤写进 SKILL.md

这点我非常认同

Skills 最值钱的地方，是让 Claude 知道你认为什么才叫完成

一个好的 Skill，应该把怎么做和怎么验收都写进去

前端、数据分析、视频处理、文章发布这类任务，光听模型说“看起来没问题”不够。得让它真的打开、点击、跑脚本、看输出。

4. 第二层：Goal-based，把「做完」定义清楚

/goal 是这篇文章里最值得普通用户立刻用起来的能力

官方文档写得很直白：/goal 需要 Claude Code v2.1.139 或更新版本（v2.1.139 release 明确把 /goal 列为新增命令）。低于这个版本，命令根本不识别

它的核心作用是：你给 Claude 一个完成条件，它会跨多轮持续工作。每轮结束后，再由一个评估模型判断条件是否满足。

一个最常见的例子：

/goal npm test exits 0 and npm run lint exits 0, stop after 6 turns

或者官方给的：

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

这里有个细节决定 /goal 到底能不能用：

评估模型（默认是 Haiku）不会自己跑命令、读文件。它只能看当前会话里已经出现的证据。

换句话说，你必须让命令真的跑过，把 exit code 写进对话，评估者才看得到。

所以一个好的 /goal 条件，最好写清三件事：

• 一个可衡量的结果，比如测试通过、分数达标、队列清空
• 一个证明方式，比如跑哪个命令、看哪个报告
• 一个边界条件，比如最多尝试几轮、哪些文件不能动

我建议你以后少写这种：

/goal 把这个项目优化好

多写这种：

/goal npm test exits 0, npm run build exits 0, homepage Lighthouse performance score is at least 90, stop after 6 turns

前者像许愿，后者才像工程。

另外几个工程上要注意的硬约束（官方文档明确）：

• 一个 session 同时只能有 1 个 active goal
• 条件最长 4,000 字符
• 用 /goal 看状态，用 /goal clear 停止，stop/off/reset/none/cancel 都是 clear 的别名
• active goal 可随 --resume / --continue 恢复，但计时、turn 数和 token 基线会重置
• 非交互模式建议用 stream-json，否则长循环看起来像卡住

GitHub 上有个很值得提的 issue：anthropics/claude-code#58348。用户报告 v2.1.139 上 /goal 条件引用了一个未注册、模型调不到的 Skill，结果评估者一直说「这个条件没法验证」。循环跑了 30 多次还没停。这事印证了上面那条判断：goal 条件只能写评估者能从 transcript 里看到证据的事，不能许愿模型去调用某个 Skill 自己搞定

5. 第三层：Time-based，让 Claude 定时看外部世界

有些任务并不会因为 Claude 当前这一轮努力就结束

比如：

• PR 可能过 5 分钟才收到 review
• CI 可能跑 10 分钟才失败
• Slack 或 Linear 每天都会有新消息
• 依赖升级、告警、用户反馈都来自外部系统

这就该用 /loop 或 /schedule

/loop 是本地循环，官方例子是：

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

它会按你给的间隔重新运行这条任务。如果你只给 prompt 不给间隔，Claude 会在 1 分钟到 1 小时之间自己选下一次触发时间；如果你什么都不给，跑的是内置 maintenance prompt，或读 .claude/loop.md / ~/.claude/loop.md

但 /loop 跑在你的电脑上，电脑关了就停

如果你想把这件事搬到云端，就要用 /schedule 创建 Routine。Routine 跑在 Anthropic-managed infrastructure 上，机器关机也能继续；支持三种触发器：

• Scheduled：按小时、每天、每周或未来一次触发
• API：HTTP POST 到 per-routine endpoint，附 bearer token
• GitHub：PR 或 Release 事件，可按分支、label、draft/merged 过滤

官方文档明确说，Routine 当前是 research preview，行为、限制和接口都可能变化。云 schedule 最小间隔 1 小时，需要 Pro / Max / Team / Enterprise 且启用 Claude Code on the web。Routine 每次执行都是新的 autonomous cloud session，没有交互 approval prompt。每次运行都会重新 clone repo，默认只能 push claude/ 前缀分支。

这一层最容易踩的坑，是预算失控。

GitHub 上有个 issue #64744 报告了一次真实事故：用户的 /loop 取消异常（ScheduleWakeup 没正常取消），结果跑了 864 次、约 72 小时、花了约 300 美元。这不是普遍行为（只是一个 issue），但足以说明几件事：

• 高频轮询看起来很勤奋，本质上是在花钱买焦虑
• 必须设置 turn / time / cost 硬上限
• 取消一个 /loop 任务后，要确认它真的停了（/loop 列表里检查、CronList / CronDelete 管理任务）

我的建议是：能事件触发就别高频轮询，能一天一次就别五分钟一次

另外本地 /loop 还有两个硬约束容易被忽略：session 最多保存 50 个 scheduled tasks，recurring task 在创建 7 天后会自动到期

6. 第四层：Proactive，真正的 Agent 班组

最猛的是 Proactive loop

它没有实时人类在旁边等着输入下一句

事件或日程一触发，Claude 自己启动，自己拆任务，自己调用 Skills，自己设目标，必要时再拉起 Dynamic Workflows 和多个子 Agent

官方给了一个非常典型的组合：

/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 负责定时启动
• /goal 负责定义本轮做到什么程度
• Skills 负责沉淀验证和操作流程
• Dynamic Workflows 负责并行探索、对抗评审、合并结论

这已经不只是“让 AI 写代码”了。你是在把一小段研发流程交给 Claude Code 托管。

Dynamic Workflows 是这里的硬门槛

官方文档说 Dynamic Workflows 需要 Claude Code v2.1.154 或更高版本。它让 Claude 生成 JavaScript workflow，runtime 在后台执行，脚本控制 loop、branching、pipeline 与中间变量，subagents 负责文件和 shell 操作

几个数字必须知道：

• 每次 run 总计最多 1,000 个 agent
• 同时最多 16 个并发 agent（CPU 受限机器可能更少）
• Workflow script 本身不能直接访问文件系统或 shell，必须由 agent 执行
• 中途没有普通用户输入；需要 stage sign-off 时应拆成多个 workflow
• 仅能在同一 session 内 resume；退出 Claude Code 后重新开始

这两项数字描述的是 runtime 上限，不是推荐规模。官方 UI 在 agents 超过 25 个或 projected tokens 超过 150 万时提示 Large workflow，但提示不自动阻断

我的判断是：绝大多数个人开发者暂时用不到这么大的规模。它先把方向摆出来了——以后真正拉开差距的，可能是能不能设计出一套可靠的 Agent 流水线。

Proactive loop 里最容易翻车的两处

第一处是把外部 payload 当可信输入

Routine 触发时，issue、Slack 消息、API body 都可能包含 prompt injection。官方 Routine API 已经对 fire payload 加 untrusted wrapper，但你保存的 prompt 必须明确只把 payload 当数据，不能让模型自己决定遵循里面的指令

第二处是把 Goal 写成「调用某个 Skill」

上面 #58348 的事在 Proactive 里被放大很多倍：Goal 里写「调用 review-pr Skill 完成 review」，但 Skill 没注册或被禁用，评估者就永远拿不到 yes，循环就一直跑。安全的写法是把验收条件写成「review.md 里包含了 X、Y、Z 三个章节」这种产物层的可验证条件

Dynamic Workflows 架构图：触发器、Runtime、子 Agent 网格与并发边界

7. Loop 工程的真正难点：质量、成本和停止

很多人看到 Loop，会第一时间想到自动化、无人值守、夜里帮我干活

我更关心另一面：质量怎么守住

官方文档提了几条，我觉得都很实在：

• 代码库本身要干净，Claude 会跟着现有模式和约定走
• 要给 Claude 自检手段，把验收标准写进 Skills
• 文档要容易拿到，尤其是框架和库的最新用法
• 关键代码让第二个 Agent review，fresh context 能减少自我偏差
• 确定性的事尽量用脚本，别让模型每次重新推理

这几条合起来其实是一句话：自主程度越高，验证越要前置

你不能指望一个循环跑了 20 轮之后，靠最后一句「请检查一下」兜底

正确做法是把检查机制嵌进循环本身

成本这件事比质量更现实

/loop、/schedule、Dynamic Workflows 都能在你不注意时烧钱。Reddit 上有个用户报告用自学习外循环把 Python 仓库迁到 TypeScript，自述 约 4 小时、119 commits、约 1.4 万行代码，build/tests/examples 都过。

这当然是作者自己说的，没独立审计；但它至少说明：只要不设上限，Loop 可以跑得比你想象的久。

社区对 Loop 最大的批评，是它不适合一次性、探索型需求。先写完整的完成条件、权限、回滚、边界和升级规则，有时比直接跟 Agent 迭代还慢。

这话我同意一半：日常 hack 根本用不上 Loop 工程。只有任务真的会重复、会跑很久，或者需要并行 review 时，这套机制才值回票价。

模型质量波动被循环放大也是真问题。HN 和 Reddit 上都有人吐槽：Claude 在一类任务上能写出很干净的代码，换一类任务就会重复、冗余、范式漂移。

Loop 增加吞吐，也加快了错误复制。这就是为什么要 Maker 和 Checker 分离，也要让一个 review subagent 带着 fresh context 来看。

Claude Code Loop 工程 2 起事故对比：#58348 与 #64744

8. 怎么落地：四步走

如果你刚开始玩 Claude Code Loop，建议按这个顺序来

第一步，先写验证型 Skill

挑一个你最常让 Claude 做的任务，把「完成前必须检查什么」写进 SKILL.md

比如前端改动必须打开页面、脚本必须拿样例数据跑一遍、文章必须查句号和外链、PR 必须确认只动了预期文件

这一步是其他所有层的基础。没这一步就上 /goal，只会让模型自信地错下去

第二步，把清晰任务交给 /goal

适合 /goal 的任务一定要有明确终点

测试通过、构建通过、分数达标、issue 清空，这些都可以

优化一下、帮我整理好、尽量完善这种模糊愿望，先别交给 /goal

写条件时把退出码、报告路径、turn 上限都写进去，别怕啰嗦

第三步，用 /loop 看外部状态

PR、CI、review、部署结果，这些很适合定时检查

但一定要设置合理间隔和 turn 上限

高频轮询看起来很勤奋，本质上是在花钱买焦虑。/loop 在 session 内最多 50 个 scheduled task，recurring 7 天到期，记一下这两个数

第四步，再考虑 Routine 和 Dynamic Workflows

当一个任务已经稳定重复出现，而且你知道输入、输出、验收和失败处理，才值得做成 Routine

这时再加并行 Agent、对抗 review、工作树隔离，收益会很明显

但 Dynamic Workflows 的 16 并发 / 1,000 agent 是天花板，不是起步价。先小范围试跑，再扩大规模

Claude Code Loop 工程 4 步落地路径与 6 个典型坑

9. 几个坑提前说

第一，Loop 不宜越跑越长

一个任务如果 3 轮都没有明显进展，继续跑大概率只是扩大错误。设置 stop after N turns 是个简单但有效的方法

第二，别把 stop 条件写成主观判断

页面看起来不错很难评估。截图没有遮挡、控制台 0 报错、Lighthouse 超过 90 才靠谱

第三，别把所有任务都塞进多 Agent

小任务用单 Agent 更稳，也更省。Addy Osmani 的建议是只在「第二意见值得付费」的阶段上 subagent，社区也反复强调并行数量不是价值本身，最终 review bandwidth 仍是瓶颈

第四，别忽略成本

Dynamic Workflows 可以拉起很多 Agent。爽是真的爽，账单也是真的账单。先小范围试跑，再扩大规模

第五，别混用 Goal 和未注册 Skill

/goal 条件里不要写「调用某个不存在的 Skill 完成 X」这种条件。GitHub #58348 就是这么卡住的。Goal 条件必须能由 transcript 里的证据验证，不依赖一个可能不存在的工具

第六，把外部 payload 当不可信数据

issue、Slack、API body 都可能被人塞 prompt injection。Routine prompt 要明确只把 payload 当数据，让模型只提取结构化字段，不要遵循里面的指令

总结

Anthropic 这篇文章最有价值的地方，是把 Loop Engineering 从一个流行词，拆成了 Claude Code 里可以直接使用的四层能力

Turn-based 解决临时任务，/goal 解决可验收长任务，/loop 和 /schedule 解决外部状态触发，Proactive loop 解决稳定重复的工作流

如果你只记住一句话，我会这么说：

Loop 工程的核心，是让 AI 知道什么时候该继续、什么时候该停、拿什么证明自己做完了

对于 Claude Code 用户，我建议今天就做两件小事：

• 把你最常做的一类任务写成验证型 Skill
• 找一个有明确验收标准的任务，用 /goal 跑一次（注意需要 v2.1.139+）

跑完你会发现，AI 编程的手感会从「我不停催它」，变成「我定义好边界，然后等它交付」

这才是 Agent 真正开始替你干活的感觉

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！