Loop Engineering：把"提示 AI"这件事交给 AI 自己

推荐一个非常好用的海外 AI 代充平台 BeWild，我的海外 AI 服务全都是在这个平台代充的。

最近几个月，AI 编程圈冒出一个新词：Loop Engineering（循环工程）。Peter Steinberger（Steipete）在一条推文里说了一句被反复引用的话：

"别再手动提示 coding agent 了。你应该设计的是让 agent 跑起来的循环。" —— Steipete 推文，2026 年 6 月（经 Addy Osmani 博客与 The Register 转述）

Anthropic Claude Code 负责人 Boris Cherny 在另一次场合说了几乎一样的话："我已经不直接 prompt Claude 了，我有一堆跑着的循环在替我 prompt Claude、搞清楚该干什么。我的工作是写循环。"（同样经 The Register 同篇报道转述）

这两句话几乎同时引爆话题，Addy Osmani 随即写了篇同名博客把概念系统化。一时间 Hacker News 上相关讨论近千条，"loop engineering"成了继 prompt engineering、agentic coding 之后又一个被争相讨论的标签。

但这个概念到底是真进步，还是旧瓶装新酒？我研究了一圈一手资料后，发现答案是：两者都是。这篇文章就来把它拆开看清楚——它新在哪里、旧在哪里、以及作为工程师该怎么理性地用它。

如果你读过我这个博客上一篇 《AI Agent 的工程化哲学：Harness 设计的核心原则》，可以把本文当成它的下一层：Harness 讲的是"如何搭好单个 agent 的脚手架"，Loop Engineering 讲的是"如何在脚手架之上再搭一层让 agent 自己跑起来的循环"。Addy 自己也是这么定位的——loop engineering 是 harness engineering 的上一层。

1. 到底什么是 Loop Engineering

先把定义说清楚。Addy Osmani 给出的最常被引用的定义是：

"Loop engineering 是用一套系统替换掉'那个亲自提示 agent 的人'。你来设计这个系统，让它去提示。这里的 loop 可以理解成一个递归目标——你定义一个目的，AI 不断迭代直到完成。"

关键词是递归目标和迭代直到完成。传统用 AI 编程是"你说一句、它做一步、你再说一句"——你是那个 driver，每一轮都要你在场。Loop Engineering 要把人从 driver 座位上挪开，换成一坨自动跑的代码：它自己发现该干什么、自己干、自己验、自己记录、自己决定下一步。人退到"循环设计者"的位置上。

打个比方：用 Claude Code 像是在开车，你的每一次指令都是打方向盘；Loop Engineering 像是在给车装自动驾驶，你设定目的地和规则，它自己跑，你只在关键路口接管。

这不是简单的"让 agent 多跑几轮"。ReAct 循环、agentic coding 早就有了，Loop Engineering 多出来的东西是让循环能长期、自治、可记忆地跑下去的那套外围设施——调度、隔离、记忆、验证、子 agent。这才是它作为一个新标签的内核。

小结： 从 prompt engineering 到 loop engineering，人机关系的转变是从"我每一轮都在场"到"我设计好规则就离场"。这个转变能不能成立，完全取决于那套外围设施搭得够不够硬。

2. 一个 Loop 需要的五件套 + 一个记忆

Addy 把一个 loop 拆成五个组件外加一个记忆载体。这个模型很实用，直接照搬过来：

第五条"制造者/检查者分离"特别值得展开。人类写代码都有"自己写的 bug 自己看不出来"的问题，LLM 更甚——它对自己产出的置信度天生偏高。所以一个靠谱的 loop 一定会派第二个 agent 来审查第一个 agent 的产出，而且最好用不同的 prompt 甚至不同的模型。Addy 特别提到，很多成熟 agent 框架会用一个独立的 goal-checker（通常配更小更便宜的模型）来判断"任务到底完成没有"——停止条件必须是可验证的，比如"auth 模块测试全过、lint 干净"，而不是让干活的模型自评一句"done"。

