最近团队群里有人转发了一篇讲 Loop Engineering 的文章，底下第一条评论是：「又冒出来一个新词，前几个月还在学 Harness 呢。」
这话真是说到心坎里。从 2023 年到现在，Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering，隔几个月就冒出来一个「XXX Engineering」，博客、播客、推文一起上。手头在做 AI 编码的人，多半都被这几个词绕晕过。
这篇不打算再吹一遍新概念多颠覆。想做的是三件事：把四个范式的演进脉络捋清楚，把 Loop Engineering 到底在干什么拆开讲，再把落地时会踩的坑摆出来。看完之后，你至少能判断这波概念里哪些值得跟进，哪些只是营销。建议先收藏，后面第三节的四步闭环和第四节的落地边界，团队讨论的时候能直接拿去对线。
第一章：概念井喷的时代：AI 工程化四范式的诞生背景
为什么这两年新名词冒得这么密？追到根上，其实就是三件事在往前推：模型能力在往上跳，上下文窗口在变大，Agent 的自主执行时间也在被拉长。每往上跳一格，原先那套工程手法就开始不够用，于是有人跳出来造新词。
社区的情绪挺分裂的。一边是群里有人吐槽：「又学到新名词了，这半年所学到的新名词比前面 10 年加起来还要多」「你往那儿栓条狗，用着用着，这些技巧自然而然也就冒出来了」；另一边，真正在一线做 Agent 的那批人，还在认真讨论 harness 的完善度会怎样影响最终产出。
我的看法是：概念带有营销成分，但也不是纯粹忽悠。每一波新词背后，都对应着模型能力的某一个具体台阶。名词可以不学，底下的变化不能忽略。把每个范式究竟解决的是哪个阶段的什么痛点搞清楚，比单纯记名词有用。
第二章：四范式脉络梳理：从 Prompt、Context、Harness 到 Loop
先把结论摆出来：这四个范式不是替代关系，而是叠加关系。每一层都建在前一层上面，要解决的是前一层解决不了的新问题。
有一条群友评论说得挺到位：「本质都是控制反馈回环」。要是你学过控制原理，就会发现 Harness 和 Loop 本质上都在设计闭环控制系统，一个偏约束，一个偏驱动。
第三章：Loop Engineering 拆解：发现、并行、验证、沉淀的四步闭环
很多人第一反应是：「Loop 不就是 while(true) 嘛？不就是个 cron job 吗？」这话对了一半，也错了一半。
说它对，是因为它的确属于循环。说它错，是因为它不是无脑轮询，而是一套收敛控制系统。每一轮都要能产出新的输入、对输出做验证、把上下文沉淀下来，好让下一轮比上一轮更靠近目标。
社区里目前讨论较多的落地形态大致是下面这样，分四个阶段：
跑完一轮再触发下一轮，直到 Agent 找不到新问题为止。可以看出，Loop 比 Harness 多的东西就是并行加独立验证加跨轮次记忆。它已经不再是单个 Agent 在跑，而是一群 Agent 在一个持续演化的工作台上协同干活。
看到这里，如果你团队里正在琢磨要不要引入 Loop 工作流，先对照一下自己手头的项目：你现在的 harness 到底做到了什么程度？端到端测试、静态分析、可视化验证这些有没有？基础设施还不齐就直接上 Loop，验证这一环节就是走过场，Agent 说改好了那就是改好了。
不少团队踩坑，不是 Loop 本身不行，是顺序搞反了：harness 还没稳，就急着把 Loop 用起来。就像给新手司机装自动驾驶，方向盘还没扶稳，就先开循环巡航，很快要出事。
第四章：落地的现实考验：token 成本、架构腐坏与人工审核困境
概念听着挺美，可真跑起来坑就一堆了。这里把社区当中讨论比较集中的几个问题罗列一下，都是能实实在在把项目搞黄的：
1. Token 成本：这是最直接的一项。一个小团队开 Loop，多 Agent 并行加上独立验证，再加每轮的沉淀，很容易一条命令就把当天的限额给榨干。群里有个说法讲得很直白：「原本的小项目经过 AI 的多 agent 循环验证+审阅之后，codex 把一个小项目左右脑互博之后变成了分布式负载多租户项目。」听起来挺搞笑，本质上是 Agent 压根没有成本感这回事，你要是不做硬性约束，它就会把任何小事都做得很重。
2. 架构腐坏：Loop 擅长打补丁，可它不擅长做架构层面的决策。每一轮迭代都在解决当下发现的问题，几十轮下来回头再看，就会发现补丁摞着补丁，核心结构已经没什么人在守了。有条评论说得挺狠：「补丁越来越多，最终结果就是 bug 越来越难解，直到完全解决不了。」这不是危言耸听，Loop 天然就缺一个「重构」的动机。
3. 上下文污染：多个 Agent 互相读写沉淀下来的文档，很容易就把错误的结论给固化下来。一旦某一轮的错判被写进了 Notion 或者 md，后面的每一轮都会把它当成前提。这种污染比 context rot 还难发现，缘由在于它藏在「历史决策」里头，看起来还挺权威的。
4. 人工审核困境：一线开发对这套东西最真实的反馈是——「大片大片完成，再去人工 review，我是真没耐心」。Loop 的产出量远远超过单轮，review 的成本反倒暴涨了。你要是不 review，就等于把质量交给了验证 Agent；可要是你 review，那 Loop 在效率上的优势马上就要打个对折。这里头的 trade-off 目前还没有标准答案。
取舍清单：
可以试试 Loop 的场景：
别硬上的场景：
一句口诀：Loop 适合「重复劳动 + 机器可验证」，不适合「架构决策 + 人工判断」。
第五章：范式之外：回归模型能力与 Human-in-the-loop 的本质
聊了这么多，最后想说点跳出概念层面的话。
把 Prompt、Context、Harness、Loop 这几个词身上的营销外壳撕掉，会发现它们讨论的其实是同一件事：模型能力还不到位的时候，用工程手段补短板。措辞不行就调 prompt，记不住东西就管 context，容易漂移就加 harness，要长期迭代就设计 loop。每一层做的事，都是在给模型打辅助。
所以有个观察，可能已经听过很多遍，但依然成立：模型能力往上走一个台阶，这些工程手法就往后退一步。今天要动用五层 harness 才能约束住的行为，到了下一代模型那里，可能一句 prompt 就搞定了。与其把筹码押在工程范式上，不如押在对模型能力边界的理解上。
另一个观察是，Human-in-the-loop 到现在依然省不掉。不管叫什么 Engineering，只要涉及生产代码，人工审核这一环大概率是绕不开的。区别只在于：人是在每一行 diff 上审，还是在每一轮 loop 的关键节点上审，或者在架构决策的分岔口上审。人所处的位置在往上挪，但没有消失。
对开发者，想给的建议其实很朴素：别追新词，追问题。每次听到一个所谓的「XXX Engineering」，先别急着学，先问三个问题：它解决的是哪个具体痛点？我现在有没有这个痛点？它带来的成本我能不能承受？把这三个问题想清楚，比读十篇科普文章都值。
到这里差不多该收尾了。整篇文章想说的其实就三件事：
要是这篇文章帮你理清了这几个词的关系，欢迎点个赞。团队里有人正在纠结要不要跟这波 Loop，直接转给他，比你自己解释省事。已经在生产环境跑过 Loop 工作流的，欢迎到评论区聊聊踩过的坑，尤其是 token 成本控制和验证 Agent 设计这两块，想听听一线怎么做的。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。