---
title: "Loop Engineering 实用指南：先写刹车，再写循环"
source_url: https://mp.weixin.qq.com/s/XDacdNndcDbBc3EpOT6oXA
publish_date: 2026-06-15
tags: [wechat, article, loop-engineering, harness, claude-code, codex, 若飞, ruofei, jiagoux, 架构师, feedback-loop, braking, evaluator, state, six-parts, three-types, budget, brake-first, reviewer-agent]
review_value: 9
review_confidence: 8
review_recommendation: ingest
sha256: 76f2b31668be6f04e3ff01caf118b70aed210899550d7a92f8b6101525aea830
---
# Loop Engineering 实用指南：先写刹车，再写循环
> Source: https://mp.weixin.qq.com/s/XDacdNndcDbBc3EpOT6oXA
> Author: 若飞 (架构师 JiaGouX)
> Date: 2026-06-15
> Collected: 2026-06-16

## 一句话总结

**先写刹车，再写循环。**

Loop 不是一句 prompt，也不是一个 cron。它是"触发、执行、验证、记录、继续或停止"的小系统。**最危险的 loop 往往不是跑不起来，而是跑得太顺，顺到没人知道它为什么继续。**

## 开篇案例

凌晨两点，一个 Agent 每 5 分钟检查一次 CI。

- 第一次发现测试失败，它读日志，改代码，重新跑测试
- 第二次还是失败，它换了一个方案
- 第三次它觉得自己修好了，于是推了一个 commit

早上打开电脑，发现它确实很勤快：**多了 7 个 commit，3 个新文件，2 个绕开的测试，还有一段看起来很完整的总结**。问题是——**真正的 bug 还在**。

> Loop Engineering 的难点，不是让循环转起来。难点是让它在该停的时候停，在该交还给人的时候交还给人，并且留下足够证据让人接手。

## 6 大核心结论

1. **Loop 不是一句 prompt，也不是一个 cron** — 它是"触发、执行、验证、记录、继续或停止"的小系统
2. **最危险的 loop 往往不是跑不起来，而是跑得太顺** — 顺到没人知道它为什么继续
3. **第一步应该先设计"怎么限制它只能做该做的事"**，再谈自动做更多事
4. **第一个 loop 不要从核心业务开发开始** — 优先选 CI 分流、事实核验、文档漂移、依赖升级预检查、重复故障归类
5. **一个 loop 至少需要四个可写清楚的边界**：输入、权限、验证、停止
6. **可复用资产不靠某句万能 prompt** — 而靠 Skill、Runbook、测试、状态账本和验收标准

## Prompt 没死：位置变了

过去 prompt 是一句临时输入：
> "帮我修一下这个 CI。"

现在更像一组可维护的工程资产（CI loop 示例）：
```
触发条件：main 分支 CI 失败超过 10 分钟
输入范围：最近 5 个 commit、失败 job 日志、相关测试文件
可写范围：独立 worktree，不允许改生产配置
验证方式：目标测试通过，全量 lint 通过，变更摘要可读
停止条件：最多 3 轮，超过 30 分钟，或连续两轮无新增进展
升级条件：涉及权限、计费、数据迁移、测试绕过，交还给人
```

**核心判断**：**prompt 从"对模型说一句话"，变成了"给一个持续系统写运行协议"**。

## Loop 与 cron / workflow / harness 的关系

| 概念 | 解决什么 |
|---|---|
| cron | 什么时候醒来 |
| workflow | 步骤怎么排 |
| harness | 模型运行在什么环境里 |
| **loop** | 这一轮做完以后，系统如何根据反馈进入下一轮，或者停止 |

## 一个 Loop 的最小结构（6 部件）

1. **触发器** — 谁叫醒它（定时/事件/人工/目标未完成）
2. **隔离空间** — 让它在哪个隔离空间里做（worktree/临时分支/沙箱）
3. **过程资产** — 让它按哪套项目经验做（Skill/Runbook/SPEC/规则）
4. **执行器** — 让它能接触哪些真实工具
5. **Evaluator** — 让谁来复核它
6. **State** — 把结果写回哪里

