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

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

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

Agent 与自主循环的概念扩充 在 AI 领域,Agent(智能体)是指能够感知环境、自主决策并执行操作的软件实体。与传统的请求-响应模式不同,Agent 具备持续性和自主性——它可以根据环境变化主动调整行为,而无需每次都等待人类指令。自主循环(Autonomous Loop)是 Agent 的核心机制之一,使其能够在无人监督的情况下反复执行「观察-思考-行动」的循环,直到达成目标或触发停止条件。这种范式在 DevOps 监控、持续集成、自动化测试等场景中尤为关键,它将人类从重复性的监控任务中解放出来,让 AI 承担「守夜人」的角色。

打个比方:终端里的你就像一个夜店门口的守门人,每隔一分钟就要问一句「还有人吗?」而 /loop 就是戴在你手腕上的闹钟——每五分钟自动帮你查看一次,让你可以放心去跳舞。

Anthropic 与 Claude 技术背景 Anthropic 是由前 OpenAI 核心成员于 2021 年创立的 AI 安全研究公司,专注于开发可解释、可控的大语言模型。其旗舰产品 Claude 系列模型以安全性和可靠性著称,在代码生成、推理和工具调用方面表现突出。Claude 的 Agent 能力建立在函数调用(Function Calling)机制之上——模型可以决定何时调用外部工具(如文件系统、API、数据库),并根据返回结果继续推理。这种能力使 Claude 不仅是对话助手,更是可以自主执行复杂任务的自动化系统。Anthropic 还提供了 Claude Code 等开发者工具,让开发者能够构建基于 Claude 的自主 Agent 应用。

Anthropic 官方对此的定义很冷静:Loop 就是不断重复执行循环的 Agent,直到某个停止条件被触发。 换成更形象的说法:你在搭建一台能替你「反复追问」的机器。

Slashloop 就是闹钟

Prompt Engineering 的演进 Prompt Engineering(提示工程)最初是指如何通过精心设计的文本指令来引导大语言模型产生期望的输出。早期的 Prompt Engineering 关注单次交互优化——通过添加示例(few-shot learning)、明确角色定义、结构化输出格式等技巧提升模型表现。但在 Agent 时代,这一范式发生了根本性转变:从「写一句好的指令」升级为「设计一个自主运行的系统」。这要求工程师不仅要考虑单次提示的质量,还要设计循环逻辑、异常处理、状态持久化、资源限制等系统级问题。这种转变类似于从编写单个函数到设计分布式系统的跃迁——你需要考虑的不再是「如何问一个好问题」,而是「如何让系统在无人值守时持续可靠地工作」。

这也意味着 Prompt Engineering 并没有消亡,它只是往上抬升了一层——从「写好一句话」变成了「设计好一套自动重复的机制」。当你在使用 /loop 时,你其实是在做架构设计,而不仅仅是在「调 Prompt」。

四个核心控制杆

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

Turn(回合)

你掌握节奏。在 SDK 层面,这对应 Max Turns——只有涉及工具调用的轮次才会被计数。

SDK 与 API 资源控制 SDK(Software Development Kit,软件开发工具包)是软件厂商为开发者提供的编程接口集合,封装了底层 API 调用的复杂性。在 AI Agent 框架中,SDK 通常提供模型调用、工具注册、会话管理等功能。资源控制参数是 SDK 的关键组成部分,用于防止 Agent 失控消耗资源。Max Turns 限制模型可以执行的工具调用轮次,Max Budget 限制 token 消耗总量(即模型处理的文本量,直接关联到 API 费用)。这些参数的设计借鉴了操作系统的资源配额管理思想——通过硬性限制防止单个进程耗尽系统资源。合理设置这些参数需要在自主性和成本之间找到平衡:太低会导致任务无法完成,太高则可能造成无意义的资源浪费。

