Loop Engineering循环工程

一、什么是 Loop Engineering

1. 一句话定义

Loop Engineering（循环工程）关注的不是「这一句 Prompt 怎么写」，而是：如何设计一套能自动发现任务、执行、验证、记录状态，并决定下一步的闭环系统。

你不再坐在 Agent 旁边逐轮打字，而是设计「会给 Agent 下指令、会判断成败、会决定何时停止」的外层循环。

2. 和 Prompt Engineering 的区别

维度	Prompt Engineering	Loop Engineering
关注点	怎么问 AI	怎么让 AI 持续把事做完
交互方式	人问一句，AI 答一句	系统驱动多轮迭代
成功标准	单次输出看起来对	可验证目标达成（测试通过、构建成功等）
人的角色	提问者	规则与系统设计者
失败处理	人再改一句 Prompt	系统根据反馈自动重试或升级给人

可以粗略记成：

1 2	Prompt Engineering：教 AI 怎么做 Loop Engineering：设计一个系统，让 AI 自己持续做

3. AI 工程能力的演进

过去几年，AI 开发的重心大致经历了这样的上移：

Prompt：怎么问
    ↓
Context：给 AI 看什么
    ↓
Harness：在什么环境里、用什么工具干活
    ↓
Loop：做完一步之后怎么办（检查、修正、继续、停止）

阶段	核心问题
Prompt Engineering	这一句话怎样写得更准？
Context Engineering	Agent 应该看到哪些代码、文档、历史？
Harness Engineering	Agent 有哪些工具、权限、沙箱与保护？
Loop Engineering	何时运行、如何验证、如何继续、何时停止？

Loop 不是否定前面几层，而是把它们串成可重复运转的闭环。

二、概念从哪里来

2026 年前后，AI 编程社区把这类实践逐渐命名为 Loop Engineering。几个常见表述大意是：

不再亲自逐条 Prompt，而是让「Loop」去提示 Agent、决定下一步
工程师的工作重心，从写提示词，转向写循环、写规则、写验证

这和工具形态的变化是对得上的：

代际	代表形态	瓶颈
补全型	早期 Copilot	只能辅助，决策全在人
对话型	ChatGPT / Claude 网页	每一步都要人推进
Agent 循环型	Claude Code、各类 Coding Agent	如何让闭环可靠、可停、可审计

第三代工具出现后，「会不会写 Prompt」仍然重要，但更稀缺的是：会不会设计可靠的 Loop。

三、内循环与外循环

1. Agent 自带的内循环

单个 Agent 执行任务时，通常已经有一个内置循环，类似：

1	感知 → 推理 → 行动 → 观察 →（再感知）

落到写代码场景，常见路径是：

1	读文件 → 改代码 → 跑测试 → 读报错 → 再改

这是 Agent「自己转圈」的能力。

2. 你要设计的外循环

Loop Engineering 主要工作在外循环：

1	发现任务 → 分派 Agent → 验证结果 → 持久化状态 → 决定下一轮 / 停止

层级	谁驱动	做什么
内循环	Agent	单次任务内的读写、执行、自修
外循环	你设计的系统	任务发现、调度、验证、记忆、停止策略

外循环的价值在于：把「人盯着屏幕点下一步」变成「系统按规则推进」，人只在关键节点介入。

四、一个可靠 Loop 的核心要素

不同文章拆法略有差异，但可靠闭环通常离不开下面几块。

1. 明确目标（Goal）

「完成」必须可描述、最好可机械检查。例如：

单元测试全部通过
lint / 类型检查无错误
指定接口行为符合约定
生成 draft PR 且 CI 绿灯

模糊目标（「把代码写优雅一点」）很难闭环，因为系统不知道何时该停。

2. 充足上下文（Context）

每轮启动时，Agent 需要看到：

目标与约束（如 VISION.md、RULES.md）
当前状态（已完成什么、卡在哪）
相关代码与文档
上一次失败的客观反馈（测试日志、编译错误）

3. 受限动作（Action）

只开放必要工具：读文件、改文件、跑命令、开 PR 等。权限过大容易「能干坏事」；权限过小又转不动。

原则是：能完成目标的最小工具集。

4. 客观反馈（Feedback）

反馈可信度决定闭环质量。优先使用 Agent 骗不过去的信号：

反馈类型	例子	可信度
确定性验证	编译器、单元测试、类型检查、linter	高
半客观验证	契约测试、快照对比	中高
主观评判	LLM-as-judge、人工观感	中低，宜作补充

核心原则：每一步都验证，防止错误累积。

5. 停止条件（Stop Condition）

至少准备几类互相独立的出口：

成功：验证通过
硬上限：最大步数 / 最大耗时 / 预算耗尽
无进展：连续多轮犯同类错误
升级：危险操作或卡住时交给人（Human-in-the-Loop）

没有停止条件的 Loop，不是自动化，是失控。

6. 持久状态（Persistent State）

模型上下文会遗忘、会漂移。不要把「会话窗口」当唯一记忆。

更稳妥的做法是把状态落到外部系统：

Git 仓库与分支
Markdown / JSON 状态文件
Issue / PR 评论
数据库或任务队列

每一轮可以从「干净上下文」启动，但必须站在真实持久化内容之上继续工作。

五、闭环骨架：五阶段循环

多数编码类 Loop 可以压成同一骨架，直到满足可验证停止条件：

