Cursor与Claude Code的loop命令深入解析

从守夜人到闹钟：loop命令的本质

没有人愿意在终端前坐五个小时，只为不断按回车让 Agent 重新检查同一个 PR。这不是工作，这是站岗。而 /loop 命令正是为解决这个问题而生。

打个比方：终端里的你就像一个夜店门口的守门人，每隔一分钟就要问一句「还有人吗？」而 /loop 就是戴在你手腕上的闹钟——每五分钟自动帮你查看一次，让你可以放心去跳舞。Anthropic 官方对此的定义很冷静：Loop 就是不断重复执行循环的 Agent，直到某个停止条件被触发。 换成更形象的说法：你在搭建一台能替你「反复追问」的机器。

这也意味着 Prompt Engineering 并没有消亡，它只是往上抬升了一层——从「写好一句话」变成了「设计好一套自动重复的机制」。Prompt Engineering（提示工程）的传统范式关注单次交互：如何用一句精心措辞的指令让模型给出最佳回答。但在 Agent 时代，它演变为一种「系统设计」能力——你不再只是写一条指令，而是设计一整套触发条件、循环逻辑、退出策略和状态管理机制。这种跃迁类似于从写单个函数到设计整个事件驱动架构的转变。当你在使用 /loop 时，你其实是在做架构设计，而不仅仅是在「调 Prompt」。

四个核心控制杆

理解 loop 体系，需要抓住四个关键概念，它们各司其职：

Turn（回合）

你掌握节奏。在 SDK 层面，这对应 Max Turns——只有涉及工具调用的轮次才会被计数。SDK（Software Development Kit，软件开发工具包）在 Agent 框架中提供编程接口来控制模型的行为边界，而 Max Turns 是其中一个关键的资源限制参数。这里的「工具调用」是指模型决定执行某个外部操作（如读取文件、运行代码、查询 API）并获取结果的完整过程。如果模型只是在说话而不调用工具，那不算一个 turn；只有当它真正「动手」（调用工具、拿到结果、再调用工具）时才计入。这种计数方式的好处在于资源控制更加精准——纯文本推理不消耗 turn 配额，只有真正产生外部副作用的「动作」才被计量。

Go（教练）

像一位不让你离场的教练，只有当目标数字达成（比如某个指标达到 90）或达到重试上限时才吹哨结束。它按数字停，不按感觉停。 这是关键——不是「模型累了就停」，而是「条件满足或封顶了才停」。

Loop（时钟）

本地时钟负责掌控节拍，每隔固定间隔触发一次。

Schedule（云端时钟）

和 Loop 是同一个时钟，但运行在云端。即使你合上笔记本，它依然继续运转。这是两者最本质的区别：本地 loop 活在会话里，笔记本一关就停；schedule 是云端的「夜班」。这种区别在实际使用中至关重要——如果你的任务需要跨越下班时间持续运行（比如监控一个可能持续数小时的部署过程），本地 loop 就力不从心了，你需要将它提升为 schedule。

实际操作命令与进阶技巧

实际操作其实很简单。基础语法是：

/loop 5m 检查部署状态

即「间隔 + Prompt」的组合，等于一个「带指令的闹钟」。这里需要牢记的铁律：笔记本一关，本地闹钟就死。

还有几个进阶技巧：

• 省略间隔时，Claude 会自己选择暂停时长，范围从一分钟到一小时——CI 着火时间隔短，任务闲置时间隔长。执行完一轮后，它会打印出暂停时长及其原因，像一个「有眼睛的节拍器」。
• 只输入 /loop 不带任何内容，它会读取 loop.md 或内置的默认 Prompt。
• 按 Esc 只会取消下一次唤醒，而不是关闭整个 Agent——它只掐掉下一次「敲钟」。

闹钟与心跳的区别

这是最容易混淆的一点。/loop 是闹钟——每五分钟重新执行一次相同的任务。而 Agent 内部的循环是心跳——Prompt、工具、结果、再工具，直到模型不再需要工具为止。

