写在前面前面可以不看就是说说话很久不写文了。沉寂了一段时间后最近我又把精力投入到了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 DevelopmentSDD 下的 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 润色…确实很久没写文了有感后就直接写了如有错误望请纠正…