Discover（发现）
   ↓
Plan（规划）
   ↓
Execute（执行）
   ↓
Verify（验证）
   ↓
Iterate / Stop（迭代或停止）

阶段	做什么
Discover	从 backlog、失败 CI、Issue、TODO 中找下一件可做的事
Plan	拆成小步骤，明确本轮成功标准
Execute	Agent 改代码、跑命令、调用工具
Verify	测试 / lint / 构建 / 契约检查
Iterate	失败则带着新反馈重试；成功则固化状态并进入下一任务

Loop 的力量不在某一步「特别聪明」，而在于：失败本身变成下一轮的输入。测试红了不是终点，是新的上下文。

六、闭环 vs 开环

类型	特征	风险
开环	跑完一轮就结束，或只靠人肉续跑	依赖人盯梢，难规模化
闭环	有目标、反馈、重试、停止与状态	设计成本更高，但可长期运转

闭环的五个必要组成可以记成：

明确目标
充足上下文
受限动作
客观反馈
清晰停止条件

缺反馈或停止条件，看起来像「自动」，实际是「盲跑」。

七、实践中的关键组件

结合社区常见拆法，落地时经常会碰到这些组件：

组件	作用
Automations	触发器：定时、Webhook、CI 事件，给 Loop「心跳」
Worktrees / 隔离环境	避免多任务互相踩文件
Persistent State	跨轮次记忆任务进度与决策
Skills / 工具集	可复用工作流与工具访问
Sub-agents	执行者与检查者分离（Maker / Checker）
Connectors	连接真实系统（仓库、Issue、CI、MCP 等）
Human-in-the-Loop	高风险步骤人工门控
预算与限流	控制成本、防止死循环烧钱

其中最值得强调的两点：

验证优先于单次聪明：宁可每步都跑测试，也不要指望「一次生成就完美」。
卡住就升级：系统设计成「发现无进展就交给人」，而不是「祈祷永不失败」。

八、一个最小可运行例子（思路）

不必一上来做企业级平台，可以先做一个「修测试」小闭环：

目标：指定目录下测试全部通过
触发：手动或 CI 失败事件
循环：
  1. 读取失败日志
  2. Agent 修改代码
  3. 重新跑测试
  4. 通过则提交 / 开 draft PR；失败则把新日志写回状态文件
停止：
  - 测试全绿 → 成功停止
  - 超过 N 轮仍失败 → 升级给人

伪代码示意：

MAX_STEPS = 10
state = load("state.json")

for step in 1..MAX_STEPS:
  context = build_context(state)
  agent.act(context)                 # 改代码 / 跑命令
  result = run_tests()               # 客观反馈
  save_state(state, result)

  if result.ok:
    open_draft_pr()
    break
  if no_progress(state):
    escalate_to_human()
    break

你会发现：Prompt 只是其中一小段；真正决定成败的是验证、状态、停止条件。

九、常见误区

误区	为什么有问题	更好做法
只堆更长 Prompt	解决不了跨轮遗忘与漂移	外置状态 + 每轮重建上下文
没有客观验证	错误会滚雪球	测试 / lint / 类型检查优先
没有步数上限	成本失控、死循环	MAX_STEPS + 预算熔断
执行者兼裁判	自我开脱、漏检	Maker / Checker 分离
目标不可测	永远不知道何时完成	把完成定义成可检查条件
权限过大	误删、误推、误发	最小权限 + 危险操作人工确认

十、对工程师意味着什么

Loop Engineering 带来的角色变化大致是：

以前更像	现在更像
会提问的使用者	会设计系统的架构者
盯着对话窗口推进	设计触发、验证、停止与升级策略
追求单次回答质量	追求闭环可靠性与可审计性

能力侧重点也会变：

把模糊目标翻译成可机械检查的终止条件
会搭工具链与反馈回路（测试、CI、沙箱）
会治理长期状态（哪些该记、哪些该丢）
接受「系统会失败」，并设计失败后的路径

一句话：重验证，胜过重单次聪明。

十一、和日常开发怎么结合

即使不搭完整 Agent 平台，也可以先用 Loop 思维改造工作方式：

写任务时先写验收标准：怎样算做完？哪条命令能证明？
让失败日志成为下一轮输入：别只看一眼红字就重开对话。
小步实验：一次只改一类问题，跑通再扩大。
状态外置：用 Issue、PR、笔记记录「当前假设 / 已尝试 / 下一步」。
危险操作留人工门：推正式分支、改生产配置、删数据等必须门控。

这和本博客里谈的「工匠思维」「刻意练习」并不冲突：Loop 解决的是如何规模化地推进与纠错，工匠解决的是能力本身是否够硬。两者叠加，才既会做，又能持续做对。

十二、小结

Loop Engineering 可以记成三句话：

从「写 Prompt」升级到「设计闭环」
闭环的核心不是转圈，而是可验证的反馈与停止
状态放在会话外，失败变成下一轮输入，卡住就升级给人

如果你已经在用各类 Coding Agent，不妨问自己四个问题：

成功标准能不能被机器检查？
每一步有没有客观反馈？
状态会不会在下一轮还在？
最坏情况下会不会自动停下来？

把这四件事设计清楚，你就已经在做 Loop Engineering 了——哪怕第一版只是一个十行脚本加一套测试命令。