ECC 的 `/loop-start` 命令详解：以安全默认值启动受管自主循环

ECC 的/loop-start命令详解：以安全默认值启动受管自主循环

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC

导读

在 ECC（Agent Harness Performance Optimization System）中，/loop-start是「受管自主循环（managed autonomous loop）」的启动入口：它用一个命令把仓库状态确认、循环模式选择、Hook 质量门禁、运行手册（runbook）与监控命令串成一条可重复的安全链路。阅读本文后，你将掌握/loop-start的完整语法与参数语义、四种循环模式的适用场景、safe/fast 两种模式对应的门禁差异、启动前的强制安全检查（含ECC_HOOK_PROFILE的底层实现），以及配套的/loop-status监控与loop-operatorAgent 的介入规则，从而安全地把长时间自主迭代跑起来而不是任其失控。

本文以仓库中的 commands/loop-start.md 为主干展开，源码级佐证来自 scripts/lib/hook-flags.js、skills/autonomous-loops/SKILL.md、agents/loop-operator.md 等仓库文件。

/loop-start命令定位：站在哪个生态位

在 ECC 的命令体系中，/loop-start与/loop-status成对出现，归属同一职责域。仓库内的命令编排文档 docs/COMMAND-AGENT-MAP.md 将其映射给loop-operatorAgent（agents/loop-operator.md），职责描述为 "Start autonomous loop" 与 "Inspect loop status"。在配方技能 skills/ecc-recipes/SKILL.md 中，它被归入 "managed autonomous loop and monitor" 这一组，推荐链路是：

loop-start <pattern> 然后 用 loop-status 观察

官方命令速查表 COMMANDS-QUICK-REF.md 把/loop-start描述为 "Start a recurring agent loop on an interval"，并在流程路由里提示「Running repeated tasks? → /loop-start」。

其 front matter 给出的语义自述是：

Start a managed autonomous loop pattern with safety defaults and explicit stop conditions.

关键词有两个：safety defaults（安全默认值）与explicit stop conditions（显式停止条件）。也就是说，它不是一个"裸跑死循环"的开关，而是"在默认安全约束下启动一个受控循环"的编排命令。

命令语法与参数语义

命令文档给出的用法如下：

/loop-start [pattern] [--mode safe|fast]

两个参数都标注为可选（$ARGUMENTS声明）：

参数	取值	含义
pattern	sequential|continuous-pr|rfc-dag|infinite	选择要启动的循环架构模式
--mode	safe（默认）|fast	质量门禁强度档位

模式选择的默认策略：--mode不传时默认走safe，即"默认即安全"——这与命令文档开篇 "Start a managed autonomous loop pattern with safety defaults" 的自述一致。只有当你明确想要追求速度、愿意牺牲一部分门禁时，才显式传--mode fast。

四种 pattern 的语义：与循环架构谱系一一对应

原命令文档只罗列了四个取值，并未展开每种模式内部是什么。仓库中的 skills/autonomous-loops/SKILL.md 恰好给出了从简到繁的完整"循环模式谱系"，可以精确对应/loop-start的四个枚举值，从而说明"选哪个 pattern = 选哪种循环架构"：

/loop-startpattern	对应架构（SKILL 中的章节）	典型适用场景
sequential	Sequential Pipeline（claude -p链式调用）	把日常开发拆成一系列无交互的步骤，一步步串行推进
continuous-pr	Continuous Claude PR Loop	多天迭代项目，每轮创建 PR、等待 CI、自动修复并合并
rfc-dag	Ralphinho / RFC-Driven DAG Orchestration	大型特性：把 RFC 拆成依赖 DAG，多单元并行执行后经合并队列落地
infinite	Infinite Agentic Loop	规格驱动的并行内容生成、长时间持续工作

需要留意：SKILL 文件顶部有一条 v1.8.0 的兼容性说明——autonomous-loops技能本身已计划退役，新指南应迁移到continuous-agent-loop，但当前仓库中仍保留autonomous-loops以免破坏既有工作流。这意味着你在使用/loop-start时看到的"四种模式命名"是稳定的契约，而底层承载的架构文档可能会随时间换新目录。

配方技能 skills/ecc-recipes/SKILL.md 给出了一个真实的组合范式，可见 pattern 的实战选择不是孤立的：

loop-start rfc-dag --mode safethen monitorloop-status; STOP when all units land

即：RFC 驱动的 DAG 循环 + safe 门禁启动，用/loop-status持续观察，以"全部工作单元落地"作为停止条件。