在 SDK 里，心跳对应 Max Turns 和 Max Budget。一次心跳还不构成一个 /loop；/loop 会启动很多次心跳。 换一种方式理解：/loop 是外层循环（每隔 N 分钟触发），心跳是内层循环（单次触发后 Agent 自主完成的多步推理和工具调用链）。外层循环控制「多久检查一次」，内层循环控制「每次检查时做多深」。如果你把两者混为一谈，就会造出两个闹钟，然后疑惑「为什么厨房着火了」。

Cursor上的本地实现与常见陷阱

在 Windows 的 Cursor 环境下，loop 本质上是一个 PowerShell 脚本：

while true
  sleep 300
  echo "Agent Loop Tick: Deploy"

旁边配一个包含 Prompt 的 JSON，通过 Notify on Output 加正则匹配来捕获信号。这里的实现原理是一个经典的「生产者-消费者」架构：PowerShell 脚本充当生产者，定时向终端输出特定的哨兵字符串（sentinel）；Cursor 的 Notify on Output 功能充当消费者，监听终端输出流，当检测到匹配正则表达式的 sentinel 时触发 Agent 响应。理解这个底层机制后，以下几个致命陷阱就更容易理解了：

• 顺序陷阱：第一个 sentinel 必须在 sleep 之后才出现，否则会重复触发 tick。如果你把 echo 放在 sleep 前面、又立即执行 Prompt，就会在一秒内连击两次。这是因为脚本启动时立即输出了 sentinel，Cursor 立刻响应；而 sleep 结束后又输出一次，导致双重触发。
• 命名陷阱：每个 loop 用一个独立名字，否则别的噪音会误唤醒 Agent。这就像消息队列中的 topic 命名——如果多个 loop 共享同一个 sentinel 字符串，任何一个 loop 的输出都会触发所有监听该字符串的消费者。
• 订阅陷阱：相同的定时器名、不加 unsubscribe，等于一个「无声的否定」——你以为改了配置，其实底层的锅炉根本没变。必须先取消订阅，再重新订阅。 这与事件监听器的生命周期管理如出一辙：旧的 listener 不移除，新旧就会同时生效，产生不可预期的行为。

学术规范与实测数据

学术界已经为这类机制建立了规范。arXiv 论文 2607.00038 提出了 Loop 规范：触发 → 工作 → 验证 → 停止，外加写在磁盘上的记忆——而不是存在聊天里。arXiv 是全球最大的学术预印本平台，AI/ML 领域的前沿研究通常会在此首发。论文中提出的这一范式，本质上是将软件工程中的状态机理论应用到 Agent 循环中。「写在磁盘上的记忆」这一设计原则尤其关键——大语言模型的上下文窗口有限（即使是最新的模型也只有 128K-200K token 的窗口），且每次新会话都会完全丢失历史信息。因为在聊天上下文中，Agent 会忘记自己昨天已经失败了三次。通过将状态持久化到文件系统，Agent 可以跨会话保持一致的决策依据，避免在同一个坑里反复跌倒。

该规范定义了五种终止状态，值得像法律条文一样记住：

1. Success（成功）
2. No-op（无事可做）
3. Blocked（需要人工介入）
4. Stalled（停滞、无进展）
5. Exhausted（资源耗尽）

其中最重要的原则：错误绝不能被标记为 Success，否则你就是在一个「绿色的谎言」上跳舞。这五种状态的设计借鉴了分布式系统中任务调度的经典模式——每个终止状态都对应明确的后续处理逻辑：Success 可以安全推进下一步，No-op 意味着可以拉长轮询间隔，Blocked 需要发出告警等待人类决策，Stalled 应该触发诊断流程，Exhausted 则必须停止并保存现场。

另一篇论文 2608.21884 扫描了开源项目，确认了 217 个自主 loop。研究发现一个普遍问题：配置文件躺在仓库里，但状态文件几乎从不提交——运行时数据活在 Git 旁边，就像汤放在冰箱里、菜谱却写在食谱书上。如果不规划好这一点，你的 loop 会在日报里撒谎。

loop 常见的失败模式

