# 当前的大模型已经杀死了循环工程

> 龙虾AGI通用实验室 · 2026-08-26

6月7号，OpenClaw创始人Peter Steinberger发了一条推文："你不应该再给编程Agent写提示词了。你应该设计循环来提示你的Agent。"

8百万浏览量。评论区炸了。有人说这是下一个范式转移，有人预言LinkedIn上马上会冒出一堆"循环工程师"的新头衔。Anthropic的Claude Code负责人Boris Cherny在演讲里说了类似的话："我不再prompt Claude了。我有循环在后台跑着，它们替我prompt Claude、替我判断下一步做什么。我的工作变成了写循环。"

然后7月18号，Steinberger自己发了另一条推文："我们还在谈循环吗，还是已经转到图（Graph）了？"

六周。一个概念从诞生到被它的提出者亲手弃掉，只用了六周。

但杀死循环工程的不是Steinberger，也不是什么更新的方法论。杀死它的是大模型本身。

## 循环工程在解决什么问题

循环工程主张不要手动给Agent写提示词，而是设计一个自动循环系统来驱动Agent持续工作。

为什么会有这种主张？因为几个月前的模型有一个很现实的限制：它们很难长时间自主工作。

你问一点，它答一点。你不追问，它就停了。它不会自己规划接下来做什么，不会主动验证自己的产出，更不会发现做错了自己回头改。你必须坐在屏幕前不断追问、不断纠偏、不断告诉它下一步干什么。

在那个阶段，如果你想让Agent持续工作几个小时完成一个复杂任务，你得在外面搭一个循环：Agent跑完一轮，检查结果，不满意就把新的指令塞回去再跑一轮。这个外部循环替代了人坐在屏幕前不断追问的过程。

逻辑上没毛病。但它有两个绕不过去的成本。

## 第一重成本：大量token花在了不该花的地方

循环工程的token开销需要拆开看，因为不是所有的token消耗都是浪费。

如果你在开发一个必要的功能，Agent跑了20轮才把代码写对、测试跑通，这20轮是必要的。循环只是让这个过程不需要你坐在屏幕前手动驱动而已。这种情况下循环工程的价值是真实的，它把你从"每隔几分钟看一眼、敲一次回车"的重复劳动中解放出来了。

但另一些情况就不一样了。

在《不要随便用子代理模式》里我算过一笔账：8个子代理并行写8篇文档，每篇有效内容约4000 token，但每个子代理的总消耗在25000到30000之间。多出来的两万多token花在了哪？系统提示词重复加载、参考文件重复读取、工具调用的格式开销。8个子代理就是8份一模一样的上下文，87%的token花在了重复上。

循环工程有类似的问题。每一轮循环如果需要重置上下文（这在很多实现里是默认行为，因为旧上下文太长会影响质量），那每一轮都在重新理解任务、重新加载工具定义、重新读取已有代码。这些重复开销在几十轮循环里累积起来很可观。

更隐蔽的浪费是跑偏。在《循环工程到底在干什么》那篇文章里我提过一个真实案例：AI要处理一个数据库外键约束问题，它明明已经读到了错误信息，知道毛病在哪，然后花了47轮反复尝试同一条命令的各种语法变体。一个5毛钱就能解决的问题，变成了30美元的学费。还有更离谱的，某个Agent一夜之间烧掉437美元，因为它陷入了一个"自己觉得有道理但其实在原地打转"的推理循环。

人坐在屏幕前的时候，第3轮就会发现不对劲。循环替代了人，这种纠偏也一起被替代掉了。

循环放大了AI的生产力，但同样放大了AI的愚蠢。而且是悄无声息地放大，你不盯着都不知道钱去哪了。

而且推崇循环工程的人有一个普通开发者没有的条件。Boris Cherny在Anthropic，Steinberger在OpenAI，他们有近乎无限的token预算。有开发者直接说了一句大实话："你们有无限token，我没有啊。"

## 第二重成本：循环之前，你得先把所有事情想清楚

循环工程有一个被低估的门槛：它要求你在启动循环之前，就把任务的验收标准完全想清楚，并且翻译成机器能自动检查的规则。

在《循环工程到底在干什么》里我详细拆过一个被广泛引用的成功案例。那个开发者先用HTML写了一份像素级精确的设计稿，最终页面该长什么样全部定死。然后写了三层测试：端到端测试模拟用户操作，UI测试做像素级截图比对，单元测试管底层逻辑。然后一行命令启动循环，Claude跑几个小时交付了完整功能。

到这里你可能觉得循环工程真的很猛。但仔细看，这个开发者真正厉害的地方不是会敲那行启动命令，而是他在启动之前做的所有准备工作。他把脑子里那句"这个东西该做成什么样"，硬生生翻译成了一整套精确的、机器能自动执行的验证体系。