这里有个反直觉的点：Memory 用 markdown 文件或 Linear 看板这种"土"载体，而不是塞进 LLM 的 context window。原因很现实——agent 会忘，但 repo 不会忘。把状态写在磁盘上，下一次循环从文件读起来接着干，比指望模型记住跨会话的上下文可靠得多。这其实是 Context Engineering 的延伸：上下文窗口是稀缺资源，长期状态就该外置。

小结： 一个能脱离人长期跑的 loop，缺一不可的是这五件套加一个外部记忆。其中最容易被忽视、也最关键的是"制造者/检查者分离"和"状态外置"——前者保证质量，后者保证连续性。

3. 四层循环栈：从"会跑"到"会进化"

Addy 的五件套是"横向"的组件视角。LangChain 给了一个"纵向"的分层视角，把 loop 工程拆成四层嵌套的循环栈。我觉得这个框架更透，因为它解释了 loop engineering 的价值到底在哪一层：

┌─────────────────────────────────────────────┐
│ Loop 4  Hill-climbing loop   自我改进        │  ← 用生产 trace 优化 harness 配置
├─────────────────────────────────────────────┤
│ Loop 3  Event-driven loop    嵌入生态        │  ← cron/webhook 触发，后台常驻
├─────────────────────────────────────────────┤
│ Loop 2  Verification loop    质量闸门        │  ← grader 按标准打分，失败带反馈重试
├─────────────────────────────────────────────┤
│ Loop 1  Agent loop           干活            │  ← 模型反复调工具直到子任务完成
└─────────────────────────────────────────────┘

• Loop 1（Agent loop）：最底层，就是模型在一个子任务里反复"调工具 → 看结果 → 再调"直到干完。这是 ReAct 时代就有的，不算新。
• Loop 2（Verification loop）：在 Loop 1 外面套一个验证循环。agent 干完不是直接交付，而是交给一个 grader 按评分标准检查；不过关就把失败原因喂回去让它重做。这就是上一篇 Harness 文章里讲的 Verifier Loop 的工程化形态。
• Loop 3（Event-driven loop）：让 loop 真正"活"在系统里——cron 定时触发、webhook 事件触发，agent 在后台常驻运行。这一层是 loop 从"手动跑一次"变成"自动持续跑"的关键。Addy 的"早晨循环"就是典型形态：每天定时跑起来，扫 CI 失败和 issue，自己派活、自己开 PR。
• Loop 4（Hill-climbing loop）：最上层，也是最科幻的一层。把生产环境的 trace 喂给一个分析 agent，让它根据实际运行数据重写下面几层 harness 的配置——loop 不只是干活，还在改进自己干活的系统。一个最小可行形态长这样：把 Loop 2 里 grader 打分偏低、却靠重试蒙混过关的 case 收集起来，喂给一个分析 agent，让它自动改写 grader 的 rubric prompt 或调整某个工具的 description，下次 Loop 2 就能用更严的标准拦住同类问题。这本质是把 eval 结果当优化信号，反向喂给 harness——再往前一步，LangChain 甚至展望它对接 RL fine-tuning，用 trace 直接改模型本身。

一个关键判断：Loop 1、2 是基本功，Loop 3 是分水岭，Loop 4 是远景。绝大多数团队现在能做好 Loop 1 就不错了，Loop 2 要认真做验证基础设施，Loop 3 才是"loop engineering"这个标签真正想强调的东西——让 agent 真正嵌入工作流自治运行。Loop 4 目前基本还是愿景，但它指出了 loop engineering 的终极方向：让系统自己变好。

小结： 四层循环栈里，真正的工程价值集中在 Loop 2（验证）和 Loop 3（事件驱动）。Loop 1 早就有，Loop 4 还很远。判断一个所谓"loop engineering"方案成不成熟，看它有没有把 Loop 2、3 做扎实就够了。

4. 一个早晨循环长什么样

