AI 圈又在造新词：所谓 Loop Engineering，不过是自动化换了个包装
AI 圈又在造新词：所谓 Loop Engineering，不过是自动化换了个包装
AI 圈造新词的速度，已经快赶上模型更新了。
前脚还在讨论 Prompt Engineering，后脚有了 Context Engineering、Harness Engineering，现在又冒出来一个 Loop Engineering。
听名字，好像 AI 编程又迎来了一次方法论升级：以后不需要自己写提示词了，只要设计一个循环，让 Agent 自动发现任务、修改代码、运行测试、检查结果，再进入下一轮。
听起来很厉害。
但把外面的包装拆开，你会发现里面装的基本都是老熟人：定时任务、工作流、状态管理、Git Worktree、自动测试和代码审查。
这些东西早就存在。现在把 Agent 塞进流程中间，再统一取一个叫 Loop Engineering 的名字，就成了一门新“工程学”。
循环当然有用，自动化也很重要，但“有用”和“全新的工程范式”是两回事。
先看看 Loop Engineering 在说什么
目前对 Loop Engineering 比较常见的解释是：不要再由人一条条提示 Agent，而是设计一套能够持续提示 Agent 的系统。
这套系统通常包含以下流程：
▼text复制代码发现任务 ↓ 调用 Agent 执行 ↓ 运行测试或检查 ↓ 记录当前状态 ↓ 没有达到目标就继续下一轮
为了让它运行得更像样，还会加上定时触发、并行 Agent、独立 Worktree、Skills、MCP 连接器和外部状态文件。
把这些词放在一起，确实显得很有未来感。
可如果你做过自动化系统，就会发现这套结构并不陌生。它就是一个带有状态、判断条件和重试机制的工作流，只不过其中一些步骤从固定代码换成了大模型。
拆开包装，里面都是什么
Loop Engineering 常见的几个“核心能力”，几乎都能在传统软件工程中找到对应物。
| Loop Engineering 中的说法 | 原本的工程概念 |
|---|---|
| 自动发现并触发任务 | Cron、Scheduler、事件触发器 |
| 让任务持续流转 | Workflow、状态机、任务队列 |
| 隔离多个 Agent 的修改 | Git Branch、Worktree |
| 保存跨轮次记忆 | 文件、数据库、任务看板 |
| 自动判断任务是否完成 | 测试、CI、验收规则 |
| 让另一个 Agent 复核 | 代码审查、职责分离 |
就连“一个 Agent 负责写，另一个 Agent 负责检查”也不是什么新思想。
软件开发早就在强调开发和审核分离，测试也不会因为代码是同一个人写的，就自动相信它没有问题。
如今把审核者换成另一个模型，只是执行主体发生了变化，背后的工程原则并没有变。
真正新增的东西，其实只有一块
当然，也不能说这里完全没有变化。
过去的自动化流程要求步骤足够确定：收到什么输入、执行什么命令、出现什么结果，都要提前写进程序。
大模型加入后，可以处理一些不容易写成固定规则的工作，例如：
- 阅读日志并猜测失败原因
- 从多个 Issue 中挑选下一项任务
- 根据项目结构决定修改哪些文件
- 结合测试结果调整下一次尝试
- 将零散信息整理成新的任务说明
这确实扩大了自动化能够覆盖的范围。
但这更像是给现有工作流增加了一个不确定的执行节点，而不是重新发明了工作流本身。
以前流程节点调用脚本、接口或人工审批，现在其中一个节点调用 Agent。变化发生在节点内部，不代表调度、状态、重试和验收这些基础概念都需要换个新名字。
如果非要起名，叫“Agent Workflow”或者“AI 辅助自动化”可能更加准确。
为什么 AI 圈喜欢不断创造新词
因为旧概念不容易制造新鲜感。
你说“给 Agent 加一个定时任务”，听起来只是普通自动化；换成“设计自主 Agent Loop”，立刻像是在讨论下一代软件工程。
你说“把执行进度写进文件”，这叫状态持久化；换成“为 Agent 构建外部记忆”，味道马上不一样了。
你说“用独立分支避免代码冲突”，大家都懂；换成“多 Agent 并行隔离架构”，就更适合写进演讲标题。
新词并非完全没有价值。一个统一名称可以帮助传播，也方便把零散工具放到同一个话题里讨论。
问题在于，当包装盖过内容以后，人们很容易把“已有组件的组合”误以为“出现了新的底层能力”。
最后讨论的重点从工程是否可靠，变成了谁还没有用上最新概念。
Loop 不会让 Agent 突然变聪明
循环只是让同一套流程重复执行，它不会自动提高模型的判断能力。
如果 Agent 第一次就理解错了需求，Loop 可能让它稳定地错上十次。
如果验收条件只有一句“继续优化”，它会不断寻找可以修改的地方，直到耗完 Token 或把原本正常的代码改坏。
如果检查结果仍然由模型自己判断，那么“任务已完成”很可能只是它自己的结论。
如果没有保存失败原因，下一轮还可能重新尝试刚刚失败过的方法。
把一个不稳定的 Agent 放进无限循环，不是工程能力升级，只是把错误从偶发变成批量生产。
用一个例子看看它到底新不新
假设我们希望每天自动处理项目中的 CI 失败。
按照 Loop Engineering 的说法，可以设计这样一套流程：
- 每天定时读取 CI 状态
- 发现失败后，让 Agent 分析日志
- 创建独立 Worktree 修改代码
- 自动运行测试
- 测试失败就继续修改
- 测试通过后让另一个 Agent 检查
- 生成 Pull Request 等待人工确认
如果不使用这些新名词，这件事可以描述成：
▼text复制代码一个定时触发的 CI 修复工作流， 其中日志分析和代码修改步骤由大模型执行。
是不是突然朴素了很多？
这个流程可以有实际价值，但价值来自 CI、权限控制、隔离环境、测试和人工确认共同形成的约束，不是因为我们给它起了 Loop Engineering 这个名字。
比学新名词更重要的六个问题
与其研究自己的流程算不算 Loop Engineering，不如先把下面六个问题回答清楚。
1. 什么事件触发任务
是固定时间、CI 失败、Issue 更新，还是人工确认？
如果任务入口不明确，Agent 每一轮都只能猜接下来该做什么。
2. 状态保存在哪里
会话关闭以后，下一轮从哪里读取已经完成的工作、失败原因和剩余任务？
只依赖聊天上下文的循环，不是真正可靠的长期流程。
3. 怎样才算完成
“代码质量更好”“继续优化”都不是可以验证的结束条件。
测试通过、构建成功、指标达到阈值，才是机器能够判断的验收规则。
4. 失败多少次必须停止
重试次数、运行时间、Token 消耗和并发数量都应该有上限。
没有停止条件的 Loop，本质上就是一个可能持续烧钱的 while(true)。
5. Agent 能操作哪些东西
它能不能推送代码、创建 Pull Request、修改数据库或访问生产环境？
权限越大，循环出错后的影响范围越大。默认应该只开放完成当前任务所需的最小权限。
6. 最后由谁负责
另一个 Agent 的复核不等于人工审核，更不等于责任已经转移给模型。
自动化系统可以执行工作，但最终仍然需要有人对上线结果负责。
这六个问题比 Loop Engineering 的定义重要得多，因为它们决定流程到底是工程系统，还是一个自动重复提示词的脚本。
“让 Agent 自己检查”也没有想象中可靠
Loop Engineering 经常强调执行 Agent 和检查 Agent 分离。
这个方向听起来合理，但容易产生一种错觉：只要换一个 Agent 检查，结果就可信了。
实际上，两个 Agent 可能共享相同的模型、相似的训练数据和相同的错误倾向。第二个 Agent 能发现一部分问题，但它不是独立的事实来源。
真正可靠的验证仍然来自可重复的测试、静态检查、数据对比、权限约束和人工审查。
如果缺少这些客观证据，再多加几个 Agent，也只是让模型互相评价模型。
自动运行越久，风险不一定越小
很多人把“可以长时间运行”当成 Agent 能力增强的证明。
但从工程角度看，运行时间越长，反而越需要警惕：
- 上下文不断累积，早期错误可能影响后续判断
- 修改范围逐渐扩大，人工越来越难审查
- Token 和工具调用成本持续增加
- 多个 Agent 并行后，合并与复核成为新的瓶颈
- 自动生成的代码越来越多，团队对系统的理解可能越来越少
Agent 可以一晚上生成几十个改动，不代表团队第二天有能力理解和验证这几十个改动。
自动化的产出速度超过审查速度后，多出来的不是生产力，而是待确认的风险。
可以用 Loop，但没必要迷信 Loop Engineering
我并不反对给 Agent 加定时任务，也不反对让它自动读取日志、运行测试和继续尝试。
这些工具该用就用，能减少重复操作当然是好事。
我质疑的是，把一套已有多年的工程实践重新组合后，包装成一种即将取代 Prompt Engineering 的新范式。
提示词不会消失。Agent 每一轮仍然需要任务说明、上下文和约束，只不过这些提示词从人手动输入，变成了由程序定时发送。
软件工程的核心也没有改变。我们仍然需要明确需求、限制权限、保存状态、编写测试、处理异常和承担结果。
Agent 没有让这些问题消失，只是让流程跑得更快了。
而一个方向错误的流程，跑得越快，离正确答案越远。
写在最后
Loop Engineering 这个名字可以留下，毕竟行业需要一些词来概括新的使用方式。
但没必要被名字吓住，更没必要因为没搭建所谓的 Agent Loop，就觉得自己的开发方式已经落后。
把它拆开看，无非是：
▼text复制代码自动触发 + 工作流编排 + 状态持久化 + 隔离环境 + 自动验证 + 大模型执行部分模糊任务
真正值得学习的是这些组件如何组合、怎样限制风险，以及什么时候应该让人接手，而不是再背一个听起来很新的英文名词。
技术可以更新，工具可以变化，但工程问题不会因为换了包装就自动解决。
少追一点新词，多问几个边界问题，可能比搭建一个能够无限运行的 Loop 更有价值。
参考资料 Addy Osmani：Loop Engineeringz：https://addyosmani.com/blog/loop-engineering) Claude Code 文档：Run prompts on a schedule：https://code.claude.com/docs/en/scheduled-tasks
欢迎关注我的公众号【兮动人】，每天分享一些技术文章和实战经验。