这件事的难度很高。

大量实际开发中的判断是模糊的、渐进的。架构方向走不走得通？你不知道，写着写着才知道。功能做到什么程度算够？你不确定，看了用户反馈才清楚。代码的可读性好不好、设计是不是过度？这些判断你自己都是边做边想明白的，让你在动手之前就写成测试用例，你写不出来。

不是你能力不行，是这些判断的性质决定了它不可能被提前编码。有些答案在你做的过程中才会浮现。

所以循环工程的适用范围其实很窄：只有那些目标可以精确定义、成功标准可以完全自动化验证、任务范围从头到尾不会变的场景，循环才跑得通。CI监控、依赖升级、代码格式化、有完善测试的功能开发，这些没问题。但一旦进入需要品味、需要取舍、需要理解"用户到底想要什么"的地带，循环就转不动了。

你没法把"品味"编译成一个返回true或false的函数。

## 真正杀死循环工程的：模型自己学会了长时间工作

以上两个成本是循环工程的固有缺陷。但真正杀死它的不是这些缺陷，而是一个更根本的变化：循环工程试图解决的那个问题，被模型自身的进化解决了。

Fable 5是6月9号发布的，比Steinberger那条推文晚两天。发布之后，情况发生了质变。

此前的模型，包括Opus 4.6和4.8，确实是"你问一点它答一点"的模式。你不给它下一步指令，它就不知道接下来该做什么。这正是循环工程存在的前提：模型自己不会持续工作，所以你需要一个外部程序来驱动它持续工作。

Fable 5打破了这个前提。它可以持续数小时多目标自主运行，默认1M token上下文，在长复杂任务中保持强指令记忆。Stripe用它在一天内完成了5000万行Ruby代码库的迁移，同样的工作人工团队估计需要两个多月。Kimi 3也有类似的长程任务能力。

之前需要外部循环来实现的事情，持续工作、不丢上下文、自主规划执行验证，现在模型原生就能做到了。

为什么模型突然能做到了？

在《深度解读GLM创始人唐杰眼中的Scaling Law》那篇文章里，我详细讨论过一种叫Agent RL的训练方式。它不是让模型做选择题，而是让模型在真实环境中执行完整的长链条任务：收到"修复这个代码仓库里的bug"→阅读代码→定位问题→修改文件→编译→编译失败→阅读错误信息→再修改→再编译→跑测试→发现另一个问题→继续修→最终测试通过。

这一整条轨迹可能有几十步甚至上百步。模型从这些轨迹中学到的，不是某个具体的知识点，而是如何规划、执行、检查、犯错之后恢复。

在《大模型的刻意练习》里我把这种能力概括为元认知：做完验算一遍、卡住了换条路、发现矛盾就回查假设。这些"思考的流程"以前靠外部循环来强制执行（跑一轮、检查、不行就再来一轮），现在模型自己内化了。

打个比方。循环工程是给不会骑自行车的人装的辅助轮。辅助轮不是一个坏发明，对于不会骑车的人来说它确实有用。但现在模型学会骑车了。辅助轮不只是多余的，它还限制了转弯半径，拖慢了速度。

你让一个能自主工作数小时的模型在外部循环里跑，每隔几分钟就被重置一次上下文，被迫重新理解已经理解过的东西，这不是在增强它，是在给它加枷锁。

## 委曲求全的技术方案注定短命

循环工程不是一个糟糕的想法。它是一个在特定限制条件下合理的工程妥协。但工程妥协的命运就是：一旦限制条件改变，妥协就失去存在的理由。

当前这一代模型已经改变了限制条件。模型能力的进化速度，远快于外部编排方法论的成熟速度。循环工程还没来得及形成完整的最佳实践和工具生态，它要解决的问题就已经被模型自身消化了。

回看整条线索：从prompt engineering到context engineering到harness engineering到loop engineering到graph engineering，每个概念的生命周期都在缩短。这本身就暗示了一个趋势：这些外部工程技巧的重要性在递减，真正驱动进步的是模型能力本身。

六周从爆火到被弃，不是因为循环工程这个概念不好，是因为模型变强的速度太快了，快到任何"弥补模型不足"的外部方案都来不及站稳脚跟。

而同样的逻辑，也适用于Steinberger六周后推出的接替者graph engineering，以及整个多Agent编排的思路。这个话题，我们下一篇再聊。

![](images/4db38b/img_001.png)

我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。

如果你也在自己**跑模型、写代码、做项目**，

或者使用**Claude**和**Claude code**，

欢迎**点赞关注转发**一键三连，然后加我微信，备注写清"你在做的AI方向"，聊得来的话我拉你进群。纯围观的和小白就不加了，有一定门槛。当然你也可以简单粗暴的甩给我999元，我拉你进群，这个没门槛。

![](images/4db38b/img_002.jpg)