循环工程：Claude Code循环、例程与工作流

简而言之：Loop engineering是一门让智能体反复执行工作周期，直至满足停止条件的工程方法，而不是每次只提示智能体执行一轮。Anthropic的Boris Cherny（Claude Code的创造者）直言不讳地描述了自己的工作流：“我已经不再提示Claude了。我有多个循环持续运行。它们会提示Claude，并自行判断该做什么。我的工作就是编写循环。”¹如今，Claude Code提供了一套完整的循环机制：/goal（不断重复，直至另一个独立模型确认条件已满足）、/loop（定期在本地运行）、官方Ralph插件（持续迭代，直至兑现承诺）、routines（云端定时任务），以及dynamic workflows（Claude编写JavaScript编排图，并据此运行最多1,000个subagents）。然而，真正举足轻重的并非上述任何功能，而是验证。只有当生成器之外的机制——测试、评分模型、像素差异对比或机器检查——判定“完成”时，循环才会收敛。验证得当，循环便能产生复利效应；验证失误，得到的只会是一场代价高昂的随机游走。本指南将介绍每一种循环机制及其版本锚点、Ralph模式及其失效情形、循环何时需要演变为图、验证阶梯、成本与安全规范，以及如何运营一支常驻智能体队伍。内容更新至Claude Code v2.1.234（2026年8月）。

什么是 Loop Engineering？

两年前，工程师还在手工编写源代码。随后，agents 开始根据人类的提示词编写代码。如今正在发生的转变又上升了一个层次：agents 向 agents 发出提示，而人类编写的是决定提示内容的系统。Cherny 直言不讳地评价了这场跨越：“从源代码迈向 agents 的转变有多么重大，loops 就同样重要，也是一次同等规模的跨越。”²

他的定义朴实得令人耳目一新：“Loop 本质上就是一个在本地为 Claude 运行的 cron 作业。Routine 与之相同，只不过运行在云端。”³ 这种听起来颇为神秘的实践——夜间让“数百个、有时甚至数千个 agents 连续运行 5、10、20 小时”，⁴ Claude Code“超过六个月一直 100% 由 Claude Code 编写”⁴——归根结底只依赖少数几个基本要素：按计划或条件重新触发的提示词、在迭代之间持续保留的状态，以及结束运行的检查机制。

Anthropic 于 2026年6月为这门方法命名：loops 是“agents 不断重复工作周期，直至满足停止条件”，而且“loop 的输出质量取决于其周围的系统”。⁵ 本指南讨论的正是这个外围系统。

有必要说明一下出处，因为相关讨论在 2026年年中演变得很快：“graph engineering” 一词——热门帖子往往将其归于 Cherny——其实源自社区，而非 Anthropic 或 Cherny。Peter Steinberger 于 7月18日发问“我们还在讨论 loops，还是已经转向 graphs 了？”，随后经 Hamel Husain 推广而流传开来。⁶ 广为传播的“我们 85% 的工程师……实现方式就是 graph engineering”这段话只见于第三方帖子；在编写本指南时，我们未能在他的任何一手演讲记录中找到这段话（包括 YC Startup School 对谈、Bloomberg 的 Odd Lots，以及 TechCrunch 对 Meta @Scale 的报道），因此应将其视为未经证实的归因。他的实际工作方式确实呈图结构（orchestrators 会生成 implementer/verifier/fixer subagents，最多嵌套 5 层），但经过核实的术语是 loops、routines 和 workflows——本指南也将沿用这些术语。

5 分钟黄金路径

只需 3 条命令，即可从发出提示迈向循环执行：

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud routine: runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

这些命令与普通提示词的区别在于结构，而非表面形式：每一种方式都有一条重新触发规则（条件、时钟或 cron），也都需要一条停止规则。本指南余下的全部内容，都是为了让这两条规则值得信赖。

核心 Loop 与唯一准则

每个 agentic 系统都运行着相同的内层周期。Anthropic 的 Agent SDK 文档将其确立为标准流程：收集上下文 → 采取行动 → 验证工作 → 重复。⁷ Claude Code 自身的处理过程也是一个 loop：评估提示词、调用工具、读取结果并重复执行，直到响应中不再包含工具调用。⁸

