每次发新模型，都有人说”能长程工作”、“连续干几小时”、“一口气写完操作系统”。我一直在想一个问题：他们怎么做到的？为什么我用了AI之后，活反而更多了？
6月最后一周，X上开始流传一句话：Stop prompting, start looping.
不prompt了那干什么？怎么让AI自己跑？
Claude Code的负责人Boris Cherny说他不prompt了。OpenAI的团队已经用这个思路造出了一个百万行代码的产品，有人天天在用。
但X上有人写了篇文章，标题叫”WTF Is a Loop?”，副标题是：AI编程圈被反复传颂的一句话只有六个单词长，但几乎没人能定义它。
harness、loop、loop engineering，不同的人不停地造词。我花了一周追这条线，从2月到6月，四篇文章，想搞清楚这些词到底在说什么。越往深看，越觉得这事不只是技术升级。
从harness到loop
2月11号，OpenAI发了一篇文章，标题叫 Harness Engineering。他们有个团队做了个实验：用Codex从零开始造一个产品，0行手写代码。应用逻辑、测试、CI配置、文档、监控，全部agent生成。
5个月，3个工程师，1500个PR合并，百万行代码。产品有内部用户天天用，有外部测试者在用。
OpenAI总结了一句话：Humans steer. Agents execute. 人掌舵，agent干活。
这篇文章讲的是harness。怎么给agent搭一个环境：怎么组织代码库让它读得懂，怎么写规则让它不跑偏，怎么搭测试让它的产出可信。harness是让单个agent能可靠干活的那层脚手架。
我读完最想知道的是：他们到底怎么做到的？用什么工具？提示词写什么？但这篇没细讲操作。它讲的是另一件事：环境。
但这只是第一层。
三个月后，OpenAI自己往前迈了一步。
5月12号，他们发了一篇Cookbook：Agent Improvement Loop。不教你搭环境了，教你怎么搭一个循环，让环境自己变好。
agent跑完，抓trace。收集反馈，人写的加上模型自己评的。把反馈变成eval，下次能自动跑。然后用HALO分析一遍，产出一份改进清单，Codex直接拿去执行。改完再跑，跑完再抓，抓完再改。
一个飞轮。
“飞轮”这个词让我一下来了兴趣。怎么搭？用什么工具？
（图片来源：OpenAI Cookbook）
OpenAI在这篇里还给harness下了个明确定义：围绕模型的完整契约，包括指令、工具、路由、输出要求和验证检查。
harness是”搭好环境让agent能干活”。improvement loop是”搭一个循环让harness自己变好”。又过了一个月，有人给这一层取了名字。
6月7号，Addy Osmani写的。前Chrome团队的人，技术圈顶级博主。文章标题就两个字：Loop Engineering。
读这篇之前我一直有个困惑：loop和harness到底什么区别？
他在文章里把两层的关系说得很清楚：
“我之前写过它的表亲，agent harness engineering。Loop engineering sits one floor above the harness。”
loop比harness高一层。harness是给一个agent搭好环境，让它能干好一次。loop是在上面再盖一层，让agent自己找活、自己调度、自己检查、自己循环。harness解决的是”能不能干好”，loop解决的是”能不能自己一直干下去”。
Addy在文章里引了一句话：
“你不需要擅长prompt了。你需要擅长的是那个替你prompt的loop。”
三周后，6月30号，Anthropic发了Getting Started with Loops。我一开始没看出来这篇和Addy那篇有什么不同。读完才发现，Addy拆的是loop由什么构成，Anthropic分的是loop能走多远。
Anthropic把loop正式分成了四层：第一层，你手动一句一句prompt。第二层，你设一个目标让它自己跑到达标。第三层，你定时触发它自己干活。第四层，事件驱动，全自动闭环，你不在场它自己转。
Anthropic在博客里给了几个具体例子。第二层，你设一个目标，比如”把首页性能分提到90以上，最多试5次”，agent自己判断达标没有，没过就继续改。第三层，你设一个节奏，比如”每5分钟检查我的代码评审，有意见就处理，测试挂了就修”。第四层把前面的全组合起来：每小时自动检查bug反馈，每条报告都要被分诊、修复、回复，修的时候开三个并行分支探索不同方案，再让一个审查agent对抗式评审。整个过程没人盯着。
Claude Code的负责人Boris Cherny也说过一句话（引自Addy的博客）：
“我不再prompt Claude了。我有loop在跑，loop替我prompt Claude。我的工作是写loop。”
做Claude的人自己都不prompt了。
从2月到6月，四篇文章，一条线逐渐清晰：怎么让agent不仅能干活，还能自己一直干下去。
那loop到底是什么
读完这几篇文章我发现，这些词虽然叫法不同，说的其实是同一件事。
你用AI干活，不管用的是Claude、GPT、还是我用的opencode配GLM和DeepSeek，基本模式都一样：你说一句，它做一步，你看一眼，再说下一句。你来我往，像打乒乓球。
prompt是你拿着球拍，一下一下打。loop是你设计一台发球机，让它自己打。
Addy Osmani把loop拆成了五个积木块。我挨个翻译：
第一块：自动心跳。 你不用守着。设一个节奏，比如每天早上自动检查一遍有没有新bug，有没有测试挂了，有没有代码冲突。它自己找活，找到就干，找不到就归档。你醒来一看，昨晚的活已经干完了。
第二块：隔离工作区。 你同时让两个agent干活，它们改的是同一个文件，撞了怎么办？给每个agent一个独立的工作目录，各干各的，干完再合。就像给两个程序员各分一个分支，互不打架。
第三块：技能文件。 你每次跟AI对话都要重新解释一遍”我们项目用什么技术栈，代码规范是什么，测试怎么跑”。技能文件就是把这些东西写一次，AI每次启动自己读。你不用当复读机了。
第四块：连接器。 你的AI能碰到你的真实环境吗？能读你的GitHub issue吗？能查你的数据库吗？能往Slack发消息吗？连接器就是这些触手，让AI不是在真空里干活，是在你的真实系统里干活。
第五块：子agent。 一个agent写代码，另一个agent审代码。写的人和审的人不能是同一个，因为给自己改卷子的人都会手软。用两个不同的agent，互相制衡。
五块搭起来，就是一个自己运转的系统。你设计的不是某一次对话，是一个能反复运行、自己找活、自己检查、自己修正的循环。
这就是loop engineering。
读到这儿我才反应过来，我之前对”用AI”的理解一直是错的。我以为用AI就是坐在那儿盯着它干活，一句一句来，它做一步我看一步。但loop说的不是这个。loop说的是你不在场，AI自己跑。你的活是思考，不是盯着。
Addy Osmani那篇文章里还有句话，我觉得是全文最重要的一句：
一旦你发现这五个积木在Codex、Claude Code、opencode里形状是一样的，你就不再纠结用哪个工具了。你只设计loop本身。
工具不重要了。loop的形状，是一样的。
还有另一个角度值得知道。
Andrew Ng，吴恩达，6月30号也聊了loop engineering。他不用五个积木来拆，他用三个节奏来分：
第一个loop最快，几分钟一轮： agent写代码、跑测试、自己迭代，直到bug-free。你不在场。
第二个loop中等，几十分钟到几小时： 你看产品，给方向，agent改。你不再是QA了，你变成了产品经理。
第三个loop最慢，几小时到几周： 真实用户、A/B测试、市场反馈。数据回来，你调整方向，再喂给第一个loop。
三个loop嵌套着跑。最内圈自动转，中间圈你定时介入，最外圈靠真实世界反馈。
（图片来源：Andrew Ng / X）
Ng说了句挺到位的话：很多人把人的作用叫”taste”（品味），他更愿意叫”context advantage”（上下文优势）。因为人对用户和场景的理解，AI还比不了。只要这个优势还在，人就不会被删掉，只是站的位置变了。
Anthropic那篇文章还提供了一个很实用的视角：每一种loop，你交出去的东西不一样。
turn-based loop，你交出去的是”检查”。goal-based loop，你交出去的是”停止条件”。time-based loop，你交出去的是”触发时机”。proactive loop，你交出去的是整个prompt。
交出去的越多，你越轻松，也越危险。所以Anthropic在那篇文章里反复强调一件事：你得给agent一种自己验证自己的能力。
他们的方案是写一个验证技能文件。比如你改了前端代码，agent不能只说”改完了”，它得自己启动开发服务器、打开浏览器、点一遍、截个图、查console有没有报错。把这些步骤写成一个SKILL.md，agent每次完成前端任务就自动按这个清单走一遍。
不靠你检查，靠它自己检查。而且检查标准是你定的。
Anthropic还提了几条管理token的建议：先用小范围试跑再放大，能用脚本解决的别让agent推理，别让routine跑得比你要监控的东西变化得还频繁。
交出去之前，先想清楚你怎么信任它。
loop的暗面
第一，“done”是声明，不是证明。
agent跑完一轮，跟你说”搞定了，测试全过”。你信了。但你没自己跑一遍。loop越长、越自动，你越不在场，它犯错的时候你越看不见。
Addy Osmani在文章里反复强调这一点：loop跑的时候你不在，所以一个你能信任的验证机制是唯一让你敢走开的原因。没有验证，loop就是一个高速造错的机器。
第二，loop会放大代码的坏习惯。
Armin Ronacher说的。Flask框架的创建者，Python生态里最有影响力的开发者之一。他在自己博客上写了The Coming Loop。
他的判断很具体：现在的模型写出来的代码天生就too defensive, too complex, too local in its reasoning。遇到边界条件，它们倾向于加fallback，而不是让坏状态根本不可能发生。代码重复、烂抽象、用更多机制去遮盖不清楚的设计。
然后他点出了最关键的问题：当你把这种行为放进loop里，你会放大它。每轮迭代加一层防御，系统看起来越来越健壮，实际上越来越看不懂。
“Looping is powerful but it removes responsibility more and more, and it at least today very much encourages us to give in to the machine.”
不是键盘侠吐槽。是一个写了二十年代码、创建了Flask和Jinja的人，在自己博客上认真写的判断。
第三，loopmaxxing。
有人给过度使用loop造了个词：loopmaxxing。什么任务都往loop里塞，不管适不适合。简单的改一行代码也要开个loop，跑测试也要开个loop，写个文档也要开个loop。
Anthropic自己在那篇文章里也说了：不是所有任务都需要复杂loop。从最简单的方案开始，选择性使用。
第四，loop不便宜。
有人算了token成本：
单个agent跑一个中等任务，5万到20万token。一个编排器带3个专家agent的fleet loop，50万到200万token。
你睡着的时候loop在跑。你醒来一看，活干完了，账单也到了。跑歪了一晚上烧掉的钱，可能比你一天工资还多。
第五，最隐蔽的危险：认知投降。
loop跑得太顺，你会忍不住停止思考。它给什么你收什么。它写的代码你不读，它做的决策你不审，它选的方向你不质疑。你不是在用AI，你是在被AI带着走。
Addy Osmani有一句话，我觉得是整个loop话题里最清醒的一句：
两个人搭一模一样的loop，结果完全相反。一个用它加速自己理解的工作。另一个用它逃避理解。loop分不出区别。你能。
Anthropic那篇博客结尾有个建议，我记了下来：先看看你现在的活，找一个你自己是瓶颈的地方，问自己三件事，验证标准能不能写清楚，目标够不够明确，这活是不是定期重复的。能答上来，就知道从哪一层开始。
他们还有句话让我印象很深：loop跑出来的东西不达标，别只修那一个bug，把它写进验证流程里，让以后每次跑都自动检查这个问题。不是打补丁，是升级系统。
回到开头那个问题
为什么我用了AI之后，活反而更多了？
以前我只需要干活，写代码、改文案、做测试。现在这些AI全干了。但多出来的不是空闲，是别的东西：设计系统，定义检查标准，读AI写的代码，判断哪些方向是对的，出了问题往哪儿查。
以前累的是手，现在累的是脑子。
Andrew Ng说人对AI的优势叫”context advantage”，上下文优势。你知道用户是谁，知道场景长什么样，知道什么东西做出来有人用。AI不知道。只要这个优势还在，人就不会被删掉。但这个优势不是白来的，它要求你持续理解你自己的系统，持续读AI写的代码，持续保持判断力。
有人说没人再写prompt了。没错。但新工作不是更轻松了。以前你盯执行，现在你定方向。活从手上挪到了脑子里，重量一点没少。
