Loop Engineering 模式选择指南：从仓库症状到正确 Loop 的决策框架（pattern-picker 全解析）

Loop Engineering 模式选择指南：从仓库症状到正确 Loop 的决策框架（pattern-picker 全解析）

【免费下载链接】loop-engineeringPractical patterns, starters & CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址: https://gitcode.com/gh_mirrors/lo/loop-engineering

导读

在 loop engineering 实践中，最常被问到的不是"如何写一个 loop"，而是"现在到底该跑哪个 loop"。本文基于 loop-engineering 仓库的 pattern-picker 决策文档，给出从仓库症状（CI 红、PR 卡住、issue 噪音、依赖告警、合并债、changelog 过期）到具体 loop 模式的完整映射，并结合作品库中的patterns/registry.yaml、loop-cost、loop-init、loop-audit等工具源码，讲透"一个 concern 只选一个主 loop""如何做成本感知选择""重叠 loop 如何协调"三件事。读完后你将能基于实际症状快速选型、估算 token 预算并安全落地第一个 loop。

决策树：什么在痛，就选什么

pattern-picker的核心是一棵决策树：先问"现在最痛的是什么"，再逐层分流。其完整流程如下：

这棵树揭示了一个容易被忽略的边界：完成一个 feature 或 refactor 不属于循环模式（cadence loop）的范畴。如果痛点是一次性交付变更，请直接走 docs/refactor.md 描述的重构/变更路径，仓库中并不存在"全仓重构"这种常驻 loop 模式。换句话说，loop 服务于"持续运营仓库"这一职责，而非"一次性交付"。

其余八个判断节点分别命中八种已文档化、可复用的模式：CI Sweeper、PR Babysitter、Daily Triage + Issue Triage、Dependency Sweeper、Post-Merge Cleanup、Changelog Drafter。决策树末端的两个兜底分支值得注意：若 token 预算紧张（Tight token budget?）则收敛到成本最低的 Changelog Drafter；否则回到 Daily Triage。

决策树背后的"一条规则"：每个 concern 一个主 loop

决策树的第一性原则写在 pattern-picker 开头：每个 concern 只选一个主 loop（Pick one primary loop per concern）。重叠的 loop 需要协调，协调规则见 docs/multi-loop.md。

这条规则的意义在于：多个 loop 盯同一个信号（例如 CI 状态）会产生重复修复、重复评论与重复耗 token。正确做法是让每个信号只有唯一的"责任 loop"，其余 loop 要么只读、要么让位（下文"重叠规则"一节会给出具体仲裁方式）。

快速参考：症状 → 模式 → 起点

pattern-picker的 Quick Reference 把症状直接映射到模式与推荐起点，是落地时最常用的表格：

各模式的节奏、风险与成本基线

patterns/registry.yaml是上述模式的机器可读索引（被loop-audit、loop-cost、文档站和工具链共同消费）。它给出了选型时最关键的三个维度：节奏（cadence）、风险（risk）与 token 成本基线：

数据来源：patterns/registry.yaml。从源码结构看，cost块中的tokens_noop/tokens_report/tokens_action三档分别对应"无可操作项时提前退出""完整扫描报告""L2 行动路径（worktree + implementer + verifier）"三种运行场景，这正是loop-cost估算工具的直接数据源。

注意两个"提前退出必需"（early_exit_required: true）的高频模式：ci-sweeper与pr-babysitter。它们的节奏在分钟级，若每次 tick 都跑完整行动路径，日耗会爆炸（下文成本小节详述）。

成本感知选型：先估算，再调度

pattern-picker给出的选型原则是Estimate before you schedule（先估算再调度）。仓库为此提供了三个 CLI 工具，串成一条"估算 → 脚手架 → 审计"链路。

用 loop-cost 估算每日 token 消耗

npx @cobusgreyling/loop-cost --pattern <id> --level L1 npx @cobusgreyling/loop-cost --pattern daily-triage --cadence 1d --level L1 npx @cobusgreyling/loop-cost --pattern ci-sweeper --cadence 15m --level L2 npx @cobusgreyling/loop-cost --list

loop-cost直接从 patterns/registry.yaml 读取成本元数据（含stable_fraction与suggested_daily_cap），按节奏（--cadence）与 readiness 级别（--level，默认 L1）计算每日 token 消耗。常用参数见 tools/loop-cost/README.md：

每个估算包含四类场景：early-exit / no-op（空队列，最小 token）、full triage（每次完整扫描）、action every run（每次 implementer + verifier，最坏情况）、realistic blend（基于级别的混合）。--orchestration对行动路径施加乘数：maker-checker2x（L2+ 默认形态）、parallel:NN+1、debate:R1+R；乘数超过 2x 会发出警告——深度 fan-out 或辩论式编排很容易开启，但无人值守跑起来极贵。

