过去两年，AI 领域最显著的趋势就是不断涌现新术语。从 Prompt Engineering 热潮（大家钻研如何撰写精准提示词），到 Context Engineering（聚焦上下文窗口、RAG 与长期记忆），再到 Agent Framework、Harness Engineering，概念层出不穷。因此，当第一次在 X 上看到 Peter Steinberger 提出“不要对 Agent 进行 Prompt Coding，而应该设计能够对 Agent 进行 Prompt 的 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 再强，也无法解决一个没有被定义清楚的问题。
你让它“优化系统性能”，它不知道优化到什么程度算完成；你让它“提升代码质量”，它不知道质量提升多少才算达标；你让它“重构架构”，它甚至不知道重构的边界在哪里。但如果能够把目标描述成：
- “将页面加载时间从 3 秒降到 1.2 秒，通过 Lighthouse 测试”
- “将测试覆盖率从 60% 提升到 90%，新代码不允许低于 90%”
那么事情就会变得简单很多。因为目标明确了，验证标准也明确了，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 在没有人持续干预的时候，依然知道自己应该做什么。