Loop engineering 会在这个内层周期之外包裹外层 loops，同时继承一条不容妥协的准则。该领域所有严肃资料都反复强调：

完成工作的 agent 绝不能为自己的工作评分。

• Anthropic 的 /goal 文档：“是否完成由一个全新的模型判断，而不是由执行工作的模型判断。”⁹
• Anthropic 的 harness 设计文章：“事实证明，将执行工作的 agent 与评判工作的 agent 分离，是解决这一问题的有力手段。”¹⁰
• Cherny 谈从业者经常忽略的要点：“验证很可能是最重要的一环，也是人们最容易做错的一环。”³ 在他给出的实例中，他要求系统用两周时间将 Electron 应用重写为 Swift：“在 Mac 虚拟机中运行 Electron 应用，截取屏幕截图，然后逐像素查看。将其与 Swift 版本比较。完成之前不要停止。”³

原因在于机制，而非道德：当被问及“您完成了吗？”时，模型会表现出肯定性的自我评分偏差，而一份充满自信的执行记录可能诱导由模型判断的退出条件过早给出“完成”结论。¹¹ 外部验证——测试套件、编译器、像素差异比较，或一个对答案没有既得倾向的全新模型——是唯一能够抵御这种偏差的信号。

自主性阶梯

Claude Code 中的 loop 形态构成了一架阶梯，从“再次按下回车键”一直延伸到“无需您介入即可运行”。每向外一环，都会以更重的验证负担换取更高的自主性：

（这种环级划分沿用了 pardel.dev 在 2026年7月提出的分类法；这是目前对该领域最清晰的独立梳理。¹¹）

这架阶梯的原则是：从能够解决问题的最低环级开始，只有在该环级的验证机制得到证明后才继续向上攀升。 如果 /goal 无法将条件表述为可检查的内容，就还不具备升级为 routine 的条件。

Loop 的各种形态详解

（本指南讲解 loop 本身的各种形态。Claude Code 指南是完整的 CLI 参考资料，涵盖配置、权限、hooks 和 MCP；Agent Architecture 指南则介绍 harness 组件如何组合。loops 是运行在二者之上的机制。）

/goal——evaluator-optimizer loop

/goal <condition> 会让 Claude 持续工作，直到条件成立：“每轮结束后，一个小型快速模型会检查条件是否成立。如果不成立，Claude 将开始新一轮，而不是把控制权交还给您。”⁹ evaluator（默认使用 Haiku）会返回“是”或“否”以及理由，Claude 会将其作为下一轮的指导信息。它也能以 headless 模式运行：claude -p "/goal ..." 会执行 loop 直至完成。

编写提示时应注意：条件要可观察（如“测试通过”“端点返回 200”“TypeScript 错误为零”），而不能只是愿景（如“代码很整洁”）。含糊的 verifier 无法为 loop 指明方向。况且，一份充满自信的执行记录可能说服由模型判断的条件同意任务已经完成，因此只要存在机器检查，就应将其与 /goal 配合使用。¹¹

v2.1.234 中的两项变更增强了 loop 本身的稳健性。现在，如果某一轮因不可恢复的错误而终止——身份验证被撤销、余额耗尽或上下文溢出——goal 会自动清除并显示通知，不再对已经无法继续执行的会话保持启用状态。此外，当后台任务让 goal 等待 30 分钟以上时，Claude 会主动检查其状态，而不是无限期等待（可通过 CLAUDE_CODE_GOAL_CHECKIN_MINUTES 调整阈值；设为 0 则恢复原先永久等待的行为）。³³

/loop——定期本地运行

/loop [interval] <prompt> 会按计划重复运行提示词：可以采用固定间隔（/loop 5m check the deploy）、自主安排节奏（Claude 根据观察结果决定下一次延迟时长），也可以只输入 /loop，执行内置的维护流程。其底层使用 CronCreate/CronList/CronDelete（5 字段 cron、每个会话最多 50 个任务、7 天后过期）以及 Monitor 工具；后者会流式传输后台脚本的输出，无需轮询。¹² Cherny 自己给出的启动示例是：“/loop babysit all my PRs. Auto-fix build issues and when comments come in, use a worktree agent to fix them.”¹³

