让 Claude Code 跑很久：/loop、/goal、Routines 和 Desktop scheduled tasks 该选哪个
跑很久不一定要跳出当前会话。如果任务有一个能被验证的完成条件，/goal 配合 auto mode 就能在当前会话里连续跑很多轮——它没有 /loop 那样的 7 天强制过期，也不用像 /loop 一样按固定间隔等待，条件没达标就直接开始下一轮，这就是为什么它能被随手挂着跑一两天。但它仍然是「会话范围」的机制：终端或客户端进程要保持存活，重启会中断（--resume 能找回条件，但轮次和计时会重置）。真正需要「合上电脑也在跑」，或者要按固定时刻、外部事件反复触发的，才需要 Routines（云端，研究预览）或 Desktop scheduled tasks（本机，跨重启持久）。四种机制解决的是不同的问题，不是谁比谁更强的升级关系。
四种机制怎么选
Section titled “四种机制怎么选”/loop（固定间隔） | /goal（完成条件） | Desktop scheduled tasks | Routines | |
|---|---|---|---|---|
| 运行位置 | 当前会话进程内 | 当前会话进程内 | 本机，Claude 桌面客户端 | 云端 |
| 终端/客户端要求 | 必须保持打开 | 必须保持打开 | 客户端需在运行 | 不需要，可关闭设备 |
| 跨重启持久 | 不支持，重启即丢 | 不支持（条件可用 --resume 找回，但轮次/计时重置） | 支持 | 支持（云端天然持久） |
| 触发方式 | 固定/自主间隔，7 天后过期 | 每轮结束自动评估，不满足就继续，无固定间隔和默认上限 | 定时 | 定时、Webhook、GitHub 事件等 |
| 本机文件访问 | 有 | 有 | 有 | 无（跑在云端沙箱里） |
| 适用场景 | 短时会话内轮询、调试期的重复检查 | 有明确可验证完成条件，想让当前会话连续跑到达标 | 需要本机环境、但要求重启不丢的日常任务 | 真正长期、脱离设备、接外部事件的自动化 |
什么时候选哪个
Section titled “什么时候选哪个”- 只是在当前调试会话里想「每隔几分钟看一眼」，用
/loop，见《loop 命令怎么用》。 - 任务有明确的、可验证的完成条件（比如「直到测试全绿」「直到 CHANGELOG 补全」），想让 Claude 自己反复迭代直到达标，用
/goal，见《/goal 命令怎么用》。 - 需要读写本机文件、依赖本机已装的工具链，但又不想每次重启电脑后手动重新创建，用 Desktop scheduled tasks。
- 需要真正的「设备关了也在跑」，或者要接 GitHub 事件、Webhook 之类外部触发，用 Routines。
/goal 为什么能被随手挂着跑一两天
Section titled “/goal 为什么能被随手挂着跑一两天”/loop 的 7 天过期和固定等待间隔，是专门为了防止「被遗忘的循环任务无限期占用资源」而设的限制；/goal 没有对应的限制——条件不满足，它就直接开始下一轮，官方文档里没有默认的轮数或时长上限。所以只要满足两个前提，/goal 确实可以连续跑很久：
- 终端/客户端进程别断——这是「会话范围」机制共同的硬要求，
/loop也一样； - 打开 auto mode，否则默认权限模式下每次未被允许的工具调用还是会停下来等确认。
想真的挂一两天不管，最好在条件里主动写清楚兜底（比如「或者跑满 200 轮就停」），避免条件写得太模糊、评估器一直判 no 而空转浪费。
用 Routines：/schedule
Section titled “用 Routines：/schedule”Routines 的入口是 /schedule，用自然语言描述即可：
/schedule daily code review of open PRs at 9am/schedule list/schedule pause <name>/schedule run <name>创建方式除了对话里的 /schedule，还可以在 Claude Code 网页端的 Routines 页面配置，或者调用 API 触发一次性运行（用于接入外部系统，比如 CI 流水线在特定阶段触发一次 Routine）。触发条件不止定时，还支持 GitHub 事件（比如「有新 PR 打开时跑一次审查」）。
每次触发的 Routine 是一次独立的新会话，不会复用上一次触发时的上下文，这点和 /loop 相反：/loop 是同一个会话反复追加消息，上下文会一直涨；Routine 每次都是干净的开始，没有「记忆延续」，也就不存在上下文膨胀的问题，但也意味着它记不住上一次跑的中间状态。
怎么确认任务真的在跑，而不是「看起来正常」
Section titled “怎么确认任务真的在跑，而不是「看起来正常」”Routines 的运行计入账户的用量额度，按账户每天有运行次数上限；手动触发的一次性运行不计入这个每日上限。如果是团队账户，管理员可以在组织层面整体禁用 Routines 功能。
长跑任务的上下文策略
Section titled “长跑任务的上下文策略”如果场景需要「同一个会话持续跑很久」而不是「每次触发都是新会话」（比如 /goal、/loop，或者 Desktop scheduled tasks 绑定同一个会话反复触发），上下文膨胀的问题都是一样的：消息会一直累积，最终触发自动压缩。跑得越久越容易撞到这个问题，提前确认压缩阈值符合预期，比等到长跑任务中途报错才发现划算，具体配置见《自动压缩阈值配置》。
还没确认的点
Section titled “还没确认的点”- Desktop scheduled tasks 的具体创建入口、触发日志的查看方式，官方文档在独立页面描述，这篇没有展开逐条核实，后续需要补测。
- Routines 目前标注为研究预览，配额规则、支持的触发事件类型可能会随版本调整，写这篇时看到的细节不保证长期有效。
/goal挂着连续跑一两天时，评估器的判断准确性会不会随对话变长而下降，没有做过本机复现，详见《/goal 命令怎么用》里的未确认清单。