Loop解决了AI仙人token多得没处花的问题

本文来自微信公众号： 碳基智 ，作者：碳基智

我真的是麻了，AI圈拜托能别这么每天造词吗：

Prompt Engineering-Context Engineering-Harness Engineering-Loop Engineering

两年不到，范式都特么「进化」到第四个了，我看还有哪些旧酒可以装到你们这些新瓶里。

1

先说说Loop Engineering怎么来的，它的横空出世要得益于这三位AI仙人：

6月，Boris Cherny（Claude Code创造者）演讲展示他"6个月没打开IDE、一个人靠AI循环产出259个PR、497次提交、4万行代码"的实战模式。Peter Steinberger（OpenClaw作者）发文推广AI循环编程方法。Addy Osmani（Google工程师）2026年6月7日发表系统性博客正式命名。

Addy Osmani的定义：

Loop engineering is replacing yourself as the person who prompts the agent.You design the system that does it instead.

翻译成人话就是：

以前你要人肉去写提示词调教Agent，现在你搞个Loop工程让AI自己去驱动、评估、修正、执行。

他们把Loop分成了6个阶段：

1. Input Capture：自己找到下一件要做的事（cron、事件监听、上一轮输出触发）

   
   

2. Context Assembly：自动从文件、向量索引、上一轮摘要中组装上下文

   
   

3. Model Inference：Prompt是Harness自动生成的，不是人写的

   
   

4. Action Execution：写文件、跑测试、调API、开PR

   
   

5. Observation&Logging：捕获结果并结构化记录

6. Memory Update：将本轮学到的信息写回持久存储

   
   

639b5c929a225e787a02545e1e37bfa0.png

坦率讲，Loop的每一项技术构件都不新：

• 自动化调度→cron job（1975年）

  
  

• 工作树隔离→git worktree（2015年）

  
  

• 子Agent分工→多Agent协作（2022年ReAct论文）

  
  

• 反馈闭环→控制论（1948年Norbert Wiener）

  
  

• Maker-Checker分离→四眼原则（金融行业用了几十年）

  
  

我是真的不想再说一次，但很遗憾，AI圈现在新造的这些工程范式，依旧在套《控制论》的公式，就像我之前写的那篇一样。

2

Prompt Engineering-Context Engineering-Harness Engineering-Loop Engineering，这所谓的四次跃迁背后，其实也没多少新的变化，每次都遵循几乎完全相同的模式：

触发条件：上一层范式的局限性被实践暴露。Prompt的局限催生Context；Context的局限催生Harness；Harness的局限催生Loop。

跃迁方向：人的工作从「直接操作」升级为「”」设计操作规则」。本质上是控制论里的抽象层级跃迁：从直接施加力，到设计施力系统，到设计施力系统的调度规则。

叠加关系：四者不是替代关系，是层叠嵌套关系。Loop建立在Harness之上，Harness建立在Context之上，Context建立在Prompt之上。没有Harness的Loop=没装刹车的自动驾驶；没有Loop的Harness=停在车库里的好车。

变与不变：技术底座始终没变，依然是Prompt+LLM+工具调用。改变的只是人与系统的交互界面所处的抽象层级。

就这些东西，翻来覆去吹了两年，什么眩晕瘫痪啦，什么核弹爆炸啦，什么颠覆世界啦，什么XX已死啦，烦得很。

3

要我说，Loop Engineering解决的最大问题，就是AI仙人们token多得花不完的现象。当我们每天还在肉疼那token消耗量的时候，一群一天干掉几千上万（没那么少？）美刀的人，分享着何不食肉糜的所谓实战经验，我问你食不食油饼？

这套东西背后最大的问题，首先就是成本的失控。Boris和Peter的4万行AI代码背后，是Anthropic和OpenAI近乎无限的Token额度。实测数据：Loop模式的总Token消耗是手动Prompt模式的3-8倍。单段自动化任务的成本是人工完成同类任务的2-4倍。我一个20美刀的Codex你让我跑自循环？

好，假设你真有这么多token。那我请问了，Loop一天帮你ship 20个PR，你真正理解其中几个？Addy Osmani自己都说：Loop越快交付你没写过的代码，仓库里存在的和你实际理解之间的差距就越大。代码库里有30%的代码你从未仔细看过，这个比例只会随Loop运行时间线性增长。

更典的是，当Loop稳定运行几周后，你，还能有啥自己的想法？Loop给你啥你就接受啥，一坨巧克力味的粑粑你吃不吃？Osmani的原话："The danger is stopping having an opinion when loops run autonomously."两个人搭建完全相同的Loop，可能得到完全相反的结果：一个用它加速自己深入理解的工作，另一个用它逃避理解工作这件事情。

程序员花了很多年做可观测性的事情，一Loop就全玩完。当Loop在凌晨3点跑了47轮输出一坨垃圾代码，你怎么debug？当下没有成熟的Loop Observability方案。传统APM监控的是确定性请求链路，Loop的链路是动态生成的、非确定性的、跨多个Agent的。难搞啊！

Prompt Engineering有benchmark和eval框架，Loop Engineering连什么算一个好的Loop都还在争论。没有一个量化的标准去评估，也没有像Harness那样的脚手架，你这玩意儿怎么整呢。

消停会吧，别吹了。