# 模式库与上线分级

> 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 做成长线能力的路线。

## 延伸阅读

- [五个构件与状态中枢](./02-five-primitives-and-state.md)
- [跨工具迁移：Claude Code、Codex、Cursor 怎么落地](./04-cross-tool-mapping.md)
- [风险、成本与反模式](./05-risks-costs-and-anti-patterns.md)

下一篇：[04 跨工具迁移：Claude Code、Codex、Cursor 怎么落地](./04-cross-tool-mapping.md)