Now is loop engineering？

Update: 2026-06-09

看到 Addy Osmani 写了一篇不错的 Loop Engineering 介绍：

他里面提到的 loop 需要几类东西：定时自动跑起来的 discovery 和 triage；让多个 agent 并行工作时互不踩文件的 worktrees；把项目知识写下来的 skills；把 agent 接到现有工具里的 plugins 和 connectors；用 sub-agents 做分工和复核；以及一份活在单次对话外部的 memory，比如 markdown 文件、Linear board，或者任何能记录已完成事项和下一步的地方。

这和我下面写的判断很接近：loop engineering 的重点不是再写一句更好的 prompt，而是把任务来源、执行环境、验证机制、项目知识、外部工具和持久状态组织成一个可以持续运转的系统。

正文

最近 X 上被 Loop Engineering 刷屏了。

6 月 7 号，Peter Steinberger 发了一条推特：

再往前一点，Boris 也和 Acquired 合作过一个讲座：

这两件事放在一起看，就很像业界前沿的 coding agent 使用方式，又往前走了一步。

而且这一步可能已经发生了，只是我们还没完全意识到。

这里我想聊聊我从里面学到的东西，以及自己的一些思考。

编程一直在抬高抽象层

Boris 在采访中提到一个很关键的判断：

编程的本质，就是抽象层级（Level of Abstraction）在不断拔高。

最底层，他开玩笑说自己的祖父在苏联时期，是用纸质打孔卡（Punch Cards）给大机器喂数据来编程。

中间一层，他的父亲写 Assembly，甚至会嫌弃 Boris 写 Python 这种高级语言“不是真正的编程”。

再往上，编程语言演进到了 COBOL、Fortran、Java，再到现在大行其道的 JavaScript 和 Python。

现在可能又到了最新一层：AI 驱动的语言层。

人类不再需要一行行抠语法，而是用更高层的逻辑去指挥系统完成任务。

这不是说底层不重要了。恰恰相反，越往上，底层越要稳定。只是工程师手里直接操作的对象变了。

以前你操作的是语法。后来你操作的是 framework。再后来你操作的是 cloud、CI、workflow。

现在你开始操作 agent runtime。

三次范式变化

Boris 自己在 Anthropic 开发 Claude Code 的过程中，亲身经历了过去一年内编程范式的三级跳。

第一阶段：人类写代码，AI 自动补全。

大概一年前，也就是 2025 年中，工程师主要还是在 IDE 里自己写代码。VS Code、Cursor 这一类工具在旁边做行级或块级补全。体验很像 Copilot：你还是主驾驶，AI 在旁边补几句。

第二阶段：人类给 AI 刷 prompt。

到了 2025 年底，差不多 11 月左右，模型能力又往前了一截。Boris 发现自己不再需要一行行写代码了。

他的工作方式变成同时开 5 到 10 个 Claude sessions 并行跑。自己要做的事，是疯狂给 AI 写 prompt，分配任务，看输出，再继续调度。

也就是在那个月，他卸载了自己的 IDE。因为他发现自己整整一个月没打开过它。

第三阶段：人类写 loop。

到了现在，2026 年中，事情又进入一个新的抽象维度。

工程师连 prompt 都不一定要自己亲手写了。

人类写出一段控制循环（Loop）的小程序。这个 loop 自动、连续地向 Claude 发送 prompt，读取输出，执行测试，收集报错，再把反馈喂回去，让 agent 自我修正。

Boris 的原话大概可以这样直译：

我的工作 leveled up 到了下一个抽象维度。我不再直接去 prompt Claude 了，我让 loops 跑起来，由它们去 prompt Claude 并搞定该干嘛。我现在的工作，就是写这些 loops。

这句话很重要。

它不是在说 prompt 没用了。

它是在说，人类开始从 prompt 的直接操作者，变成 prompt loop 的设计者。

什么是 Loop

在传统 AI 聊天里，你是处于循环之内的，也就是 Human-in-the-loop。

AI 给你一段代码。你复制到终端运行。报错了，你再把报错贴回给 AI。AI 再改一版。你再运行。

你就是连接 AI 和 terminal 的那个人。

更直白一点，你是那个无情搬砖机器。

Loop Engineering 说的是，把这部分人肉搬运抽离出来，让一小段程序作为监工。

这个 loop 可能长这样：

discover task
  -> prompt agent
  -> let agent edit code
  -> run tests
  -> collect failure
  -> feed failure back to agent
  -> repeat until verification passes
  -> submit result for human review

它不是一次 prompt。

它是一套智能体编排循环。

里面至少有四个部分。

第一是触发方式。

最简单的就是 Cronjob。也可以是事件触发，比如 GitHub issue 被打了某个 label，Slack 里有人发了某类请求，或者某个 monitor 发现线上问题。

第二是感知与决策。

loop 调用 AI 模型去读取当前任务源。可能是 GitHub Issues、Linear、Notion、Slack，甚至社交媒体上的用户反馈。agent 需要判断今天该处理什么。

第三是自主执行。

AI 选定任务后，自己写代码，调用本地工具，比如 Bash、Git、测试命令，最后提交 PR。

