# 风险、成本与反模式

> loop engineering 真正拉开水平差距的地方，不是谁会说“自动化”，而是谁会设计边界。
> 一条 loop 的价值，必须和它制造的成本、噪音与事故概率一起看。

## 一、先承认：loop 会放大好判断，也会放大坏判断

单次 agent 会话犯错，通常只影响当前回合；一条持续运行的 loop 犯错，会把错误：

- 重复很多次
- 写进状态文件
- 扩散到 GitHub、CI、工单系统
- 消耗预算
- 让团队慢慢对自动化失去信任

所以 loop 最大的风险不是“偶尔错一次”，而是**把一个小错误变成系统性误差**。

## 二、最容易被低估的成本：token 成本和注意力成本

大家通常会先想到 token，但真实代价至少有两种：

### 1. token 成本

高频 loop、长上下文、sub-agent、失败重试，都会迅速放大消耗。

特别是下面几类组合最危险：

- 高 cadence + 长日志
- 多 agent + 多轮验证
- 失败后反复重试
- 没有 early-exit 的“空跑”

如果没有预算上限和终止条件，一条本来很有帮助的 loop 很快就会变成“持续烧钱但没人看”的背景进程。

### 2. 注意力成本

这是更容易被忽略的成本。

如果 loop：

- 每次都发通知
- 报告里大量无关信息
- 频繁升级一些并不需要人处理的项
- 反复提相同建议

它消耗的其实是团队对自动化的耐心。很多 loop 不是被技术问题杀死，而是被“太吵了”杀死。

## 三、五个最危险的反模式

源仓库的 checklist 和 caveats 很值得直接吸收。结合真实使用场景，我认为下面五个反模式最值得先防。

### 1. 同一个 agent 既实现又验收

这是最经典的伪自动化。

问题不在于“它完全不能工作”，而在于它太容易产生虚假的完成感。实现者天然更容易相信自己的产出，尤其是在同一上下文里，它会不断沿用刚刚生成的解释。

解决办法很直接：

- verifier 独立
- 在独立 worktree 或独立线程里验证
- 完成条件写清楚

### 2. 没有状态文件，loop 每次都失忆

没有 `STATE.md`、没有队列、没有上次运行记录，loop 每轮都像第一次来项目一样：

- 重复发现同一问题
- 不知道上次做了什么
- 无法累计尝试次数
- 无法判断何时该升级给人

这种 loop 看起来在“持续跑”，本质上只是持续遗忘。

### 3. 一上来就做自动修复

很多人跳过 L1，直接想做 L2/L3。

结果常见是：

- triage 逻辑还没稳定
- 状态结构还没跑顺
- verifier 还没站住
- denylist 还没定义
- 团队还没习惯读 loop 输出

这时自动修复不是提高效率，而是在放大未知风险。

### 4. 通知策略失控

如果每次运行都 ping 人，或者每个小问题都升级，loop 很快会从“助手”变成“噪音源”。

通知应该只在这些情况发生时触发：

- 真正需要决策
- 达到最大重试次数
- 命中 denylist
- 预算超限
- 验证连续失败

除此之外，更多信息应该留在状态文件或 run log，而不是把人当日志系统。

### 5. 没有 kill switch

任何长期运行系统都要能停。

如果一条 loop 出了问题，却没有：

- 暂停标志
- 预算阈值
- 人工停机入口
- 明确的升级条件

那它迟早会在你不注意的时候继续做错事。

## 四、最容易出事的场景

下面这些场景需要特别保守：

### 1. 认证、权限、密钥、支付、生产基础设施

这些路径最适合直接 denylist。因为一旦误操作，代价通常远超节省的人力。

### 2. 高噪声输入

比如 flakey CI、长日志、重复 issue、自动生成但质量很差的报告。

输入越脏，loop 越容易在错误问题上浪费预算。

### 3. 没有稳定测试或验证器的仓库

没有验证闭环的自动修复，本质上就是“自动盲改”。

### 4. 团队没有统一工作习惯

如果大家根本不会看状态文件，也不会按 loop 的约定更新工单、处理升级项，那么 loop 只是增加了一个新的信息孤岛。

## 五、最低限度的安全护栏

如果你只愿意先做最小投入，我建议至少加上这几条：

1. **先从 L1 报告型开始**
2. **每轮都读写状态文件**
3. **maker / checker 分离**
4. **代码改动必须在 worktree**
5. **限制自动动作范围**
6. **配置预算上限**
7. **有 run log**
8. **有 kill switch**
9. **有 denylist**

这不是“成熟后再加”的增强项，而是 loop 真正进入真实工程前的最低门槛。

## 六、一个很实用的 readiness 自检

可以在准备升级 loop 前，问自己下面几个问题：

- 这条 loop 的单句目标够清楚吗
- 它的非目标写出来了吗
- 它每次运行会读哪些状态
- 它会把结果写回哪里
- 谁负责验收
- 验证失败后做什么
- 什么情况下必须叫人
- 一天最多花多少 token
- 如何暂停

如果其中三四个问题答不上来，说明它离“长期运行系统”还差得远。

## 七、什么时候应该停掉一条 loop

不是每条 loop 都值得长期养着。下面这些信号出现时，应该认真考虑停机或降级：

- 连续多次没有发现有价值事项
- 大部分输出都被人工忽略
- 同一问题反复出现却没有闭环
- verifier 频繁否决 implementer
- 成本显著高于人工处理成本
- 团队已经不再信任它的报告

停掉并不代表失败。有时候最工程化的决定，就是承认某条 loop 不值得继续。

## 八、最成熟的心态：把 loop 当系统，而不是魔法

一条 loop 不是“装上就省事”的神器，它更像一套小型生产系统：

- 有输入污染
- 有运行成本
- 有观测盲点
- 有故障模式
- 有停机和回滚需要

只要你用这个心态看 loop，就不容易被“全自动”幻觉带偏。

## 当前最值得坚持的原则

如果把整篇压缩成一句实操建议：

**先设计能停、能查、能审、能回放的 loop，再设计能自动执行的 loop。**

前者做不到，后者越强，风险越大。

## 延伸阅读

- [模式库与上线分级](./03-patterns-and-rollout-levels.md)
- [跨工具迁移：Claude Code、Codex、Cursor 怎么落地](./04-cross-tool-mapping.md)
- [Loop Engineering 专题总览](./README.md)