这半年冒出来的新名词，是不是比过去十年加起来都多？Prompt、Context、Harness、Loop，这几个 Engineering 到底是四样东西，还是同一件事换了几层包装？下面把四种范式的来龙去脉、Loop Engineering 的实际工作流程，以及落地时遇到的 token 成本、架构腐坏、人工审核这些麻烦拆开讲，供正在为 AI 编码流程做选型的后端和团队负责人参考。
开场
最近团队群里有人转发了一篇讲 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
先把结论摆出来：**这四个范式不是替代关系，而是叠加关系。**每一层都建在前一层上面，要解决的是前一层解决不了的新问题。
- Prompt Engineering（2022-2023） ：那会儿上下文只有几 K，模型能跑完一两轮对话就算不错了。所以核心就是「一轮里把话说清楚」，措辞、格式、few-shot example，全在一段文本上做文章。
- Context Engineering（2024-2025） ：上下文窗口涨到了几十万 token，多轮的长任务开始能跑了。可是很快大家就发现了一个新毛病，叫 context rot，上下文塞太多东西进去，性能反倒下降。于是重点就变成「怎么合理管上下文」，什么时候压缩、什么时候检索、什么时候清空。
- Harness Engineering（2025 末-2026 初） ：Agent 能跑更长的任务了，新冒出来的问题是「任务漂移」，跑着跑着就跑偏。Harness 讲的是给 Agent 套一层外部约束，包括工具、验证器、结构化输出还有 guardrail，硬把它拽回目标上。
- Loop Engineering（2026） ：Agent 已经能长时间自主运转了，重点也就变成「怎么设计让 Agent 自我驱动的循环」，从人工提示变成由系统提示 Agent。
有一条群友评论说得挺到位：「本质都是控制反馈回环」。要是你学过控制原理，就会发现 Harness 和 Loop 本质上都在设计闭环控制系统，一个偏约束，一个偏驱动。
什么是 Loop
第三章：Loop Engineering 拆解：发现、并行、验证、沉淀的四步闭环
很多人第一反应是：「Loop 不就是 while(true) 嘛？不就是个 cron job 吗？」这话对了一半，也错了一半。
说它对，是因为它的确属于循环。说它错，是因为它不是无脑轮询，而是一套收敛控制系统。每一轮都要能产出新的输入、对输出做验证、把上下文沉淀下来，好让下一轮比上一轮更靠近目标。
社区里目前讨论较多的落地形态大致是下面这样，分四个阶段：
- 发现问题 ：Agent 从代码库、issue、日志，或者上一轮沉淀的内容里，找出下一个要解决的任务。
- 并行开发 ：开几个 git worktree 同时动手，避免多个 Agent 改到同一份文件互相污染。这一步也是 Loop 跟 Harness 差别最明显的地方。
- 独立验证 ：再开一个 Agent 专门负责验收，看代码、跑测试，必要时用 playwright 做端到端验证。 关键是，验证 Agent 不能就是开发 Agent 本身 ，否则会陷入「yes 幻觉」，写代码的自己夸自己写得没问题，一路点头点到底。
- 上下文沉淀 ：把这一轮的结论、决策、边界，通过 MCP 写进 Linear、Notion、GitHub Issues，写到本地一个 md 文件也行。下一轮开始的时候，从这里把上下文回显出来。
跑完一轮再触发下一轮，直到 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 的场景：
- 验收标准明确的任务，比如「所有 API 加上 OpenAPI 注解」「单测覆盖率补到 80%」这种
- CI、E2E 和静态检查已经比较完善，Agent 的输出机器能验
- 老项目里的批量重构、批量迁移、批量升依赖
- Token 预算充足，或者是一次性任务，不太担心成本失控
别硬上的场景：
- 要做架构决策的新功能，Loop 会把它做成缝合怪
- 验证标准得靠人判断的，比如 UI 手感、文案调性、业务合理性，验证 Agent 兜不住
- 屎山老项目，边界条件多、隐式依赖重，Loop 每跑一轮都可能踩雷
- 小团队小项目，harness 都没搭，直接上 Loop 是本末倒置
- Token 预算紧张，或者用的是共享额度
一句口诀：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 Engineering 的价值在闭环，不在循环 ，并行开发、独立验证、跨轮次沉淀，少一样都算不上 Loop。
- 能不能落地，看 harness 完善度、token 预算和验证能否自动化 ，条件不够还硬上，小项目最后就是个缝合怪。
要是这篇文章帮你理清了这几个词的关系，欢迎点个赞。团队里有人正在纠结要不要跟这波 Loop，直接转给他，比你自己解释省事。已经在生产环境跑过 Loop 工作流的，欢迎到评论区聊聊踩过的坑，尤其是 token 成本控制和验证 Agent 设计这两块，想听听一线怎么做的。