模式库与上线分级

loop engineering 真正可落地的地方，不在概念，而在 pattern。 也就是：什么问题值得做成 loop，第一周该怎么跑，什么时候才有资格放大自动化。

为什么 pattern 很重要

很多团队谈 loop 时会直接说：

• “搞个自动巡检吧”
• “让 agent 帮我盯着 PR”
• “让它自动修 CI”

问题是，这些说法都太宽了。真正落地时，你需要的是一套可复用模式：

• 典型输入是什么
• cadence 多快合适
• week one 应该只做到哪一步
• verifier 要不要上
• 哪些路径必须人工 gate

这就是 pattern 的价值。它把“想法”压缩成能复制的运行模板。

七类最常见的 loop pattern

源仓库里最有代表性的七类 pattern，基本覆盖了工程团队最常见的高频代理任务。

1. Daily Triage

最适合作为第一条 loop。

它通常做的是：

• 读取 issue、PR、CI、待办或仓库状态
• 分类高优先级项和观察项
• 更新 STATE.md
• 输出报告，不改代码

优点：

• 风险最低
• 最容易证明有价值
• 最适合训练团队如何读状态、调 cadence、写 triage skill

如果你从任何别的 pattern 起步，通常都比它更容易翻车。

2. PR Babysitter

负责持续关注活跃 PR：

• 有没有 review 卡住
• 有没有 CI 红了
• 有没有 merge conflict
• 有没有待响应评论

这条 loop 的价值很高，因为它切中真实团队摩擦点；但它比 Daily Triage 更敏感，因为它距离代码改动和协作沟通都更近。

3. CI Sweeper

负责盯失败的构建、测试或检查。

这是高价值、也是高风险 pattern，因为：

• 触发频率可能很高
• 日志很长
• 假阳性多
• 很容易把临时波动误判成应该修的代码问题

这类 loop 如果没有 verifier、worktree 和重试限制，很容易迅速烧钱并制造噪音。

4. Dependency Sweeper

负责依赖升级和低风险补丁。

它适合做成 loop，是因为输入非常结构化：

• 新版本信息
• 安全补丁
• lockfile 变化
• 测试结果

但这条 loop 也要特别强调范围收缩：

• 先只做 patch 级
• 先只做 allowlist
• 先只提建议或草稿 PR

5. Changelog Drafter

这是低风险高收益的典型。

它做的是：

• 汇总近期 commit / PR / release notes
• 生成 changelog 草稿
• 交给人审阅后再发布

它非常适合做 agent 自动化，因为：

• 输出可审查
• 错了代价相对低
• 节省的是稳定、重复的人力

6. Post-Merge Cleanup

用于 merge 之后的善后工作，例如：

• 清理临时分支
• 同步状态文件
• 更新 backlog
• 整理 follow-up 项

它不像 CI Sweeper 那么显眼，但非常适合做稳定 loop，因为工作模式重复、边界清晰、风险较低。

7. Issue Triage

面向 issue 队列健康度管理：

• 初步分类
• 打标签建议
• 识别重复项
• 标出需要人工判断的模糊问题

它和 Daily Triage 接近，但更聚焦 issue 面。

不同 pattern 背后的共同结构

虽然 pattern 各不相同，但它们的骨架其实很像：

1. 发现候选项
2. 做 triage
3. 写入状态
4. 必要时创建低风险动作
5. 风险路径升级给人

如果一个 pattern 脱离了这条骨架，通常要么会变得太脆弱，要么会开始失控。

上线分级：L0 / L1 / L2 / L3

这是整个 loop engineering 最值得直接照抄的部分。

L0：只有意图，没有运行

特点：

• 只有文档
• 只有想法
• 没有真实 cadence
• 没有状态写回

很多团队长期停在这一步，以为自己“已经有方案了”。其实这一步几乎没有任何工程价值。

L1：报告型 loop

特点：

• 会定时跑
• 会读写状态
• 只输出观察和建议
• 不自动改代码
• 不写远程高风险动作

这是最应该认真经营的一层。因为 L1 一旦做好，已经能帮团队节省大量 triage 和跟进成本，而且风险非常可控。

L2：辅助型 loop

特点：

• 开始做小范围自动动作
• 需要 worktree
• 需要 verifier
• 需要 denylist
• 需要人工 gate

这里可以出现：

• 小修复建议
• 低风险依赖升级
• 草稿 PR
• 补充评论或标签

但前提是动作范围要非常窄。

L3：无人值守型 loop

特点：

• 有较强自动执行能力
• 可以在较少人工盯盘下持续运行
• 有完整预算、日志、暂停和升级机制

这是最容易让人兴奋的阶段，也是最不该太早追求的阶段。多数团队真正应该做的是把 L1 打磨扎实，把 L2 控到足够小，而不是把 L3 当 KPI。

一个现实建议：第一周只做 L1

如果你正在搭第一条 loop，第一周最好的规则就是：

只报告，不修复。

具体一点：

• 更新 STATE.md
• 写高优先级项和 watch list
• 标记待处理问题
• 记录 last run
• 不改代码
• 不开 PR
• 不自动 merge

这样做的目的不是保守，而是让你先验证三件事：

1. 这条 loop 真的能稳定发现值得看的问题吗
2. 它的状态结构真能帮下一轮继续工作吗
3. 团队愿不愿意实际使用它写下来的结果

这三件事没跑通，后面所有自动修复都没有意义。

从 L1 升到 L2 之前，至少要满足什么

如果一条 loop 要从报告型升级到辅助型，最低要求我建议看这几项：

• 有稳定的 state schema
• verifier 已独立存在
• 自动动作范围非常窄
• 有 denylist 路径
• 有 attempt 限制
• 有 run log
• 有 kill switch
• 团队已经读过这条 loop 一段时间的实际输出

只要其中两三项还没有，继续停在 L1 往往更理性。

pattern 该怎么选

如果你想快速落地，我建议按下面顺序选：

第一步：先选低风险高频

首选：

• Daily Triage
• Issue Triage
• Changelog Drafter

第二步：再选靠近代码但边界清晰的

其次：

• Dependency Sweeper
• Post-Merge Cleanup

第三步：最后才考虑高频高噪音高干预的

最后：

• PR Babysitter
• CI Sweeper

原因不复杂：越靠近代码写入、越高频、越多外部系统交互的 loop，越应该建立在前面几条已跑稳的经验之上。

一个简单的 pattern 选择框架

可以用这四个问题筛：

1. 这个任务是否反复出现？
2. 它的输入是否足够结构化？
3. 出错后能否低成本回滚？
4. 能否先只报告而不自动执行？

四个问题里如果有两个答不上来，先别做 loop。

当前最有价值的落地策略

把上面这些压缩成一句实操建议就是：

从 Daily Triage 这类 L1 pattern 开始，用真实运行记录换取升级资格，而不是靠自信直接开 L2/L3。

这听起来不性感，但它是少数真的能把 loop 做成长线能力的路线。

延伸阅读