**最容易忽略的是 Evaluator 和 State**：
- **没有 Evaluator**：loop 就会自写自审 — Agent 写完代码再问自己"我做对了吗"，答案常偏乐观
- **没有 State**：loop 就会像每天入职的新同事 — 昨天否掉的方案今天再试一遍，上轮失败的路径下轮继续走

> 如果这 6 个问题答不出来，先别急着建 loop。

**与 Addy Osmani 拆法对比**：Addy 拆成 Automations / Worktrees / Skills / Plugins-Connectors / Sub-agents + 记忆位置。换成团队语言就是上面 6 个问题。

## 三类 Loop

### 1. 提醒型（入门首选）
- 只负责定期发现问题和生成清单
- 主要读，不直接改
- 输出是"待处理清单"，不是最终动作
- 例子：每天扫一遍新 issue / 每小时查一次失败 CI / 每晚整理当天新增线上错误 / 每天早上生成技术选题候选

### 2. 修复型（第二阶段）
- 在隔离空间里尝试修复
- **一定要有 worktree、最大轮数、测试和人工审查**
- 可以开 PR，但不要直接合并
- 例子：自动修复 flaky test / 尝试最小依赖升级 / 修文档链接 / 补缺失测试 / 按 review comment 做小范围修改

### 3. 演进型（最高阶段，最危险）
- 持续发现新任务、规划、分派、验证，并把状态写回
- 碰到的不只是代码执行问题，还有产品判断、权限、预算、组织协作和系统理解债
- **普通团队不要从第三种开始**

**稳的路线**：提醒型 → 修复型 → 演进型。如果反过来，会把拆分、验证和收口的责任往后推。

## CI 分流 Loop 实战模板

| 字段 | 内容 |
|---|---|
| **目标** | 每天早上 9 点检查过去 24 小时失败的 CI |
| **输入** | 失败 workflow 名称、job 日志、最近 5 个 commit、相关测试文件、过去 7 天是否出现过同类失败 |
| **允许动作** | 只读分析 / 失败归类 / 对低风险问题创建独立 worktree 尝试修复 / 生成候选 PR |
| **禁止动作** | 不允许跳过测试 / 不允许修改生产配置 / 不允许改数据库迁移 / 不允许直接 merge |
| **验证** | 目标测试通过 / 相关 lint/type-check 通过 / 输出失败分类、证据链接和变更摘要 |
| **停止** | 最多 3 轮 / 单个问题最多 30 分钟 / 连续两轮失败原因不变就停止 / 涉及权限/数据/计费/安全直接升级给人 |

> 这个模板不花哨，但很接近能落地的第一版。它的价值不是"自动修好所有 CI"。它先把每天重复的第一轮排查做干净：哪些是环境问题，哪些是最近提交引入，哪些是测试不稳定，哪些需要人判断。

## 写作核验 Loop 实战模板

| 字段 | 内容 |
|---|---|
| **目标** | 检查一篇技术稿里的事实断言，输出可发前风险清单 |
| **输入** | 当前草稿 / 公开来源清单 / 官方文档 / 公开讨论链接 / 相关代码仓库或 README |
| **允许动作** | 抽取事实断言 / 按来源类型标注可信度 / 查官方文档/代码/论文/访谈 / 输出修改建议 |
| **禁止动作** | 不直接替换正文中的关键结论 / 不把二手来源写成官方确认 / 不为缺来源的数字补编出处 |
| **验证** | 每条事实至少有来源类型 / 高风险断言必须标红 / 时间敏感信息标注日期 / 无法确认的内容建议降级或删除 |
| **停止** | 找不到可信来源时停止外推 / 来源互相冲突时交给作者 / 涉及法律/财务/安全结论时不自动定稿 |

## 成本前置：Loop 的成本是乘法

```
总成本 ≈ 触发次数 × 每轮上下文 × Agent 数量 × 工具调用 × 重试次数
```

如果再加 reviewer agent、浏览器测试、外部连接器、截图、日志读取，成本会继续放大。

**所以 loop 设计里必须有预算字段（不是"最好有"，是必须有）。至少 4 个上限**：
- 最大运行时长
- 最大迭代轮数
- 最大 token 或金额
- **最大无进展轮数**（**最重要的一个**）

> 如果连续两轮没有新增证据、没有缩小失败范围、没有通过任何新增验证，**停止并交还给人**。这比"继续优化"有用得多。