• Infinite Fix：同一道菜反复加盐五次
• Verifier Theater：评审点头，客人却吐了（验证形同虚设）
• Token Burn：没人点餐灶台却一直烧着
• Parallel Collision：两个厨师抢一把刀（并行冲突）

对应的解药：三次尝试后转人工、用测试而非模型意见作为裁判、先廉价分诊再上重型子 Agent、worktree 隔离加锁。其中 Git Worktree 值得特别解释——这是 Git 提供的一项功能，允许在同一个仓库下创建多个独立的工作目录，每个目录可以签出不同的分支并独立操作。在多 Agent 并行执行的场景下，如果多个 Agent 同时修改同一个工作目录中的文件，就会产生写冲突。通过为每个 Agent 分配独立的 worktree，配合文件锁机制，可以实现真正的并行而不互相干扰。这种隔离策略在 CI/CD 流水线和多 Agent 协作系统中已成为最佳实践。

实测破除的常见迷思

本文最有价值的部分，是拿 Claude Code 的解析器实测对照官方文档，破除了多个流传的迷思：

• 迷思一：/loop 检查部署 并非总是自定节奏。旧版本默认固定 10 分钟，新版文档改为动态的 1 分钟到 1 小时——但 Bedrock 和 Foundry 环境仍保持 10 分钟。看版本，别看推文。
• 迷思二：30 不会变成 30 秒。这是因为底层的时间调度沿用了 Cron 的设计哲学。Cron 是 Unix/Linux 系统中经典的定时任务调度器，其表达式格式为「分 时 日 月 周」五个字段，最小粒度为分钟——秒级精度从未在其规范之内。现代云调度服务（如 AWS EventBridge、GitHub Actions 的 schedule 触发器）大多沿用 Cron 语法，因此同样继承了这一分钟级的粒度限制。所以输入 30 会被向上取整到 1 分钟，而非解析为 30 秒。
• 迷思三：7m 的触发点是 0、7、14……到 56，跨越整点时那一跳只有 4 分钟而非 7 分钟——闹钟会「瘸腿」。这是因为 7 不能整除 60，当计数到 56 分时，下一个整点（即下个小时的 0 分）距离只有 4 分钟，打破了预期的等间隔节奏。
• 迷思四：5 分钟任务不会精确到秒触发，会有高达间隔一半（150 秒）的抖动，而且 Claude 忙碌时不会补做，空闲时只补一次。准时只是营销话术。 调度抖动（jitter）是分布式系统中的常见现象，在 Claude 的场景下主要来源于三个层面：API 请求的网络延迟、Anthropic 服务端的请求排队与限流机制、以及模型推理本身的计算耗时。当系统负载较高时，请求可能被排入等待队列，导致响应时间波动。「忙碌时不补做、空闲时只补一次」本质上是一种「最多执行一次」（at-most-once）的调度语义，而非「精确一次」（exactly-once），这与大多数云端定时服务的设计哲学一致。

实测显示，Cursor 的 Start-Sleep 精度极高（5 分钟量级上误差仅约 17 毫秒），真正吃掉你精度的是 Claude 本身的调度抖动，而非 sleep。这意味着优化定时精度时，应该关注的是 Agent 调度层面的策略（如错峰执行、预热连接），而非纠结于本地定时器的精度。

结语：造一个会看门的守夜人

与其构建一个「朗诵诗歌」的看门人，不如造一个真正盯着门、知道目标数字、并在「汤被加盐五次」时会大声呼救的守夜人。

Anthropic 提出的自省练习非常犀利：你在哪里成了瓶颈？你能把检查、停止条件、触发器，还是整个 Prompt 交出去？ 建议从一个控制杆开始，而不是一上来就建一座工厂。先跑起来，看它在哪里停滞或越界，然后加固「装备」——技能、验证器、状态文件，而不是给 Prompt 多加三个形容词。

最后的落地清单：提交解析器验证、7m 别乱动、30 别轻信、sentinel 加正则、清扫 echo、把文档版本和 skill 放在一起对照。做完这些，你才可以安心去跳舞——因为守夜人已经就位了。