抽象框架讲完，来个具体的。Addy 描述了一个他每天在用的"早晨循环"，很能说明 loop engineering 的实际形态：

每天早晨 cron 触发
   ↓
automation 跑在 repo 上，调用 triage skill
   ↓
读取：昨天的 CI 失败、open issues、最近 commits
   ↓
把发现写进 markdown / Linear 看板（Memory）
   ↓
对每个值得做的发现：
   ├─ 开一个隔离 worktree
   ├─ 派 sub-agent A 起草修复
   └─ 派 sub-agent B 对照项目 skills 和测试审查 A 的草稿
   ↓
connectors 开 PR、更新 ticket
   ↓
loop 处理不了的 → 扔进 triage inbox 给人

注意这个流程里人什么时候出现——只在最后，处理 loop 自己搞不定的东西。前面所有环节：发现工作、隔离环境、起草、审查、开 PR，全是 loop 自己跑的。人从"每一行代码的审批者"变成了"异常处理者"。

这听起来很美，但有个容易忽略的成本：人的 review 带宽是天花板。Addy 自己强调，worktree 解决的是多个 agent 互相踩踏的"机械碰撞"，但解决不了"人看得过来吗"这个问题——你能同时 review 几个 agent 开的 PR，决定了你这个 loop 实际能跑多大规模。工具不是瓶颈，你是瓶颈。这点我深以为然，很多人讨论 loop engineering 时只盯着自动化能跑多快，却不想想自己 review 的速度跟不上，结果 loop 跑出来的东西堆在那没人看，反而是负资产。

小结： 一个成熟的 loop 把人挤到异常处理的位置，但人的 review 带宽决定了 loop 的实际吞吐上限。自动化跑得再快，review 跟不上就是堆废代码。

5. 它和那些相邻概念什么关系

Loop engineering 不是凭空冒出来的，它处在一堆近义词的包围里。不讲清关系，很容易越看越糊涂：

一句话总结这张关系图：Loop engineering 是个上位概念，它把 agentic coding、context engineering、eval-driven、spec-driven 当组件编织进一个自治循环系统；vibe coding 是它的前驱与反面。 这也解释了为什么它争议大——上位概念天然容易"看起来什么都包含、又什么都没新说"。

小结： 别把 loop engineering 当成一个独立的新学科，它是把一堆已有实践（agent 循环、context 管理、eval、spec）编织进一个自治系统的"打包命名"。理解它最好的方式是理解它打包了什么。

6. 争议：这是新工程，还是旧概念换皮？

这是整件事最值得认真看的部分。Loop engineering 一边被追捧，一边被尖锐批评。批评方核心论点很统一：你说的这些，分布式系统二十年前的概念都有。

iii.dev 的 Mike Piccolo 给了一张很扎眼的术语对照表：

他的结论很直接："命名不同，系统是一样的。" AWS SQS 早在 2004 年就上线了（比 S3 和 EC2 还早）。The Register 更是冷嘲热讽，说这是在"celebrating autonomous token consumption"（为"自主烧 token"欢呼），并指出编程里的循环早在 Fortran 时代就有。

这些批评对不对？对，事实层面完全对。loop engineering 描述的机制——调度、重试、死信、隔离、可观测——确实都是分布式系统的老概念。如果你是一个做过消息队列、工作流引擎、批处理系统的工程师，看 loop engineering 的五件套会有强烈的"这不就是 XX 吗"的既视感。

但批评也漏了一层。旧概念换了个新场景，本身就是有价值的工程进展。这些分布式系统原语过去是给"确定性的业务代码"用的，现在要套到"非确定性的 LLM"上，这个迁移不是简单改名：

• LLM 的输出是概率性的，验证循环（Loop 2）的比重远大于传统系统——你不能假设一次执行就对。
• LLM 有 context window 限制，Memory 这一层不只是缓存，而是"把记忆外置让 agent 跨会话连续"的专门设计。
• LLM 的"智能"可以被引导，所以 Skills（把项目知识固化）这一层在传统系统里没有对应物——你不需要给一个 SQS worker 讲"我们项目的代码风格"。