--mode safe与--mode fast的语义

命令文档对两个档位只有一句话定义：

• safe（默认）：严格的质量门禁和检查点（strict quality gates and checkpoints）
• fast：为速度而减少门禁（reduced gates for speed）

结合仓库中门禁相关命令与 Hook 基础设施，可以把这两个档位翻译成可落地的行为：

• 门禁（quality gates）在 ECC 中由 Hook 体系承载。以格式化门禁为例，commands/quality-gate.md 说明质量门禁通常以post:quality-gate这个 PostToolUse Hook 运行（实现脚本为scripts/hooks/quality-gate.js），其注册保留了standard/strict两个 profile——也就是说"完整门禁"只在standard与strict档位生效，这正是 safe 模式需要的档位，也是 fast 模式可以裁掉的部分。
• 检查点（checkpoints）由 /checkpoint 承担：创建检查点前先跑/verify quick确认当前状态干净，再以 git stash 或 commit 固化，并追加写入.claude/checkpoints.log（含时间戳、检查点名与 git SHA）；验证检查点时则对比文件变更、测试通过率与覆盖率变化。safe 模式要求"严格检查点"，即循环在两次迭代之间具备可回滚、可对比的锚点。

五步启动流程：从仓库状态到一条可执行命令

命令文档给出了启动的完整 Flow，共五步。这里结合仓库中的配套文档把每一步的"该做什么、为什么"讲透。

第 1 步：确认仓库状态与分支策略

Confirm repository state and branch strategy.

在启动任何自主循环前，必须先回答"代码当前是否干净、改动要落在哪里"。这条要求与loop-operatorAgent 的 Required Checks 直接呼应——agents/loop-operator.md 规定循环前必须确认：quality gates are active（质量门禁处于激活态）、eval baseline exists（评估基线存在）、rollback path exists（存在回滚路径）、branch/worktree isolation is configured（分支/工作树隔离已配置）。其中"分支/工作树隔离"正是为了防止循环过程中多轮改动互相污染主干；SKILL 中 Continuous Claude PR Loop 一节也强调每轮迭代新建独立分支（如continuous-claude/iteration-N），RFC DAG 模式则把每个工作单元放进独立 worktree。

第 2 步：选择循环模式与模型层级策略

Select loop pattern and model tier strategy.

• 循环模式即上一节的pattern四选一，它决定循环的整体骨架。
• 模型层级策略（model tier strategy）在 ECC 中有专门命令支撑——/model-route，路由启发式为：haiku用于确定性、低风险的机械改动；sonnet作为实现与重构的默认档；opus用于架构设计、深度审查与需求不明确的场景。循环启动前应通过它决定"哪类阶段用哪个档位的模型"（例如 SKILL 中 RFC DAG 各阶段按 Research/Plan/Implement/Test/Review 分配 Sonnet、Opus、Codex 等不同模型，正是"模型层级策略"的实例）。

第 3 步：为所选模式启用所需的 Hook/Profile

Enable required hooks/profile for the chosen mode.

这一步是"安全默认值"落地的关键，因为 ECC 的质量门禁完全建立在 Hook 事件之上。Hook 的机制（见 hooks/README.md）是：User request → Claude picks a tool → PreToolUse hook runs → Tool executes → PostToolUse hook runs。PreToolUse Hook 可用退出码 2 阻断工具执行（例如 pre-commit 质量检查），PostToolUse Hook 在工具执行后分析产出，Stop Hook 在每次响应后运行。

ECC_HOOK_PROFILE环境变量就是"为当前模式启用对应强度 Hook 集合"的开关，其真实取值与解析逻辑在 scripts/lib/hook-flags.js 中实现（详见下文"安全检查"一节）。safe 模式对应standard/strict档位的完整门禁，fast 模式则可退到更少的门禁换取速度。

第 4 步：创建循环计划并在.claude/plans/下写运行手册

Create loop plan and write runbook under.claude/plans/.

自主循环不能只靠一句 prompt 就放任自流，必须有一份计划 + 运行手册沉淀到仓库的.claude/plans/目录，作为循环每轮迭代读取的"宪法"——它通常包含目标、阶段拆分、质量要求与停止条件。这正是"受管（managed）"二字的含义：循环是执行计划的主体，计划本身由人类（或规划类命令）先行固化成文件。

第 5 步：打印启动与监控命令

Print commands to start and monitor the loop.

