你是否曾有过这样的体验——

提交代码后，CI 流水线需要运行 10 分钟。你不愿空等，于是切换到其他任务；10 分钟后返回查看，结果却是失败状态。修复、再次推送、再等待 10 分钟，依然报错。整个下午就这样被割裂成了碎片。

或者更糟糕的情况：测试套件中存在十几个偶发性失败的用例，你希望一次性修复完毕，但 Agent 一上来就试图同时修改十几个文件，导致改动混乱不堪，你不得不逐个回滚。

这两类问题的共同点在于：它们都属于“循环”性质的任务，而你始终在用“单次”处理的思路去应对。

2026 年，编码 Agent 领域最值得关注的范式转变，就是从“一次提示（prompt）”转向“让循环去执行提示（prompt）”。Claude Code 负责人 Boris Cherny 的一句话精准点明了本质：“我不再直接提示 Claude 了。我让循环去提示，我的工作就是编写循环。”

这个范式有一个专属名称——loop engineering（循环工程）。而 Claude Code 在 2026 年初推出的 /loop 命令，正是它的首个代表性工具。然而经过数月的使用，许多人要么完全不了解它，要么把它当作定时闹钟（cron）来用，要么一晚上就被它消耗光了 API 额度。

本文不仅要讲清楚“/loop 怎么用”——更希望通过它来透视整个编码 Agent 的循环革命：为什么需要循环、循环分为哪几个层次、Claude Code 的实现精妙在何处、其他 Agent 是否具备类似能力、以及如何真正高效地使用它。

一、为什么“单次”永远不够：循环的三个层次

要理解 /loop，首先得跳出 /loop 本身，看清“循环”的全貌。社区中讨论的“loop”实际上混杂了三种不同的概念，简单梳理一下，可以分为三个层级：

L1 是所有 Agent 的基本配置，这一点并不意外——只要是 Agent，就具备“推理→调用工具→观察结果→再次推理”的基础运作模式，这算不上特色。

L2 才是真正的分水岭。能够在同一会话中连续运行数小时、自主纠错、不达目标不罢休，这需要精心设计停止条件。

L3 是最难、也最稀缺的一层。它必须同时满足“按时间重复”和“跨迭代记忆”两个要求——而这两者的结合，恰好是 Claude Code /loop 所定位的位置。

请记住这个三层模型，它将帮助我们理解后续“各 Agent 的差异究竟在哪”。

二、/loop 到底妙在哪：不是“定时”，是“带记忆的定时”

很多人将 /loop 理解为“定时闹钟”：到点了，执行一次。这种理解只对了一半。

它与系统 cron 以及 watch 命令有一个本质区别，这句话值得强调：

对比两种方式就一目了然：

外部 cron 包裹 claude -p：每次 = 冷启动 + 上下文清零 agent 不知道上一轮做了什么，从头开始猜 /loop（会话内循环）：每次 = 同一会话 + 同一上下文 + 同一工具连接 agent 记得"上次试过方案 A 没用"，直接试方案 B

外部调度器最致命的问题是**“上下文在两次运行间蒸发”**；/loop 让会话保持存活，agent 能够逐步积累工作成果。

这才是 /loop 的核心价值——不是“定时”，而是“带记忆的定时”。

它是如何实现的

/loop 并非凭空创造的新事物，而是将已有原语组合成循环的最薄一层。整个流程如下：

你输入 /loop "每5分钟检查构建" ↓ Claude 解析自然语言 → 生成 cron 表达式（*/5 * * * *） ↓ 会话内调度器（CronCreate 工具）注册任务，返回 job ID ↓ 定时器到点 → 在【当前会话】触发该 prompt ↓ 同一上下文窗口执行（记得上轮）→ 工具调用 → 状态写磁盘 ↓ 循环，直到 Esc / 3 天到期 / 会话结束

也就是说，你用自然语言告诉它“每 5 分钟”，它内部将其转换为 cron 表达式，然后借助会话内的调度器按时触发。底层是 CronCreate 这类 cron 工具，/loop 则是面向用户的上层封装。

这里面有四个设计细节，每一个都值得深入思考，因为它们揭示了“为什么 /loop 是这样设计的”：