真正需要注意的限制是：/loop 依附于当前会话。关闭终端，loop 也会终止——这正是 routines 要解决的问题。

Ralph plugin——迭代直至兑现承诺

Anthropic 官方的 ralph-wiggum plugin 将社区最常用的暴力迭代模式产品化：Stop hook 会拦截 Claude 结束会话的尝试，并重新注入提示词，使模型在同一会话中持续迭代。使用 /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" 启动；使用 /cancel-ralph 中止。README 明确指出，--max-iterations 是“您的主要安全机制”——精确字符串完成匹配可能永远无法成功。¹⁴

动态 workflows——Claude 编写 graph

动态 workflows 随 Claude Code v2.1.154（2026年5月）推出，并在 Anthropic 于 2026年6月2日发布的文章中得到详细介绍。这是概念上最大的一次飞跃：“Claude 现在可以即时编写自己的 harness，为当前任务量身定制。”¹⁵ 您只需描述任务（甚至只需说“use a workflow”）；Claude 就会编写一段 JavaScript 编排脚本——agent() 可生成带有可选 JSON-schema 输出的 subagent，pipeline() 让项目依次通过各个阶段，而普通的 await、loops 和条件语句负责控制流程——随后由运行时在后台执行。“workflow 将计划转化为代码……workflow 脚本自行承载 loop、分支和中间结果，因此 Claude 的上下文只需保留最终答案。”¹⁶

限制与形态：最多同时运行 16 个 agents，每次运行最多 1,000 个（“防止 loops 失控”），运行期间不接受用户输入；保存到 .claude/workflows/ 的脚本会成为可重复使用的斜杠命令；运行过程支持通过缓存的 agent 结果恢复。¹⁶ 其标志性拓扑结构是 fan-out / refute / converge：先由相互独立的 finders 展开搜索，再由收到反驳指令的对抗性 verifiers 审查每项发现，持续迭代，直至答案经受住质疑。发布文章中最引人注目的成果是 Bun 对其 535,496 行 Zig 代码库的 Rust 移植：根据 Jarred Sumner 的说法，64 个并行 agents 在 11 天内（2026年5月3日至14日）完成了移植，最终生成的 Rust 代码库超过 100 万行。¹⁵

Agent teams——peer graph

该功能隐藏在 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 之后（自 v2.1.32、2026年2月起提供研究预览版）：由一名 team lead 和多名 teammates 组成，后者“各自在独立的上下文窗口中自主工作，并能彼此直接通信”。这是一种 peer graph，而非 subagent tree；它通过带有依赖关系的共享任务列表、文件锁定认领机制以及每个 agent 独立的邮箱进行协调。由 Hook 强制执行的质量关卡（TaskCompleted 返回退出代码 2 时阻止完成）会在 teammate 与“完成”状态之间加入机器检查。¹⁷

Routines——比您的笔记本电脑运行得更久的 loops

routine 是“保存好的 Claude Code 配置：包含一个提示词、一个或多个代码仓库以及一组 connectors，只需打包一次，之后即可自动运行”，既可运行在 Anthropic 管理的云端，也可运行在您自己的 self-hosted runners 上。¹⁸ 支持 3 种可组合的触发类型：cron 计划（最短间隔 1 小时）、API 触发（POST .../routines/{id}/fire）以及 GitHub 事件。可通过 /schedule 或 claude.ai/code/routines 创建。运行会自主执行，不会发出批准提示；正因如此，文档中的这条警告至关重要：绿色运行状态“并不意味着提示词中的任务已经成功。请打开运行记录，阅读执行过程，并确认 Claude 实际执行了什么。”¹⁸

Anthropic 在自己的各个代码库中“每天大概运行 20 或 30 个这样的 routines”，用于清理死代码、提高测试覆盖率以及发布实验性功能。³

配套机制