所以我的判断是：机制是旧的，场景是新的，组合是有价值的。把它当神药吹捧是傻，把它当纯营销话术一棍子打死也是懒。正确的态度是承认它的工程内核借鉴了成熟的分布式系统设计，同时认真对待 LLM 这个新场景带来的新约束。

小结： 批评者说"这就是分布式系统旧概念"在事实上没错，但忽略了把这些原语适配到非确定性 LLM 场景本身就是工程迁移。loop engineering 的价值不在发明新机制，在于把老机制和新场景做了一次有效组合。

7. 真实代价：钱、理解腐烂、认知缴械

比起概念之争，更该关心的是实际代价。有意思的是，最清醒的风险清单来自 Addy 本人——他在定义 loop engineering 的同一篇文章里就列了三大风险，这种坦诚反而增加了他的可信度。

第一，验证仍然在你身上。 无人值守的 loop 也在无人值守地犯错。agent 说"done"是声明，不是证明。如果你没配好 Loop 2 的验证循环，或者验证标准本身有漏洞，loop 会又快又自信地生产错误。jeena.net 有一个血淋淋的案例：他用完整的 plan/execute/critique/repair 循环架构做韩译英翻译，结果 critic 一直说"翻得不够好"打回来，executor 又一直改进不到让 critic 满意的程度——死循环跑了几个星期，最后放弃了。这是 loop engineering 的典型失败模式：验证者和执行者陷入死锁，没有断路器（circuit breaker）兜底。loop 能替你干活，但替不了你判断干得对不对。

第二，理解腐烂（comprehension debt）。 loop 越快地 ship 你没读过的代码，"代码库里存在的"和"你真正理解的"之间的差距就越大。短期看产出飞快，长期看你维护的是一个自己越来越看不懂的系统。这比技术债更阴险——技术债至少你知道欠了多少，理解腐烂是你根本意识不到自己不懂了。代码能跑和你能维护，是两件事。

第三，认知缴械（cognitive surrender）。 这是最微妙也最危险的一个。loop 自跑的时候，人极易"放弃自己的判断、照单全收"。Addy 有句话说得很准：

"Designing the loop is the cure when you do it with judgement, and the accelerant when you do it to avoid thinking. 同一个动作，相反的结果。"

他自己也说，如果不是亲自 review 代码、而是完全依赖自动 loop 来修，"产品质量会下降，很可能陷入下行螺旋"。

除了 Addy 列的三条，还有个绕不开的现实问题：钱。loop 让多个 sub-agent 各跑各的，每个都烧 token。Ed Zitron 在批评时引用了一个数字（虽是批评者转述）——Boris Cherny 每月的 token 开销"upwards of $130,000"。这个量级对个人开发者和小团队是天文数字。loop engineering 默认假设你烧得起 token，这个假设本身就筛掉了大多数人。Codacy 的调研也佐证：开发者平均每周已经在 Claude Code 里花 20 小时，且团队在"增加而非削减"每个开发者的 token 预算。loop engineering 是有门槛的奢侈玩法。

小结： loop engineering 的真实代价是四重：验证漏了会又快又错、理解会随自动化腐烂、人容易认知缴械放弃判断、token 开销可能高到不可承受。前三个尤其阴险，因为它们不会立刻暴露，而是悄悄累积。

8. 工程师该怎么理性对待它

讲了这么多，落到一个实际问题：作为工程师，现在该怎么对待 loop engineering？我的建议是分阶段、看场景：

先别急着搭 Loop 3、4，把 Loop 1、2 做扎实。 大多数人连单 agent 的验证循环都没做好，就想着搞自动调度、多 agent 并行，这是典型的还没学会走就想跑。先把"agent 干完 → 客观验证 → 失败带反馈重试"这条 Loop 2 跑通，再谈更高层。Loop 2 的 grader 和测试基础设施，是后面一切的地基。