从源码看，loop-cost的估算还会回喂给loop-context的熔断器：--budget-from-pattern <id> --budget-level L2可以直接把某模式的 realistic per-run 估算解析为 token 预算，替代手填的猜测值。

用 loop-init 生成预算与运行日志骨架

npx @cobusgreyling/loop-init . --pattern daily-triage --tool claude # scaffolds loop-budget.md + loop-run-log.md

loop-init按模式（--pattern）与工具（--tool claude，也支持grok/opencode等）脚手架出仓库内配套文件：loop-budget.md（token 上限与 kill switch）与loop-run-log.md（append-only 运行历史）。这两份文件是后续loop-audit评估"预算纪律"的必备信号（见下文）。

用 loop-audit 验证并获取下一步建议

npx @cobusgreyling/loop-audit . --suggest

loop-audit对项目打分（0–100，Loop Readiness），并基于分数给出下一步建议，详见 tools/loop-audit/README.md。--suggest模式会输出 copy-from-template 命令与各工具的活动建议；--badge可生成 README 徽章；退出码 2 表示分数 < 40，可用于 CI 门禁。

成本敏感选型速查表

pattern-picker给出了四类典型场景的"偏好/避免"对照：

这张表透露三条成本纪律：

1. 分钟级高频模式的耗散是乘法级的。以ci-sweeper为例，15m 节奏、无提前退出时最坏日耗可超过 500 万 token（见 patterns/ci-sweeper.md 的成本说明），因此"main 绿时"必须走 no-op 早退路径。
2. "先 L1 观察、后 L2 行动"是通用起步姿势。PR Babysitter 与 Daily Triage 都建议先用 L1（只读报告 + 打标）稳定一周再开修复权限。
3. L3 需要前提：loop-audit会限制L3的授予，直到项目同时具备loop-budget.md、loop-run-log.md以及LOOP.md中的预算段落。

重叠规则：多个 loop 共存的仲裁表

当一个仓库同时跑多个 loop 时，pattern-picker给出了明确的协调规则（完整版见 docs/multi-loop.md）：

这些规则的价值在于把"信号所有权"显式化：CI 信号归 CI Sweeper，PR 状态归 PR Babysitter，行动执行归执行 loop、报告归 triage loop。loop-audit的 readiness 信号清单中也有对应印证——它检查是否存在 human-escalation path、stall/no-progress 检测（如loop-context熔断器或 ledger）以及 least-privilege 工具范围，这些正是"多 loop 共存不失控"的工程前提（见 tools/loop-audit/README.md 的 Signals Checked 表）。

第一个 loop 推荐：从 Daily Triage L1 开始

如果无法确定从哪个模式入手，pattern-picker的明确建议是：

If unsure, start with Daily Triage at L1.它训练状态纪律（state discipline），且没有 auto-merge 风险。

落地命令（同样来自原文档）：

npx @cobusgreyling/loop-init . --pattern daily-triage --tool claude npx @cobusgreyling/loop-audit . --suggest

为什么是它？对照 patterns/daily-triage.md 与registry.yaml可以归纳出三个理由：

• 风险最低：risk: low，L1 纯报告模式，第一周不自动修复；
• 状态纪律训练：每次运行必须更新STATE.md的Last run时间戳、条目状态 + 上次行动、以及覆盖 loop 的人类决策——这是所有模式共用的记忆脊椎；
• 自带"事后批评"（post-run critique）：每次运行记录高噪音项、误报、应降级项、人类 review 摩擦点，并为下一轮做一处调整，形成自我改进闭环。

Daily Triage 稳定之后，pattern-picker与其上游模式文档建议按此路径扩展：第二个 loop 可选 Post-Merge Cleanup（低风险）或 Changelog Drafter（文中明确称为"最高 ROI、最低风险"的 loop，适合作为第二个或第三个引入），之后才考虑 Dependency Sweeper / CI Sweeper 等 medium 风险、高成本的执行类 loop。各模式的引入顺序与"第一周 L1 只读"的做法在各模式文档中反复出现，例如 patterns/changelog-drafter.md 明确建议"L1 先只起草"，patterns/dependency-sweeper.md 建议"前 1–2 周只做 patch 级 + 已知 CVE 修复"。

八种模式的选型画像

以下画像综合各模式文档与registry.yaml，聚焦"何时选它、以何起点运行"：

CI Sweeper（ci-sweeper，5–15m，medium）——main 或活动分支 CI 失败时快速诊断并给出最小修复。事件驱动优于轮询：GitHub Action 可在workflow_run失败时触发（见 examples/github-actions/ci-sweeper.yml）。loop-guard熔断器（loop-context --check）在每次重试前检查，同一失败超限（如 3 次）即升级人工。它是团队新手的最佳入门 loop：高频、边界清晰、验证路径明确。

