Loop Engineering：让 AI Agent 自己推进任务的循环系统

Loop Engineering 可以翻译成“循环工程”。它解决的问题很直接：当 AI Agent 已经能写代码、查资料、跑命令、改文件之后，人还要不要每一步都手动告诉它下一步做什么？

传统用法是人不断发指令：

修这个 bug。
跑一下测试。
看看哪里失败了。
再改一下。
重新跑测试。
写 PR 描述。

Loop Engineering 的做法不是继续优化单句提示词，而是把这些动作设计成一个可重复运行的系统。人不再逐句指挥 AI，而是设计一个循环，让它自己发现问题、交付结果、检查质量、记录进展，并根据结果决定下一轮要做什么。

一句话概括：

Loop Engineering 不是“提示 AI 做事”，而是“设计一个会持续提示 AI 的系统”。

它和提示词工程、上下文工程有什么区别

AI Agent 相关的“工程”概念不少，但它们并不是同一层东西。

可以把它们理解成一层一层往外扩：

flowchart TB
    A[提示词工程<br/>写好单次指令] --> B[上下文工程<br/>组织模型可见信息]
    B --> C[Harness Engineering<br/>配置单次 Agent 运行环境]
    C --> D[Loop Engineering<br/>让 Agent 多轮自动推进任务]

提示词工程管“怎么说”。上下文工程管“给它看什么”。Harness Engineering 管“这次运行怎么跑”。Loop Engineering 管“这一轮结束后，下一轮怎么继续”。

越往上，人越少做具体操作，越多做系统设计。

一个循环由五个动作组成

Loop Engineering 听起来像一个很大的系统，其实拆开后并不复杂。一个完整循环通常包含五个动作：

1. 发现：找出现在有什么值得处理。
2. 交付：让 Agent 生成修复、代码、文档或其他产物。
3. 验证：用测试、规则、审查 Agent 或人工门禁检查结果。
4. 记录：把状态写到对话之外，避免下一轮忘记进度。
5. 决策：根据验证结果决定继续、重试、升级给人，还是结束。

流程可以画成这样：

flowchart LR
    A[发现任务] --> B[生成交付物]
    B --> C[验证结果]
    C --> D[记录状态]
    D --> E{是否完成}
    E -- 是 --> F[结束或提交给人]
    E -- 否 --> A

关键点在于“循环”不是简单重复同一条命令。它每跑一轮，都会读取上一轮留下来的状态，并根据新结果调整下一步。

用 CI 修复任务理解 Loop Engineering

假设一个团队希望每天早上自动处理一部分 CI（持续集成）失败问题，可以设计一个这样的循环：

sequenceDiagram
    participant Scheduler as 定时器
    participant Finder as 发现模块
    participant Builder as 生成 Agent
    participant Reviewer as 验证 Agent
    participant Repo as 代码仓库
    participant Memory as 状态文件

    Scheduler->>Finder: 启动每日检查
    Finder->>Repo: 读取失败 CI、Issue、近期提交
    Finder->>Memory: 读取上次处理进展
    Finder->>Builder: 分配可处理任务
    Builder->>Repo: 在隔离工作区修改代码
    Builder->>Reviewer: 提交草稿结果
    Reviewer->>Repo: 运行测试并检查规则
    Reviewer->>Memory: 写入结果、失败原因、下一步
    Reviewer-->>Repo: 通过时创建 PR

这个系统每天可以做几件事：

• 读取昨天失败的 CI 任务。
• 找出适合自动修复的问题。
• 在隔离分支或临时工作区里改代码。
• 运行测试和检查规则。
• 通过后创建 PR。
• 失败时记录失败原因，下一轮继续或交给人。

它和普通定时脚本的区别在于，普通脚本通常只会按固定逻辑重复执行，而 Loop Engineering 里的 Agent 会根据当前状态选择动作。它不是“每天运行同一个脚本”，而是“每天根据仓库现状继续推进任务”。

循环系统需要哪些部件

一个可用的循环系统通常由六类部件组成。

这几个部件里，最容易被低估的是“验证”和“记忆”。

没有验证，循环会把错误越滚越大。没有记忆，循环每次启动都只知道当前上下文，看不到长期进度，复杂任务很容易断线。

生成器和评判器必须分开

Loop Engineering 里有一个非常重要的原则：

写代码的 Agent，不应该独自判断自己的代码是否合格。

原因很简单：生成者天然倾向于证明自己的结果已经完成。让同一个 Agent 既写代码又宣布“任务完成”，很容易出现假完成、漏测试、忽略边界条件等问题。

更稳的结构是把角色拆开：

flowchart LR
    A[任务目标] --> B[生成 Agent]
    B --> C[候选结果]
    C --> D[验证 Agent]
    D --> E{是否满足标准}
    E -- 满足 --> F[提交结果]
    E -- 不满足 --> G[指出问题]
    G --> B

生成 Agent 负责完成任务，验证 Agent 负责挑错。验证 Agent 不需要温和，它的任务是检查结果是否满足标准，而不是配合生成 Agent 结束工作。

验证标准越具体，循环越可靠。模糊目标会导致模糊结果。

不推荐这样写目标：

把功能开发完成。

更好的写法是：

完成用户登录功能，必须满足：
1. 支持邮箱和密码登录。
2. 密码错误时返回明确错误信息。
3. 连续 5 次失败后锁定 10 分钟。
4. 登录成功后返回有效 token。
5. 新增或更新测试，登录相关测试全部通过。

