用途
Loop Ops 用于设计并安全运行“外层循环”（outer loop）——即位于单次智能体运行之上的、按计划或事件重复执行的流程。它要解决的问题是：逐轮提示会让人永远留在循环里；而循环工程把这件事反过来，让你设计一个带记忆、验证和边界的周期性流程，由它去发现工作、交给智能体执行、验证结果，并按计划或直到目标达成来决定是落地还是升级给人工。
它是 iterate（内层循环）的孪生，强调“组合而非重建”：复用仓库中已有的能力，而不是重新实现。
主要能力
- 原生调度优先：不手写调度器，而是选择原生宿主并在配置中声明 host:。资料中列出的原生原语包括：/loop（会话级、7 天过期、仅 L1）、Desktop 计划任务（本地持久、worktree 开关默认关闭）、cloud routines（机器关机也可运行、1 小时下限、无权限模式、所有连接器默认挂载）、/goal（完成门，不是节奏）。
- 补齐原生原语缺失的部分：跨 tick 存活的状态脊柱、token 预算、可信的验证门、升级规则，以及决定循环是否已赢得自主权的风险分级阶梯。
- 风险分级阶梯：L1 报告（只读发现与分诊，不写入）、L2 辅助（建议变更，人工把关合并）、L3 无人值守（在隔离容器内、denylist 边界内自主落地）。
- 升级门：明确哪些动作必须升级（force-push、推送到 main、生产部署或迁移、大规模删除、授予 IAM/仓库权限、破坏会话前文件、编辑 .claude/ 设置即自我修改、curl | bash 等），哪些在 L2/L3 允许清单下可自动落地。
- 状态脊柱：STATE.md（分诊快照）、run-log.md（每次运行追加一行审计记录）、loop.config.yaml（循环定义：目标、层级、节奏、宿主、范围、门、预算、升级）。
- 模式目录：由触发方式（节奏/事件/目标）× 姿态（L1/L2/L3）× 位置（连接器→cloud routine / 本地→Desktop 任务）三个轴组合而成。命名模式包括 L1 的 daily-scan、pr-watch、changelog-gen、merge-hygiene、issue-sort、regression-watch、digest、monitor、freshness；L2 的 ci-watch、dep-bump、metric-chase、backfill。
- 多循环协调与终止开关：优先级顺序（CI Watch → PR Watch → Dependency Bump → Merge-Hygiene/Changelog → Daily Scan）避免冲突；每个循环都必须遵守一个终止开关（如 PAUSED 哨兵文件或 loop-pause 标签）。
- 工具脚本：loop-scaffold.sh（init 脚手架）、loop-check.sh（audit 审计，退出码 10 表示未就绪）、loop-doctor.sh（doctor 预检，退出码 10 表示预测运行失败）、loop-estimate.py（成本估算，考虑缓存）、check-pricing-sync.py 与 check-native-facts.py（漂移守卫）。
使用方式
资料给出的端到端工作流为：
- 从模式目录选择模式（或自定义），并选择宿主；从 L1 开始。
- 脚手架：
bash scripts/loop-scaffold.sh --name <n> --pattern <p> --tier L1 --host <h>。 - 填写 loop.config.yaml：真实目标、范围（有界 glob，绝不用 *）、验证门、升级规则、budget_tokens、kill_switch。
- 成本估算：
python scripts/loop-estimate.py --pattern <p> --cadence <c> --model <m>。 - 审计：
bash scripts/loop-check.sh .loops/<n>/loop.config.yaml，修复所有错误后再调度。 - 预检：
bash scripts/loop-doctor.sh --live .loops/<n>/loop.config.yaml，证明它确实能运行。 - 在声明的宿主上调度 L1 运行；L1 只读，写入 STATE.md 和一份报告。
- 阅读报告，只有判断力被证明后，才升级到 L2（worktree + guard + fleet-ops 落地），必要时更换宿主，并在更高层级重新审计。
资料还提供了一个完整、通过审计与预检的 L1 示例：assets/examples/pr-watch/，可复制后调整范围与节奏，运行 loop-check 与 loop-doctor --live，再让调度器指向其 loop-run.sh。
适用场景
当以下任一条件成立时，就应使用 loop-ops：循环开始改变东西、无人值守运行、需要知道上次做了什么，或者它的静默会带来代价。反之，如果工作不写入需要撤销的内容、处于监督下或短生命周期、tick 之间无需记忆、且某个 tick 静默未触发也无所谓，则直接使用原生原语即可，例如 /loop 5m check if the deploy finished 就是完整正确的答案。
限制与注意事项
- 宿主本身是层级的一部分：session-cron（/loop + CronCreate）根本无法承载 L2+，因为它需要打开的闲置会话，且每个周期任务 7 天后过期。
- cloud-routine 没有权限模式，其层级通过仓库、环境网络策略和连接器来表达，这意味着 routine 一创建就实际上是自主的，L1 姿态必须来自只读提示。
- 核心规则：无人值守循环是调用
claude -p的调度器/脚本，而不是生成无门子进程的 Claude 会话。在 auto 模式下尝试启动--permission-mode bypassPermissions子进程会被作为 Create Unsafe Agents 阻止。 - 任务自我重排属于自我修改，除非自适应节奏是循环的既定目的，否则应在始终升级清单中。
- 反模式包括：绕过门、编排会话生成无门子进程、没有门、假设原生宿主给了边界、无界范围（scope: "*" 会被审计拒绝）、没有终止开关或预算、跳过 L1。
- 资料中未提供具体的收费、价格或平台信息。