Loop Engineering 是什么？AI Agent 时代的新范式，还是新瓶装旧酒？

最近，AI 编程圈里一个词突然热了起来：

Loop Engineering，循环工程。

有人说它会取代 Prompt Engineering，有人说它只是把老概念重新包装了一遍。那它到底是什么？能不能落地？有没有真实的实践价值？还是又一个技术圈的新名词游戏？

这篇文章试着从多个角度把它讲清楚。

一、先说结论

Loop Engineering 不是凭空出现的新技术，但也不只是营销概念。

它更准确的定位是：

AI Agent 时代，对“闭环自动化工程”的重新命名和重新组合。

它的新意不在于“循环”本身。

循环、反馈、验证、自动化，这些概念在软件工程、DevOps、控制论、自动化运维里早就存在。

它真正值得关注的地方在于：

现在的 AI 编程 Agent 已经具备了读代码、改代码、跑测试、读取错误、继续修正的能力。

于是，过去很多必须由人手动推进的工程闭环，开始可以被系统化地交给 Agent 执行。

二、什么是 Loop Engineering？

根据 Addy Osmani 的定义，Loop Engineering 的核心是：

你不再亲自一轮轮提示 Agent，而是设计一个系统，让这个系统去提示、调度、验证和推进 Agent。

以前我们使用 AI 编程工具，大多是这样的：

我提一个问题
AI 给一个答案
我复制代码
我运行测试
我把错误贴回去
AI 再改一版
我继续验证

这其实是一个“人肉闭环”。

而 Loop Engineering 想做的是，把这个闭环系统化：

发现任务
  -> 提供上下文
  -> Agent 执行
  -> 自动验证
  -> 读取结果
  -> 失败则继续修正
  -> 成功则记录状态
  -> 决定下一步

所以，Loop Engineering 关注的不是“如何写一条完美提示词”，而是：

• 任务从哪里来？
• Agent 拿到什么上下文？
• 它可以调用哪些工具？
• 怎么判断它做对了？
• 失败几次后应该停止？
• 哪些情况必须交给人？
• 多个 Agent 如何协作？
• 状态、日志、成本如何管理？

一句话概括：

Prompt Engineering 关注一次回答，Loop Engineering 关注一个持续运行的工程系统。

三、它和 Prompt Engineering 有什么区别？

可以用一张表理解：

| 维度 | Prompt Engineering | Loop Engineering |
|---|---|---|
| 工作单位 | 一条提示词 | 一个持续运行的工作流 |
| 优化目标 | 让模型这次回答更好 | 让系统最终完成任务 |
| 人的角色 | 手动提示者 | 流程设计者、监督者 |
| 核心能力 | 表达清楚 | 调度、验证、状态管理、失败控制 |
| 常见风险 | 回答不准确 | 错误被自动化放大、成本失控、误判完成 |

这并不意味着 Prompt Engineering 没用了。

恰恰相反，Loop 里面仍然包含很多 Prompt。只是 Prompt 不再是全部，它变成了系统中的一个零件。

更完整的层次大概是：

| 层级 | 作用 |
|---|---|
| Prompt Engineering | 单次指令怎么写 |
| Context Engineering | 给 Agent 什么上下文 |
| Harness Engineering | 单次 Agent 运行时的工具、权限和规则 |
| Loop Engineering | 多轮任务如何发现、执行、验证、升级和记录 |
| Fleet Engineering | 多个 Agent 或多个 Loop 如何治理 |

可以这样理解：

Harness 是给一次 Agent 执行装上工具和护栏。Loop 是让多次 Agent 执行形成持续闭环。

四、一个典型 Loop 长什么样？

假设我们要设计一个“自动修复 GitHub Issue”的 Loop，它可能是这样的：

1. 从 GitHub Issues 中找到带有 bug 标签的问题
2. 创建独立 worktree
3. 让 Agent 阅读 issue、相关代码和测试
4. Agent 提出修复方案
5. Agent 修改代码
6. 自动运行测试、lint、类型检查
7. 如果失败，把错误日志反馈给 Agent
8. Agent 继续修复
9. 最多尝试 3 次
10. 成功后生成 PR
11. 另一个 Agent 或人类进行 review
12. 记录本次处理结果

这个流程已经不是“一句提示词”能解决的事情。

它涉及任务发现、上下文组装、工具调用、验证机制、失败控制、状态记录和人工介入点。

这就是 Loop Engineering 和普通 Prompt 使用之间的差别。

五、Loop Engineering 能落地吗？

答案是：

可以落地，但不能理解成“按下按钮，AI 自动开发完整系统”。

