Now Is Loop Engineering?

Coding agent 的下一层不是更长的 prompt，而是 loop。

Prompt 告诉模型下一步做什么。Loop 决定任务从哪里来，模型在哪里运行，失败后怎样重试，什么结果算通过，以及什么时候必须交给人。

Peter Steinberger 最近把这个判断说得很直接：

Boris 也在和 Acquired 的讲座里描述了类似的变化：

Addy Osmani 后来整理了一篇 Loop Engineering 介绍：

他提到的组件包括自动 discovery 和 triage、隔离多个 agent 的 worktree、记录项目知识的 skill、连接外部工具的 plugin，以及活在单次对话之外的 memory。

这些词不新。新的是它们开始组成一套日常开发方式。

工程师操作的对象又变了

编程史一直在提高抽象层。

Boris 举过一个很形象的家族例子。他的祖父用纸质 punch card 给机器输入程序；父亲写 Assembly，还觉得 Python 不算真正编程。之后我们有了高级语言、framework、cloud 和 CI。

底层没有消失。它只是变得足够稳定，让工程师把注意力移到上一层。

Coding agent 又推了一步。以前我们直接操作语法，后来操作 framework 和 workflow，现在开始操作 agent runtime。

从补全，到 Prompt，再到 Loop

过去一年的变化可以粗略分成三个阶段。时间点来自 Boris 的个人经历，不是整个行业的统一时间表。

最初，人写代码，AI 做行级或块级补全。工程师仍坐在 IDE 里，模型像一个速度很快的副驾驶。

之后，人开始同时开多个 Claude Code session。工作变成分配任务、写 prompt、检查输出，再给下一轮指令。Boris 说自己有一个月没打开 IDE，最后干脆卸载了它。

现在，他连 prompt 也交给一段控制程序。程序调用 agent，执行测试，收集错误，再把结果送回模型，直到通过验证或触发停止条件。

人从每次 prompt 的操作者，变成 loop 的设计者。

这不代表 prompt 不重要。它仍是 loop 调用模型的接口，只是不再承担整个系统的可靠性。

Loop 到底是什么

在常见的 coding chat 里，人负责粘合系统。

模型给代码。你复制到终端。命令报错，你把日志贴回聊天。模型再改，你再跑一次。模型和工具之间没有自动反馈，所以你充当了 runtime。

Loop Engineering 把这段搬运写成程序：

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

一套最小 loop 要有四类能力。

第一类是触发。它可以是 cron，也可以来自 GitHub label、Slack request 或线上 monitor。

第二类是任务选择。Agent 要从 GitHub Issues、Linear、Notion 或其他来源读取候选任务，判断该处理哪一个。

第三类是执行环境。Agent 能编辑代码，调用 shell，使用 Git，运行项目依赖，并提交结果。

最后是验证。测试、typecheck、lint 和 e2e 都可以成为 gate。验证失败，错误重新进入下一轮；验证通过，结果才交给人。

没有最后这一步，就不是可靠的 loop，只是批量生成未经检查的代码。

新的是工作边界，不是推理循环

Agent 系统一直都有循环：推理、执行、观察结果，再推理。模型如果看不到执行反馈，就无法纠正错误。

Loop Engineering 把同一个结构提到了人和 coding agent 的工作关系上。

过去，人参加每一轮。现在人先定义环境和验证边界，agent 自己完成中间循环，最后再提交 review。

Human 仍然在 loop 里，只是不再卡在每一步之间。

把 Loop 跑起来需要什么

最小原型可能只是一段 shell script。稳定运行则需要更多东西。

先要有任务来源。GitHub Issues、Linear、Notion 或本地 Markdown 都能用。工具不重要，重要的是任务记录里有上下文、状态和验收条件。Agent 完成后也要把结果和执行记录写回去。

再准备执行环境。Git、worktree、package manager、language runtime、测试工具、本地 CLI 和云权限最好预先配置。让 agent 临时修环境当然可以，但后台 loop 很容易因此卡住，或在未经审查时扩大权限。

项目知识也要放到对的位置。Skill 可以记录发布流程和仓库约定，plugin 可以封装内部 API，脚本可以把高频操作固定下来。否则每一轮都在重新猜路径。

最后需要持久状态。单次 conversation 不够。Loop 至少要知道哪些任务已经完成，上次为什么失败，下一步是什么，预算还剩多少。

人负责 Taste 和边界

自动运行不等于取消 review。

人仍要决定什么值得做，什么改动风险太高，哪些测试能代表正确，哪些结果只能由人判断。Agent 可以执行这些判断，但不能凭空发明它们。

这也是 loop design 最难的部分。把「修好这个 bug」写进 prompt 很容易。把完成标准写成机器可以验证的条件，常常需要真正理解系统。

好的 loop 是工程判断的可执行版本。

工作方式会怎样变

最明显的变化是从实时互动转向后台任务。

以前你守着屏幕，一步步推进 agent。以后可能在睡前启动一组任务，早上 review 30 个 PR。这里的价值不在数字。30 个不能 merge 的 PR 只会制造新的工作。价值在于合格结果可以在你离开屏幕后继续产生。

工程师的重心也会上移。实现细节仍要懂，但更多时间会花在产品意图、架构约束和验收边界上。模型负责一部分 how，人要把 what、why 和 acceptable result 说清楚。

成本也会换位置。人工时间不再是天然刹车后，token、sandbox、CI 和 review queue 都可能失控。后台 loop 必须有预算、优先级、最大重试次数和停止条件。

一个没有上限的 agent，不是自动化资产。它是会自动花钱的 while loop。

我的判断

Loop engineering 是 prompt engineering 的上一层，不是替代品。

Prompt 决定一次模型调用怎样开始。Loop 决定它怎样接收真实反馈，怎样从失败恢复，怎样证明自己完成了任务。

我接下来更想拆的是这套 runtime：任务发现、环境隔离、event stream、checkpoint、verification gate、budget 和 human handoff。模型是否会说得更漂亮，已经不是最难的问题。

难的是让它在没人盯着时，仍然做对事，并且知道什么时候停。