Background subagents（自 v2.1.198 起默认启用）会让委派的工作保持在您的上下文之外；可通过 /agents 面板进行监控。Cross-session messaging（v2.1.224）借助 SendMessage 将相互独立的会话组成消息传递 graph，其安全原则值得借鉴：来自另一会话的消息“绝不代表您已经同意”。¹⁹ Self-hosted runners（v2.1.224，面向 Team/Enterprise）可在您自己的机器上执行云端会话和 routines，是构建组织级 agent 集群的基础设施。²⁰

Ralph 模式

社区率先探索出了这条路。2025年7月，Geoffrey Huntley发表了一篇文章，以《辛普森一家》中的角色命名了这项技术：Ralph实际上就是

while :; do cat PROMPT.md | claude-code ; done

——这是他发表时的原话——一个仓库，每次迭代处理一个任务，每轮都使用全新上下文，通过文件系统中的规范和进度文件在迭代之间传递状态，并以测试和 lint 充当“反压”机制。²¹如今，同一模式的现代无头形式是在 shell 循环中运行claude -p "$(cat PROMPT.md)"，本质上也正是Anthropic自己的 C 编译器 harness 所采用的方式。²³他宣称取得了显著成果（用价值297美元的 token 完成了一份5万美元合同的MVP；在黑客松上一夜处理6个仓库），同时也明确指出了局限：仅适用于绿地项目；占位实现和重复实现是反复出现的故障模式；而且“LLMs是操作者能力的镜子”。

Anthropic从未在其工程资料中使用这个名称，但该模式如今已两度成为官方准则：2025年11月发布的长时间运行 agents 文章明确规定了同样的模式——由初始化 agent 创建功能列表和进度文件，随后每个上下文窗口都启用全新的 coding agents，并“在会话开始时读取进度说明文件和 git 提交日志”²²——而2026年2月的 C 编译器项目则并行运行了16个Claude agents。正如 Nicholas Carlini 所述：“我构建了一个 harness，把Claude放进一个简单循环中。”该项目使用基于文件的任务锁，并以 git 作为同步层，在约2,000个会话中生成了约10万行 Rust 代码，成本约为2万美元。²³文章中关于验证的一句话概括了该模式的完整理论：“任务验证器必须近乎完美，这一点至关重要。”

为什么全新上下文胜过一个漫长会话：随着会话上下文逐渐填满，效果会不断下降——从业者的共识是，大约达到10万 token 后便会开始偏离——而压缩摘要属于有损释义，可能将错误粉饰成自信笃定的表述。²⁴Ralph 的“全新实例加文件”设计避开了这两个问题。（官方插件在会话内循环，为便利性牺牲了部分优势；对于长时间运行的任务，使用外部状态的无头形式仍然更为稳健。）

该模式的警示案例同样发人深省：一名从业者使用含糊的提示词运行插件，并设置了max_iterations: 0——这表示无限，而非禁用——结果Claude连续1,966次向自己提出同一个澄清问题，Stop hook 还劫持了之后的每条消息。²⁵迭代上限绝非可有可无。

当循环演变为图

单个循环假定各次迭代彼此独立，或严格按顺序执行。一旦并行工作存在依赖关系——例如任务 B 需要任务 A 的输出，或两个 agents 会编辑同一个文件——自由形式的循环便会相互冲突。此时需要明确的结构：带依赖数组的任务列表、文件认领机制以及合并规范。这正是“循环与图”之争的实质：一个仓库、一个目标使用循环；并行工作需要排序时使用图。²⁶

图结构方案按基础设施复杂度从低到高排列如下：