这里的「工具调用」是指模型决定执行某个外部操作(如读取文件、运行代码、查询 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"

事件驱动架构与 Sentinel 模式 事件驱动架构(Event-Driven Architecture)是一种系统设计范式,组件之间通过异步事件进行通信,而非直接调用。在这种架构中,生产者发出事件,消费者监听并响应事件,两者通过事件总线解耦。文中描述的 PowerShell 脚本配合 Cursor 的 Notify on Output 就是典型的事件驱动模式:脚本定时向终端输出特定字符串(Sentinel,哨兵),Cursor 监听终端输出流,匹配到 Sentinel 后触发 Agent 响应。Sentinel 模式在分布式系统中广泛应用于心跳检测、状态同步、任务协调等场景。这种模式的优势在于松耦合——生产者无需知道消费者的存在,只需按约定发出信号。但也带来了调试复杂性:错误的 Sentinel 命名或重复订阅会导致难以追踪的幽灵触发。理解这一模式有助于避免常见陷阱,如文中提到的「相同定时器名不取消订阅」问题。

旁边配一个包含 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 可以跨会话保持一致的决策依据,避免在同一个坑里反复跌倒。

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

Success(成功)
No-op(无事可做)
Blocked(需要人工介入)
Stalled(停滞、无进展)
Exhausted(资源耗尽)

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

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

loop 常见的失败模式

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

Git Worktree 并行隔离机制 Git Worktree 是 Git 2.5 版本引入的功能,允许一个仓库同时维护多个工作目录,每个目录可以签出不同的分支并独立操作。这解决了并行开发的经典难题:如何在同一个仓库上同时进行多项独立工作而不互相干扰。在多 Agent 协作场景中,Worktree 的价值在于物理隔离——每个 Agent 在独立的文件系统目录中操作,避免了文件写冲突和状态污染。配合文件锁机制,可以构建真正的并行执行环境。这种隔离策略在 CI/CD 流水线中已是标准做法:Jenkins、GitLab CI 等系统在执行并行任务时都会为每个任务分配独立的工作空间。理解 Worktree 的本质有助于设计可扩展的 Agent 系统——将「空间隔离」作为防御并发冲突的第一道防线。

对应的解药:三次尝试后转人工、用测试而非模型意见作为裁判、先廉价分诊再上重型子 Agent、worktree 隔离加锁。

实测破除的常见迷思

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

30 分钟不会变成 30 秒

迷思一:/loop 检查部署 并非总是自定节奏。旧版本默认固定 10 分钟,新版文档改为动态的 1 分钟到 1 小时——但 Bedrock 和 Foundry 环境仍保持 10 分钟。看版本,别看推文。
迷思二:30 不会变成 30 秒。

Cron 与任务调度系统 Cron 是 Unix/Linux 系统中的经典定时任务调度器,自 1970 年代起就是系统管理的基础工具。它使用五字段表达式(分时日月周)来定义任务执行时间,最小粒度为分钟。现代云服务(如 AWS EventBridge、Google Cloud Scheduler、GitHub Actions)在设计定时触发器时大多沿用了 Cron 的语法和设计哲学,因为这一标准已经过数十年的生产环境验证。Cron 的设计权衡体现了工程实用主义:分钟级粒度足以覆盖绝大多数系统管理任务(日志轮转、数据备份、健康检查等),而秒级精度会大幅增加调度器的复杂度和系统开销。理解 Cron 的这一设计决策,有助于理解为什么大多数 Agent 循环系统的最小时间间隔都设置为 1 分钟。

这是因为底层的时间调度沿用了 Cron 的设计哲学。所以输入 30 会被向上取整到 1 分钟,而非解析为 30 秒。

迷思三:7m 的触发点是 0、7、14……到 56,跨越整点时那一跳只有 4 分钟而非 7 分钟——闹钟会「瘸腿」。这是因为 7 不能整除 60,当计数到 56 分时,下一个整点(即下个小时的 0 分)距离只有 4 分钟,打破了预期的等间隔节奏。
迷思四:5 分钟任务不会精确到秒触发,会有高达间隔一半(150 秒)的抖动,而且 Claude 忙碌时不会补做,空闲时只补一次。准时只是营销话术。

分布式系统中的调度抖动 调度抖动(Jitter)是指任务实际执行时间与计划执行时间之间的偏差,在分布式系统中普遍存在。其根源包括:网络延迟的随机性、服务端负载引起的排队延迟、多租户环境中的资源竞争等。在云端 AI 服务中,抖动尤为显著——API 请求可能因限流排队,模型推理时间因输入复杂度波动,token 生成速度受负载影响。大多数云服务提供的是「尽力而为」(best-effort)的调度语义,而非实时保证。文中提到的「忙碌时不补做、空闲时只补一次」体现的是「最多执行一次」(at-most-once)的幂等性设计,这在分布式系统中是常见的权衡选择——相比「精确一次」(exactly-once),它实现成本更低,且对大多数监控类任务已经足够。

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

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

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

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

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