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

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

什么是 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 scheduled task (formerly a 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月提出的分类法；这是目前对该领域最清晰的独立梳理。¹¹）

在环级 3 与环级 5 之间还有一个本地选项：Desktop 定时任务无需打开会话即可在您的机器上运行；由 Claude 设置时，间隔最短可达 1 分钟（通过表单设置时为 1 小时）。文档建议“在需要访问本地文件和工具时”使用它们。¹²

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

Loop 的各种形态详解

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

/goal——evaluator-optimizer loop

/goal <condition> 会让 Claude 持续工作，直到条件成立：“每轮结束后，一个模型会检查条件是否成立。如果该模型判定条件尚未满足，Claude 将开始新一轮，而不是把控制权交还给您。”⁹ 在底层，“/goal 是对一个会话级、基于提示词的 Stop hook 的封装”，因此只要 hooks 被关闭（disableAllHooks，或托管设置中的 allowManagedHooksOnly），它就无法使用。evaluator 是您配置的小型快速模型，它会返回以下三种判定之一，每种都附带简短理由：⁹

它也能以 headless 模式运行：claude -p "/goal ..." 会执行 loop 直至完成。

编写提示时应注意：条件要可观察（如“测试通过”“端点返回 200”“TypeScript 错误为零”），而不能只是愿景（如“代码很整洁”）。含糊的 verifier 无法为 loop 指明方向。况且，一份充满自信的执行记录可能说服由模型判断的条件同意任务已经完成，因此只要存在机器检查，就应将其与 /goal 配合使用。¹¹ 文档直接点明了这一局限：evaluator“不会独立运行命令或读取文件，因此请把条件写成 Claude 自身输出能够证明的内容”。⁹ 停止规则也应写进条件之中：像 or stop after 20 turns 这样的子句会与条件的其余部分一并判断，条件最长可达 4,000 个字符。如果 Claude 连续数轮只回应 evaluator 而不使用任何工具，Claude Code 会停止 loop 并将控制权交还给您，goal 仍保持设置状态。⁹

失败处理最初在 v2.1.234 中得到加强，³⁴ 如今已覆盖一轮可能失败的所有情形：

当桌面应用或云端会话等宿主负责管理凭据时，身份验证失败不会清除 goal，因为宿主会自行恢复访问。此外，当后台工作让 goal 处于等待状态时，Claude 会在 30 分钟后检查一次，1 小时后再检查一次，此后每 2 小时检查一次；在您的两次提示之间，最多发起三次空闲检查（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.md（项目中的 .claude/loop.md 优先，或 ~/.claude/loop.md）；“对 loop.md 的修改会在下一次迭代时生效”，超过 25,000 字节的内容会被截断。¹²

真正需要注意的限制是：/loop 依附于正在运行的 Claude Code 进程。“任务只会在 Claude Code 正在运行且处于空闲状态时触发。”退出后，任务便不再触发；将会话转入后台，loop 无需终端也会继续运行；使用 --resume 或 --continue 恢复会话时，通过 CronCreate 安排的任务会随之恢复，但自主安排节奏的 /loop 不会恢复，需要重新运行。¹² 对于必须在会话结束后继续运行的工作，文档比较了三种形态：¹²

需要在机器关闭时运行的工作，正是云端定时任务的用武之地。

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

Anthropic 官方的 ralph-loop plugin 将社区最常用的暴力迭代模式产品化。自 2026年1月6日起，它在 anthropics/claude-plugins-official 仓库中的名称就是 ralph-loop；当天，Anthropic “根据法律意见”将其从 ralph-wiggum 更名。2026年10月26日，claude-code 仓库删除了自己那份过时的 ralph-wiggum 副本，其 marketplace 现在从官方仓库安装 ralph-loop，因此“现有的 plugin id 仍可正常使用”。¹⁴ 其机制是：Stop hook 会拦截 Claude 结束会话的尝试，并重新注入提示词，使模型在同一会话中持续迭代。使用 /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" 启动；使用 /cancel-ralph 中止。README 明确指出，--max-iterations 是“您的主要安全机制”——精确字符串完成匹配可能永远无法成功。¹⁴ 所有基于 Stop hook 的 loop 之下都有一项 harness 限制：“如果 hook 连续阻止八次停止，且其间没有任何工具调用，Claude Code 会覆盖下一次阻止并结束该轮”（可通过 CLAUDE_CODE_STOP_HOOK_BLOCK_CAP 提高上限）。²⁹ 这能终止已经停滞不前的 loop，却无法终止持续调用工具的 Ralph loop，因此迭代上限依然重要。

动态 workflows——Claude 编写 graph

动态 workflows 随 Claude Code v2.1.154（2026年5月）推出，并在 Anthropic 于 2026年6月2日发布的文章中得到详细介绍。这是概念上最大的一次飞跃：“Claude 现在可以即时编写自己的 harness，为当前任务量身定制。”¹⁵ 您可以描述任务、说“use a workflow”，或加入关键字 ultracode；Claude 就会编写一段 JavaScript 编排脚本：其中 agent() 可生成带有可选 JSON-schema 输出的 subagent，pipeline() 为列表中的每个项目各运行一次，parallel() 同时运行一组任务，而普通的 await、loops 和条件语句负责控制流程；随后由运行时在后台执行。/effort ultracode 更进一步：Claude 会“为会话中的每一项实质性任务规划一个 workflow”，而这样的会话“会比关闭该选项完成同样工作时更快达到会话或每周限额”。¹⁶ “workflow 将计划转化为代码……workflow 脚本自行承载 loop、分支和中间结果，因此 Claude 的上下文只需保留最终答案。”¹⁶

根据文档，限制与形态如下：¹⁶

保存到 .claude/workflows/ 的脚本会成为可重复使用的斜杠命令。Claude 重新启动某次运行时，会从已保存的 agent 结果处恢复；但失败的 agent“会重新运行，脚本在它之后启动的每个 agent 也会重新运行，即使它们已经完成”，而您在运行中途转入后台或退出的运行“不会自行继续”。¹⁶

其标志性拓扑结构是 fan-out / refute / converge：先由相互独立的 finders 展开搜索，再由收到反驳指令的对抗性 verifiers 审查每项发现，持续迭代，直至答案经受住质疑。Anthropic 现在直接提供了这种拓扑的一个实例：内置的 /deep-research workflow 会“从多个角度就一个问题展开网络搜索，获取并交叉核对找到的来源，对每项论断进行投票，并返回一份附带引用的报告，未通过交叉核对的论断会被过滤掉”；当其 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月以研究预览版形式加入；文档现在表示“Agent teams 仍处于实验阶段，默认处于禁用状态”）：由一名 team lead 和多名 teammates 组成，后者“各自在独立的上下文窗口中自主工作，并能彼此直接通信”。这是一种 peer graph，而非 subagent tree；它通过带有依赖关系的共享任务列表、文件锁定认领机制以及每个 agent 独立的邮箱进行协调。由 Hook 强制执行的质量关卡会在 teammate 与“完成”状态之间加入机器检查：TaskCompleted 返回退出代码 2 时会阻止完成，TeammateIdle 返回退出代码 2 时会让 teammate 继续工作。¹⁷ 启用前需要了解两项行为：启用 agent teams 后，“由 Claude 命名的 subagent 会以 teammate 身份启动，因此即使您没有要求，也可能形成团队”；并且“teammate 无法代表您批准权限提示或给予同意”。¹⁷

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

云端定时任务（原称 routine）是“保存好的 Claude Code 配置：包含一个提示词、一个或多个代码仓库以及一组 connectors，只需打包一次，之后即可自动运行”，既可在 Anthropic 管理的云端基础设施上执行，也可在您组织的 self-hosted 环境中执行。¹⁸ 在更名会造成破坏的地方，旧名称仍然保留：网址（claude.ai/code/routines）、/schedule 的别名 /routines，以及 /fire API 路径。支持 3 种可组合的触发类型：计划（循环执行时最短间隔 1 小时，也可在指定时间一次性运行）、API 触发（POST .../routines/{id}/fire）以及 GitHub 事件。可通过 /schedule、Desktop 应用或 claude.ai/code/routines 创建。每次运行的会话都以自动模式启动，除非自动模式不可用；分类器会允许或阻止每项操作，在某些情况下运行会停下来等待，例如遇到即使在自动模式下也会请求确认的操作（ask 规则），或操作被反复阻止。正因如此，文档中的这条警告至关重要：运行结果说明的是“会话如何结束，而不是 Claude 是否完成了提示词所描述的工作，因此请打开该次运行并阅读执行记录，了解实际发生了什么”。¹⁸ 自 9月以来的两项修复表明，这一差距确实存在：在 v2.1.286 之前，云端会话从未启动的运行会显示为 Succeeded；在 v2.1.302 之前，运行会“在其云端会话意外停止后显示为 Completed”。³⁶ 同一版本还修复了中途失败的运行被从头重新运行的问题，这种情况“可能重复执行某些工作，例如将同一份报告发布两次”，这也提醒我们应让被触发的工作具备幂等性。³⁶

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

配套机制

Background subagents（自 v2.1.198 起默认启用）会让委派的工作保持在您的上下文之外；可通过 /agents 面板进行监控。Cross-session messaging（v2.1.224）借助 SendMessage 将相互独立的会话组成消息传递 graph，其安全原则值得借鉴：来自另一会话的消息“绝不代表您已经同意”。¹⁹ 从连接到 Remote Control 的会话出发，它还能触达您在其他机器上（v2.1.225+）以及云端的会话。为了在 loops 之间等待，可使用 notify_when_idle 输入（v2.1.236+）³⁶ 请求本机上的某个会话在下次进入空闲或退出时发送一次通知；Claude Code 会订阅该通知，“既不会在被监视的会话中启动新一轮，也不会消耗 tokens”。¹⁹ 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个仓库）也伴随着同样明确的局限：仅适用于从零开始的项目，占位实现和重复实现是反复出现的失败模式，而且“LLM是操作者能力的镜子”。

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

为什么全新上下文优于一次长会话：随着会话上下文逐渐填满，执行效果会下降——实践者普遍认为，偏移大约从10万token开始出现——而压缩摘要是有损的转述，会将错误包装成语气笃定的文字。²⁴ Ralph采用“全新启动加文件”的设计，绕开了这两个问题。（官方插件为方便使用而采用会话内循环，牺牲了部分优势；对于长时间运行的任务，结合外部状态的无头运行形式仍然是更有力的模式。）

这一模式的反面案例同样值得借鉴：一位实践者用含糊的提示词运行插件，并设置了max_iterations: 0——这表示无限次，而不是禁用——结果Claude向自己重复提出了1,966次相同的澄清问题，Stop hook劫持了此后的每一条消息。²⁵ 迭代次数上限不可省略。

当循环演变为图

单个循环假设各轮迭代彼此独立，或严格按顺序执行。一旦并行工作存在依赖关系——任务B需要A的输出，两个智能体会编辑同一个文件——自由运行的循环就会相互冲突，此时必须引入明确的结构：带有依赖数组的任务列表、文件认领机制、合并规范。这才是循环与图之争的实质：一个仓库、一个目标时用循环；并行工作需要安排先后顺序时用图。²⁶

按所需基础设施由少到多，可选择以下图结构方案：

1. 动态工作流——在JavaScript控制流中表达依赖关系；只有某个阶段确实需要全部前置结果时，才设置同步屏障。Anthropic列出的拓扑包括：扇出并综合、对抗式验证、生成并筛选、锦标赛（“启动N个智能体，让它们分别用不同方法尝试同一任务”，然后两两评判），以及循环直至完成。¹⁵
2. 智能体团队——使用支持依赖跟踪的共享任务列表；负责人处于计划模式时生成的队友会提交计划以供审批，由Claude Code自动批准；只有当您将正在运行的进程内队友切换到计划模式（Shift+Tab）时，负责人才会审查该计划；图以数据形式存在，而非代码。¹⁷ 这一模式下有一项默认行为已改变，最早见于v2.1.233：³⁴ 任务跟踪工具（TaskCreate、TaskGet、TaskUpdate、TaskList、TodoWrite）现在“仅在Opus 4.7、Sonnet 4.6、Haiku 4.5及更早的模型上默认可用”，这一默认集合自v2.1.268起适用。³⁸ 没有这些工具的智能体“通过消息协调，而不是通过共享任务列表”，¹⁷ 因此在普通本地会话中使用当前模型时，除非主动启用，否则任务列表并不存在；后台会话和云端会话则在所有模型上都提供这些工具。³⁸ 可通过CLAUDE_CODE_ENABLE_TODO_TOOLS=1、--allowedTools TaskCreate或列出这些工具的--tools列表启用。导出的环境变量不会传递给分屏队友，因此若要为其提供这些工具，请使用claude --settings '{"env":{"CLAUDE_CODE_ENABLE_TODO_TOOLS":"1"}}'启动负责人。³⁸
3. 外部编排器——社区的横向扩展方案：Steve Yegge的Gas Town运行20至30个Claude Code实例，围绕由git支撑的“beads”所组成的DAG执行任务（17天内写出7.5万行Go代码，但按他自己的说法，它也是一个要求操作者具备高超能力的“吞金兽”）；²⁷ claude-flow/Ruflo（约3.1万颗星）以女王/工人的层级结构组织智能体集群；LangGraph风格的引擎则在上层引入带类型的状态机，将Claude Code放在节点内部。

Cherny本人将这一发展路径正式归纳为AI采用阶段阶梯，并于2026年7月通过Anthropic发布：设有审批关卡（0个智能体）→辅助（约1个）→并行（约10个）→受监督的自主运行（约100个，此时“大多数智能体由Claude启动，而非人类”）→AI原生（1,000个以上）。他同时建议：“在每一个阶段……您都需要找出并突破下一组瓶颈，建立下一组防护措施。”²⁸

验证工程

上文所述都是基础设施。这一节才是产品本身。

Anthropic的逐级升级路径，摘自当前最佳实践文档，从一条建议出发：“给Claude一个它能够运行、并会返回通过或失败结果的东西。有了它，Claude就能自行持续工作，您也无需一直盯着。”随后，各级从由Claude决定逐步过渡到由harness强制执行：一行提示（run the auth tests after, and keep going until they pass）→一个/goal条件，“由另一个独立模型在每轮结束后对照对话内容进行检查”，这“对于长时间的后台运行很重要，因为Claude有时会在仍有事项未完成时，以一段进度总结结束一轮”→一个Stop hook，“由Claude Code（即harness）强制执行，因此在类型检查通过或达到阻止上限之前，该轮不会结束”→“由未编写该代码的人”进行审查，其中/code-review“会在一个从未见过您对话的全新subagent中审查差异。它不会被产生这些代码的推理所左右。”²⁹ 与之配套的证据准则是：“请Claude出示证据：它运行的命令及其输出，或截图”，因为“对于您没有盯着的会话，这也是您仅有的证据”。²⁹ 这条阶梯过去以对抗式反驳收尾，如今这一级改由工作流文档承载，其中的示例提示要求工作流“在报告前对每项发现进行对抗式验证”。¹⁶

同一文档将每条指令分为两类：由Claude决定的，以及由Claude Code强制执行的。其中有三行正是循环的停止、预算和合并规则：²⁹

无人值守的循环需要在每一行中都有一项来自右栏的内容；没人写下这些时，循环就只剩左栏。该文档还摒弃了一种提示习惯：诸如“keep going, loop until done, don’t be lazy”之类的语句“更可能导致过度工作，而不是解决停滞”，而且“对于无人盯守的运行，应由/goal或Stop hook来强制执行”。²⁹

三类反馈，出自Agent SDK一文：基于规则的反馈（“为输出定义明确的规则，再解释哪些规则未通过以及原因”——这是最佳形式）、视觉反馈（截图、像素差异）以及由LLM担任评判者（采用模糊的评分标准——用Anthropic的话说，“通常不是一种很可靠的方法”）。⁷ 应按这个顺序优先选用；切实可用的确定性检查，胜过只发表看法的评判者。

收敛条件。 对循环最犀利的批判性分析——Yoko Li于2026年8月发表的文章——将收敛归结为4项要求：明确的目标状态、可观测的当前状态、精确的局部修改，以及位于生成器之外的停止规则。她通过测量实验得出的数字值得记住：循环中67%的token开销没有带来任何改进，因为没有任何机制告诉循环，收益已进入对数增长阶段。³⁰ 预算上限不仅用于控制成本，也是最后一道停止规则。

测试完整性。 Anthropic关于长时间运行智能体的指导原则指出：“删除或修改测试是不可接受的，因为这可能导致功能缺失或存在缺陷。”²² 循环会钻规格说明的空子——通过可见测试，却违背隐含意图——因此，验证器本身也必须受到保护，不能任由其所评判的智能体修改。

评判结果，而非路径。 评估文章指出：“应评判智能体产出了什么，而不是它采取了什么路径。”客观标准应使用基于代码的评分器，评分量规则应使用基于模型的评分器，并进行校准：“只有阅读大量试验的交互记录和评分，您才能知道评分器是否工作良好。”³¹

还有一个常被相关讨论忽略的区别：当循环中的每一项检查都是确定性的，循环中根本就不需要模型。 比较时间戳的偏移监测器、链接检查器、构建监测器——这些都只是定时运行的shell脚本：不消耗token，每次运行只需几秒，结果完全可重复。只有需要判断力的迭代，才应交给模型驱动的循环。成本最低的循环，是从不调用模型的循环。

成本与安全纪律

社区对循环工程最强烈的质疑是成本，事故复盘也印证了这一点：一个生成subagents的缺陷在5分钟内消耗了400万tokens；整夜运行的循环花掉数千美元；用量上限“比预期快得多”就触达了。³² 其中一道限制此后发生了变化：自v2.1.234起，claude.ai用量限额重置后，会话会自动继续（对应autoContinueAtUsageLimit设置；可在/config → “Continue automatically at usage limit”中关闭）。³⁴³⁷ 但适用范围很窄。“在使用claude.ai订阅登录的交互式会话中，自动继续默认开启”；对于“24小时以上才会重置的限额”（例如每周限额），Claude Code不会自行开始等待；退出Claude Code即结束等待；而在“后台会话和-p运行”中，Claude Code“根本不提供等待选项”，这涵盖了无头Ralph和claude -p "/goal ..."。³⁷ 在符合条件的会话中，循环会遵循这一机制：暂停的/goal会在重置时恢复；⁹ 自v2.1.271起，工作流运行会等待限额解除，而不是让其智能体失败，每次运行最多等待两次。¹⁶ 留在打开的交互式会话中的夜间循环，如今可以撑过上限；以无头方式或在后台会话中运行的循环，仍会在上限处停止。因此，下述预算控制措施变得更加重要。实践中逐渐形成了以下纪律，每一项都有已发布的控制机制与之对应：

最后一行值得单独展开，因为实践最激进的人正是靠它保障安全：将影响范围限制在拉取请求内。 Cherny常驻的后台智能体，一个持续改进架构，一个寻找重复抽象，无需人工触发便会提交PR；² 但未经审查，任何内容都不会合并。一个最坏结果只是“留下未合并分支”的常驻循环，可以放手运行；直接写入main的循环则不行。云端定时任务将这一做法设为默认：“除非您的提示要求推送到其他分支，否则Claude会将工作推送到以claude/为前缀的分支”，而GitHub分支保护或规则集决定了一次运行能推送到哪里。¹⁸ 应逐步扩大循环的权限：先只观察（生成报告，不执行写入），通过一次次平稳运行赢得信任，再升级为提出变更——并且要在设置调度之前，写明执行顺序的证明（“只有验证返回新标记后，才执行清除”）以及完整的影响范围声明。验证成本低的地方，循环更有优势讨论的正是这条晋级路径背后的经济性：决定哪些工作可以无人值守运行的，是验证成本，而非循环的构建成本。

任何循环输入都不算同意。 四条有据可查的规则彼此呼应：来自另一会话的消息“绝不代表您已经同意”；¹⁹ 队友“无法代表您批准权限提示或给予同意”；¹⁷ 云端定时任务被触发时收到的提示“不能在运行期间充当对操作的批准或同意”，而随API触发发送的文本“会被包裹在<routine-fire-payload>块中，标记为不可信数据”；¹⁸ 在自动模式下，工作流脚本传给agent()的提示“不算作来自您的请求”，因为“Claude Code会将其标记为脚本计算得出的文本”。¹⁶ 不妨把这条规则照搬到您自己的循环中：机器生成的文本是数据，批准只能来自人。

更深层的质疑不是成本，而是审查能力——循环生成代码的速度，超过了人类能够有效审查的速度。³³ 对此没有巧妙的解法，只有如实限定范围：无人值守循环只适用于能够由机器验证的工作，其他地方都不适用。无法验证，就不要发布。

对照研究如何看待harness组件

大多数harness建议，包括本指南中的建议，都来自实践者在生产环境中逐项调整的经验。2026年9月，UMass Amherst、Emory、UNC Charlotte和Zoom开展了一项对照研究：他们专门构建了一个harness，“固定执行循环，仅改变3个组件：规划、动作空间和上下文管理”，使用4个开放权重模型，即3种规模的Nemotron-3和Mistral-Medium-3.5-128B，在SWE-Bench Verified和Terminal-Bench 2.1上测试了“176组匹配配置，涵盖5种上下文管理策略、4种上下文窗口预算，以及针对规划和动作空间的消融实验”。³⁵ 用作者的话来说，研究得出了4项发现：

• “上下文窗口预算越紧张，上下文管理的价值就越大，其大部分收益来自避免上下文溢出导致的失败。”
• “先按规则删减内容，再使用LLM进行摘要，在各类上下文管理策略中取得了最好的整体效率；而让已删减内容可恢复，则增加了模型很少使用的机制，却未带来准确率提升。”
• “对于较弱的模型，规划是提升准确率的支撑；对于较强的模型，规划则转变为节省成本的手段，对准确率影响很小。”
• “预定义工具能改善bash熟练度较低的模型的表现；而擅长bash的模型仅凭bash接口就能有效工作，并显著降低成本，在以命令行为主的任务中尤其如此。”

在我看来，其中3项发现直接适用于循环工程。上下文管理是防止溢出的保障：长期运行的循环应规划窗口预算，并在生成摘要前先删减冗长的工具输出；模型不会使用的回溯机制，则可以不建。对于能力较强的模型，规划主要用于调节成本，而非提高准确率。因此，在为使用强模型的循环增加规划阶段前，值得先了解这一点。而仅使用bash的结果，则是在更高一层印证了执行与模型分工的原则：当执行者能力足够强时，减少动作次数、增大单次动作范围，成本会更低。局限性也是研究自身指出的：仅涉及4个模型、2个基准，且harness是为实验专门构建的，并非任何已发布的智能体。因此，这些结果可以作为方向参考，不能直接照搬为配置。³⁵

运行循环集群

循环工程的最终形态并非单个循环，而是一组常驻循环。实践稳定后，大致会呈现以下样貌：

• 将规格写成文件。 每个循环都有一份纳入版本管理的规格，包含名称、层级、调度、目标、验证器、允许使用的工具、预算和超时，存放在它所服务的仓库中。如果同一项手动检查已经输入了3次，就应将其写成规格。Anthropic提供了这一理念的一个小型版本：loop.md文件可替换不带参数的/loop的内置提示，对它的修改会在下一次迭代时生效。¹²
• 两个层级，凭表现晋级。 观察级循环可以读取任何内容，但只能写入自己的报告目录，并可立即启用调度。执行级循环会对外部环境产生实际影响，因此必须在设置调度前写明执行顺序的证明、影响范围声明，并配备独立于产出者的验证器。所有循环都从观察级起步，通过表现赢得晋级。
• 执行与模型分工。 确定性检查交给脚本运行（零tokens，1–2秒）；模型循环专门负责判断。整个集群的每日例行检查可以不产生任何费用。
• 报告约定。 每项检查占一行，格式为PASS|FAIL <check>: <reason>，追加到按日期命名的报告文件中。如果无法定义一条一目了然的PASS记录，循环就还没准备好。汇总循环读取整个集群的报告，让人只需阅读一页，而非30页。
• 自行维护的基准。 最好的漂移监测器从受监测产物本身推导预期值，例如指南自身记录的时间戳、锁文件自身的哈希值。这样，更新产物便会同步更新监测依据，也就不会出现被遗忘的第二套事实来源。
• 持续可靠的调度。 本地集群通过操作系统调度器（launchd、cron、systemd timers）调用运行脚本，或在机器保持开启时使用Desktop定时任务；云端集群则使用云端定时任务（原称例程）。绑定会话的循环（/loop）适合在您在场时运行，或在已转入后台的会话中运行。¹²

这就是Cherny所说的“我的工作就是编写循环”的具体形态：人的工作转向定义检查项、验证器和预算，以及阅读报告。

最值得先构建的两个循环

如果从零开始构建循环集群，有两个循环能够立即体现价值——它们都已在本站的harness中得到验证：

把关循环——为所有待发布内容建立产出与检查分离的机制。一个全新的评估器（不记得此前轮次）按明确标准为产物评分；您处理每一项被指出的问题；再由新的评估器重新评分；达到标准或触及严格的轮数上限时，循环停止。在一次集中处理15篇文章的实践中，有两点值得记录：修复可能引入新缺陷（某轮修复误标了一项数据的归属，下一轮评估器才发现）；而且评估器会犯两个方向的错误——有一个评估器曾信心十足地“纠正”了一条真实陈述，因此，具体修改建议在应用前都要回到来源核实。检查者不是权威，来源才是。

维护循环——进入执行级的起点。每次运行只在分支上完成一项小规模、可客观验证的修复，测试全部通过后才创建PR，且循环绝不自行合并。两条规则保障其安全：凡有歧义，只标记，不修复（首次有人监督的运行就正确拒绝处理了检测器的一次误报）；main上原有的失败必须如实报告，绝不混入循环的差异中。

有一个集群运维细节值得借鉴：为无人值守的模型循环设置会话租约——只要同一仓库中有交互会话处于活跃状态，就推迟运行。两个写入者共用一个检出目录，迟早会发生提交交错；租约则从机制上确保循环为人让路。

常见问题

什么是循环工程？

循环工程是让AI智能体反复执行工作周期，直到满足停止条件，而非逐轮发送提示。工程师的工作从编写提示转向设计循环：再次触发的规则（条件、调度或事件）、迭代之间的状态、验证器及预算。Anthropic于2026年6月为这一实践命名；在Claude Code中，其对应功能包括/goal、/loop、Ralph插件、云端定时任务（原称例程）和动态工作流。

什么是Ralph循环？

这是一种由Geoffrey Huntley于2025年7月命名的暴力迭代式自主执行模式：在shell的while循环中运行Claude Code，每轮都使用全新上下文输入相同的提示，通过进度文件和git在各轮之间传递状态，并以测试提供背压。Anthropic提供官方ralph-loop插件（2026年1月由ralph-wiggum更名而来），通过Stop hook在会话内实现循环，并以--max-iterations作为主要安全机制。

如何让Claude Code循环运行？

选择满足需求的最低层级：用/goal <condition>持续迭代，直到独立评估器确认条件已满足；用/loop <interval> <prompt>在Claude Code会话运行期间定期运行；用/ralph-loop围绕单个任务迭代，直到给出完成承诺；用/schedule创建按cron调度的云端定时任务，无需本机保持运行。无界面运行的经典形式，是在shell循环中调用claude -p，并配合外部检查。

循环会取代提示吗？

提示不会消失，只是换了位置。您只需将它写入循环规格一次，循环便会反复触发；而且，越来越多时候，每项任务的提示由编排智能体编写（例如动态工作流，以及Cherny所说的“实际上是另一个Claude在编写提示”）。取代提示打磨、成为人类核心技艺的，是验证设计：明确写出机器或全新模型能够检查的条件。

Claude Code中的循环、例程和工作流有何区别？

循环（/loop）在本地Claude Code会话内按调度重新运行提示，该进程退出后便不再触发；转入后台的会话则会让它继续运行。云端定时任务（原称例程）则将同样的思路封装为在云端基础设施上运行的任务：由cron、API或GitHub事件触发，无需笔记本电脑保持运行。工作流是单次运行的编排图：由Claude编写的JavaScript脚本生成并协调最多1,000个subagents，循环和分支逻辑保存在代码中，而非上下文中。

智能体循环的成本是多少？

如实回答，范围是“从零到难以承受”，关键变量在于设计。确定性监测器不消耗模型费用——它们只是定时运行的脚本。模型循环则按迭代计费：设置上限（--max-iterations、--max-budget-usd），让收益可观测，以便在边际收益递减时停止，并将每个上限视为停止规则，而非碍事的限制。那些失败复盘——一夜花掉数千美元、几分钟消耗400万tokens——有着共同的根因：没有外部停止条件。

何时应将循环升级为图？

当并行工作开始出现依赖关系时：一个任务需要另一个任务的输出，或者两个智能体会修改相同的文件。循环处理单个仓库和单个目标；图（动态工作流、智能体团队、外部编排器）则增加依赖排序、文件认领和合并纪律。只有实际发生冲突时，才应引入图——新增结构会增加可观测性和配置方面的成本。

更新日志