# Loop Engineering 是什么

> 如果你只能先带走一句话，带走这句：
> **Loop engineering 不是教你写下一条 prompt，而是教你设计一个会持续驱动 agent 工作的系统。**

## 一个足够准确的定义

源仓库给 loop 的定义很直白：**loop 是一个递归目标**。你给出目的，AI 在验证、外部状态、子 agent 和人工接管规则的约束下持续迭代，直到完成、暂停或升级给人。

这一定义有三个关键词：

- **递归**：不是一次调用，而是多轮循环
- **目标**：不是随便聊天，而是围绕一个持续目标推进
- **外部约束**：不是模型想干嘛就干嘛，而是被状态、验证、人类 gate 和系统边界控制

所以，真正的 loop 从来不是一句“帮我每天看看有没有啥要处理的”。那只是意图。只有你把触发、状态、输出格式、验证规则、升级路径都补齐，loop 才开始成形。

## 它和 prompt engineering 的差别

Prompt engineering 关注的是：

- system prompt 怎么写
- 指令顺序怎么排
- few-shot 示例怎么给
- 输出格式怎么约束

这些当然重要，但它们默认还是一次会话、一次调用、一次交互的思路。

Loop engineering 往前走了一步，开始问更工程的问题：

- 这个任务应该 **多久跑一次**
- 上一轮结果 **存在哪里**
- 下一轮开始时 **先读哪些状态**
- 发现风险项时 **谁来决定是否继续**
- 出了错怎么 **暂停、回放、追责**

也就是说，prompt engineering 更像是写一份“当前回合的战术指令”，loop engineering 则是在设计“整个赛季怎么打、战报怎么留、谁能下场、谁必须审批”。

## 它和 workflow 的差别

表面上看，loop 和 workflow 都是在做流程编排，但两者关注点不同。

### Workflow 更像固定流程

典型 workflow 会先写清楚：

1. 读输入
2. 跑步骤 A
3. 跑步骤 B
4. 失败就重试
5. 成功就输出

它更适合**输入稳定、步骤稳定、输出稳定**的任务。

### Loop 更像持续运行的控制回路

Loop 除了步骤，还关心：

- 这件事会不会反复出现
- 这轮没处理完，下一轮如何接着来
- 这个 agent 什么时候不该继续
- 这个系统如何长期活着，而不是跑一次就结束

所以你可以把 loop 理解成一种更偏“运维态”的 workflow。它不是只执行一次流程，而是持续观测、持续判断、持续修正。

## 它和 goal engineering 的关系

这是一个容易混淆，但很重要的边界。

### Goal 更适合“做完一个明确任务”

例如：

- 把当前 failing test 修到全绿
- 完成一个 feature 的实现和验证
- 解决一个具体 bug

这类事情有明确终点，适合 run-until-done。

### Loop 更适合“长期看守一个持续问题”

例如：

- 每天巡检 issue / PR / CI / changelog
- 持续观察依赖升级和安全补丁
- 反复整理 backlog、状态和下一步动作

这类事情通常没有永久终点，只能通过节奏化运转维持秩序。

一个很实用的判断方法是：

- **有明确完成条件**：更像 goal
- **本质上会不断再发生**：更像 loop

两者最好的关系不是互斥，而是协作：**loop 负责发现和排队，goal 负责把某个具体项做完。**

## 它和 harness engineering 的关系

Harness engineering 研究的是模型外面那层工程骨架：工具调用、上下文管理、沙箱、评测、接口设计。

Loop engineering 则是在这个骨架之上，再补一层“长期运行逻辑”：

- 何时开始
- 何时继续
- 状态如何持久化
- 多个 agent 怎么分工
- 何时停机或交还给人

所以可以把两者理解成：

- **Harness engineering**：让 agent 能干活
- **Loop engineering**：让 agent 持续、可控地干活

前者偏能力构建，后者偏运行设计。

## 一个最小 loop 长什么样

如果删掉所有花哨包装，一个最小可用 loop 至少包含下面这些环节：

1. **触发器**：定时、事件或手动启动
2. **任务定义**：本轮到底在看什么、输出什么
3. **状态读取**：读取 `STATE.md`、队列、工单或上次结论
4. **执行体**：让 agent 做 triage、修改、建议或生成报告
5. **验证器**：检查结果，而不是让执行体自我宣布成功
6. **状态写回**：记录本轮做了什么、下轮从哪继续
7. **人类 gate**：对风险路径进行升级或终止

少掉其中任一项，都很容易退化成“自动跑一次 prompt”。

## 为什么这个主题最近重要

这不是因为大家突然喜欢造新概念，而是因为 AI coding agent 进入真实项目后，单次对话已经不够用了。

团队真正想解决的是：

- 重复 triage 太耗人
- 大量小修复没人想手动盯
- 代码 agent 会写，但不会自己持续 follow-up
- 会话一断，历史判断就散了
- 自动化一旦多起来，没人说得清楚谁该停、谁该放

Loop engineering 回答的正是这些“进入真实世界后才出现”的问题。

## 它最适合哪些任务

适合 loop 的任务有四个典型特征：

### 一、高频重复

每天、每小时、每次 PR、每次 CI 都可能发生。

### 二、输入相对结构化

例如 issue、PR、依赖变更、失败日志、状态文件，而不是完全开放式探索。

### 三、能定义安全边界

你能写出“哪些路径绝不自动动手，哪些情况必须升级给人”。

### 四、能定义足够明确的输出

例如更新 `STATE.md`、生成草稿、标记优先级、提出修复建议，而不是“帮我持续想一个更好的产品战略”。

## 它最不适合哪些任务

不适合 loop 主导的任务通常有这些特征：

- 高度依赖商业判断或组织权衡
- 输出没有稳定评价标准
- 风险面过大，任何误操作代价都很高
- 任务本身频率不高，人工处理更便宜

比如权限模型重构、核心架构迁移、法务合规判断、生产数据批量变更，这些都不应该先从 loop 开始。

## 一个常见误区：把“自动化”当成目标

很多人第一次接触 loop，直觉是“太好了，终于能让 agent 自动把事情都做完”。这通常是错的起点。

更靠谱的目标应该是：

- 先让系统持续看见问题
- 再让系统稳定记录问题
- 再让系统在小范围里提建议
- 最后才讨论自动执行

换句话说，**loop engineering 的第一目标不是减少人，而是减少失控。**

只有当系统先变得可见、可查、可停、可回放，自动化才值得继续放大。

## 当前最值得采纳的基本原则

结合源仓库和现实落地经验，下面几条最值得先接受：

1. **先从 report-only 开始。**
2. **状态文件比提示词花样更重要。**
3. **maker / checker 必须分开。**
4. **worktree 和 denylist 是低成本高收益护栏。**
5. **成本、run log、kill switch 不是后补件。**

如果你愿意把这五条守住，已经比大多数“自动化 agent demo”更接近生产可用。

## 延伸阅读

- [Loop Engineering 专题总览](./README.md)
- [五个构件与状态中枢](./02-five-primitives-and-state.md)
- [模式库与上线分级](./03-patterns-and-rollout-levels.md)

下一篇：[02 五个构件与状态中枢](./02-five-primitives-and-state.md)