• 会话级作用域。循环存在于当前会话之中，而非后台守护进程。这是有意为之——用“不持久”换取“安全与可预测性”：没有孤儿进程在凌晨 3 点消耗你的 API 额度，关闭终端即停止循环。代价是不够耐用，如需跨重启则需要另寻方案。
• 持久上下文。这是核心卖点。同一会话 = 同一上下文 + 同一 MCP 连接，这正是它碾压外部 cron 的根本原因。
• 10% 时间抖动（jitter）。给你的设定间隔最多增加 10% 的随机偏移。例如设置 10 分钟循环，实际触发时间可能在 9:12、10:48、9:36 等时刻。为什么？如果一千个开发者都设置“每 10 分钟”，就会在同一秒内同时调用 API，形成访问尖峰。抖动将负载均匀分散——这与指数退避的原理相同，只是预防性地提前应用了。
• 守护机制。72 小时硬性上限、1 分钟最小间隔、可被组织整体禁用。这些安全护栏说明 Anthropic 非常清楚：自治循环一旦失控，代价是实实在在的资金消耗。

别与 /goal 混淆

讲到 /loop 就不得不提 /goal，它们是两种不同的循环原语，极易混淆：

/goal 有一个精巧的设计：判断“是否完成”的是另一个独立的小模型，而非正在执行任务的那个模型。这实现了“制作/检查分离”的理念，并应用到了停止条件本身——防止 agent 自我评价“已完成”而草率收尾。一个负责“如何执行”，一个负责“是否足够”，分工明确。

三、实战：什么情况用、怎么用、如何避免踩坑

理论已经清楚了，现在回到实操层面。本节提供可直接上手的内容。

一条判断标准：三个问题

是否需要使用 /loop？问自己三个问题：

1. 这个任务需要重复执行吗？ —— 不需要，直接用普通 prompt 即可。
2. 每次执行需要记住上次的状态吗？ —— 不需要，用外部 cron 包裹 claude -p 即可。
3. 我会一直保持这个会话开启吗？ —— 不会，那就别用 /loop，改用 GitHub Actions。

三个问题都回答“是”，才使用 /loop。最后一条尤其重要——记住它是会话级别的，关闭窗口就会停止。

五个可以直接照搬的示例

示例 1：盯着 CI 直到变绿（最经典）

/loop 5 minutes 检查当前分支的 CI 状态，如果失败，读取错误日志、修复、提交，直到变绿

提交代码后挂上这个循环，然后去忙其他事情。可能第一次修复仍报红——没关系，它记得上次尝试过什么，会换一种思路继续尝试。等你回来时，大概率已经是绿色状态。

示例 2：整夜修复测试（高阶用法）

/loop 10 minutes 运行 npm test，逐个修复失败的测试并提交，每轮只处理一个，避免改动过大

注意最后半句——“每轮只处理一个”。这是使用 /loop 最重要的防坑技巧。不加这句，agent 可能在一轮中试图修复所有问题，导致改动混乱；明确“每轮一个”，它就能稳扎稳打。睡一觉醒来，提交历史里往往已经安静地修复了好几个问题，每个独立提交，干净利落。

示例 3：定时汇总到文件（配合 MCP 连接 GitHub）

/loop every 2 hours 拉取最近的 commit 和 PR 更新，追加汇总到 DAILY.md 的新日期段落下

每次拉取最新状态，累积写入文件。它记得“已经写过哪些内容”，不会重复。

示例 4：等待 PR 评论

/loop 15 minutes 检查我的 PR #123 的最新评论，如果有，根据评论意见修改代码并回复说明改了什么

提交 PR 后去忙其他事情，reviewer 留下意见后，它就会开始处理。同样依靠“记得已回复哪些评论”来避免重复操作。

示例 5：可验证终态使用 /goal

/goal 运行到所有测试通过、lint 干净，然后停下告诉我

这个场景应当使用 /goal 而非 /loop——因为你需要的是“运行到条件满足”，而非“按时间重复”。

防坑清单

以下都是实践中常遇到的坑：

最后一条尤其要强调——状态写入磁盘。长时间运行的 agent，每次迭代都可能“遗忘”部分信息（上下文有上限）。因此所有重要的进度、待办事项、决策，都必须记录在一个 markdown 文件中，而不是仅存在于对话上下文中。这是 loop engineering 的核心原则之一：agent 会遗忘，但仓库不会。

四、其他 Agent 有 loop 吗：一张图看清能力光谱

如果你不使用 Claude Code，自然会问：其他工具有类似能力吗？用第一节的三层模型来衡量，答案很清晰：

能力强 ●━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━● 能力弱/无 Claude Code Codex CLI OpenCode Reasonix Aider Gemini/Cursor （原生 L3 （L2 自治 （L3 靠插件） （L2 为常驻 （L2 局部） （L1， 需自配 cron） 定时+持久） 数小时） 而生）

关键结论是那句话：L3 这一层，目前只有 Claude Code /loop 做成了原生的、一等公民的功能。 其他工具的处境各不相同：