/loop-start完成以上编排后，应向会话输出"接下来怎么跑、怎么看"的命令清单：启动命令本身（即/loop-start <pattern> --mode ...）与配套的监控命令/loop-status。完整监控能力参见 commands/loop-status.md：/loop-status [--watch]可报告当前激活的循环模式、当前阶段与最近成功检查点、失败中的检查、预估时间/成本漂移，以及建议介入动作（continue/pause/stop）。

启动前的强制安全检查：三项硬约束

命令文档用一节专门列出必需的安全检查，这三项是启动循环的前置条件，缺一不可。

检查 1：首次循环迭代前必须验证测试通过

Verify tests pass before first loop iteration.

循环第一轮迭代必须站在一个"全绿"的基线上，否则循环会把既有失败当成自己的起点，产生大量噪声和错误归因。这与loop-operator的 Required Checks 中的 "eval baseline exists" 同源——没有基线，就无法判断循环是在改进还是在原地打转。实操上可配合 /checkpoint 的/verify quick先确认当前状态干净，再让循环起步。

检查 2：确保ECC_HOOK_PROFILE未被全局禁用

EnsureECC_HOOK_PROFILEis not disabled globally.

这是三项检查中最需要源码级理解的一条。全局禁用钩子有两个环境变量会共同起作用（源码见 scripts/lib/hook-flags.js 头注释）：

• ECC_HOOKS_ENABLED=true|false（默认true）——总开关；
• ECC_HOOK_PROFILE=minimal|standard|strict（默认standard）——档位选择；
• 另有ECC_DISABLED_HOOKS=comma,separated,hook,ids可精确禁用指定 Hook。

从 scripts/lib/hook-flags.js 的实现可以确认几个关键事实：

1. Profile 取值白名单：VALID_PROFILES = new Set(['minimal', 'standard', 'strict'])，除此之外的任何值都会被回退到standard。
2. 解析优先级链：getHookProfile()依次取ECC_HOOK_PROFILE环境变量 →CLAUDE_PLUGIN_OPTION_HOOK_PROFILE→ managed 安装下的ecc/setup.json中的managed.profile→ 兜底'standard'。
3. Hook 是否生效的判定：isHookEnabled()的逻辑是——先看areHooksEnabled()（ECC_HOOKS_ENABLED默认 true，同样支持从CLAUDE_PLUGIN_OPTION_HOOKS_ENABLED与 managed 配置回退）；再看该 Hook id 是否在ECC_DISABLED_HOOKS名单中；最后getHookProfile()得到的当前 profile 必须落在该 Hook 声明的allowedProfiles（parseProfiles默认回退为['standard', 'strict']）内才算启用。

因此，所谓"ECC_HOOK_PROFILE未被全局禁用"，严格说应同时满足：ECC_HOOKS_ENABLED不为false、当前 profile 落在循环所需档位（safe 模式至少是standard）、且关键门禁 Hook 未被ECC_DISABLED_HOOKS点名拉黑。判定式可写为：

hooksEnabled(ECC_HOOKS_ENABLED != false) AND profile ∈ hook.allowedProfiles（默认 standard/strict） AND hookId ∉ ECC_DISABLED_HOOKS

以post:quality-gate为例，commands/quality-gate.md 明确指出该 Hook 在注册时保留standard/strict两个 profile——如果把 profile 降到minimal或通过ECC_DISABLED_HOOKS移除它，格式化门禁就不再生效，--mode safe也就名存实亡。

检查 3：循环必须有显式停止条件

Ensure loop has explicit stop condition.

这是防止"烧钱死循环"的根本约束。ECC 对无界循环的态度在配方技能 skills/ecc-recipes/SKILL.md 中有直白的警告：

WARNING (autonomous loops only): an unbounded loop burns subscription/credits — ...

同时loop-operatorAgent 的工作流第 5 条也规定"仅在验证通过后恢复（Resume only after verification passes）"，并把以下情形列为必须升级（Escalate）的信号：

• 连续两个检查点无任何进展；
• 反复出现相同堆栈的失败（retry storms，重试风暴）；
• 成本漂移超出预算窗口；
• 合并冲突阻塞队列推进。

可接受的停止条件，在 SKILL 中归纳为以下四类：

停止条件类型	示例
次数上限	--max-runs N，跑满 N 轮即停
成本上限	--max-cost $X，花到预算即停
时间上限	--max-duration 8h，超时即停
完成信号	输出约定的 magic phrase 连续 N 次（如 completion signal），或rfc-dag模式中"全部工作单元落地"

