写在前面
前面可以不看，就是说说话，很久不写文了。
沉寂了一段时间后，最近我又把精力投入到了 AI Agent 的开发中。在查阅资料时，我发现 Loop Engineering（循环工程）这个词突然在各大技术社区霸屏。初步了解下来，它给我的第一印象是：将 AI 烧钱这件事更深的刻到了每个开发者心里，会导致 Token 爆炸起飞；但它在复杂任务上的最终完成度却出奇的高。
刚好这两天手头的项目告一段落，我终于可以带着偏见来研究一下。结果查看了几篇文章之后，我猛然发现：Loop Engineering 不就是我一直在用的开发模式吗？ 并且我们开发的 AI 项目已经落地了这种模式，只是我之前 日用而不知。
回想刚开始接触这个概念时，我被网上的一些文章带偏了。我以为，Loop Engineering 就是 用户丢进一句 Prompt，系统就能全自动理解需求并完美达成目标 的神奇的东西？直到最近，在查阅了一些专业文档后并与群里的大佬们讨论后，我才彻理清了它的真实边界与运作机制。
当然，Loop Engineering 确实伴随着一个致命的痛点：Token 爆炸。但刚好，今年以来我一直在这种模式下摸爬滚打（省钱），在如何控制上下文、实现 Token 收敛，刚好积累了一些行之有效的实战经验。
在正式进入技术细节前，我想先澄清一个被严重误导的误区。最近网上充斥着诸如《SDD（规格驱动开发）已过时...》、《开发新范式 Loop Engineering ...》等博眼球的标题，让我一度以为 Loop Engineering 是要 消灭 其他范式。但实际上，工程界从来没有银弹，Loop Engineering 与 SDD 等范式绝不是非此即彼的替代关系，而是互补共存的。
接下来，我将结合最近的思考与项目实践，聊聊我对 Loop Engineering 的真实理解，以及如何在这个 Token 爆炸 的时代，把成本死死按住。
一、先说说 Loop Engineering 吧
1.1 我的 AI 编程 “进化史”
在正式聊 Loop Engineering 之前，我想先回顾一下自己的 AI 编程心路历程。因为正是这些工具的演进，把我一步步推向了 Loop Engineering。
阶段一：把 AI 当“高级搜索引擎”（2022年）
记忆拉回 2022 年，ChatGPT 刚上线那会儿。那时的我，终于体验到了不用在浏览器里开十几个窗口查资料的快感。遇到报错，直接把日志丢给 GPT 排错；需要写点小脚本，也让它生成后复制粘贴到项目里。那时候，AI 在我眼里只是一个极其聪明的助手，脏活累活都给他做就对了。
阶段二：深度依赖与“技术戒断反应”（Cursor 爆发期）
后来，Cursor 横空出世。说实话，早期的 Cursor 生成的代码质量有时让人一言难尽，但它带来的效率提升是颠覆性的，帮我省去了无数繁琐的机械劳动。
也就是从那时起，我产生了一种深深的 技术依赖 ——甚至偶尔会恐慌：如果有一天断网了、用不了 AI 了，那个扫地、打扫厕所的人又是我自己了，自己手写代码太累了，我已经彻底躺平在 AI 的 石榴裙 下了。
阶段三：Vibe Coding（氛围编程）的狂欢
因为我个人就像失败的 winer 一样，终端在上学时期（交换机路由器配置）有着非常恐惧的不好印象，所以我热衷于尝试各种 IDE，只要不是终端我都心理门槛下降一百倍。
我忘记什么原因了，之后 Cursor 用不了后，我就开始用 vscode 中 codebuddy 插件，免费又好用，在之后得知腾讯 codebuddy 中的 default 就是克劳德后一直用了很长一段时间，并且开销也不大。
在这个阶段，我和我那些用着 API 中转站的同事们一样，都进入了一种被称为 “Vibe Coding（氛围编程/直觉编程）” 的状态：我们不再关心底层的具体实现，遇到问题就敲 Prompt，想做什么就写 Prompt。 代码是在一种“凭感觉、靠氛围”的对话中拼凑出来的。
阶段四：觉醒时刻——从 Vibe 到 Loop
这种“一问一答”的 Vibe Coding 状态持续了很久，直到最近 2026年初，随着 Qwen3.5 等优秀开源模型的推出（当时铺天盖地的宣传），我的开发模式迎来了真正的拐点。
当时为了找 Qwen3.5 的模型试用，想到了同为阿里系的 Qoder，却意外发现了它的 Quest 模式 （一种多步自主执行/Agent 模式），而 Quest 是 25年8月上线的（不是软广，是因为刚好当时找 qwen3.5）。
当看到 AI 不再是被动地等我输入 Prompt，而是开始自主拆解任务、循环执行、自我纠错时，我恍然大悟：这一切，就是从这个时候开始改变的。而这，正是 Loop Engineering 在我个人开发流中的真正起点。
注意：虽然大家都在用，但是准确命名为 Loop Engineering 由 OpenClaw 创始人 Peter Steinberger 在 2026 年 6 月的一条推文中正式提出，随后 Google 工程师 Addy Osmani 与 Anthropic Claude Code 负责人 Boris Cherny 共同推波助澜，让它成为继 Prompt / Context / Harness Engineering 之后的第四代 AI 工程范式。
1.2 Loop Engineering 是什么
在历经了 提示词工程、上下文工程、编排工程等一系列“调教 AI”的漫长摸索后，大佬们终于迈出了统一的步伐，走到了一起，引用在群里讨论时一个大佬说的话“大部分做工程的，为了解决问题最终都会选择相似的道路。”。
其实 Loop Engineering 并没有网上吹的那么晦涩难懂，它的核心逻辑非常直白：“你只管输入目标，系统自己把活干完”。听到这儿，你大概率会想：“这个作者那么水吗？解释不明白别解释，跟以前有什么区别？...”
确实，表面上看都是提需求到拿结果。但你仔细回想一下以前的痛苦经历：AI 给你生成了一坨代码，你满怀期待地一品，臭不可闻（报错了确实是shi）。然后呢？你得自己去看日志，把报错信息复制下来，再丢给 AI 让它改。改完再跑，再报错，再复制……然后这是个 loop。
在这个过程中，你其实一直是个人肉质检员兼擦屁股的。在 AI 达成最终目标前，你必须死死盯着，不断介入，还要端着臭不可闻的一坨代码给AI，告诉他这是一坨，心累得很。
但 Loop Engineering 就不一样了，这个时候就强迫 AI 自己的一坨自己看。它接收目标后，会自己去理解、自己制定计划、自己执行。最爽的是，遇到报错了，它自己捕获、自己分析、自己修复，在内部疯狂 loop（循环），直到把代码跑通。
最后交到你手里的，就是一个高完成度的结果。哪怕中间某些细粒度的实现细节跟你脑子里想的稍微有点出入，但大方向绝对死死咬住你最初定下的目标。而这，就是 Loop Engineering。
1.3 误闯 Loop Engineering
在明白了 Loop Engineering 是啥之后，突然意识到，我自己的 Agent 项目不就是使用了 Loop Engineering 思想吗？
由于之前一直在用 Qoder 之类的工具，在很长的一段时间里，我下意识地觉得“正常的 Agent 不就应该是这样跑的吗？”。为了印证这个直觉，我回头翻了翻几个开源框架的源码，比如 Hive。
Hive 是一个目标驱动的自动化 Agent 项目，同时支持事件触发（IM / Webhook / 定时任务）作为系统入口。下面我就拿它开刀，扒一扒 Loop Engineering 思想到底是怎么被塞进系统里的。
1.主 Agent Loop（事件/定时驱动）Hive 的心脏就是一个主 Agent Loop。当某个事件被触发时，系统就会围绕这个事件进入循环，一遍遍地迭代，直到这个事件被彻底消化完成。
2.动态任务编排与 Skill 调用
主 Agent 拿到宏观目标后，不会像个无头苍蝇一样直接开干。它会先把目标拆解成一整条计划链/任务链，然后创建多个带有特定功能的子 Agent 去干活。
重点来了：这些子 Agent 可不是写死的硬编码模块，而是主 Agent 在运行时动态编排出来的。每个子 Agent 拥有独立的垂直能力，可以调用各种底层 Skill，专攻固定目标。说白了，主 Agent 就是个项目经理，临时招人、临时分组、临时派活。
3.一个 Agent 一个对话 的硬隔离：
在干活的时候，每个子 Agent 都有自己独立的对话上下文。这样能保证它们各司其职，不会被其他不相关的任务信息干扰。专门写测试的就看测试相关的上下文，专门写业务逻辑的就看业务逻辑，各做各的，防止多对话多目标之间的互相干扰。
4.沙箱运行与 裁判 机制：
子 Agent 把活干完后，代码绝对不能直接提交或者上线，甚至都不能直接让它说“我写完了”。裁判（审计/验证器）会直接把生成的代码扔进一个隔离的沙箱里，自动执行编译、运行服务、跑测试用例。裁判会盯着沙箱的运行结果、标准输出、标准错误和日志信息，做出判断：“这事儿到底办成没有？有没有产生新的回归 Bug？”
5.不通过？吃药重来（正式进入自主死磕循环）：
如果裁判判断没通过，或者沙箱直接崩了，拿裁判就可以拿着鞭子，尽情的鞭打地里干活的 Agent 。这个 Agent 得到反馈后，自动进入下一个循环：自我PUA、自我分析原因、自我重写代码、自我再次提交沙箱、再次接受裁判打分。这时候，用户不会参与这个过程，如果Agent 在干活干不下去了没有任何结果，裁判就会让 Agent 不在继续（但也浪费了Token 毕竟喂了食）。
6.通关，推进下一题：
只有当裁判点头说 “bor，你完成的不错，代码编译通过，测试用例全部 Clear，完全符合要求，你可以休息了。”，这一步的任务才算彻底完成。系统才会依次按照编排好的任务链，找到下一个任务，分配下一个 子 Agent ，直到所有子任务执行完毕，完成最初的目标。
上面这套流程：Plan（规划） → Do（执行） → Check（沙箱与裁判） → Act（自动修复）。这不就形成了一个完整的自动化闭环。
在这种模式下，咱们作为开发者的身份算是彻底变了。咱们不再是那个在一线苦哈哈改拼写错误、盯着调用栈找 Bug 的“高级牛马”了，而是牛马都不是了。但也有可能直接退后到了更高的一层——变成了这个闭环系统的“规则制定者”，甚至是“裁判的裁判”。
这，就是 Loop Engineering 的庐山真面目，似乎再见 闭环控制系统？
二、 Spec-Driven Development（SDD） 下的 token 收敛
2.1 Loop下的 token 循环爆炸
看到这里，相信每一个钱包不够鼓、或者天天要向财务报销（或者贷款上班） API 账单的开发者，敏锐的雷达已经开始疯狂报警了。（还有一个大事，国外的模型报不了啊，没有发票！！！）
让 AI 搁这儿自己无限循环、疯狂死磕，直到通过为止？这听起来确实爽，但代入一下实际的工程场景，你就会发现这是一个多么恐怖的无底洞，这也是我第一次看到 Loop Engineering 后置之不理的原因，这也是我后面明白为什么 DeepSeek 市场占用率那么高的原因。
早期的 Vibe Coding，你顶多是输入了同样的问题，或者输入了错误的问题，顶多浪费不多的 Token；而在 Loop Engineering 时代，由于它是全自动的，你可能去上个摸鱼，后台的 Agent 已经在一个逻辑死胡同里撞墙撞了 10 回，等你回来的时候，你收到的不是一份完美的代码，而是一张足以让你肉疼 -2000 credits 的余额衰减，和一堆被彻底玩坏的、上下文。
在使用 Loop Engineering 的早期，我天天跟这头 Token 吞吞兽斗智斗勇，生为一个穷酸普通程序员，硬生生的用下了一天快 200 刀的花费记录。
后面为了省下那点买排骨的钱，我硬生生逼着自己，在一次次项目中，摸索出了一套把这头吞噬兽死死按在地上摩擦的控本绝招。而最后证实“大部分做工程的，为了解决问题最终都会选择相似的道路。”（现在又突然想到，以前在 vibe coding 的时候，还会自动的让AI总结对话记录并且读取的另类知识库。）
而让 token 收敛的方式，就是以 SDD 最详细的边界控制（GitHub Spec-Kit 范式）编写的文档，以最近的项目为例，我用 SDD 四层规范（Constitution / Specify / Plan / Tasks）做需求治理——41 份分层 spec 文档，把 AI 的搜索空间压到最小，token 可预测、产出可验证、需求可追溯。2100 credits 完成一个复杂项目。
2.2 SDD 下的 token 收敛
虽然 SDD 并不是为了省 token 诞生的，主目标是 对齐 + 可复现 + 可验证。但在当前烧 token 的时期，对于我来说省 token 就是提升生产力，因为定义得越死，AI 能瞎发挥的地方越少，token 就越可控，钱就花的越少，做的项目就会越多，钱也会花的越多，即“钱花的越少==钱花的越多”。
为啥 SDD 能省 token？这事儿说起来其实就一句话：用规格把 AI 的搜索空间，从全宇宙压缩到一个小房间。例如你对 AI 说："给我做个电商网站。"
AI 的内心 OS 是：妈呀，电商网站？淘宝那种？拼多多那种？还是 Shopify 那种？要不要带支付？要不要多语言？要不要后台管理？……（这就像AI的思考链）
它的搜索空间是整个知识库。它要从所有可能的电商网站里，挑一个最像你想要的。这中间要试错无数次，每一次试错都在烧 token。
而 SDD 模式下，你递给 AI 一份 100 页的 spec，里面写清楚了：
- 用什么技术栈（
React + Node + PostgreSQL） - 有哪些页面（首页、商品列表、商品详情、购物车、结算）
- 哪些功能不做（不做优惠券、不做会员体系、不做直播）
- 验收标准是什么（首屏加载 < 2s，购物车数据持久化）
AI 一看 spec，心里就有数了：哦，不是淘宝那种，是个小而美的独立站，技术栈定好了，功能边界定好了。
它的搜索空间瞬间从没有方向的乱闯变为一个 10 平米的小房间。它几乎不需要猜，因为答案已经在你写的 spec （你按照SDD写的文档）里了。猜的次数少了，token 自然就少了。
古法手敲，当前这篇文章 70% AI 润色...
确实很久没写文了，有感后就直接写了，如有错误望请纠正...