状态外置比上下文塞满重要。 这是 loop 能不能脱离人长期跑的关键分水岭。把"做了什么、下一步是什么"写在磁盘文件或看板里，而不是指望模型记住。你设计 loop 的第一件事应该是设计它的 state schema——这和设计任何长跑系统一样。

制造者/检查者分离，从单 agent 内部先做起。 不一定要上来就派两个 sub-agent。先在一个 agent 里，让"写代码"和"review 代码"用不同的 prompt 角色切换，也能拿到大部分收益。等你发现单 agent 自审总是漏 bug，再升级到真正的双 agent。

对"无人值守"保持警惕。 loop 跑得越自动，你越要保留人类检查点（human-in-the-loop）。LangChain 强调"自动化不等于移除人类"——敏感动作（改生产配置、动数据库、发外部消息）前必须人类审批。loop 的自动化程度，应该和你的验证可靠度匹配，而不是和你的乐观程度匹配。

给 worktree 并发数设两道闸门：token 预算和 review 带宽。 这是 loop engineering 比 harness 多出来的一层具体约束。N 个 sub-agent 并行就是 N 倍的 token 烧速，先按"月 token 预算 ÷ 单 agent 平均消耗"估出 token 维度的安全并发数；再算你一天能认真 review 几个 PR——两者取小值，才是你实际该开的 worktree 数。多数人会高估第一项、忽略第二项，结果要么月底账单爆炸，要么 PR 堆成山没人看。

小结： 分阶段、看场景，别让自动化程度超过验证可靠度。loop engineering 目前还处于"流行词 + 实践流派"的早期阶段，没有统一标准定义，公开的可验证生产案例也极少——除了 jeena 那个失败案例和 iii.dev 的产品自述，几乎没有带量化指标的第三方生产数据。所以现在学它的价值，在于学这套工程思维（调度、隔离、验证、记忆、子 agent 的组合），而不是急着找个"标准框架"照搬。那些分布式系统的老概念之所以能用二十年，正因为它经过充分验证；loop engineering 要真正成熟，也得经过同样的检验。

总结

把整件事浓缩成几句话：

• Loop Engineering 的内核：把"人逐轮提示 agent"升级成"人设计循环、agent 自治运行"，核心是让循环能脱离人长期跑下去的那套外围设施（调度、隔离、记忆、验证、子 agent）。
• 它的结构：横向是 Addy 的"五件套 + 一个记忆"，纵向是 LangChain 的四层循环栈（agent → verification → event-driven → hill-climbing）。真正的工程价值在 Loop 2 和 Loop 3。
• 它的争议：机制是分布式系统二十年前的旧概念，但适配到非确定性 LLM 场景的这次迁移是有价值的组合，不必神化也不必贬低。
• 它的代价：验证漏洞、理解腐烂、认知缴械、token 成本——前三个阴险，第四个昂贵。
• 怎么对待它：先把 Loop 1、2 做扎实，状态外置，制造者/检查者分离，保留人类检查点，别让自动化程度超过验证可靠度。

如果说 vibe coding 是"感性共舞"，harness engineering 是"给 agent 搭脚手架"，那 loop engineering 就是"在脚手架之上装一套让 agent 自己干活的自动循环"。三者是同一条演进线上的不同阶段。作为一个仍在快速分化的早期概念，现在最值得学的不是某个具体框架，而是它把已有工程原语重新组合的那套思路——调度、隔离、验证、记忆，这些词你换成 cron、worktree、测试、状态机，其实就是你早就熟悉的那些东西。

Loop engineering 没有发明新机制，它只是提醒我们：当模型聪明到可以自治时，工程师的主战场就从"写每一行代码"挪到了"设计让代码自己被写出来的系统"。这个转变是不是真的会发生、能走多远，还得再观察一阵——但至少，先把它的工程内核吃透，总没坏处。

返回博客列表