大家好，我是鲁工。
经常在X上AI圈冲浪的朋友可能已经发现了，最近AI圈，又出新名词了：
Loop Engineering（循环工程）。
Claude Code之父Boris Cherny前阵子在一场访谈时说了句话，这两天被翻来覆去地转，他这么说的：我已经不提示Claude了，我有一堆循环在跑，它们替我提示Claude。我的工作，是写loop。
说这话的不止Cherny老哥一个人。OpenClaw作者、现在人在OpenAI的Peter Steinberger，几乎同时也在喊：别再给Coding Agent写提示词了，你该去设计提示它们的循环。
紧接着6月7号，谷歌的Addy Osmani发了篇长文，标题就叫Loop Engineering，把这个概念系统性的阐述了一遍。X上跟着出了个14步路线图的帖子，也转发刷屏了。Loop Engineering这个词，算是正式出圈了。
我把原文和几篇衍生帖都读完了，第一感觉是：词是新词，但内容一点都不新。
Loop Engineering具体是个啥
Osmani老哥给的定义就一句话：Loop Engineering是把你自己从给Agent写提示词的岗位上替换下来，由你设计的系统顶上。
过去两年我们跟Coding Agent的相处方式是打字、等、看diff、再打字，工具一直掌握在我们手里。循环工程的意思是搭一个小系统，它自己找活、派活、验收、记账、决定下一步。你设计一次，之后它来提示Agent。
把它拆分开看，其实就是六个常见的Agent系统组成部分：定时触发的自动化、隔离并行任务的worktree、沉淀项目知识和流程的skills、接通真实工具的MCP连接器、把写代码和验收分开的Subagents，外加一个写在磁盘上的状态文件。Osmani有句话说得很准，Agent会忘，仓库不会（这个其实去年Manus那篇关于Context Engineering文章也强调了）。
这六样，其实全是我们熟悉的东西。循环执行器和状态文件，我一月份推荐ralph-loop加planning-with-files组合的时候就聊过：
推荐一个Claude Code干活组合：/ralph-loop + planning-with-files
/loop怎么用，三月份也写过一篇：
Claude Code近期两大实用更新：/loop和Code Review
Loop中最核心的"一个模型生成、另一个模型挑错"的对抗审查模式，其实都是Anthropic在2024年12月那篇Building effective agents里写过的evaluator-optimizer模式。换了个名字，然后现在火起来了。
上述这六样，Claude Code和Codex都满足：
往回看，这已经是AI圈子第四次给怎么用好模型这件事起名字了。
2023年叫Prompt Engineering，研究怎么把一句话问得漂亮，提示词工程师一度成为大模型领域的新职业。2025年年中，Andrej Karpathy他们开始讲Context Engineering，焦点从怎么问转向动态提供什么，上下文窗口被当成稀缺资源来管。今年年初起，风向又挪到Harness上，模型外面那层壳决定了同一个模型能发挥几成，这波我三月份专门写过一篇：
Loop Engineering管的则是这层壳什么时候转起来、运转到什么时候结束。名字一年一换，杠杆每次都往上挪一层：模型越强，人离键盘越远。
零件早就齐了，真正的变量是模型这半年真的能在循环里自我纠错了。特别是这周Anthropic发布了地表最强模型Claude Fable 5，Loop起来越来越丝滑。
Anthropic的Lance Martin前几天发了组实验。任务叫Parameter Golf，在8张H100上、10分钟内训出一个16MB的最优模型。他给Fable 5一份9条可验收标准的评分细则（rubric，就是一张可以逐条打勾的checklist），再挂一个独立的验收Subagent，最长跑了8个小时。
结果是Fable 5对训练pipeline的改进幅度，大约是Opus 4.7的6倍。
改进的方式比改进的幅度更有意思。Opus 4.7第一个实验拿到小赢之后，后面几乎全在重复同一个模板：调一个常数，测一下，有正收益就保留。Fable 5敢押架构层面的大改动，中间被一次量化回归搞砸了，但顶着压力做下去，反而做成了最大的单项收益。
还有个细节：让写代码的模型给自己打分，效果不好，验收得交给独立上下文里的Subagent。/goal判定干没干完，用的就是另一个模型。
需要上Loop Engineering的四个条件
要是只讲到这，这篇跟X上的转发就没什么区别了。原帖里最有价值的，其实是泼冷水的那部分。
Loop只在四个条件同时成立时才划算：
任务每周都会重复
有测试、构建、linter这类能自动把低质量交付打回去的门控（gate)
token预算扛得住循环的开销，循环会反复读上下文、反复重试，这些都烧钱
Agent手里有日志和能跑代码的环境
上述条件缺任意一条，循环的成本就高过收益。
说得再直接点就是，低于100刀的订阅就别碰重验证循环了，根本不够用。
同一个帖子里还有个划分方法，我觉得比14步路线图还实用：开放循环和封闭循环。开放循环是给个目标让Agent自己探路，OpenAI那帮人玩的就是这个，能做出你没规划过的东西，token也烧得最凶；封闭循环是人先把路径定死，每步带验收、有明确停点，普通预算跑得起。作者建议从封闭循环起步，质量门搭扎实了再放开。
顺带说一句，那帖子后半截有点给DeepSeek打广告的感觉，但token太贵这个问题，对国内读者来说确实最有解。DeepSeek、Kimi、MiniMax这个价位，跑封闭循环基本不用太担心token消耗。
不过钱只是四个条件里的一个，剩下三条国产模型救不了。代码里没有任何自动化验证的，照样别上loop：没有客观的门控，所谓循环就是Agent自己跟自己点头。原帖的说法是，一个没有测试兜底、只被要求review一下的二号 Agent，无非是第二个乐观主义者。
四条都过了，起步姿势也有讲究。最小可行循环就四样：一个自动化、一个 skill、一个状态文件、一个门控。顺序比配置更重要，先把一次手动执行跑稳，再固化成skill，再包进循环，最后才挂上日程。
衡量循环值不值，指标只有一个：每条被接受的变更花了多少钱。接受率低于 50%，说明你在替循环干它本该省掉的review活，这循环不值当。
看到这我坐不住了，因为它正好戳在我上个月写的那个状态上。当时我每天token消耗5亿上下，人根本跟不上。Code review完全没有，diff也懒得翻，账面上一天干完半个月的活，七成以上的决策和验证没有经过我。
Osmani给这个状态起了名字，叫理解债。循环交付代码越快，仓库里有的和你脑子里懂的，距离拉得越大。token账单还是小头，真正贵的是哪天你不得不去调试一个全组没人读过的系统。他还提了个更扎心的词，认知投降：懒得再形成自己的判断，Loop说什么就是什么。
他给的解法没有一条是技术的。读diff。抽查你的门控，看那个测试是不是真能拦住你在乎的低质量交付。别让循环碰架构和支付这类要拍板的活。
我目前跑得最稳的Loop一直不在代码仓库里，在写作流水线上：几个/schedule挂的定时任务，每周日晚扫一遍剪藏库，每半个月盘一次选题覆盖，状态记在Obsidian。写这篇的时候，我顺手把它往前推了一步，搭了个正经的最小闭环。
四件套是这么凑的。
门控：把稿件自检清单里能机械判断的部分（禁用词、破折号、加粗配额、字数）写成一个百来行的Python脚本，命中即不通过。
Skill：自己设计的鲁工写作工作流。
状态文件：选题brief。
自动化：包一层/goal，判定干没干完的是读脚本退出码的独立检查者，不是写稿的模型自己。每次写作时按四条件测试逐条check。
所以回到标题那个问题，Loop Engineering到底是什么？
是杠杆点从写提示词挪到设计系统的一次正式命名，所有的组件我们早就有了。
要不要现在就上Loop？很遗憾，实际情况上大多数开发者现在还不需要循环。
我的建议是把盯住那四个条件，感觉手上的活大差不差的能满足这四个条件了，就差不多可以上Loop Engineering了。
后面，我会专门出一期Loop Engineering的实战案例。
本文首发于微信公众号「AI编程实验室」，阅读原文