Agent 不擅长判断“好不好”，但更擅长核对清单。把主观标准拆成可检查条件，循环才知道什么时候该停。

/goal 和 /loop 的区别

在 Claude Code 这类 Agent 工具中，/goal 和 /loop 代表两种不同的循环方式：一种按目标推进，一种按时间运行。

/goal 的重点是“做到为止”。它适合有明确终点的任务，例如修复某个测试失败，或者完成一个功能清单。每一轮结束后，独立的验证逻辑会检查目标是否满足；如果没满足，就继续生成下一轮修改。

/loop 的重点是“按节奏运行”。它适合持续观察外部状态，例如每隔几分钟检查部署是否完成，或者定期扫描一批等待处理的 PR。

两者不要混用：

更简单的判断方式是：

flowchart TD
    A[任务是否有明确完成标准] -->|有| B[使用 goal]
    A -->|没有| C[是否需要周期性检查外部状态]
    C -->|是| D[使用 loop]
    C -->|否| E[先重新定义任务边界]

如果一个任务能写出验收条件，就优先考虑目标驱动。如果任务是在等待外部系统变化，就更适合时间驱动。

状态不能只存在上下文里

Agent 的上下文窗口不是可靠记忆。循环跑得越久，越需要把状态写到对话之外，例如 Markdown 文件、JSON 文件、数据库、Issue 评论或 PR 描述。

一个简单的状态文件可以长这样：

# loop-state.md

## 当前目标
修复 payment 模块中失败的 3 个测试。

## 已完成
- 修复 `test_refund_when_order_cancelled`
- 增加退款金额边界测试

## 待处理
- `test_refund_idempotency` 仍然失败
- 需要检查 refund_id 的唯一约束

## 最近一次失败原因
数据库迁移没有在测试环境中创建唯一索引。

## 下一步
检查 migration 文件，并补充测试环境初始化逻辑。

状态文件的价值不只是“备忘”。它让循环能够跨轮次恢复，也让人可以随时接管。一个没有外部状态的循环，本质上只是一次很长的对话；一旦上下文丢失，系统就很难继续之前的推理链路。

Loop Engineering 的常见坑

Loop Engineering 的风险不在于 Agent 会不会运行，而在于它会不会在没人注意的时候持续做错事。

其中最危险的是验证债。一个没有测试、没有审查、没有退出条件的循环，不是自动化工程，而是自动化放大器。它能放大正确流程，也能放大错误判断。

适合使用 Loop Engineering 的场景

Loop Engineering 适合任务边界清楚、反馈信号明确、可以拆成多轮推进的工作。

不适合的场景也要避开：

判断一个任务能不能交给循环，可以问三个问题：

1. 目标能不能写成清单？
2. 每一轮结果能不能被测试或规则验证？
3. 出错时能不能安全回滚或交给人？

三个问题都能回答清楚，才适合让循环自动推进。

搭建第一个循环的最小方案

不需要一开始就做复杂平台。一个最小可用的 Loop Engineering 系统可以只包含四个文件和一个执行入口：

agent-loop/
├── goal.md          # 目标和验收标准
├── loop-state.md    # 当前进展和下一步
├── rules.md         # 代码规范、限制、禁止事项
└── run-loop.sh      # 启动脚本

goal.md 负责定义终点：

# 目标

修复订单模块的退款测试失败。

# 验收标准

- 退款成功路径测试通过
- 重复退款不会产生第二笔退款记录
- 退款金额不能超过订单实付金额
- 所有 order 相关测试通过

rules.md 负责限制 Agent 的行为：

# 规则

- 只能修改 `src/order` 和 `tests/order`
- 不允许修改数据库连接配置
- 不允许跳过或删除现有测试
- 每轮结束必须更新 `loop-state.md`

循环每轮执行时，可以按固定顺序工作：

flowchart TD
    A[读取 goal.md] --> B[读取 rules.md]
    B --> C[读取 loop-state.md]
    C --> D[执行一轮修改]
    D --> E[运行测试]
    E --> F[更新 loop-state.md]
    F --> G{验收标准是否满足}
    G -- 是 --> H[停止并输出结果]
    G -- 否 --> I{是否达到轮次或预算上限}
    I -- 否 --> A
    I -- 是 --> J[停止并交给人]

这个最小方案已经具备循环工程的关键特征：有目标、有规则、有验证、有状态、有停止条件。复杂系统只是把这些能力接到更多工具上，例如 GitHub、CI、任务系统、日志平台和权限系统。

设计循环时要给它边界

一个可靠的循环必须有边界。边界不是束缚 Agent，而是防止它在不该自动化的地方继续扩张。

至少要设置四类边界：

边界越明确，循环越像工程系统；边界越模糊，循环越像一次失控的长对话。

核心结论

Loop Engineering 的重点不是让 AI Agent 更“自主”，而是让它在可控的结构里持续推进任务。真正有价值的循环，必须同时满足四个条件：

• 能发现任务，而不是只执行固定命令。
• 能交付结果，而不是只给建议。
• 能独立验证，而不是让生成者自我批准。
• 能记录状态，并根据状态决定下一步。

人仍然需要负责目标、边界、验证标准和关键决策。Agent 适合在这个框架里反复执行、修正和推进。设计得好，它能减少重复指挥；设计得差，它只会把错误更快地跑完。