## 别自写自审：执行者和验证者边界

Loop 最容易自欺欺人的地方，是让**同一个 Agent 做、同一个 Agent 判**。

最小版本不一定要再开一个昂贵模型，可以先用**确定性验证**：
- 测试 / lint / type-check
- 链接检查 / schema 校验
- Playwright 截图
- SQL 只读对账
- 静态扫描

需要主观判断时，再用 reviewer agent。**Reviewer 的提示词不要写成"看看有没有问题"，而要写成检查表**：

```
你是验证者，不是实现者。
只检查以下内容：
1. 是否满足 SPEC
2. 是否有未验证声明
3. 是否扩大权限或修改范围
4. 是否跳过测试
5. 是否引入不可回滚变更
6. 是否需要人工决策

输出：
- pass/fail
- 证据
- 需要人确认的问题
- 不允许直接修复
```

**关键**：**验证者如果一边批判一边改，角色又混回去了**。

## 8 项暂停清单（什么时候别用 loop）

| 情况 | 为什么暂缓 |
|---|---|
| 目标每天都在变 | loop 会追着噪声跑 |
| 验证只能靠"感觉对" | 很难判断是否真的完成 |
| 需要生产写权限 | 错误影响太大 |
| 依赖口头背景 | 状态账本无法接住上下文 |
| 预算没有上限 | 容易变成持续烧钱 |
| 团队没人读结果 | loop 会制造无人负责的产物 |
| 一次性任务 | 自动化成本高于收益 |

**特别强调"团队没人读结果"**：很多 loop 失败，问题不一定出在 Agent 能力，而是人类流程没有接住它 — 它开了 PR 没人 review，写了报告没人确认，标了风险没人处理，最后这些产物会堆成另一种噪声。

> 建 loop 之前先问：**这个 loop 的输出，明天早上谁会看？看完以后谁有权决定下一步？** 没有答案，就先别建。

## Loop 设计表（18 字段完整模板）

| 项目 | 需要填写 |
|---|---|
| Loop 名称 | 用一句话说明它负责什么 |
| 业务目标 | 降低哪类重复成本，或提高哪类质量 |
| 触发方式 | 定时、事件、人工、目标未完成 |
| 输入来源 | 日志、issue、PR、文档、代码、监控 |
| 信任等级 | 哪些来源可信，哪些只作参考 |
| 可读范围 | 允许读取哪些仓库、目录、系统 |
| 可写范围 | 默认只读还是可写，可写到哪里 |
| 隔离方式 | worktree、临时分支、沙箱、只读快照 |
| 过程资产 | 使用哪些 Skill、Runbook、SPEC、规则 |
| 执行动作 | 分类、修复、开 PR、写报告、发通知 |
| 验证方式 | 测试、lint、截图、日志、reviewer agent |
| 状态账本 | 每轮结果写到哪里 |
| 成本上限 | 时间、轮数、token、金额 |
| 停止条件 | 失败、无进展、超预算、触碰禁区 |
| 人工升级 | 哪些情况必须交给人 |
| 回滚方式 | 如何撤销变更，如何追溯 |
| 复盘入口 | 失败经验如何回写 Skill 或 Runbook |

> 这张表填完，一个 loop 才算开始成形。**填不完的地方，通常就是系统还没准备好的地方**。

## 最终判断

Loop Engineering 这个词可能会热一阵，也可能很快被下一个词盖过去。但它背后的工程问题不会消失。

> 现在更愿意把 loop 看成一种**小型运行时设计**，而不是一种提示词技巧。它把人从一轮一轮的手工推进里解放出来，但也要求人把目标、边界、证据和预算写得更清楚。
>
> **这不是降低工程要求。这是把工程要求提前了。**

**给团队的最短建议**：
> 别先问"怎么让 Agent 一直跑"。先问"它跑偏时，谁能发现；它跑贵时，谁能停；它做完时，谁能验收"。这些问题有答案，再写循环。

从 Fable 5 到 Dynamic Workflows 再到今天的 loop：**强模型会把系统里的弱边界照出来**。边界写得清，Agent 能跑得更远；边界写不清，它只是更快地把问题扩大。