第四是自检反馈。

这是最关键的闭环。

loop 里必须有 verification gates。比如自动跑 test suite，跑 typecheck，跑 lint，甚至跑 e2e。如果编译失败或测试失败，loop 把错误重新喂给 AI，让它自查自纠，直到通过为止。

没有这个验证闭环，就只是自动化地制造更多未验证代码。

一切好像变了，一切好像又没变

听起来这件事很新。

但如果你做过 agent 系统，其实会发现一切好像又没变。

我们搭建 agent 系统时，最重要的本来就是给 agent 足够的反馈验证循环机制。

agent 推理，执行，验证，再推理，再执行，再验证。如此循环，直到任务完成。

如果 agent 无法验证和纠正循环中的报错，它就无法真正完成任务。

所以 loop engineering 不是凭空出现的新概念。

它更像是把 agent 内部的执行循环，提炼到人和 coding agent 的工作循环里。

以前是人全程参与这个 loop。人写 prompt，人复制命令，人跑测试，人贴报错，人判断下一步。

现在是我们提前设计好 loop，让 coding agent 自己检索任务、执行任务、验证任务。在 agent 自己确定完成之后，再提交给人类检查。

人仍然在 loop 中。

只是人不再全程参与这个 loop。

要实现这个 Loop 需要什么

我现在觉得最小实现不复杂，但细节很多。

第一，需要自动化流程。

最简单的就是一个 Cronjob。像 OpenClaw 这种思路，可以定期唤醒 agent，去检索是否有任务，有就执行。

第二，需要一个记录任务的地方。

这是人类和 agent 共同管理的地方。

人往里面添加任务，review agent 的提交结果。agent 负责更新进度，写执行记录，提交产出。

这个地方可以是 GitHub Issues，可以是 Linear，可以是 Notion，甚至可以是你本地的 markdown 文件。

重点不是工具本身，而是它必须能表达任务状态、上下文、验收标准和最终结果。

第三，需要良好的 agent 执行环境。

agent 需要各种运行依赖。Git、git worktree、包管理器、编程语言 runtime、测试工具、本地 CLI、云服务权限。

虽然 agent 也可以自行安装这些东西，但更好的方式是提前准备好环境。否则 loop 很容易因为权限、依赖或环境差异中断。

第四，可选的是 Skills、plugins 这些额外能力。

这些东西可以把 agent 从“会用 shell 的模型”变成“知道你系统里有哪些稳定能力的执行者”。

比如某个 plugin 封装了内部 API，某个 skill 记录了发布流程，某个脚本负责标准化创建 PR。loop 不需要每次重新发明路径。

人没有离开 Loop

但这里很容易有一个误解。

人只是不用全程参与这个 loop，不是彻底离开这个 loop。

你还是要 review agent 的产出。

你还是要理解 agent 在做什么。

你还是要把自己的 taste 和 experience 融入系统。

只是你不需要再一直坐在屏幕前，对着 Codex、Claude Code 或者其他 coding agent 不停敲键盘。

你要做的是设计这个 loop，以及设计如何 verify agent 的产出。

这件事的核心不是“让 AI 替你写代码”。

而是你把自己的工程判断，变成一套可运行的反馈系统。

这个转变意味着什么

第一，从高频互动变成后台离线作业。

以前写代码是一直盯着屏幕敲。现在可能是写好一个 loop 丢到云端，你去睡觉。第二天早上起来，看 AI 给你提了 30 个开源 bug fix PR。

当然这 30 个 PR 不一定都能 merge。

但你的工作状态变了。你不再是每一步都手动推进，而是检查一个后台系统批量产出的结果。

第二，工程师的角色继续上移。

工程师不会因为这个失业。但工作重心会从“如何实现这个功能（How）”，继续转向“定义产品意图、架构和自检边界（What & Value）”。

你要更清楚什么值得做，什么不能做，什么必须验证，什么结果可以接受。

第三，成本中心会转移。

以前最贵的是雇程序员写代码的薪水。

现在写代码本身的边际成本在下降。真正贵的地方，可能变成管理和运行这些无限跑着的 AI agent loops。

token 消耗会成倍增加。

如果以前你坐在屏幕前管理 agent coding，每一步都人工控制，成本至少还有一个天然刹车：你的时间。

但 loop 一旦在后台自动跑，成本刹车就变成了工程系统本身。

所以 verification gate、任务优先级、预算控制、停止条件，都会变得非常重要。

我的判断

Loop Engineering 不是把 prompt engineering 替换掉。

它更像是 prompt engineering 的上一层。

prompt 仍然是接口。

loop 才是 runtime。

coding agent 真正能不能稳定产生价值，不只取决于模型能不能写代码，也不只取决于 prompt 写得多好。

它取决于这个 loop 设计得怎么样。

任务从哪里来。

agent 在哪里跑。

它怎么验证。

失败后怎么修正。

什么时候停。

什么时候交给人。

这也是我接下来想继续拆的方向。

不是研究怎么让模型更会说。

而是研究怎么把模型放进一个可执行、可观察、可恢复、可审计、可沉淀的系统里。