目前更适合落地的场景包括：

• Issue 自动分类和补充上下文
• 小型 bug 修复
• CI 失败分析和局部修复
• 依赖升级
• 文档同步
• 测试补全
• 代码审查辅助
• 重复性迁移
• changelog 自动生成

这些场景有一个共同点：

边界相对清晰，验证方式比较明确。

比如测试能不能通过，lint 有没有报错，类型检查是否成功，文档是否和代码一致。

这些都是 Agent 可以围绕反馈不断修正的任务。

六、哪些场景不适合直接上 Loop？

Loop Engineering 不是万能的。

以下场景不适合一开始就全自动化：

• 产品需求不清楚
• 业务判断很重
• 架构方向需要权衡
• 涉及安全、权限、资金、数据删除等高风险操作
• 缺少自动化测试和验收标准
• 老系统高度耦合，影响范围难判断
• 团队本身没有工程规范

所以，Loop Engineering 的前提不是“AI 足够聪明”，而是：

你的工程系统本身要足够可验证。

如果没有测试，没有 lint，没有类型检查，没有 CI，没有 review 规范，Loop Engineering 很容易变成：

AI 在黑箱里反复自嗨。

这不是工程化，而是自动化地制造不确定性。

七、它的实践价值在哪里？

Loop Engineering 真正有价值的地方，主要有三个。

1. 把 AI 使用从“聊天”推进到“工程系统”

很多团队现在用 AI 编程，仍然停留在问答模式。

人负责拆任务、贴上下文、跑测试、判断结果，AI 只是提供代码片段。

Loop Engineering 的价值在于，把这些重复动作变成系统流程。

人不再每一步都亲自推动，而是设计好规则、边界和验证机制，让 Agent 在闭环中持续推进。

2. 让“验证”成为 AI 工作流的中心

AI 编程最大的问题不是它不会写代码，而是它经常“看起来对”。

Loop Engineering 的重点不是让 AI 多写代码，而是让 AI 在反馈中工作。

这些反馈可以包括：

• 单元测试
• 集成测试
• lint
• 类型检查
• 构建结果
• 浏览器检查
• 日志分析
• 静态扫描
• Code Review

好的 Loop 应该不断把这些验证信号反馈给 Agent，让它基于事实修正，而不是基于自信继续生成。

从“看起来对”，变成“被验证过”，这是 Loop Engineering 的核心价值之一。

3. 让团队沉淀可复用的 Agent 工作流

以前，一个资深工程师怎么用 AI，很大程度上是个人经验。

他知道怎么拆任务，怎么补上下文，怎么让 AI 修错误，怎么判断结果是否靠谱。

但这些经验很难复制给团队。

Loop Engineering 试图把这些经验沉淀成：

• 项目规范
• Agent 指令
• 工具权限
• 验收规则
• 自动化脚本
• 失败处理策略
• 人类介入节点

这对团队非常重要。

因为 AI 不应该只靠每个人临场发挥，而应该被纳入工程流程。

八、Loop Engineering 的风险

Loop Engineering 最容易被高估的地方，是大家容易把“循环”误解成“自主智能”。

但实际上，Loop 的质量取决于一堆非常现实的工程问题：

• 任务是否清晰
• 上下文是否完整
• 工具是否可靠
• 验证是否有效
• 停止条件是否明确
• 权限边界是否安全
• 成本是否可控
• 人类是否仍在关键节点判断

常见反模式包括：

• 让同一个 Agent 自己实现、自己验收
• 没有最大尝试次数，导致 token 成本失控
• 测试很弱，却把测试通过当成完成
• 没有人类 review
• Agent 可以直接修改高风险配置
• 状态记录混乱，失败原因无法追踪
• 多 Agent 互相调用，但没有最终负责人

尤其要注意一点：

不能让 Agent 同时当运动员和裁判。

一个 Agent 写代码，最好由另一个 Agent 或人类来检查。关键业务场景，最终判断权仍然应该在人手里。

九、GitHub 上有相关实践吗？

有，而且已经出现了一批项目。

比较值得关注的包括：

1. cobusgreyling/loop-engineering

这是目前最贴近 Loop Engineering 概念的仓库之一。

它提供了模式、starter、CLI 工具、反模式文档等内容，面向 Grok、Claude Code、Codex、Cursor 等 AI coding agents。

项目地址：

https://github.com/cobusgreyling/loop-engineering

2. eugenelim/agent-ready-repo

这个项目关注如何把一个 repo 改造成适合 Agent 工作的结构。

它强调 plan、execute、verify、review，并通过检查机制限制 Agent 走捷径。