1. 动态工作流——在JavaScript控制流中表达依赖关系；仅当某个阶段确实需要此前所有结果时才设置屏障。Anthropic列出的拓扑包括：扇出并综合、对抗式验证、生成并筛选、锦标赛（“生成 N 个 agents，分别以不同方法尝试同一任务”，再两两评判）以及循环直至完成。¹⁵
2. Agent teams——使用带依赖关系跟踪的共享任务列表，并由负责人审批计划；图是数据，而非代码。¹⁷这一模式下有一项默认设置发生了变化：从 v2.1.233 起，Task 工具（TaskCreate/Get/Update/List、TodoWrite）在 Opus 4.8、Sonnet 5、Fable 5 及更新模型上默认关闭——文档明确指出，没有 Task 工具的 agents“通过消息进行协调，而非使用共享任务列表”。因此，在当前一代的默认配置中，任务列表实际上会悄然消失。设置CLAUDE_CODE_ENABLE_TODO_TOOLS=1即可恢复。³³
3. 外部编排器——这是社区采用的横向扩展方案：Steve Yegge 的 Gas Town 针对由 git 支持的“beads”所构成的 DAG 运行20–30个Claude Code实例（据他本人所述，17天内编写了7.5万行 Go 代码，但同时也是一个需要操作者具备高超技能的“吞金兽”）；²⁷claude-flow/Ruflo（约3.1万颗星）以 queen/worker 层级结构封装集群；LangGraph 风格的引擎则在上层引入类型化状态机，并将Claude Code置于节点内部。

Cherny 对这条演进路线的正式概括是AI 采用阶梯，由Anthropic于2026年7月发布：设卡阶段（0个 agents）→ 辅助阶段（约1个）→ 并行阶段（约10个）→ 监督式自治阶段（约100个，其中“大多数 agents 由Claude而非人类启动”）→ AI 原生阶段（1,000个以上）。他的建议是：“在每个阶段……都需要找出并突破下一批瓶颈，同时建立下一批防护措施。”²⁸

验证工程

以上内容都只是管道。本节才是产品的核心。

Anthropic的升级阶梯，摘自当前的最佳实践文档：为Claude提供一个能够得出通过或失败结果的机制，“循环就会自行闭合”→ 由独立评估器重新检查/goal条件 → 使用 Stop hook 作为“确定性关卡”→“由验证 subagent 或能够自查发现的动态工作流，让一个全新模型尝试推翻结果，从而避免由执行工作的 agent 自行评分”。²⁹与之配套的证据规范是：“让Claude展示证据，而不是直接断言成功。”

3类反馈，出自 Agent SDK文章：基于规则的反馈（“为输出明确定义规则，然后说明哪些规则未通过以及原因”——这是最佳形式）、视觉反馈（截图、像素差异）以及LLM-as-judge（模糊的评分标准——用Anthropic的话说，“通常不是一种非常稳健的方法”）。⁷应按此顺序优先选用；只要存在确定性检查，它就胜过仅凭观点判断的评审器。

收敛条件。Yoko Li 于2026年8月发表的分析，是对循环最为犀利的批判性论述。她将收敛归结为4项要求：明确的目标状态、可观察的当前状态、精准的局部编辑，以及位于生成器之外的停止规则。她在仪器化实验中得出的数字值得铭记：循环所消耗的 token 中，有67%未产生任何改进，因为没有任何机制告诉循环，收益已经呈对数式递减。³⁰预算上限不仅是成本控制措施，也是最后一道停止规则。

测试完整性。根据Anthropic的长时间运行 agents 准则：“删除或编辑测试是不可接受的，因为这可能导致功能缺失或存在缺陷。”²²循环会钻规范的空子——通过可见测试，却违背隐藏意图——因此，验证器本身也需要受到保护，不能任由其所评判的 agent 修改。

评估结果，而非路径。根据 evals 文章：“评估 agent 产出的结果，而不是它采用的路径。”对于客观标准，使用基于代码的评分器；对于评分规则，则使用基于模型的评分器。同时还要进行校准：“除非阅读多次试验的记录和评分，否则无法知道评分器是否运作良好。”³¹

还有一个常被相关讨论忽略的区别：如果循环中的每项检查都是确定性的，那么循环中根本不该使用模型。比较时间戳的漂移监视器、链接检查器、构建哨兵——这些都应当是按计划运行的 shell 脚本：不消耗 token、每次仅需数秒，而且完全可重复。只有当迭代确实需要判断时，才应使用模型驱动的循环。最便宜的循环，就是从不调用模型的循环。

成本与安全规范