PR Babysitter（pr-babysitter，5–15m，medium→high token）——把 PR 从 review、CI、rebase 一路推进到 merge，人类保留判断权。关键设计是"缺检/未知检必须显式处理"：零返回的检查状态记为absent/unknown，不能默认当绿。重试前同样跑熔断器（--budget-from-pattern pr-babysitter --budget-level L2），熔断见 docs/safety.md。

Daily Triage（daily-triage，1d–2h，low）——每天（或活跃周期内每 2h）产出一份排好优先级、可行动的状态画像，替代人工逐项检查 CI、issue、PR 与聊天。GitHub Action cron 可写为0 8 * * 1-5（示例见 examples/github-actions/daily-triage.yml）。很多团队先跑 1–2 周纯报告期再开行动。

Issue Triage（issue-triage，2h–1d，low）——持续发现、去重、打分、建议标签，让团队和其他 loop 始终有一个干净的可行动队列。L1 绝不自动打标或关单，L2 也仅对 allowlist 标签（如area:*、needs-repro）在 verifier 通过后生效。它是 Daily Triage 的"喂料器"，二者是文档明确推荐的极佳组合。

Dependency Sweeper（dependency-sweeper，6h–1d，medium）——发现过期/有漏洞的依赖，应用最小安全更新并在隔离 worktree 中验证，高风险项（大版本、破坏性变更、高危 CVE）升级人工。失败模式中值得注意："安全补丁引入了新漏洞"的缓解措施是 verifier 在变更后必须包含npm audit（或等价检查）。

Post-Merge Cleanup（post-merge-cleanup，1d–6h，low）——在合并后清扫弃用标记、TODO、技术债 ticket、过期 feature flag 与文档缺口，不阻塞合并本身。事件驱动（push to main 触发，见 examples/github-actions/post-merge-cleanup.yml）或非高峰定时。超过 10 文件的清理 PR 需人工批准。

Changelog Drafter（changelog-drafter，1d，low）——扫描合并的 PR/commit/label，产出分类分组的 release notes 草稿（Features / Fixes / Breaking / Security / Docs 等），人审后发布。drafter 永不发布，只提议；对超过约 50 条的扫描窗口应拆批或人工策展。它是"最便宜的高价值 loop"，适合与任何其他 loop 并行。

Thin Loop（thin-loop，事件 + 1d，low）——只读的 GitHub Action 快照模式，issue 跟踪器即状态，所有写入都归人类（human_gates: [all-writes]），token 成本极低（no-op 仅 ~1k），适合完全不需要行动路径的只读监控场景。

选型的工程支撑：registry 与工具链

整个 pattern-picker 选型流程并非纸面文档，而是有可运行的工程支撑：

• 机器可读注册表：patterns/registry.yaml 是"选型数据的唯一真源"，每种模式的 id、节奏区间、风险、token 三档成本、early_exit_required、starter路径、week_one_mode全部结构化，供loop-cost估算与loop-audit校验消费；
• 脚手架：patterns/README.md 定义了标准的"怎么用"六步——选模式 →loop-init脚手架 → 按需复制templates/中的技能 → 配置调度（/loop、scheduler_create、GitHub Action、Codex Automation）→ 第一周 L1 只读 →loop-audit --suggest；
• 成本回馈熔断：loop-context的熔断器可用--budget-from-pattern直接以loop-cost的估算为预算，实现"预算来自数据、重试有上限"；
• 审计门禁：loop-audit检查 17+ 项 readiness 信号（状态文件、triage/verifier 技能、LOOP.md 配置、safety 文档、workflow、loop-budget.md、loop-run-log.md、least-privilege 工具范围、熔断/停滞检测、人工升级路径等），把"能否安全跑某个级别"变成可打分、可 CI 门禁的工程指标。

结语：选型是纪律，不是偏好

回看 pattern-picker 全文，选型的本质是三重纪律：每个 concern 只认一个主 loop（防止重复修复）；先估算再调度（高频模式必须配提前退出与日预算上限）；先 L1 只读、后 L2 行动（用报告质量换修复权限）。把这三点写进团队的第一个 loop 设计，再借助registry.yaml→loop-cost→loop-init→loop-audit这条工具链把选择变成可估算、可脚手架、可审计的工程动作，你就完成了从"猜该跑什么"到"按症状选型"的跃迁。若仍不确定，请记住这条建议：Daily Triage at L1 起步，一周后再做加法。

【免费下载链接】loop-engineeringPractical patterns, starters & CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址: https://gitcode.com/gh_mirrors/lo/loop-engineering