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 只选一个主 loopPick one primary loop per concern。重叠的 loop 需要协调协调规则见 docs/multi-loop.md。这条规则的意义在于多个 loop 盯同一个信号例如 CI 状态会产生重复修复、重复评论与重复耗 token。正确做法是让每个信号只有唯一的责任 loop其余 loop 要么只读、要么让位下文重叠规则一节会给出具体仲裁方式。快速参考症状 → 模式 → 起点pattern-picker的 Quick Reference 把症状直接映射到模式与推荐起点是落地时最常用的表格症状模式推荐起点CI 在 main 或 PR 上失败patterns/ci-sweeper.mdL215m 节奏最多 3 次尝试PR 卡在 review / CI / rebasepatterns/pr-babysitter.mdL1 观察 → L2 辅助每天早上该做什么或 GitHub issue 噪音大patterns/daily-triage.md patterns/issue-triage.md新第一周 L1 只报告——低风险、极佳组合依赖过期 / CVE 告警patterns/dependency-sweeper.mdL2 仅打补丁denylist 大版本升级合并后的 TODO 与清理债patterns/post-merge-cleanup.mdL1 非高峰时段只做小修复release notes / changelog 过期或缺失patterns/changelog-drafter.mdL1先只起草风险极低各模式的节奏、风险与成本基线patterns/registry.yaml是上述模式的机器可读索引被loop-audit、loop-cost、文档站和工具链共同消费。它给出了选型时最关键的三个维度节奏cadence、风险risk与 token 成本基线模式 ID节奏风险no-op / 报告 / 行动tokens建议日上限pr-babysitter5–15mmedium3k / 80k / 250k2Mdaily-triage1d–2hlow5k / 50k / 200k100kci-sweeper5–15mmedium5k / 50k / 200k1Mpost-merge-cleanup1d–6hlow5k / 40k / 150k200kdependency-sweeper6h–1dmedium5k / 60k / 300k500kchangelog-drafter1dlow5k / 35k / 80k100kissue-triage2h–1dlow3k / 30k / 60k80kthin-loop事件 1dlow1k / 5k / 1k20k数据来源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 --listloop-cost直接从 patterns/registry.yaml 读取成本元数据含stable_fraction与suggested_daily_cap按节奏--cadence与 readiness 级别--level默认 L1计算每日 token 消耗。常用参数见 tools/loop-cost/README.md参数说明--pattern模式 ID用--list查看全部--cadence覆盖节奏如15m、1d--levelL1/L2/L3默认L1--orchestration多智能体行动成本single默认、maker-checker、parallel:N、debate:R--conservative取节奏区间中的较慢值--json机器可读输出--with-caching对stable_fraction部分套用缓存读取折扣约为基础输入的 10%每个估算包含四类场景early-exit / no-op空队列最小 token、full triage每次完整扫描、action every run每次 implementer verifier最坏情况、realistic blend基于级别的混合。--orchestration对行动路径施加乘数maker-checker2xL2 默认形态、parallel:NN1、debate:R1R乘数超过 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.mdloop-init按模式--pattern与工具--tool claude也支持grok/opencode等脚手架出仓库内配套文件loop-budget.mdtoken 上限与 kill switch与loop-run-log.mdappend-only 运行历史。这两份文件是后续loop-audit评估预算纪律的必备信号见下文。用 loop-audit 验证并获取下一步建议npx cobusgreyling/loop-audit . --suggestloop-audit对项目打分0–100Loop Readiness并基于分数给出下一步建议详见 tools/loop-audit/README.md。--suggest模式会输出 copy-from-template 命令与各工具的活动建议--badge可生成 README 徽章退出码 2 表示分数 40可用于 CI 门禁。成本敏感选型速查表pattern-picker给出了四类典型场景的偏好/避免对照场景偏好避免直到有预算 提前退出个人项目 / 预算紧张Changelog Drafter、Daily TriageL1、Post-Merge5m 节奏的 CI Sweeper、5m 节奏的 PR Babysitter活跃的 CI 火情带提前退出的15mCI Sweepermain 绿时仍每 5m 跑全量 triage大量待处理 PR10–15m 的 PR Babysitter先 L1 观察每个 tick 都跑 L2 修复循环发版周每日 Changelog Drafter无人值守的 Dependency Sweeper CI Sweeper这张表透露三条成本纪律分钟级高频模式的耗散是乘法级的。以ci-sweeper为例15m 节奏、无提前退出时最坏日耗可超过 500 万 token见 patterns/ci-sweeper.md 的成本说明因此main 绿时必须走 no-op 早退路径。先 L1 观察、后 L2 行动是通用起步姿势。PR Babysitter 与 Daily Triage 都建议先用 L1只读报告 打标稳定一周再开修复权限。L3 需要前提loop-audit会限制L3的授予直到项目同时具备loop-budget.md、loop-run-log.md以及LOOP.md中的预算段落。重叠规则多个 loop 共存的仲裁表当一个仓库同时跑多个 loop 时pattern-picker给出了明确的协调规则完整版见 docs/multi-loop.md组合规则CI Sweeper PR BabysitterCI Sweeper 独占修复失败检查职责PR Babysitter 不得在同一小时内对同一分支重复修复Daily Triage 其他Daily Triage 只报告行动由执行类 loop 完成L1 阶段 triage 不自动修复Dependency Sweeper CI Sweepermain 上 CI 变红时暂停 Dependency SweeperPost-Merge PR BabysitterPost-Merge 只在非高峰时段运行Changelog Drafter 其他Changelog Drafter 以只读为主可安全并行但不得自动发布这些规则的价值在于把信号所有权显式化CI 信号归 CI SweeperPR 状态归 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: lowL1 纯报告模式第一周不自动修复状态纪律训练每次运行必须更新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 Sweeperci-sweeper5–15mmedium——main 或活动分支 CI 失败时快速诊断并给出最小修复。事件驱动优于轮询GitHub Action 可在workflow_run失败时触发见 examples/github-actions/ci-sweeper.yml。loop-guard熔断器loop-context --check在每次重试前检查同一失败超限如 3 次即升级人工。它是团队新手的最佳入门 loop高频、边界清晰、验证路径明确。PR Babysitterpr-babysitter5–15mmedium→high token——把 PR 从 review、CI、rebase 一路推进到 merge人类保留判断权。关键设计是缺检/未知检必须显式处理零返回的检查状态记为absent/unknown不能默认当绿。重试前同样跑熔断器--budget-from-pattern pr-babysitter --budget-level L2熔断见 docs/safety.md。Daily Triagedaily-triage1d–2hlow——每天或活跃周期内每 2h产出一份排好优先级、可行动的状态画像替代人工逐项检查 CI、issue、PR 与聊天。GitHub Action cron 可写为0 8 * * 1-5示例见 examples/github-actions/daily-triage.yml。很多团队先跑 1–2 周纯报告期再开行动。Issue Triageissue-triage2h–1dlow——持续发现、去重、打分、建议标签让团队和其他 loop 始终有一个干净的可行动队列。L1 绝不自动打标或关单L2 也仅对 allowlist 标签如area:*、needs-repro在 verifier 通过后生效。它是 Daily Triage 的喂料器二者是文档明确推荐的极佳组合。Dependency Sweeperdependency-sweeper6h–1dmedium——发现过期/有漏洞的依赖应用最小安全更新并在隔离 worktree 中验证高风险项大版本、破坏性变更、高危 CVE升级人工。失败模式中值得注意安全补丁引入了新漏洞的缓解措施是 verifier 在变更后必须包含npm audit或等价检查。Post-Merge Cleanuppost-merge-cleanup1d–6hlow——在合并后清扫弃用标记、TODO、技术债 ticket、过期 feature flag 与文档缺口不阻塞合并本身。事件驱动push to main 触发见 examples/github-actions/post-merge-cleanup.yml或非高峰定时。超过 10 文件的清理 PR 需人工批准。Changelog Drafterchangelog-drafter1dlow——扫描合并的 PR/commit/label产出分类分组的 release notes 草稿Features / Fixes / Breaking / Security / Docs 等人审后发布。drafter 永不发布只提议对超过约 50 条的扫描窗口应拆批或人工策展。它是最便宜的高价值 loop适合与任何其他 loop 并行。Thin Loopthin-loop事件 1dlow——只读的 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考