调研了一圈 Loop Engineering，我的结论：Loop 是过往工作流的 Agent 自动化，而且越简单越好
调研了一圈 Loop Engineering，我的结论：Loop 是过往工作流的 Agent 自动化，而且越简单越好
TLDR： Loop Engineering 是今年新冒出来的工种：不再亲自提示 Agent，而是设计一个会提示 Agent、检查结果、决定继续与否的系统。Huntley 的 Ralph loop、Anthropic 的 harness 实验、OpenAI 的 25 小时长跑、Addy Osmani 的总结文章，全都在讲这件事。对比了 Goal 和 Long-running Agent 之后，我的观点是：Loop 的本质是"对过往工作流的 Agent 自动化"——过往工作流没梳理好、不理解 Agent Harness、设计不好 session 外的 memory，任何一条不满足，Loop 都做不好。还有一个反直觉的结论：Loop 越简单越好，就像给一个 7*24 小时在线的同事写交接文档，三句话讲清楚胜过十句话。
先说说 Loop Engineering 是什么
这个圈子的术语这两年一直在往上盖楼：prompt engineering 教你把一句话写清楚；context engineering 教你管好一次会话里模型能看到什么；harness engineering 教你给单个 Agent 搭运行环境（工具、沙箱、上下文压缩）。到今年，楼顶又多了一层——loop engineering：设计一个系统，让它去提示 Agent、验证产出、决定下一步，而不是你自己。
一句话：prompt engineering 优化指令，loop engineering 把"下指令的人"优化掉。
鼻祖是去年 7 月 Geoffrey Huntley 那篇《Ralph Wiggum as a "software engineer"》，核心代码就一行（原文）：
while :; do cat PROMPT.md | claude-code ; done
让编码 Agent 在一个 bash 死循环里反复跑同一份提示词，每圈都是全新的上下文窗口，测试和 linter 当裁判，跑不过就一直跑。他用辛普森家里最笨的角色给它命名，还自嘲这套东西 "deterministically bad in an undeterministic world"——缺陷已知，且都能靠提示词修。他用这个方法把一个 5 万美元的合同交付了出来，Agent 花费 297 美元。
今年 6 月，Addy Osmani 正式给它起了名字，定义很直白："Loop engineering is replacing yourself as the person who prompts the agent."（文章）Claude Code 负责人 Boris Cherny 说得更狠："I don't prompt Claude anymore... My job is to write loops."IBM 也上了定义页：设计"迭代引导 Agent 完成目标、最少人工干预"的系统，一圈四步——Goal、Action、Observation、Adjustment。
这些原语现在已经长进产品里了：Claude Code 有 /loop、/goal、cron 定时任务和 hooks；Codex 有 Automations 和 /goal。Loop 从 bash 脚本变成了产品功能，说明它已经不是极客玩具了。
大厂们都怎么说
Anthropic：Agent 跑不远，是 harness 的问题。 去年 11 月底他们发了篇《Effective harnesses for long-running agents》，把 harness 定义为包在模型外面的脚手架：工具、提示词、上下文管理。他们把长任务 session 的处境比作"一个全靠轮班工程师撑着的项目"——"each new session begins with no memory of what came before"，没人交接。观察到两种典型翻车：一是 overreach，Agent 想一口气把整个应用做完，context 耗尽留下一堆没人看得懂的半成品；二是 premature completion，下一个 session 看到已有进度，直接宣布完工。解法全是工程土办法：开局先跑一个 initializer agent，生成 200 多条的 feature 清单，每条带着 "passes": false，端到端验证过了才翻 true；进度写进 claude-progress.txt；每圈结束打一个 git commit 当 checkpoint。还有一条铁律："It is unacceptable to remove or edit tests."最戳我的是这句："Inspiration for these practices came from knowing what effective software engineers do every day."——Loop 里全是老工程师的日常操作，没有一条是新发明。
值得一提的是，2024 年 12 月 Anthropic 那篇《Building Effective Agents》还在劝大家"从最简单的方案开始，能用 workflow 就别上 agent"。不到两年，自家产品负责人说我已经不亲自 prompt 了。风向转得很快。
OpenAI：连续跑 25 个小时试试。 他们用 GPT-5.3-Codex-Maximized 跑长任务，一次不间断跑了约 25 个小时、消耗约 1300 万 token、产出约 3 万行代码（复盘）。结论有点反直觉：决定成败的不是模型的单点智力，而是 loop 本身；而整套 loop 里"最重要的技术"是 durable project memory——prompt.md 写目标、plan.md 写里程碑、implement.md 写执行手册、documentation.md 当状态日志，每圈更新，跨 session 续命。他们的判断是：agentic coding 的竞争点正在从 one-shot 智力转向 time horizon，而 METR 测出来的 Agent 可靠任务时长大约每 7 个月翻一倍。
IBM：教科书定义。 四阶段循环，加两个前提：目标要有"clear and verifiable stopping criteria"（不然 token 烧穿），人要留下来管质量、安全和业务结果。企业味的稳重，但话是对的：循环可以自动，责任没法外包。
反方 Ronacher：谨慎。 Flask 作者 Armin Ronacher 今年 6 月写了《The Coming Loop》。他分得很细：session 里的 agent loop 早就有（调工具、看结果、再调），新东西是 harness 层的 loop——"The task stays alive beyond the point where the model by itself would normally have said: 'I am done.'"他不安的点很具体：现在的模型写代码 "too defensive, too complex, too local in its reasoning"，怕异常（他引 Karpathy 的说法，模型对异常"怕得要死"）、堆 fallback、回避强不变式，而 loop 恰好放大这个倾向——"If each iteration adds another small defense, the system slowly becomes less understandable while appearing more robust."他列了 loop 真正好用的领域：移植、性能探索、安全扫描、研究——共同点是转换既有代码、或产出短命产物。他的结论不是拒绝，而是："the question is not whether we will loop"——问题是 怎么在 loop 里保住人的判断力。
Goal 和 Long-running Agent：一个接口，一个实现
今年聊 loop，绕不开两个词，很多人混着用。拆开看：
- Goal 是产品原语。Codex 和 Claude Code 都有
/goal，Cursor 对应的是 Background Agents。本质就一句话：一条带停止条件的持久指令，Agent 自己评估"完事了没"、自己挑下一步，你不用每轮重复背景。 - Long-running Agent 是另一层。让任务跨 session、跨沙箱跑几小时到几天的那套 harness 工程：checkpoint、故障恢复、session 外记忆、隔离的 worktree。
| Goal（/goal） | Long-running Agent | |
|---|---|---|
| 是什么 | 一条持久的目标指令 | 一套跨 session 的执行系统 |
| 循环在哪 | 产品内置原语，产品托管 | harness 层：沙箱、worktree、checkpoint |
| 状态放哪 | 产品帮你记 goal 状态 | 文件系统：进度文件、plan、git |
| 停止条件 | 可验证的完成判据 | verification：测试、E2E、截图 |
| 人的角色 | 偶尔看 status，pause/resume | 审 diff、管 memory、防漂移 |
| 典型失败 | 过早宣布完成 | overreach、防御性代码累积 |
| 代表 | Codex /goal、Claude Code /goal、Cursor Background Agents | Anthropic 的 harness 实验、各类自建 loop |
比来比去，我的结论是：这俩不是竞争关系。Goal 是用户看得见的接口，Long-running 是接口背后的实现，两个都建在同一副 loop 骨架上。真正拉开差距的不是选哪个词，而是骨架本身的设计质量——也就是下面要说的。
我的观点：Loop 的本质是过往工作流的 Agent 自动化
Loop 不是凭空发明一个新流程，而是把一个已经存在的工作流，交给 Agent 7*24 小时地执行。你看各家实践：Ralph 要 spec-first，先写 spec 再开循环；Anthropic 要先跑 initializer 生成 feature 清单；OpenAI 的 loop 围着 prompt.md、plan.md 转。全是同一件事：先把人脑里的流程外化成文件，再让 loop 去消费它。
所以有三个"做不好"：
- 过往工作流没梳理好，做不好 Loop。 你自己都说不清这件事每天是怎么做的、每步的判断标准是什么，就没法把它写成 Agent 能执行的循环。Loop 是放大器：流程清晰，它 10 倍速；流程混乱，它把混乱也放大 10 倍，还不下班。没有 process 的 loop，等于把幻觉挂上了定时器。
- 不理解 Agent Harness，做不好 Loop。 Loop 跑在 harness 上面。不知道 context 会退化、不知道 compaction 会悄悄丢信息、不知道 worktree 和 subagent 怎么隔离，就没法回答 loop 设计里最难的那个问题：**每一圈，什么进上下文，什么不进。**Osmani 有一句话我一直记着："every component in a harness encodes an assumption about what the model can't do on its own."看不懂这层假设的人，写出来的 loop 是玄学，调好是运气。
- 设计不好 session 外的 memory，做不好 Loop。 Session 是失忆的，loop 的连续性全在会话之外：进度文件、git 历史、任务清单、状态日志。OpenAI 把 durable project memory 叫整套系统里最重要的技术；Anthropic 用
claude-progress.txt加 git commit 当跨班交接。memory 设计不好，loop 只有两种下场：要么失忆，同一件事翻来覆去做；要么漂移，越跑越偏还自我感觉良好。"The agent forgets, the repo doesn't."
这三条里最容易被忽略的是第一条。大家默认 loop 是个技术问题，其实它先是流程问题：你能把工作流写到多清楚，loop 就能跑到多好。
反直觉的部分：Loop 越简单越好
按直觉，任务越重，loop 的说明应该写得越细。实践下来正好相反。
原因有两个。第一，指令越长，理解偏差的空间越大。十句话的说明，模型可以在十个地方各自理解出花来；三句话的说明，解释空间就小得多。第二，也是更狠的：偏差在循环里不是一次，是复利。单次会话里理解偏一点，重开一次就清零了；loop 里每一圈都从同一份说明出发，同一个理解偏差会被执行几百次，跑一个晚上就是系统性跑偏。Osmani 把 goal 在反复总结中失真这件事叫 alignment drift，是同一个道理。
所以写 loop 的心法，应该像给一个 7*24 小时在线的同事写交接文档：**三句话能讲清楚的工作流，比十句话讲清楚的更容易做好。**话越少，被误解的方式越少；目标越钝，越没空子可钻。这不是我的独创，各家实践不约而同：
- Huntley 在原文里重复了两遍："One item per loop. I need to repeat myself here—one item per loop."
- OpenAI 跑 25 小时的那个 loop，展开一共七步：Plan → Edit → Run → Observe → Repair → Update → Repeat。
- Huntley 还反对把 loop 搞成 multi-agent 编排，原话是 "a red hot mess"——单进程、单仓库、一份说明，就是最好的形态。
复杂度不会消失，但它应该被放进 verification 里——测试、类型、lint、截图这些硬约束——而不是放进对 Agent 的说明里。硬约束跑偏了会被拉回来；长说明跑偏了会被复利放大。
什么时候别上 Loop
四种情况，先缓一缓：
- 产物是要留很多年的核心代码。 Ronacher 的警告：loop 擅长移植、扫描、探索这类活，产出短命产物或转换既有代码；需要人看十年的代码，无人值守地让 loop 写，每一圈都可能悄悄多加一层防御。
- 没有验证手段。 "done is a claim and not a proof."没有测试、类型、E2E、截图之一，loop 会非常勤快地原地打转，还每圈都汇报进展。
- 存量烂代码库。 Huntley 自己都明说不会在别人的现有代码库上跑 Ralph。
- 流程本身还没梳理清楚。 回到第一条：先把工作流写明白，再谈自动化它。
Osmani 的收尾我直接抄来用："Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."Loop 不会取代工程判断，它只会放大你已有的判断——包括"没有判断"这件事。
参考
- Ralph Wiggum as a "software engineer"（Huntley） / Everything is a Ralph loop
- Anthropic: Effective harnesses for long-running agents / Building Effective Agents
- OpenAI: Run long horizon tasks with Codex
- Addy Osmani: Loop Engineering / Long-Running Agents
- IBM: What Is Loop Engineering?
- Armin Ronacher: The Coming Loop
Loop Engineering 和 Prompt Engineering、Context Engineering 是什么关系？
是一条演化链：prompt engineering 优化一句话怎么写；context engineering 管理一次会话里模型能看到什么；harness engineering 给单个 Agent 搭运行环境（工具、沙箱、上下文压缩）；loop engineering 设计一个自动提示 Agent、验证结果、决定下一步的系统。每一层都建立在下面的层之上，最上面这层把下指令的人自己也优化掉了。
Goal 和 Long-running Agent 有什么区别？
Goal 是产品原语：一条带可验证停止条件的持久指令，Codex 和 Claude Code 的 /goal、Cursor 的 Background Agents 都是它，Agent 自己评估完没完、自己挑下一步。Long-running Agent 是 harness 层的实现：让任务跨 session 跑几小时到几天的那套工程——checkpoint、恢复、session 外记忆。一个是对用户暴露的接口，一个是接口背后的实现，都建在同一副 loop 骨架上。
为什么说 Loop 越简单越好？
指令越长，模型理解偏差的空间越大；而偏差在循环里不是一次，是复利——同一份说明被每圈重复执行，跑一晚上就系统性跑偏。所以写 loop 要像给 7*24 小时在线的同事写交接：三句话讲清楚的工作流，比十句话讲清楚的更容易做好。复杂度应该放进测试、类型、截图这类硬验证里，而不是放进对 Agent 的说明里。
做好一个 Loop 的前提是什么？
三件事：先把过往工作流梳理清楚，loop 只是放大它；理解 Agent Harness，知道 context 会退化、compaction 会丢信息、隔离怎么做，才能决定每圈给 Agent 看什么；设计好 session 外的 memory（进度文件、git 历史、任务清单），否则 loop 要么失忆重做，要么越跑越偏。