风险、成本与反模式

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。

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

延伸阅读