项目地址：

https://github.com/eugenelim/agent-ready-repo

3. Saik0s/agent-loop

这是一个 AI 驱动软件开发框架，用 orchestrator 管理多个专门 Agent，覆盖计划、架构、编码、测试和部署等流程。

项目地址：

https://github.com/Saik0s/agent-loop

4. GitHub Topic: loop-engineering

可以通过 GitHub Topic 观察相关项目生态。

https://github.com/topics/loop-engineering

不过整体来看，这个生态还处在早期。

很多项目更像是模式库、实验框架、starter 或概念验证，还没到成熟标准框架的阶段。

十、它是不是新瓶装旧酒？

这个问题很关键。

我的判断是：

一半是旧酒，一半是新瓶真的有用。

说它是旧酒，是因为这些思想以前就存在：

• DevOps 里有 CI/CD 闭环
• 控制论里有反馈控制
• 软件工程里有测试驱动开发
• 自动化运维里有 observe -> act -> verify
• 机器人系统里有 perceive -> reason -> act
• 工作流系统里早就有 orchestration
• AutoGPT 时代也讲过 agent loop

所以，“循环、反馈、验证、自动化”不是新东西。

但说它不只是旧酒，是因为这一次循环中的执行单元变了。

过去自动化流程里的执行步骤，多数是确定性脚本：

运行测试
执行构建
部署服务
发送通知

而现在，循环里多了一个可以读代码、理解需求、修改实现、补测试、解释错误、继续修复的 AI Agent。

理解 issue
定位代码
提出方案
修改实现
补充测试
读取失败日志
继续修复

这让很多过去难以自动化的“半结构化工程任务”进入了自动化范围。

这就是 Loop Engineering 值得单独讨论的原因。

所以更准确的说法是：

Loop Engineering 是旧的闭环工程思想，在 AI Agent 能力成熟后的重新工程化。

它不是科学突破，但它可能是工程范式的变化。

十一、现在成熟了吗？

以目前来看，Loop Engineering 仍处于早期阶段。

我会给它一个判断：

概念热度高，实践还早期，但方向成立。

它还不是像 React、Kubernetes、GitHub Actions 那样成熟稳定的技术生态。

但背后的趋势是真实的：

• AI Agent 会越来越能长时间执行任务
• 代码仓库会越来越需要变得 agent-ready
• 工程团队会把 AI 纳入 CI、review、issue、文档、测试流程
• 人类会从逐步操作，转向设计边界、验证标准和升级机制

真正有价值的，不是追逐“Loop Engineering”这个词，而是吸收它背后的工程原则：

明确目标
提供上下文
限制权限
自动验证
记录状态
控制成本
失败升级
人类最终负责

十二、如果要落地，应该怎么开始？

不建议一上来就做“全自动开发 Loop”。

更稳妥的路径是分阶段推进。

第一阶段：只读 Loop

先让 Agent 做观察和分析，不直接改代码。

比如：

• 自动总结 issue
• 分析 CI 失败原因
• 生成 review 建议
• 扫描代码风险
• 汇总文档差异

这一阶段风险低，也方便团队建立信任。

第二阶段：低风险写入 Loop

再让 Agent 做一些边界清晰的修改。

比如：

• 更新文档
• 生成测试
• 修复格式问题
• 升级小版本依赖
• 修改简单 bug

但仍然需要 review 和 CI 验证。

第三阶段：受控开发 Loop

最后再进入更复杂的代码修改流程。

此时必须有：

• 最大尝试次数
• 可修改目录限制
• 必须通过的检查
• 明确的停止条件
• 失败后的升级机制
• 人类 review

核心原则是：

让 Agent 多做重复劳动，但不要让它绕过工程纪律。

十三、最终判断

Loop Engineering 不是纯新概念，也不是纯炒作。

它更像是 AI Agent 时代对软件工程自动化的一次重新分层。

Prompt 是零件。
Context 是燃料。
Harness 是单次运行环境。
Loop 是可持续交付系统。

如果一个团队只是把“让 AI 多跑几轮”叫做 Loop Engineering，那它确实只是新瓶装旧酒。

但如果团队真的把它落到：

• 测试
• CI
• 权限控制
• Code Review
• 状态记录
• 成本控制
• 失败处理
• 人类介入机制

这些硬东西上，那它就不只是一个新名词。

它可能代表着 AI 编程从“个人效率工具”进入“工程化生产系统”的一个重要阶段。

真正的问题不是：Loop Engineering 是不是新概念。

真正的问题是：

你的团队有没有能力设计一个可信、可控、可验证的 AI 工作闭环？