社区对循环工程最强烈的反对意见是成本，而各种事故复盘也印证了这一点：生成 subagent 的缺陷在5分钟内烧掉400万 token；通宵循环耗费数千美元；使用限额“比预期快得多”地耗尽。³²此后，其中一道限制已经发生变化：从 v2.1.234 起，当 claude.ai 使用限额重置时，会话会自动继续（可在/config→“Continue automatically at usage limit”中关闭）——过去在达到限额后便会终止的通宵循环，如今会在时间窗口重新开放时恢复运行。这使得下列预算控制措施更加重要，而非无关紧要。³³由此形成的规范如下，每一项都对应已发布的控制措施：

最后一行值得单独展开，因为这正是最激进的从业者保障安全的方式：将 pull request 设为影响范围的边界。Cherny 长期运行的后台 agents——一个持续改进架构，另一个寻找重复抽象——无需人工触发便会提交 PR；²未经审查，任何内容都不会合并。对于持续运行的循环，如果最坏情况只是“出现一个未合并的分支”，便可以高强度运行；但直接写入 main 的循环绝不可以。应循序渐进地推广循环：先从仅观察模式开始（生成报告，不执行写入），通过一次次平淡无奇的运行建立信任，再升级为提出变更——而且必须在安装计划任务之前，写明顺序证明（“仅在验证返回新标记后才运行清除操作”）和详尽无遗的影响范围声明。这条升级路径的经济学原理，正是验证成本低廉之处，循环方能取胜一文的主题：决定哪些任务可以无人值守运行的，是验证成本，而非循环构建成本。

最深层的反对意见并非成本，而是审查能力——循环生成代码的速度，超过了人类进行实质性审查的能力。³⁴对此没有什么巧妙的答案，只有诚实界定范围：无人值守循环仅适用于验证可由机器执行的场景，除此之外概不适用。“如果无法验证，就不要发布。”²⁹

运行一支 Fleet

loop engineering 的终局并非单个 loop，而是一支常备 fleet。以下是这套实践稳定后的形态：

• 以文件形式保存规格。 每个 loop 都是一份受版本控制的规格——名称、层级、计划、目标、验证器、允许使用的工具、预算和超时设置——存放在其服务的代码库中。如果同一项手动检查已经执行了3次，就应将其转化为规格。
• 双层级，晋级靠实绩。 Observe loop 可以读取任何内容，但只能写入自己的报告目录，并可立即加入计划。Act loop 会影响外部环境，因此必须先提供执行顺序证明、影响范围声明，以及并非由制作者担任的验证器——这些都必须在计划创建之前写好。loop 均从 observe 起步，满足要求后方可晋级。
• exec/model 分工。 确定性检查以脚本运行（零 token，耗时1–2秒）；model loop 仅用于需要判断的任务。fleet 的每日心跳可以不产生任何费用。
• 报告契约。 每项检查占一行，格式为 PASS|FAIL <check>: <reason>，并追加到按日期命名的报告文件中。如果无法定义一眼可辨的 PASS 行，该 loop 就尚未就绪。digest loop 会读取整支 fleet 的报告，让人只需查看一页，而非30页。
• 自维护基线。 最优秀的漂移监控器会从其守护的产物中推导预期值——例如指南自身记录的时间戳、锁文件自身的哈希值。这样，更新产物也会同步更新监控器，不会留下容易被遗忘的第二事实来源。
• 经得起时间考验的计划机制。 本地 fleet 使用操作系统计划程序（launchd、cron、systemd timers）调用 runner 脚本；云端 fleet 则使用 routines。与会话绑定的 loop（/loop）适用于您在场监督的工作。

这正是 Cherny 所说的“我的工作是编写 loops”的具体实践：人的工作转向定义检查、验证器和预算，并阅读报告。

最值得优先构建的两个 Loops

如果从零开始组建 fleet，有两个 loop 能立即带来回报——它们都已在本站自身的 harness 中得到验证：

gate loop——针对任何待发布内容的 maker-checker 机制。一个全新的 evaluator（不保留前几轮的记忆）根据明确标准对产物评分；您处理其指出的每一项问题；再由新的 evaluator 重新评分；达到标准或触及硬性轮数上限后，loop 停止。在涵盖15篇文章的一轮冲刺中，我们得到两条实战经验：修复可能引入新的缺陷（某一轮修复错误归因了一项数据，下一轮 evaluator 才将其发现）；而且 evaluators 在两个方向上都可能出错——其中一个曾信心十足地“纠正”一项真实陈述。因此，具体修改在应用前必须回到来源核实。checker 不是权威，来源才是。

