硅谷热捧的"循环工程"究竟是什么？

我们才刚刚掌握 Prompt（提示词）的写法，才刚刚学会绘制几条 Workflow，刚刚弄清楚 Agent 与 Bot 的差异……结果一夜之间，硅谷的大佬们又开始疯狂推广一个新概念——Loop Engineering（循环工程）。

很多人一听就懵了：这又是什么晦涩难懂的专业术语？又在制造焦虑吗？旧框架要被淘汰了？

先别急！其实剥开这层“高大上词汇”的外壳，它的底层逻辑非常贴近实际，而且它真的能彻底拯救你每天和 AI“斗智斗勇、疯狂复制粘贴错误日志”的崩溃日常。

简而言之：

Loop Engineering = 构建一个“自动化循环机制”，让 Agent（智能体）自主按目标反复执行、自主查看错误、自主修改代码，直到完成任务，而不是让你像个苦力一样亲自去一条条手动提示它！

回想一下你平时是如何用 AI（比如 ChatGPT 或 Cursor）写代码的：

过去的“手动模式”：

你输入 Prompt：“帮我修改一下这段代码。”

AI 输出结果。你复制到本地运行。

报错了。你把错误日志复制下来，贴给 AI：“报错了，继续改。”

跑测试又失败了，你再把测试结果喂给 AI 继续问……

在这个过程中，你充当了那个“不断提示、不断搬运错误日志、不断按循环键”的苦力。

现在的“Loop Engineering 模式”： 正如技术专家 Addy Osmani 所描述的：“你不再自己充当不断提示 Agent 的人，而是构建一个系统，用系统替代你本人去提示 Agent。”

你只需设定好“目标”和“验证规则”，AI 会在这个闭环里自主工作、自主碰壁、自主查看错误日志、自主修改，直到达标或者达到你设定的最大尝试次数才停下来。

它的本质，是围绕“行动 + 反馈”的重复循环来组织 AI。一个标准的 Loop 运行起来是这样的（本质还是个PDCA循环）：

Daniel Demmel 将其称为Feedback Loop Engineering，其核心在于：让 Agent 能够运行自己的代码、看到真实结果、再迭代，而不是靠它“盲猜自己写对了没有”。

AI 圈各种“Engineering（工程）”满天飞，我们可以通过下面这张表，看懂它们各自在“优化什么”：

Workflow是告诉 AI“总共要走哪几个大站”；Loop Engineering则是让 AI 在某个大站里“自己反复死磕，做不对不准去下一站”。更准确地说，Loop 像是在 Agent 外部加了一层“外循环控制器”。

让我们用一个具体的底层/嵌入式开发场景，来看看 Loop Engineering 是如何落地的。

需求：修复 UART DMA 接收多传感器数据时的丢包问题。

你：“帮我修复 DMA 接收逻辑。”

AI 改完代码。

你去 Keil/GCC 编译，发现报错，把 Error 贴给 AI：“编译报错了，改。”

AI 修复编译错误。你烧录到板子上跑，发现丢包。

你把串口丢包日志贴给 AI：“还是丢包，继续分析。”

你不再跟 AI 对话，而是写好一个配置文件/脚本：

目标：修复多传感器数据接收丢包问题。

约束：1. 数据包不能拆；2. USB 发送不能阻塞采集；3. 保持通道前缀格式。

循环规则：

1. Agent 修改代码。

2. 触发make自动编译。

3. 触发自动化测试脚本（验证丢包率）。

4. 条件分支

如果编译失败 ➡️ 自动把编译器 Error 喂给 Agent。

如果丢包率超标 ➡️ 自动把统计结果喂给 Agent。

5. Agent 继续修改。

6. 停止条件：最多循环 5 次，或所有测试全部通过。

7. 收尾：全部通过后生成总结，停止运行（不自动 Merge 代码防暴走）。

在这个过程里，你泡了一杯咖啡，系统自己跑了 4 轮，最后把跑通的代码和总结呈现在你面前。

要构建一个真正能干活的 Loop 系统，你需要配置好这 7 样东西：

目标：要完成什么任务？

输入：初始代码、Issue 描述、日志。

执行器：Agent 本身（负责写代码、调用工具）。

验证器：必须是客观标准（如编译通过、Lint 无警告、测试脚本跑通、甚至截图对比）。

反馈机制：失败时，如何精准地把错误信息（报错行数、堆栈）提取并重新喂给 Agent。

停止条件：绿灯通过 / 达到最大重试次数上限 / 需要人工介入确认。

记忆：把本轮循环中“踩过的坑”、“总结的教训”写入文档库，避免下一次犯同样的错。

Loop 不是万能药。它最大的风险在于：如果你的“验证器 (Validator)”设计得很差，AI 会以极高的效率，自动化地把错误做无数遍。

所以，Loop Engineering 考验的不是“写提示词的文笔”，而是系统工程能力。关键不在于让 Agent 无限跑下去，而在于设计好严谨的验证标准、明确的停止条件、合理的人工审查点（Human-in-the-loop）以及成本控制（API Token 的消耗）。