用 Grok 搭建 PR Babysitter Loop把 Pull Request 的 review、CI、rebase 与 merge 全流程交给循环调度【免费下载链接】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-engineeringPR Babysitter 是 loop-engineering 项目中的 L2可修复、带验证器模式目标是把工程师从反复催促 review、处理 CI 变红、手动 rebase、跟踪合并这类 PR 看护工作中解放出来同时把最终判断权始终留给人类。本文以 examples/grok/pr-babysitter.md 中的 Grok Build TUI 启动命令为入口完整展开该模式的调度方式、所需技能、状态管理、熔断与验证策略、失败模式与成本预算并结合仓库中的模式注册表、starter 脚手架、loop-context/loop-gate/loop-cost 等工具源码说明其底层机制。读完你将能在 Grok或其他支持/loop的 Agent 环境里落地一个安全、可控、可度量的 PR 看护循环。从一条命令说起Grok 里的 PR Babysitter 启动入口examples/grok/pr-babysitter.md给出了该模式在 Grok Build TUI 中的完整启动命令这是整篇文章的入口/loop 10m Run pr-review-triage on open PRs. Update pr-babysitter-state.md. Use worktree minimal-fix loop-verifier only for allowlisted low-risk PRs. Escalate after 3 attempts. No auto-merge in week one.这条命令其实浓缩了 PR Babysitter 模式的全部关键约束逐段拆解命令片段含义/loop 10m每 10 分钟触发一次循环Grok Build TUI 的原生原语Run pr-review-triage on open PRs首轮任务是对所有打开的 PR 执行pr-review-triage技能Update pr-babysitter-state.md每次运行都必须把状态写回状态文件保证循环是有记忆的worktree minimal-fix loop-verifier修复必须在 worktree 隔离中执行用最小修复技能改由独立验证器把关only for allowlisted low-risk PRs只有白名单内的低风险 PR 才允许自动修复其余只报告Escalate after 3 attempts单个 PR 最多尝试 3 次修复之后转人工No auto-merge in week one第一周禁止自动合并——默认永远不加自动合并除非显式开白名单在 patterns/registry.yaml 中pr-babysitter模式被登记为cadence: 5m-15m、risk: medium、week_one_mode: L1首周以只读/仅提议模式运行、token_cost: high、early_exit_required: true。这解释了为什么示例命令强调 No auto-merge in week one——模式本身在注册表层面就把首周默认在 L1 等级等你积累足够信心后再升级到 L2。模式目标与定位按 patterns/pr-babysitter.md 的定义PR Babysitter 的Goal是Reduce the human time spent herding pull requests through review, CI, rebase, and merge while keeping the human in the judgment seat.即减少人类在推动 PR 走完 review、CI、rebase、merge 流程上花费的时间同时让人类始终坐在判断席上。它不是一个替人合并代码的机器人而是一个替人跑腿、把决策点留给人类的看护进程。它属于 fix-capable 的 L2 模式——不仅能发现 CI 失败还能在受控范围内动手修复但修复必须经过独立验证并且永远只提议而不自行合并。调度节奏Scheduling推荐调度方式来自模式文档与 Grok 的 TUI 能力/loop 5m /pr-babysit check在 Grok Build TUI 中直接以/loop 5m /pr-babysit check启动即可pr-babysit技能安装后正是为此设计的。在其他环境GitHub Actions、定时任务中常见做法是工作时段每 5–15 分钟跑一次。很多团队的做法是活跃 review 时段跑一个更快的watcher循环2–5 分钟夜间换成一个更慢的cleaner循环。调度器还有一个值得一提的自管理能力当监视列表为空时技能可以调用scheduler_delete把自己从调度中移除——循环知道自己该下班。三个必备技能PR Babysitter 依赖三个技能分别承担看、修、合三个环节技能职责pr-review-triage理解项目 review 规范、必需检查项以及什么才算可以合并minimal-fix针对某一条 reviewer 评论或 CI 失败产出尽可能小的改动rebase-and-clean安全的 rebase 与冲突解决模式其中minimal-fix有仓库内的完整技能定义见 skills/minimal-fix/SKILL.md。它的核心规则是一次只修一个具体问题One problem per invocation多个失败先转人工或 triage只改必须改的文件禁止顺路重构No drive-by refactors尊重路径黑名单.env、auth/、payments/、secrets 一律不碰碰到就升级循环无人值守运行时优先使用 worktree 隔离不能给自己的产出标记完成——由验证器决定。其标准输出是一份Minimal Fix Proposal包含 Target一句话、Diff summary、Verification run命令结果、Risks/human review needed。状态文件循环的记忆PR Babysitter 把状态保存在一个很小的pr-babysitter-state.md中也可以用 Linear 看板或 GitHub Project 视图记录三件事被监视的 PR 及其当前状态上一次采取的动作与结果人类对循环的决策覆盖overrides模式文档给出的示例条目- #1234 (feat/auth-refresh) Checks: passing (unit, lint) Required-check policy: known and satisfied Reviews: changes requested by reviewer Mergeability: clean Ready to merge: no — changes requested Last action: Loop proposed minimal diff for comment X Human decision: Approved the diff, asked for one more teststarter 脚手架中的 starters/pr-babysitter/pr-babysitter-state.md.example 提供了更结构化的模板把每个字段枚举成可填写的取值域# PR Babysitter State Last run: never ## Watched PRs !-- - #1234 (branch-name) Checks: passing | failing | pending | absent/unknown Required-check policy: known and satisfied | known and unsatisfied | unknown Reviews: approved 1 | changes requested | review required | absent/unknown Mergeability: clean | conflicts | unknown Ready to merge: yes | no — reason Attempts: 0/3 Last action: — Human decision: — -- ## Escalated (human required) ## Resolved (last 7d) --- Run log: —注意几个字段的设计意图Required-check policy三态known and satisfied / known and unsatisfied / unknown——它强制循环承认我不知道这个仓库的必需检查策略而不是假装绿灯Attempts: 0/3——与 LOOP.md 中的Max fix attempts per PR: 3对应是熔断的数据来源Escalated/Resolved分区——被升级的 PR 单独列出最近 7 天已解决的 PR 单独留存避免状态文件无限膨胀。典型循环流程模式文档给出了一个 5 步的典型运行周期发现Discover扫描团队作者的 open PR或用户关心的所有 PR。逐 PR 处理Triage运行 triage 技能把检查分类为 passing / failing / pending / absent/unknown并记录仓库的必需检查策略是否已知检查失败→ 派生子 Agent 带minimal-fix技能去修复pending→ 等待absent/unknown→ 先去建立仓库策略或升级处理绝不默认绿色存在可行动的 review 评论 → 提议最小补丁已就绪策略已知且满足、必需审批齐全、无 changes requested、无阻塞评论、无合并冲突→ 打 ready to merge 标签或 ping 人类。闲置太久的 PR → 建议关闭或移交。把简明更新写回 PR 与状态文件。任何模糊或高风险事项 → 带上下文升级给人类。在 patterns/registry.yaml 中该模式的 phases 被登记为[discover, triage, fix, verify, notify]与上面的步骤一一对应并且verify是独立于fix的强制阶段。熔断器Circuit Breaker失败重复了就停手PR Babysitter 是 L2 修复型模式因此loop-init脚手架会自动为它生成loop-guard技能和一份种子化的loop-ledger.json。每次对某个被监视 PR 的重试前都要先跑熔断检查npx cobusgreyling/loop-context --check --ledger loop-ledger.json \ --budget-from-pattern pr-babysitter --budget-level L2这条命令的语义详见 tools/loop-context/README.md退出码0 继续2 升级1 错误参数错误/配置缺失非零退出意味着同一个失败反复出现或尝试次数达到上限——此时必须停止继续在 PR 上评论/重试升级给人类--budget-from-pattern pr-babysitter --budget-level L2表示从loop-cost的注册表里按模式 id 和就绪等级解析本次运行的 token 预算上限而不是手输一个拍脑袋的数字。loop-context的熔断器会监视四类信号对应其可调参数参数默认值触发升级的条件--max-iterations10迭代次数达到硬上限--stagnation3同一错误连续重复 N 次--no-progress5连续 N 次失败无进展--token-budget无累计 token 达到上限它还支持--daily-budget-from-pattern pr-babysitter来跨多次运行跟踪模式注册表中的每日上限suggested_daily_cap: 2000000即 2M tokens配合--on-exceed script在触发升级时把 BreakerDecision 以 JSON 形式管道给脚本用于自动化loop-budget.md中的On budget exceed检查清单。这套机制的完整安全语义见 docs/safety.md。验证策略Maker/Checker实现者不能给自己打勾模式文档明确要求永远不要让实现者子 Agent 给自己的活儿标记 done仓库中 skills/loop-verifier/SKILL.md 就是这一策略的落地实现其定位是checker默认立场是REJECT until proven otherwiseScope范围只改相关文件无黑名单路径无无关编辑Intent意图改动明确针对声明的目标而不是另一个问题Tests测试验证器自己跑测试不能相信实现者说测试过了并附上命令与输出片段No cheating禁止禁用测试、跳过断言、注释掉检查Risk中风险以上即使测试通过也建议人工 review。输出格式为## Verdict: APPROVE | REJECT | ESCALATE_HUMAN加 Evidence如果因环境问题跑不了测试必须ESCALATE_HUMAN。它与 maker实现者构成 maker/checker 分离。在成本层面loop-cost的--orchestration maker-checker模式对 action 路径施加 2x 乘数正是因为这个验证器 pass 是独立且必要的开销见 tools/loop-cost/README.md。另一个关键原则循环只提议合并必须由人或针对极安全情况的显式 auto-merge 白名单完成。对应仓库 gate.yaml 中的autoMergeAllowlist本仓库自己的默认白名单只放行docs/**、**/*.md与**/*.test.mjs行为变更、依赖升级、锁文件一律不在自动合并范围内。人类交接点Human Handoff以下情况必须交给人类高风险重构涉及 security、payments、auth 或核心基础设施的改动同一 PR 上循环已提议超过 N 次修复仍无进展状态文件显示同一 PR 连续多日反复出现。这些交接点与 docs/safety.md 的 Human Gates 完全一致security/auth/payments、基础设施、依赖升级、改动超过 N10 个文件、同一事项第三次尝试失败。其中改动超过 10 个文件在gate.yaml中被机械化为maxFiles: 10——一个循环提议大 diff 通常意味着它已经失去分寸无论动了哪些路径都要升级。工具差异与落地细节模式文档针对不同 Agent 环境给出了具体说明Grok Build TUI对应 examples/grok/README.md 的原生原语/loop、scheduler_create、worktree 隔离、skills、MCP、sub-agentspr-babysit技能如已安装就是为此场景设计的用/loop 5m /pr-babysit check启动任何修复尝试都使用 worktree 隔离监视列表为空时技能可自行调用scheduler_delete取消调度。Claude CodeBoris Cherny 曾公开描述过非常相似的/loop 5m /babysit流程可与/goal组合表达持续处理这个 PR直到 CI 变绿且没有阻塞评论。通用建议把状态文件暴露在仓库或共享文档中让全团队都能看到循环在做什么循环在 PR 上的评论要清晰署名例如 Loop Engineering — PR Babysitter。失败模式与缓解措施模式文档列出的五类典型失败及对策均在仓库中有对应机制失败模式缓解措施仓库对应实现循环提出坏修复强验证器子 Agentmaker/checker 超出平凡改动一律人工 review 门skills/loop-verifier/SKILL.md 的 REJECT 默认立场缺失的检查看起来像绿灯将零返回的检查表示为absent/unknown策略未建立前不视为就绪状态模板中的Required-check policy: known…/unknown三态无限 rebase 循环限制每个 PR 的自动 rebase 次数loop-context --max-iterations与 LOOP.md 的Max fix attempts per PR: 3状态过期每次运行清理已关闭/已合并的 PR状态文件Resolved (last 7d)分区通知疲劳选择性通知只在真正需要人介入时通知循环只在Escalated分区升级成本画像与预算管理模式文档给出的成本画像如下且与 patterns/registry.yaml 中登记的tokens_noop: 3000 / tokens_report: 80000 / tokens_action: 250000完全一致场景Tokens/次备注No-op空监视列表~3k目标中的大多数运行——应尽早退出Triage 扫描~80kPR CI 状态扫描修复尝试L2~250kworktree minimal-fix verifier节奏5m–15m ·等级high ·建议每日上限2M tokens ·要求尽早退出。可以用 tools/loop-cost 精确估算npx cobusgreyling/loop-cost --pattern pr-babysitter --cadence 10m --level L1 --conservative注册表中还记录了stable_fraction: 0.35意味着约 35% 的 token 属于可缓存的稳定部分可配合--with-caching查看缓存折扣场景。高频率 不早退会快速烧掉 token因此必须配合loop-budget技能见 skills/loop-budget/SKILL.md和 loop-run-log.md 运行日志来管理。注意loop-cost的--level与--budget-level一样区分 L1/L2/L3L2 的 maker-checker 修复路径成本是单实现者路径的 2 倍。成功度量指标模式的最终价值要用业务指标来度量从就绪可 review到合并的平均时间针对循环触碰过的 PR人类评论中纯粹是 LGTM, loop handled the rest 的数量Slack/Linear 中 can you rebase? 或 CI is red 这类 ping 的减少量。实践建议先从一个团队或一个仓库开始跑一周并度量然后再扩大范围。快速落地用 starter 脚手架初始化仓库提供了完整的 starter 模板 starters/pr-babysitter/README.md两步即可启动方式一自动脚手架推荐npx cobusgreyling/loop-init . --pattern pr-babysitter --tool grok方式二手动复制cp -r starters/pr-babysitter/.grok/skills/* .grok/skills/ cp starters/pr-babysitter/pr-babysitter-state.md.example pr-babysitter-state.md cp starters/pr-babysitter/LOOP.md .然后按自己的 review 规范与必需检查项定制技能最后在 Grok 中启动/loop 5m Check open PRs. Update pr-babysitter-state.md. For CI failures or actionable review comments on allowlisted PRs: worktree minimal-fix loop-verifier. Run loop-context --check before each retry; run loop-gate check before commit. Never merge — propose only. Escalate after 3 attempts per PR.这条命令比examples/grok/pr-babysitter.md的入门版更进一步额外加入了每次重试前跑loop-context --check、每次提交前跑loop-gate check两道闸门。starter 自带的 starters/pr-babysitter/LOOP.md 把团队级约束固化为配置配置项值节奏5m工作时间等级L2 assisted每个 PR 最大修复尝试3自动合并禁用监视范围团队作者的 PR /loop-watch标签人工门security、auth、payments、基础设施循环修复改动超过 10 个文件的 PR默认安全底线来自 starter 与 docs/safety.md默认不自动合并denylist 覆盖 auth、payments、secrets 等路径由 tools/loop-gate 依据 gate.yaml 机械执行loop-gate check --action type --paths changed files退出码0放行、2升级而不是依赖循环读过安全文档。此外loop-sync会在每次运行时比对 safety.md 的文本与gate.yaml是否漂移确保纸面策略与强制执行策略不会悄悄脱节。从源码看模式注册一处登记处处生效PR Babysitter 的一切工具链行为成本估算、熔断预算、审计、站点文档都源于 patterns/registry.yaml 中的这一条登记- id: pr-babysitter name: PR Babysitter file: pr-babysitter.md goal: Shepherd PRs through review, CI, rebase, and merge cadence: 5m-15m risk: medium tools: [grok, claude-code, codex, openclaw, opencode, github-actions] skills: [pr-review-triage, minimal-fix, rebase-and-clean] state: pr-babysitter-state.md phases: [discover, triage, fix, verify, notify] human_gates: [security, payments, auth, max-fix-attempts] starter: starters/pr-babysitter week_one_mode: L1 token_cost: high cost: tokens_noop: 3000 tokens_report: 80000 tokens_action: 250000 stable_fraction: 0.35 suggested_daily_cap: 2000000 early_exit_required: trueloop-cost --pattern pr-babysitter直接读取这里的 cost 元数据loop-context --budget-from-pattern pr-babysitter则把这里的 per-run 与 daily 预算解析成熔断器的 token 上限loop-init --pattern pr-babysitter --tool grok依据这里的 starter 路径与 skills 列表来脚手架。可以说模式文档patterns/pr-babysitter.md定义该怎么做注册表定义花多少、守哪些门而loop-context、loop-gate、loop-cost与loop-verifier共同把这些纸面规则变成每次运行都会执行的机械闸门——这正是 PR Babysitter 能在无人盯守时仍然把人类留在判断席的原因。【免费下载链接】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），仅供参考 用 Grok 搭建 PR Babysitter Loop：把 Pull Request 的 review、CI、rebase 与 merge 全流程交给循环调度
用 Grok 搭建 PR Babysitter Loop把 Pull Request 的 review、CI、rebase 与 merge 全流程交给循环调度【免费下载链接】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-engineeringPR Babysitter 是 loop-engineering 项目中的 L2可修复、带验证器模式目标是把工程师从反复催促 review、处理 CI 变红、手动 rebase、跟踪合并这类 PR 看护工作中解放出来同时把最终判断权始终留给人类。本文以 examples/grok/pr-babysitter.md 中的 Grok Build TUI 启动命令为入口完整展开该模式的调度方式、所需技能、状态管理、熔断与验证策略、失败模式与成本预算并结合仓库中的模式注册表、starter 脚手架、loop-context/loop-gate/loop-cost 等工具源码说明其底层机制。读完你将能在 Grok或其他支持/loop的 Agent 环境里落地一个安全、可控、可度量的 PR 看护循环。从一条命令说起Grok 里的 PR Babysitter 启动入口examples/grok/pr-babysitter.md给出了该模式在 Grok Build TUI 中的完整启动命令这是整篇文章的入口/loop 10m Run pr-review-triage on open PRs. Update pr-babysitter-state.md. Use worktree minimal-fix loop-verifier only for allowlisted low-risk PRs. Escalate after 3 attempts. No auto-merge in week one.这条命令其实浓缩了 PR Babysitter 模式的全部关键约束逐段拆解命令片段含义/loop 10m每 10 分钟触发一次循环Grok Build TUI 的原生原语Run pr-review-triage on open PRs首轮任务是对所有打开的 PR 执行pr-review-triage技能Update pr-babysitter-state.md每次运行都必须把状态写回状态文件保证循环是有记忆的worktree minimal-fix loop-verifier修复必须在 worktree 隔离中执行用最小修复技能改由独立验证器把关only for allowlisted low-risk PRs只有白名单内的低风险 PR 才允许自动修复其余只报告Escalate after 3 attempts单个 PR 最多尝试 3 次修复之后转人工No auto-merge in week one第一周禁止自动合并——默认永远不加自动合并除非显式开白名单在 patterns/registry.yaml 中pr-babysitter模式被登记为cadence: 5m-15m、risk: medium、week_one_mode: L1首周以只读/仅提议模式运行、token_cost: high、early_exit_required: true。这解释了为什么示例命令强调 No auto-merge in week one——模式本身在注册表层面就把首周默认在 L1 等级等你积累足够信心后再升级到 L2。模式目标与定位按 patterns/pr-babysitter.md 的定义PR Babysitter 的Goal是Reduce the human time spent herding pull requests through review, CI, rebase, and merge while keeping the human in the judgment seat.即减少人类在推动 PR 走完 review、CI、rebase、merge 流程上花费的时间同时让人类始终坐在判断席上。它不是一个替人合并代码的机器人而是一个替人跑腿、把决策点留给人类的看护进程。它属于 fix-capable 的 L2 模式——不仅能发现 CI 失败还能在受控范围内动手修复但修复必须经过独立验证并且永远只提议而不自行合并。调度节奏Scheduling推荐调度方式来自模式文档与 Grok 的 TUI 能力/loop 5m /pr-babysit check在 Grok Build TUI 中直接以/loop 5m /pr-babysit check启动即可pr-babysit技能安装后正是为此设计的。在其他环境GitHub Actions、定时任务中常见做法是工作时段每 5–15 分钟跑一次。很多团队的做法是活跃 review 时段跑一个更快的watcher循环2–5 分钟夜间换成一个更慢的cleaner循环。调度器还有一个值得一提的自管理能力当监视列表为空时技能可以调用scheduler_delete把自己从调度中移除——循环知道自己该下班。三个必备技能PR Babysitter 依赖三个技能分别承担看、修、合三个环节技能职责pr-review-triage理解项目 review 规范、必需检查项以及什么才算可以合并minimal-fix针对某一条 reviewer 评论或 CI 失败产出尽可能小的改动rebase-and-clean安全的 rebase 与冲突解决模式其中minimal-fix有仓库内的完整技能定义见 skills/minimal-fix/SKILL.md。它的核心规则是一次只修一个具体问题One problem per invocation多个失败先转人工或 triage只改必须改的文件禁止顺路重构No drive-by refactors尊重路径黑名单.env、auth/、payments/、secrets 一律不碰碰到就升级循环无人值守运行时优先使用 worktree 隔离不能给自己的产出标记完成——由验证器决定。其标准输出是一份Minimal Fix Proposal包含 Target一句话、Diff summary、Verification run命令结果、Risks/human review needed。状态文件循环的记忆PR Babysitter 把状态保存在一个很小的pr-babysitter-state.md中也可以用 Linear 看板或 GitHub Project 视图记录三件事被监视的 PR 及其当前状态上一次采取的动作与结果人类对循环的决策覆盖overrides模式文档给出的示例条目- #1234 (feat/auth-refresh) Checks: passing (unit, lint) Required-check policy: known and satisfied Reviews: changes requested by reviewer Mergeability: clean Ready to merge: no — changes requested Last action: Loop proposed minimal diff for comment X Human decision: Approved the diff, asked for one more teststarter 脚手架中的 starters/pr-babysitter/pr-babysitter-state.md.example 提供了更结构化的模板把每个字段枚举成可填写的取值域# PR Babysitter State Last run: never ## Watched PRs !-- - #1234 (branch-name) Checks: passing | failing | pending | absent/unknown Required-check policy: known and satisfied | known and unsatisfied | unknown Reviews: approved 1 | changes requested | review required | absent/unknown Mergeability: clean | conflicts | unknown Ready to merge: yes | no — reason Attempts: 0/3 Last action: — Human decision: — -- ## Escalated (human required) ## Resolved (last 7d) --- Run log: —注意几个字段的设计意图Required-check policy三态known and satisfied / known and unsatisfied / unknown——它强制循环承认我不知道这个仓库的必需检查策略而不是假装绿灯Attempts: 0/3——与 LOOP.md 中的Max fix attempts per PR: 3对应是熔断的数据来源Escalated/Resolved分区——被升级的 PR 单独列出最近 7 天已解决的 PR 单独留存避免状态文件无限膨胀。典型循环流程模式文档给出了一个 5 步的典型运行周期发现Discover扫描团队作者的 open PR或用户关心的所有 PR。逐 PR 处理Triage运行 triage 技能把检查分类为 passing / failing / pending / absent/unknown并记录仓库的必需检查策略是否已知检查失败→ 派生子 Agent 带minimal-fix技能去修复pending→ 等待absent/unknown→ 先去建立仓库策略或升级处理绝不默认绿色存在可行动的 review 评论 → 提议最小补丁已就绪策略已知且满足、必需审批齐全、无 changes requested、无阻塞评论、无合并冲突→ 打 ready to merge 标签或 ping 人类。闲置太久的 PR → 建议关闭或移交。把简明更新写回 PR 与状态文件。任何模糊或高风险事项 → 带上下文升级给人类。在 patterns/registry.yaml 中该模式的 phases 被登记为[discover, triage, fix, verify, notify]与上面的步骤一一对应并且verify是独立于fix的强制阶段。熔断器Circuit Breaker失败重复了就停手PR Babysitter 是 L2 修复型模式因此loop-init脚手架会自动为它生成loop-guard技能和一份种子化的loop-ledger.json。每次对某个被监视 PR 的重试前都要先跑熔断检查npx cobusgreyling/loop-context --check --ledger loop-ledger.json \ --budget-from-pattern pr-babysitter --budget-level L2这条命令的语义详见 tools/loop-context/README.md退出码0 继续2 升级1 错误参数错误/配置缺失非零退出意味着同一个失败反复出现或尝试次数达到上限——此时必须停止继续在 PR 上评论/重试升级给人类--budget-from-pattern pr-babysitter --budget-level L2表示从loop-cost的注册表里按模式 id 和就绪等级解析本次运行的 token 预算上限而不是手输一个拍脑袋的数字。loop-context的熔断器会监视四类信号对应其可调参数参数默认值触发升级的条件--max-iterations10迭代次数达到硬上限--stagnation3同一错误连续重复 N 次--no-progress5连续 N 次失败无进展--token-budget无累计 token 达到上限它还支持--daily-budget-from-pattern pr-babysitter来跨多次运行跟踪模式注册表中的每日上限suggested_daily_cap: 2000000即 2M tokens配合--on-exceed script在触发升级时把 BreakerDecision 以 JSON 形式管道给脚本用于自动化loop-budget.md中的On budget exceed检查清单。这套机制的完整安全语义见 docs/safety.md。验证策略Maker/Checker实现者不能给自己打勾模式文档明确要求永远不要让实现者子 Agent 给自己的活儿标记 done仓库中 skills/loop-verifier/SKILL.md 就是这一策略的落地实现其定位是checker默认立场是REJECT until proven otherwiseScope范围只改相关文件无黑名单路径无无关编辑Intent意图改动明确针对声明的目标而不是另一个问题Tests测试验证器自己跑测试不能相信实现者说测试过了并附上命令与输出片段No cheating禁止禁用测试、跳过断言、注释掉检查Risk中风险以上即使测试通过也建议人工 review。输出格式为## Verdict: APPROVE | REJECT | ESCALATE_HUMAN加 Evidence如果因环境问题跑不了测试必须ESCALATE_HUMAN。它与 maker实现者构成 maker/checker 分离。在成本层面loop-cost的--orchestration maker-checker模式对 action 路径施加 2x 乘数正是因为这个验证器 pass 是独立且必要的开销见 tools/loop-cost/README.md。另一个关键原则循环只提议合并必须由人或针对极安全情况的显式 auto-merge 白名单完成。对应仓库 gate.yaml 中的autoMergeAllowlist本仓库自己的默认白名单只放行docs/**、**/*.md与**/*.test.mjs行为变更、依赖升级、锁文件一律不在自动合并范围内。人类交接点Human Handoff以下情况必须交给人类高风险重构涉及 security、payments、auth 或核心基础设施的改动同一 PR 上循环已提议超过 N 次修复仍无进展状态文件显示同一 PR 连续多日反复出现。这些交接点与 docs/safety.md 的 Human Gates 完全一致security/auth/payments、基础设施、依赖升级、改动超过 N10 个文件、同一事项第三次尝试失败。其中改动超过 10 个文件在gate.yaml中被机械化为maxFiles: 10——一个循环提议大 diff 通常意味着它已经失去分寸无论动了哪些路径都要升级。工具差异与落地细节模式文档针对不同 Agent 环境给出了具体说明Grok Build TUI对应 examples/grok/README.md 的原生原语/loop、scheduler_create、worktree 隔离、skills、MCP、sub-agentspr-babysit技能如已安装就是为此场景设计的用/loop 5m /pr-babysit check启动任何修复尝试都使用 worktree 隔离监视列表为空时技能可自行调用scheduler_delete取消调度。Claude CodeBoris Cherny 曾公开描述过非常相似的/loop 5m /babysit流程可与/goal组合表达持续处理这个 PR直到 CI 变绿且没有阻塞评论。通用建议把状态文件暴露在仓库或共享文档中让全团队都能看到循环在做什么循环在 PR 上的评论要清晰署名例如 Loop Engineering — PR Babysitter。失败模式与缓解措施模式文档列出的五类典型失败及对策均在仓库中有对应机制失败模式缓解措施仓库对应实现循环提出坏修复强验证器子 Agentmaker/checker 超出平凡改动一律人工 review 门skills/loop-verifier/SKILL.md 的 REJECT 默认立场缺失的检查看起来像绿灯将零返回的检查表示为absent/unknown策略未建立前不视为就绪状态模板中的Required-check policy: known…/unknown三态无限 rebase 循环限制每个 PR 的自动 rebase 次数loop-context --max-iterations与 LOOP.md 的Max fix attempts per PR: 3状态过期每次运行清理已关闭/已合并的 PR状态文件Resolved (last 7d)分区通知疲劳选择性通知只在真正需要人介入时通知循环只在Escalated分区升级成本画像与预算管理模式文档给出的成本画像如下且与 patterns/registry.yaml 中登记的tokens_noop: 3000 / tokens_report: 80000 / tokens_action: 250000完全一致场景Tokens/次备注No-op空监视列表~3k目标中的大多数运行——应尽早退出Triage 扫描~80kPR CI 状态扫描修复尝试L2~250kworktree minimal-fix verifier节奏5m–15m ·等级high ·建议每日上限2M tokens ·要求尽早退出。可以用 tools/loop-cost 精确估算npx cobusgreyling/loop-cost --pattern pr-babysitter --cadence 10m --level L1 --conservative注册表中还记录了stable_fraction: 0.35意味着约 35% 的 token 属于可缓存的稳定部分可配合--with-caching查看缓存折扣场景。高频率 不早退会快速烧掉 token因此必须配合loop-budget技能见 skills/loop-budget/SKILL.md和 loop-run-log.md 运行日志来管理。注意loop-cost的--level与--budget-level一样区分 L1/L2/L3L2 的 maker-checker 修复路径成本是单实现者路径的 2 倍。成功度量指标模式的最终价值要用业务指标来度量从就绪可 review到合并的平均时间针对循环触碰过的 PR人类评论中纯粹是 LGTM, loop handled the rest 的数量Slack/Linear 中 can you rebase? 或 CI is red 这类 ping 的减少量。实践建议先从一个团队或一个仓库开始跑一周并度量然后再扩大范围。快速落地用 starter 脚手架初始化仓库提供了完整的 starter 模板 starters/pr-babysitter/README.md两步即可启动方式一自动脚手架推荐npx cobusgreyling/loop-init . --pattern pr-babysitter --tool grok方式二手动复制cp -r starters/pr-babysitter/.grok/skills/* .grok/skills/ cp starters/pr-babysitter/pr-babysitter-state.md.example pr-babysitter-state.md cp starters/pr-babysitter/LOOP.md .然后按自己的 review 规范与必需检查项定制技能最后在 Grok 中启动/loop 5m Check open PRs. Update pr-babysitter-state.md. For CI failures or actionable review comments on allowlisted PRs: worktree minimal-fix loop-verifier. Run loop-context --check before each retry; run loop-gate check before commit. Never merge — propose only. Escalate after 3 attempts per PR.这条命令比examples/grok/pr-babysitter.md的入门版更进一步额外加入了每次重试前跑loop-context --check、每次提交前跑loop-gate check两道闸门。starter 自带的 starters/pr-babysitter/LOOP.md 把团队级约束固化为配置配置项值节奏5m工作时间等级L2 assisted每个 PR 最大修复尝试3自动合并禁用监视范围团队作者的 PR /loop-watch标签人工门security、auth、payments、基础设施循环修复改动超过 10 个文件的 PR默认安全底线来自 starter 与 docs/safety.md默认不自动合并denylist 覆盖 auth、payments、secrets 等路径由 tools/loop-gate 依据 gate.yaml 机械执行loop-gate check --action type --paths changed files退出码0放行、2升级而不是依赖循环读过安全文档。此外loop-sync会在每次运行时比对 safety.md 的文本与gate.yaml是否漂移确保纸面策略与强制执行策略不会悄悄脱节。从源码看模式注册一处登记处处生效PR Babysitter 的一切工具链行为成本估算、熔断预算、审计、站点文档都源于 patterns/registry.yaml 中的这一条登记- id: pr-babysitter name: PR Babysitter file: pr-babysitter.md goal: Shepherd PRs through review, CI, rebase, and merge cadence: 5m-15m risk: medium tools: [grok, claude-code, codex, openclaw, opencode, github-actions] skills: [pr-review-triage, minimal-fix, rebase-and-clean] state: pr-babysitter-state.md phases: [discover, triage, fix, verify, notify] human_gates: [security, payments, auth, max-fix-attempts] starter: starters/pr-babysitter week_one_mode: L1 token_cost: high cost: tokens_noop: 3000 tokens_report: 80000 tokens_action: 250000 stable_fraction: 0.35 suggested_daily_cap: 2000000 early_exit_required: trueloop-cost --pattern pr-babysitter直接读取这里的 cost 元数据loop-context --budget-from-pattern pr-babysitter则把这里的 per-run 与 daily 预算解析成熔断器的 token 上限loop-init --pattern pr-babysitter --tool grok依据这里的 starter 路径与 skills 列表来脚手架。可以说模式文档patterns/pr-babysitter.md定义该怎么做注册表定义花多少、守哪些门而loop-context、loop-gate、loop-cost与loop-verifier共同把这些纸面规则变成每次运行都会执行的机械闸门——这正是 PR Babysitter 能在无人盯守时仍然把人类留在判断席的原因。【免费下载链接】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），仅供参考