这半年冒出来的新名词是不是比过去十年加起来都多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 Engineering2022-2023那会儿上下文只有几 K模型能跑完一两轮对话就算不错了。所以核心就是「一轮里把话说清楚」措辞、格式、few-shot example全在一段文本上做文章。Context Engineering2024-2025上下文窗口涨到了几十万 token多轮的长任务开始能跑了。可是很快大家就发现了一个新毛病叫 context rot上下文塞太多东西进去性能反倒下降。于是重点就变成「怎么合理管上下文」什么时候压缩、什么时候检索、什么时候清空。Harness Engineering2025 末-2026 初Agent 能跑更长的任务了新冒出来的问题是「任务漂移」跑着跑着就跑偏。Harness 讲的是给 Agent 套一层外部约束包括工具、验证器、结构化输出还有 guardrail硬把它拽回目标上。Loop Engineering2026Agent 已经能长时间自主运转了重点也就变成「怎么设计让 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 设计这两块想听听一线怎么做的。