• Codex CLI —— 自治能力最强。OpenAI 官方专门提供了 long-horizon task 指南，它的 Goal mode 能连续运行数小时无需监督。但更偏向 L2（单会话长时间运行直到完成），而非 L3 那种“定时重复 + 跨迭代记忆”。
• OpenCode —— 通过插件生态实现 L3。opencode-scheduler 使用操作系统原生调度器（macOS 的 launchd、Linux 的 systemd），opencode-cron 利用 SQLite 持久化任务，跨会话重启后仍可存活。最大差异：Claude 将 loop 做成原生命令（会话级别），OpenCode 走插件路线（可跨会话持久，但需额外安装）。
• Reasonix —— Loop 是其存在的意义。还记得它的北极星吗？“便宜到能一直开着”。它没有“定时”概念，但整个架构（cache-first 三段式、99% 缓存命中）就是为 L2 常驻而生的——别人的 loop 会烧钱，它的 loop 是设计目标。一句话概括：Claude 的 loop 是“调度”，Reasonix 的 loop 是“经济学允许的常驻”。
• Aider —— 局部的执行循环。它有一个“命令失败自动回馈到对话”的机制（雏形：持续运行直到成功），但没有时间调度，也不支持跨迭代持久记忆。
• Gemini CLI / Cursor —— 没有内置 loop。需要定时执行时，只能借助外部 cron 包裹，每次冷启动且上下文清零。

所以如果你需要的是“定时重复 + 跨迭代记忆”，目前 Claude Code 是唯一的原生选择。其他场景各有各的解法：Codex 适合长时间自治运行，OpenCode 依赖插件补充，Reasonix 依靠哲学（可负担的常驻），预算有限且需跨重启时，就用 GitHub Actions 包装任何 agent。

五、真正的力量：Loop Engineering 的五块积木

到这里你可能以为 /loop 就是全部了。不。/loop 单独使用，价值其实有限——它真正的力量，在于它能与 Claude Code 的其他原语无缝组合。

Boris Cherny 那句“我的工作是写循环”之所以成立，是因为一个完整的循环系统由多块积木拼成。这里借用 Addy Osmani 的框架，将其归纳为五块（Claude Code 全部具备）：

还有第六块，是隐形的粘合剂——State：一个 markdown 文件（或看板）记录“做了什么、下一步是什么”。因为长时间运行的 agent 每次都会遗忘，所以记忆必须落在磁盘上而非上下文里。前面防坑清单强调的“状态写磁盘”，就是指这一块。

将这六块拼合起来，一个完整的循环系统长这样：

/loop 每早触发 → 调用 triage skill（读取 CI 失败/issue/commit） → 将发现写入 markdown 状态文件 → 对每个待办事项创建隔离的 worktree（互不干扰） → sub-agent A 起草修复，sub-agent B 对照 skills 和测试进行审查 → 通过 MCP 创建 PR、更新 ticket → 状态文件记录进度，明早继续运行

看到差别了吗？/loop 只是这套系统的心跳。 真正让它强大的，是 skills 提供的项目知识、worktree 提供的并行隔离、sub-agents 提供的制作/检查分离、MCP 提供的外部连接、以及状态文件提供的跨迭代记忆。这五块积木缺一不可，/loop 只是将它们串联起来的节拍器。

六、回到那两个下午

文章开头提到的两个场景，现在有了解法。

CI 失败后无需干等，挂一个 /loop，它会自动尝试直到变绿；测试需要批量修复，挂一个 /loop 让它每轮修复一个，睡一觉就能清理完毕。

但比这两个具体用法更重要的，是你刚刚经历的这段认知旅程：

• 你了解了循环分为三层——L1 执行循环、L2 自治循环、L3 调度循环，而 L3 才是“真正的 loop”。
• 你明白了 /loop 的精妙在于“带记忆的定时”，而非简单的闹钟；它背后是 cron 转换、会话内调度、时间抖动以及安全护栏这一整套设计。
• 你清楚了各 Agent 的 loop 能力差异巨大——Claude 原生支持、Codex 擅长长时间自治、OpenCode 依赖插件、Reasonix 依靠经济学、其余则依赖外部脚本。
• 你意识到真正的力量来自五块积木的组合，/loop 只是其中的心跳。

而这一切指向同一个范式转变：你真正的角色，正在从“提示 agent 的人”转变为“设计循环来提示 agent 的人”。 /loop 是这个转变的第一个工具，但它绝不会是最后一个。

回到开头那句话：那些被 CI 打碎的下午，本质上都是“用单次方式解决循环问题”的代价。当你开始用循环思维重新组织工作流，你会发现，许多曾占用你注意力的琐事，都可以交给一个会自动延续、会记忆、会协作的循环系统来处理。

学会写循环，而不是写 prompt——这才是 2026 年值得掌握的新基本功。