groundskeeper——act 层级的入口。每次运行只完成一项小型、可客观验证的修复；在分支上操作；测试全部通过后才创建 PR；loop 永不自行合并。两条规则保障其安全：任何存在歧义的问题都应标记，而非修复（首次受监督运行正确地拒绝处理一项检测器误报）；main 上原有的失败必须如实报告，绝不能纳入 loop 的差异中。

有一项 fleet 运维细节值得借鉴：为无人值守的 model loop 配置 session lease——同一代码库中存在活跃的交互式会话时，推迟所有运行。两个写入者共用一个 checkout，迟早会出现提交交错；lease 从机制上确保 loop 主动让位于人。

常见问题

什么是 loop engineering？

这是一种让 AI agents 反复执行工作周期，直至满足停止条件的实践，而不是由人逐轮向其发出提示。工程师的职责从编写提示转向设计 loop：再次触发规则（条件、计划或事件）、迭代之间的状态、验证器和预算。Anthropic 于2026年6月为这一领域命名；其 Claude Code 交互界面包括 /goal、/loop、Ralph plugin、routines 和 dynamic workflows。

什么是 Ralph loop？

这是一种由 Geoffrey Huntley 于2025年7月命名的强力自治模式：在 shell while loop 中运行 Claude Code，每次迭代都以全新上下文向其传入同一提示；由进度文件和 git 在各轮之间传递状态，并由测试形成反向约束。Anthropic 提供官方 ralph-wiggum plugin，通过 Stop hook 在会话内执行循环，并将 --max-iterations 作为主要安全机制。

如何让 Claude Code 循环运行？

请选择满足需求的最低层级：使用 /goal <condition> 反复迭代，直至独立 evaluator 确认条件成立；使用 /loop <interval> <prompt> 在会话保持打开期间定期运行；使用 /ralph-loop 针对单项任务持续迭代，直至兑现完成承诺；使用 /schedule 创建按 cron 运行的云端 routine，无须本机在线。在无头模式下，经典做法是在 shell loop 中运行 claude -p，并配合外部检查。

loops 会取代提示吗？

提示不会消失，只是换了位置。您只需将其写入 loop 的规格一次，loop 就会反复触发它；越来越多的情况下（dynamic workflows，以及 Cherny 所说的“实际上是另一个 Claude 在执行提示”），由编排 agent 为每项任务编写提示。作为人的核心技艺，取代提示雕琢的是验证设计：明确机器或全新 model 能够检查的条件。

Claude Code 中的 loop、routine 和 workflow 有何区别？

loop（/loop）会在本地会话内按计划重新运行提示，并随会话结束而终止。routine 是将同一理念封装后运行在云基础设施上——可由 cron、API 或 GitHub 事件触发，无须笔记本电脑在线。workflow 是单次运行的编排图：由 Claude 编写的 JavaScript 脚本，可生成并协调多达1,000个 subagents；loops 和分支逻辑保存在代码而非上下文中。

agent loops 的成本是多少？

如实说，范围从“零成本”到“代价惨重”，关键变量在于设计。确定性监控器不产生费用——它们只是按计划运行的脚本。model loop 按迭代计费：为其设置上限（--max-iterations、--max-budget-usd），让收益可观察，以便 loop 在边际收益递减时停止；将每项上限都视为停止规则，而非碍手碍脚的限制。那些失败复盘——一夜耗费数千美元、几分钟消耗4M token——都有同一个根本原因：缺少外部停止条件。

loop 应在何时转变为 graph？

当并行工作出现依赖关系时：一项任务需要另一项任务的输出，或者两个 agents 会修改相同文件。loops 处理一个代码库和一个目标；graphs（dynamic workflows、agent teams、external orchestrators）则加入依赖顺序、文件认领和合并规范。只有在确实发生冲突时才应引入 graphs——额外结构会增加可观察性和设置方面的成本。

更新日志