启动之后的观测与介入：/loop-status与loop-operator

/loop-start只是循环生命周期的起点，运行期的可观测性是"受管"的另一半。配套命令 commands/loop-status.md 提供了会话内与跨会话两套观测手段：

会话内用法

/loop-status [--watch]

它报告：激活的循环模式、当前阶段与最近成功检查点、失败中的检查、预估时间/成本漂移，以及推荐介入动作（continue / pause / stop）。命令文档特别提示：该 slash 命令只能在当前会话将其出队（dequeue）后运行。

跨会话 CLI（打包命令ecc-universal）

当当前会话被卡住（wedged）或需要检查兄弟会话时，可在另一个终端运行：

npx --package ecc-universal ecc loop-status --json

CLI 会扫描本地 Claude 转录 JSONL（~/.claude/projects/**），报告陈旧的ScheduleWakeup调用或没有对应tool_result的Bash调用。常用选项包括：

• --json：输出机器可读状态；
• --home <dir>：检查其它本地 profile 或挂载的工作区；
• --transcript <session.jsonl>：直接检查单个转录；
• --bash-timeout-seconds 1800：调整陈旧 Bash 判定阈值；
• --exit-code：发现陈旧信号时退出码为2，无法扫描转录时退出码为1（配合--watch时必须提供--watch-count，避免看门狗脚本无限等待）；
• --watch [--watch-count N]：周期性刷新；--json时每次刷新输出一行 JSON，便于其它终端或脚本消费；
• --write-dir ~/.claude/loops：维护index.json（每会话一行）与<session-id>.json（完整状态快照），供兄弟终端或看门狗脚本在无需等待当前会话出队的情况下读取。

需要注意：这些快照文件是"本地转录分析的结果"，不会控制或超时 Claude Code 运行时的工具调用——它们只是观测手段。

在人的维度上，循环的守护者是loop-operatorAgent（agents/loop-operator.md）。它的 Mission 定义是：

Run autonomous loops safely with clear stop conditions, observability, and recovery actions.

其工作流五步与/loop-start的启动链路、/loop-status的监控能力完全咬合：

1. 从明确的 pattern 与 mode 启动循环；
2. 追踪进度检查点；
3. 侦测停滞（stall）与重试风暴（retry storm）；
4. 当失败重复出现时暂停并缩小范围；
5. 仅在验证通过后恢复。

端到端实操：把命令串成一条安全链

综合命令文档、配方技能与源码，一个完整的"受管循环"生命周期通常如下。先做启动前硬检查（测试绿、Hook 档位在线、停止条件明确），然后启动、观测、按信号介入：

# 1. 前置：确认基线干净（配合 /checkpoint 的 /verify quick） # 确认 ECC_HOOKS_ENABLED 非 false、ECC_HOOK_PROFILE 处于 standard/strict # 2. 在 .claude/plans/ 下写好 runbook（目标、阶段、质量要求、停止条件） # 3. 启动：RFC 驱动 DAG 循环，默认安全门禁 /loop-start rfc-dag --mode safe # 4. 观测：周期性查看循环状态（阶段、最近检查点、失败项、成本漂移） /loop-status --watch # 5. 在另一个终端用 CLI 做跨会话巡检（本会话被卡住时尤其必要） npx --package ecc-universal ecc loop-status --json # 6. 按 loop-operator 的介入规则行动：无进展/重试风暴/超预算/阻塞冲突 → pause 并缩小范围； # 全部工作单元落地或到达 max-runs/max-cost/完成信号 → stop

这个闭环把/loop-start的"默认安全"落实成了可执行、可验证、可回滚、可停止的工程流程，而不是一句"跑起来"的空话。

小结

/loop-start的价值不在"启动循环"这个动作本身，而在于它把 ECC 已有的自主循环架构（skills/autonomous-loops/SKILL.md）、Hook 质量门禁（hooks/README.md）、钩子档位开关（scripts/lib/hook-flags.js）、检查点（commands/checkpoint.md）、模型路由（commands/model-route.md）与循环守护 Agent（agents/loop-operator.md）编排为一次有默认安全约束的启动。理解它的关键在于记住三件事：pattern 决定循环架构，--mode决定门禁强度（默认 safe），启动前必须通过三项硬检查——测试绿、Hook profile 在线、停止条件显式存在；启动后用/loop-status（会话内或跨会话 CLI）持续观测，并让loop-operator的介入规则（无进展、重试风暴、成本漂移、合并冲突）来决定何时暂停、缩范围或终止。

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC