Loop Engineering 火了，但我觉得大家可能高估了它的新，也低估了它的重要

前言

过去两年，AI 圈最大的特点就是特别喜欢发明新名词。

Prompt Engineering 火的时候，大家在研究怎么写提示词；后来又出现了 Context Engineering，开始讨论上下文窗口、RAG 和长期记忆；再后来是各种 Agent Framework、Harness Engineering，以及数不清的新概念。以至于当我第一次在 X 上看到 Peter Steinberger 说“不要再 Prompt Coding Agent，而应该去设计能够 Prompt Agent 的 Loop”时，我的第一反应其实不是好奇，而是怀疑。

说白了，这听起来太像一个典型的 AI 圈新词了。

如果把时间往前拨几年，无论是 ReAct、AutoGPT 还是后来的 Reflexion，本质上都在做类似的事情：让模型根据执行结果决定下一步行动。单从技术角度看，Loop Engineering 很难说有什么革命性的创新。你甚至可以很轻松地找到一堆论文和框架，证明类似思想早就存在了。真正让我开始认真看待这个概念的，并不是它提出了什么前所未有的新技术，而是越来越多一线开发者都在描述同一种变化，而且这种变化和我自己的体验高度一致。

过去一年里，我用 Claude Code 的频率越来越高。最开始的时候，它更像一个特别聪明的 Copilot：帮我写函数、解释报错、补全代码。虽然效率提升很明显，但开发流程并没有本质变化，大部分时间我依然坐在键盘前，一步一步告诉它接下来该做什么。

最近几个月情况开始不一样了。

很多时候我会先花十分钟把需求梳理清楚，然后直接把目标交给 Agent。接下来的几十分钟里，它会自己去读代码、查依赖、运行测试、修改文件、分析日志，甚至在失败之后主动尝试第二种解决方案。等我再次回到电脑前，看到的往往已经不是“请问下一步怎么办”，而是一份完成度相当高的结果和若干个需要我做判断的选项。

如果一定要说这期间发生了什么变化，我觉得最准确的描述并不是“模型变强了”。

模型当然变强了，但那不是关键。

关键在于，以前是我推动 AI 工作，现在越来越多时候是系统在推动 AI 工作，而我负责决定方向、设置约束、验收结果。

这听起来只是一个很小的区别，但它直接改变了人与 Agent 的协作关系。

以前的工作模式像是在开车。你踩一下油门，车往前走一段；你再踩一下，它再往前走一段。整个过程中，前进的动力始终来自驾驶员。

而现在越来越多的 Agent 更像自动驾驶。你告诉它目的地，设定好规则和边界条件，然后系统自己决定什么时候加速、什么时候转向、什么时候重新规划路线。人没有消失，但人不再负责每一个动作。

我觉得 Loop Engineering 真正想描述的，其实就是这个变化。

它讨论的重点从来不是 Prompt，而是控制系统。

它关心的问题也不是“怎样让模型回答得更好”，而是“怎样让模型在没有人持续干预的情况下，仍然能够朝着目标不断推进”。

Claude Code 的变化，可能比很多人意识到的更大

如果只是看产品发布会或者官方演示，很容易产生一种错觉：Claude Code、Codex、Cursor Agent 这些工具的进步，主要来自模型能力的提升。

但过去几个月实际使用下来，我越来越觉得，模型升级固然重要，却未必是体验发生质变的核心原因。

因为很多能力其实去年就已经存在了。

Claude 能写代码。

GPT 能写代码。

Gemini 也能写代码。

这些事情大家早就知道。

真正发生变化的是，Agent 开始具备了持续工作的能力。

以前你让 AI 修复一个 Bug，它给你一个修改方案，然后等待下一条指令。

现在你让 Claude Code 修复一个 Bug，它往往会自己运行测试、查看日志、分析调用链、修改代码、重新执行测试。如果第一次失败，它还会继续尝试第二种方案、第三种方案，直到找到能够通过验证的方法。

从表面上看，这是一个能力问题。

但从工程角度看，这其实是一个工作流问题。

因为这里最关键的变化，不是模型会不会修 Bug，而是系统允许它不断修 Bug。

这种差异有点像搜索引擎和自动驾驶的区别。

搜索引擎回答问题。

自动驾驶完成任务。

两者都依赖同样的底层能力，但最终呈现出来的体验完全不同。

很多人把这种变化理解为 Agent 更聪明了。

而我更愿意理解为 Agent 获得了行动的连续性。

过去的 AI 更像一个瞬时函数。

输入 Prompt。

输出结果。

执行结束。

而现在的 Agent 更像一个持续运行的进程。

目标没有完成，它就继续工作。

验证没有通过，它就继续尝试。

出现错误，它就继续修正。

从这个角度看，Loop Engineering 与其说是在讨论 Prompt，不如说是在讨论如何设计一个能够持续运行的系统。

我认同的一个观点：未来最重要的能力可能不是写代码

最近经常有人讨论一个问题：

AI 会不会让程序员失业？

这个问题讨论了两三年，到现在其实已经有些审美疲劳了。

但如果换一个角度看，也许能看到一些新的东西。

过去，一个优秀程序员最大的优势通常来自实现能力。

同样一个需求，你能比别人写得更快、更稳定、更优雅。

这是典型的执行优势。

但当 Agent 的执行能力越来越强之后，优势开始向别的方向转移。

过去半年我最明显的感受是，人与人之间最大的差距已经不在于代码写得有多快，而在于谁能更准确地定义问题。

同样一个 Agent。

同样一个模型。

不同的人使用出来的效果可能天差地别。

有人能在半天时间里完成一个完整功能。

有人折腾两天都得不到满意结果。

很多时候问题并不出在 AI 身上，而是出在目标本身。

因为 Agent 再强，也无法解决一个没有被定义清楚的问题。

你让它“优化系统性能”，它不知道优化到什么程度算完成。

你让它“提升代码质量”，它不知道质量提升多少才算达标。

你让它“重构架构”，它甚至不知道重构的边界在哪里。

但如果你能够把目标描述成：

将订单接口 P99 延迟从 800ms 降低到 200ms 以下，并保证现有测试全部通过。

那么事情就会变得简单很多。

因为目标明确了。

验证标准也明确了。

Agent 才知道什么时候该继续，什么时候该停止。

从这个角度看，未来程序员的重要能力可能会越来越偏向系统设计、问题建模和目标定义，而不是单纯的编码速度。

Loop Engineering 最容易被误解的地方

最近看了很多关于 Loop Engineering 的讨论，其中一个现象让我印象很深。

大家特别喜欢讨论 Agent。

却很少讨论验证器。

仿佛只要 Agent 足够聪明，一切问题都会迎刃而解。

但在我看来，一个 Loop 里面最重要的组件，从来都不是 Agent。

而是 Verifier。

也就是验证机制。

因为 Agent 决定的是如何前进。

Verifier 决定的是什么时候停止。

这两件事情同样重要。

事实上，很多 Agent 项目最后失败的原因都不是能力不足，而是根本没有定义清楚什么叫成功。

比如让 AI 写一篇文章。

什么时候算写完？

什么时候算质量达标？

什么时候应该继续修改？

什么时候应该停止优化？

这些问题如果没有明确答案，Loop 很快就会陷入一种奇怪的状态：

永远有改进空间。

永远有优化余地。

永远可以再来一轮。

最后消耗越来越多 Token，却始终没有完成任务。

所以当很多人批评 Loop 会无限烧 Token 的时候，我其实部分同意。

因为这种情况确实存在。

但问题不在 Loop。

而在于没有设计好验证机制。

本质上，这和程序员写出无限循环没有区别。

一个成熟的系统从来不会只有执行逻辑。

一定还会有预算约束、停止条件、失败回退和人工接管机制。

如果缺少这些东西，那么问题不是 Agent 太聪明，而是工程设计太粗糙。

这到底是不是一个新概念？

关于 Loop Engineering 最大的争议，其实也集中在这里。

很多人觉得这就是旧瓶装新酒。

坦白说，我能理解这种观点。

因为如果把历史稍微往前翻几页，会发现类似思想已经出现过很多次。

ReAct 在做。

Reflexion 在做。

AutoGPT 在做。

Tree of Thoughts 在做。

甚至很多传统软件系统，本质上也在做类似的事情。

执行。

检查。

反馈。

调整。

继续执行。

这个闭环本身并不新鲜。

所以如果有人说：

Loop Engineering 并没有创造新的技术。

我基本认同。

但如果因此得出结论说这个概念没有价值，我觉得又有些低估它了。

因为工程领域有一个很有意思的现象。

很多时候真正推动行业进步的，不一定是新技术。

而是新的抽象。

微服务不是突然发明了网络通信。

DevOps 不是突然发明了自动化。

云原生也不是突然发明了容器。

它们做的事情，更多是把原本分散的实践经验组织成一套统一框架，让更多人能够理解、复制和推广。

我觉得 Loop Engineering 的价值也在这里。

它未必发明了什么。

但它把很多过去散落在 Agent、Prompt、Tool Calling、Memory、Verification 里的东西，第一次放进同一个框架里讨论。

而这种统一视角，本身就是有价值的。

真正值得关注的变化

如果让我总结 Loop Engineering 最值得关注的一点，我觉得并不是某个具体技术。

而是一种角色变化。

过去几年，我们一直在学习如何使用 AI。

研究 Prompt。

研究 RAG。

研究上下文管理。

研究工具调用。

本质上都属于同一个范畴：

如何更好地使用模型。

但最近半年，我越来越明显地感觉到，问题正在发生变化。

很多时候我们已经不再思考：

下一条 Prompt 应该怎么写？

而是在思考：

如果我离开电脑半小时，Agent 应该继续做什么？

如果当前方案失败了，它应该怎么调整？

如果目标还没完成，它应该如何继续推进？

这些问题看起来很小。

但背后对应的是完全不同的思维方式。

前者是在使用工具。

后者是在设计系统。

而我觉得，Loop Engineering 真正反映的其实就是这个趋势。

也许一年之后大家不会再讨论这个词。

就像今天已经很少有人认真讨论 Prompt Engineering 一样。

但这种变化本身大概率不会消失。

因为越来越多开发者已经开始意识到，未来真正重要的能力可能不是告诉 AI 应该做什么，而是设计一个系统，让 AI 在没有人持续干预的时候，依然知道自己应该做什么。