# 从 ReAct 到 Loop Engineering：四代智能体循环的完整演进谱系

> 本文深读来源：Data Science Dojo《Agentic Loops: From ReAct to Loop Engineering (2026 Guide)》——目前唯一一篇把 2022 到 2026 年间所有主流 agentic loop 类型排成完整四代演进谱系、且每一代都带发布日期、论文出处与量化提升数字的综述。

## TL;DR

- Loop engineering 不是凭空冒出来的新词。它是一条从 2022 年 10 月 ReAct 论文就开始积累的研究脉络，在 2025 到 2026 年完成的产品化形态。
- Data Science Dojo 把这条脉络排成四代：第一代 AutoGPT 证明需求真实但失控；第二代 ReAct、Reflexion、Plan-and-Execute 引入推理、反思、规划；第三代 OODA、Magentic-One、多 agent 把决策结构化、把协作工程化；第四代 Ralph Loop、`/goal`、Boris Cherny 并行流把循环本身变成可调度、可验证、可重启的工程对象。
- 每一代都有自己的硬数字。ReAct 在 ALFWorld 提升 34%、WebShop 提升 10%；LangChain LLMCompiler 比串行 ReAct 快 3.6 倍；Anthropic 多 agent 研究系统在内部评测中超过单 agent 90.2%；Codex `/goal` 文档化的一次运行是 25 小时、1300 万 token、3 万行代码。
- 作者有一个被多数综述回避的冷静结论：技术是真的，token 成本也是真的。Cherny 和 Steinberger 能这么玩，是因为他们在 Anthropic、OpenAI 这种公司，token 预算对他们「effectively does not exist as a constraint」。普通团队抄这套工作流会先爆账单。

## 为什么这篇综述值得单独深读

loop engineering 这个词在 2026 年上半年突然火起来，源头是 Peter Steinberger 2026 年 6 月 7 日那条推文：「Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.」据 Data Science Dojo 统计，这条推文 24 小时内获得约 500 万次浏览（其他来源给出 650 万，保守口径是「据报道约 500 至 600 万」）。Boris Cherny（React 团队成员、现 Anthropic）也有过一句被反复引用的话：「I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops.」

火归火，市面上多数解释只讲「循环长什么样」「六原语是什么」「harness 怎么搭」。这些是横切面，不是演进史。横切面回答「现在怎么用」，演进史回答「我们怎么走到这一步」。前者像解剖图，后者像化石层。要判断 loop engineering 是真趋势还是又一波营销泡沫，你必须看化石层——看每一代 loop 解决了上一代的什么死穴，又在哪一代重新暴露了问题。Data Science Dojo 这篇指南的价值就在于它提供了目前最完整的化石层骨架，且每一段都标了日期、论文出处和提升数字。本文以这篇综述为主骨架，逐代拆开四代 loop 的技术演进，并补足它在成本门槛和工程落地上的诚实判断。

## 心智模型：把四代 loop 当成生物进化

理解这四代 loop，最省力的类比是生物进化。每一代都是对上一代生存压力的回应，每一代在解决一个具体死穴的同时，又会引入新的死穴，给下一代留出进化空间。

第一代 AutoGPT 像 5 亿年前的寒武纪奇虾——体型惊人（10 万 star），但神经系统简陋（infinite loop + 巨额账单），没有走出实验室。第二代 ReAct 像第一批长出脊髓的脊椎动物——学会了「先想再动」，把 reasoning 和 action 串成可观察的轨迹，但仍是单线程生物，没有元认知。第三代 OODA、Magentic-One、多 agent 像长出社会性的哺乳动物——学会了分工、反思、策略级 reset，但协作需要昂贵的通信开销，token 消耗从 4 倍跳到 15 倍。第四代 loop engineering 像驯化出农业的人类——不再追逐单次对话的丰收，而是设计出可调度、可验证、可重启的循环系统，把状态沉淀到文件系统，让知识跨 session 累积。

这个类比的关键不是精确，而是记住一件事：每一代都不是对前一代的否定，而是对前一代的封装。ReAct 没有取代手工 prompt，它把 prompt 包进了循环；Reflexion 没有取代 ReAct，它在 ReAct 外面又套了一层自我评估；Ralph Loop 没有取代 Reflexion，它把整个循环的边界条件（context overflow、premature exit）用文件系统和 stop hook 重新约束了一遍。理解了「封装」这个动作，你就理解了 loop engineering 的全部演进逻辑——prompt 的单位，从一句话，换成了一个有 trigger、有可验证 goal、有状态脊柱的循环。

## 把 loop 的最小定义先说清楚

在拆四代之前，先把 Data Science Dojo 给出的 loop 最小定义钉死，省得后面混淆。

agentic loop 只需要两件东西。第一是 trigger——一个触发信号，可以是 PR 打开、cron 定时、文件变更、API 调用，也可以是人在终端里敲一句 `/goal`。第二是 verifiable goal——一个可验证的目标，agent 必须能在循环中主动判断「goal 是否达成」，并据此调整下一步。原文一句话：「You give the agent a goal, not a prompt. It figures out the steps, runs them, checks its work, and keeps going.」

这个定义里有几个常被混淆的点需要先划清边界。

第一，loop 不是 automation。automation 执行一系列预定义步骤，不做决策。loop 内部有决策——agent 在每一轮都主动评估当前状态距离 goal 还有多远，决定是继续、回退还是换路径。原文：「It is not just executing – it is evaluating, looping, and adjusting based on what it finds.」这条边界很关键：如果你写的「循环」里没有判断 goal 是否达成的逻辑，那它只是 automation 换了层皮，迟早会出 silent failure（工具一直在调，状态一直没变）。

第二，trigger 只有三种。Data Science Dojo 明确列出来：event-based（PR 打开、文件变更、API 调用）、scheduled（cron 定时）、human-initiated（你输入 `/goal`）。所有的 loop engineering 工程化最终都在围绕这三种 trigger 做调度、隔离、防碰撞。如果你看到的「新 trigger 类型」不能归到这三类，那大概率是其中一类的变体。

第三，loop 内部有一个 5 阶段模型。这是 Data Science Dojo 独有的提炼：Perceive（感知环境）→ Reason（推理当前状态）→ Plan（规划下一步）→ Act（执行动作）→ Observe（观察结果）→ 回到 Perceive。作者把它和强化学习做类比，指出一个关键约束：「A loop needs a verifiable reward signal」。reward 信号分两种：deterministic reward（测试通过、编译成功、type check 通过）和 non-deterministic reward（LLM-as-judge 给一段文字打分）。前者便宜、可靠、可复现；后者贵、有偏见、可能被自己骗过。这条 reward 信号的二分法，是理解后面四代 loop 各自死穴的钥匙。

## 第一代：AutoGPT 时代——证明需求，但失控（2023）

四代谱系的第一代是 proof of concept 时代，代表作是 AutoGPT。

AutoGPT 在 2023 年 3 月 30 日由 Significant Gravitas 发布。几周内拿到 10 万 star，是当时 GitHub 上增长最快的项目之一。它做的事情很简单：给 GPT-4 一个高层目标（比如「帮我研究脑机接口市场并写一份报告」），让 agent 自己分解任务、上网搜索、读写文件、循环往复，直到目标达成。

AutoGPT 的历史意义不在它能不能用，而在它证明了需求真实。在那之前，所有人都把 LLM 当成问答机：你问一句，它答一句。AutoGPT 第一次把 LLM 当成「会自己干活的循环」摆到公众面前，10 万 star 说明这件事戳中了真实痛点——人们确实想要一个「我给目标、它给结果」的系统。

但 AutoGPT 没有进入日常生产力工具，死穴有两个。

第一个死穴是 infinite loop。AutoGPT 的循环没有可靠的退出条件——它依赖 LLM 自己判断「我做完了吗」，而 LLM 的自我判断不可靠。一个经典故障模式：agent 卡在一个失败的工具调用上，反复重试同一个坏 endpoint，5 分钟内调了 400 次，账单飞涨，状态不动。这个故障模式至今仍是 loop engineering 的头号敌人，Data Science Dojo 把它列为六类失败模式之首。原文一句话总结这种 silent failure 的可怕之处：「Tool calls are happening. Nothing is actually changing.」工具在响，状态没变，监控只看到流量正常，直到账单弹出来才知道出事了。

第二个死穴是 token cost explosion。AutoGPT 每一轮都要把完整的历史对话塞回 prompt，context window 越滚越长，单次任务很容易烧到几十美元甚至上百美元，而产出质量并不可控。AutoGPT 时代没有 context 压缩、没有状态外置、没有 checkpoint，所有状态都挤在 prompt 里。

第一代的遗产是一个清醒的结论：自动化循环的需求是真的，但「让 agent 自己决定什么时候停」是反 pattern。这条结论直接催生了第二代——研究者开始思考，怎么让 agent 的推理过程可观察、可干预、可反思。

## 第二代：ReAct、Reflexion、Plan-and-Execute——推理、反思与规划（2022-2023）

第二代是学术框架时代，由三篇论文撑起骨架：ReAct、Reflexion、Plan-and-Execute。注意时间线上的一个反直觉细节——ReAct 论文是 2022 年 10 月 6 日发布的，比 AutoGPT 还早整整 5 个月。也就是说，是学术界先提出了「推理加行动」的循环范式，工程界（AutoGPT）才把它包装成爆款产品。只是 AutoGPT 太耀眼，盖过了论文的声音。

### ReAct：把推理和行动绑成可观察的轨迹

ReAct 来自 Yao 等人 2022 年的论文（Princeton + Google Research），全称是 Reasoning + Acting。它解决的核心问题是：纯 reasoning（链式思考）容易空想，纯 acting（直接调工具）容易乱撞。ReAct 让模型在每一步同时产出两样东西——一段 reasoning trace（解释为什么这么做）和一个 action（具体调用什么工具），再把 action 的 observation 反喂回下一步的 reasoning。

这种「想一步、做一步、看一眼结果再想下一步」的节奏，把循环从黑盒变成了白盒。开发者可以看到 agent 的推理过程，定位它在哪里走偏，干预它而不是重置它。

ReAct 带来了可量化的提升。论文报告，相比纯 action-only baseline，ReAct 在 ALFWorld 任务上提升 34%，在 WebShop 任务上提升 10%。这两个数字不夸张，但它们是第一次用学术 benchmark 证明了「让模型显式推理」比「让模型直接行动」更好。

ReAct 的影响远超论文本身。它是 LangChain AgentExecutor 的内置 pattern，也是几乎所有 production coding agent（包括 Claude Code、Cursor agent 模式、Codex CLI）的底层循环结构。可以说，今天你用的每一个 coding agent，在某种程度上都是一个 ReAct loop。

### Reflexion：在 ReAct 外面套一层自我评估

Reflexion 发表在 NeurIPS 2023，可以粗暴理解为 ReAct + self-evaluation。它在 ReAct 的 trace 基础上多加了一步：任务结束后（无论成功失败），让模型生成一段 critique（自我批评），存入 memory，下一次执行同类任务时把这段 critique 注入 prompt，避免重犯同样的错误。

Reflexion 的适用场景是那些「值得多轮试错」的任务：debug 一个陌生 codebase、解一道创造性问题、写一段需要反复打磨的代码。这些任务的共同点是单轮不容易做对，但每轮的错误信息很有价值，可以被下一轮利用。

Reflexion 的代价是额外的 LLM 调用。每一轮要多跑一次 evaluator 来生成 critique，token 消耗显著上升。Data Science Dojo 给出一条务实判断：简单的 retrieval 任务不值得用 Reflexion，因为它带来的额外 LLM 调用开销可能比任务本身的收益还高。这条判断背后是一个通用原则——loop 的复杂度要匹配任务的复杂度，过度工程化的 loop 反而更脆。

### Plan-and-Execute：先规划再执行，允许并行

Plan-and-Execute 解决 ReAct 的另一个死穴：串行。ReAct 是严格的一步接一步，前一步的 observation 决定后一步的 action。这种串行结构在任务有大量独立子步骤时效率极低——比如「给 10 个文件分别加单元测试」，每个文件之间没有依赖，串行跑要 10 倍时间。

Plan-and-Execute 把循环拆成三个角色：planner（一次性把任务拆成子步骤列表）、executor（执行每个子步骤）、re-planner（根据执行结果决定是否重新规划）。关键改进是 executor 可以并行处理独立的子步骤。

LangChain 的 LLMCompiler（Kim 等人，ICML 2024）是 Plan-and-Execute 的工业级实现，报告显示它比串行 ReAct 快 3.6 倍。这个数字来自把独立步骤并行化执行的收益。Plan-and-Execute 的代价是灵活性下降：当早期步骤的结果出乎意料时，re-planner 需要重新规划，而规划本身有成本；相比之下 ReAct 的每一步都基于最新 observation，更灵活。

第二代的遗产是三条可复用的 pattern：ReAct 给了「推理加行动」的基础循环，Reflexion 给了「自我评估加记忆」的反思层，Plan-and-Execute 给了「规划加并行」的执行架构。这三条 pattern 至今仍是 loop engineering 的底层积木。Data Science Dojo 给了一条很务实的建议作为这一代的总结：「A single ReAct agent with four tools handles the majority of real-world tasks.」绝大多数真实任务用一个带 4 个工具的 ReAct agent 就够了，不需要上更复杂的结构。

## 第三代：OODA、Magentic-One、多 agent——决策结构化与协作工程化（2024）

第三代是架构 pattern 时代。第二代给的是单 agent 内部的循环结构（推理、反思、规划），第三代开始解决两个新问题：一是在单 agent 内部插入更复杂的决策结构，二是把多个 agent 组合起来协作。代表作是 OODA Loop、Microsoft Magentic-One 的内外双循环、以及 supervisor 模式的多 agent 编排。

### OODA Loop：在观察和决策之间插入「定向」

OODA Loop 来自美国空军上校 John Boyd 的空战理论，全称 Observe-Orient-Decide-Act。它和 ReAct 的根本区别是多了一个 Orient（定向）步骤。Orient 不是简单地看一眼环境，而是把当前观察对照 goals、constraints、prior knowledge 进行 contextualising——把原始信号翻译成可决策的上下文。

举个具体的例子。agent 执行一个修复 bug 的任务，Observe 阶段看到「测试失败了」。如果是 ReAct，agent 可能直接 Decide「改测试」或「改代码」。如果是 OODA，agent 会先 Orient：这个测试失败是新出现的还是一直存在的？目标是把测试改绿还是修真正的 bug？constraints 是不是「不能动测试文件」？prior knowledge 里有没有类似 bug 的修复模式？Orient 这一步把「观察」和「决策」之间最容易出错的转换环节显式化了。

OODA 的适用场景是快速变化的环境——战场、生产事故、需求频繁变更的项目。这种环境里，agent 拿到的原始观察往往有歧义，必须先定向才能决策。代价是 Orient 本身要消耗一次甚至多次 LLM 调用，在稳定环境里是浪费。

### Magentic-One：内外双循环，专治「死磕一个坏方法」

Microsoft 的 Magentic-One 提出了 Inner/Outer Dual Loop 结构。outer loop 负责战略规划和 goal 监控，inner loop 负责具体执行。两个循环的分工不是简单的「高层管战略、底层管执行」，而是有一个关键机制：当 inner loop 卡住时，outer loop 会重置整个策略，而不是让 inner loop 重试当前步骤。

这个机制解决的是 ReAct 时代就存在的一个老问题，Data Science Dojo 称之为 insistent failure——agent 死磕一个坏方法。比如 agent 想用某个 API 修 bug，调了三次都失败，它会换个参数再调，再失败再换参数，陷入「同一个方法的无限变体」循环。Magentic-One 的 outer loop 检测到这种 insistent failure 后，会直接换一个完全不同的策略（比如放弃用 API，改用直接改源码），而不是让 inner loop 继续挣扎。

内外双循环的价值是它把「策略级 reset」和「步骤级 retry」分开。ReAct 只有步骤级 retry，所以会死磕；Magentic-One 有策略级 reset，所以能在死磕之前跳出来。代价是 outer loop 需要维护对整个任务的战略视图，这个视图本身要占 context、要消耗 token 来维护。

### 多 agent 编排：supervisor 加专业 sub-agent

第三代的第三条线是多 agent 协作。基本结构是 supervisor 模式：一个 supervisor agent 负责拆解任务和分派，多个专业 sub-agent 各自负责一类子任务（写代码、跑测试、写文档、做 code review）。supervisor 不直接干活，它的工作是调度和整合。

多 agent 的收益是明确的。Anthropic 在内部评测中报告，他们的多 agent 研究系统在内部 benchmark 上超过单 agent 90.2%。这个数字很猛，但 Data Science Dojo 同时给出了成本侧的硬数字：单 agent 大约消耗 4 倍标准 chat 的 token，多 agent 大约消耗 15 倍。也就是说，多 agent 的质量提升是用接近 4 倍的额外 token 成本换来的。

15 倍这个数字背后的原因不复杂。多 agent 系统里，sub-agent 之间要通信、supervisor 要整合、每个 agent 都要维护自己的 context、重复的部分不能简单共享（因为各自的任务上下文不同）。这些通信和整合开销是结构性的，不是优化能消除的。

第三代留下的两条 pattern 至今仍是 loop engineering 的核心工具：内外双循环解决「死磕」问题，多 agent 编排解决「专业分工」问题。但第三代也把 token 成本推到了一个新高度——从单 agent 的 4 倍跳到多 agent 的 15 倍，这直接为第四代埋下了伏笔：第四代的所有工程化努力，本质上都在回答「怎么在 15 倍 token 成本下还能让 loop 跑得起」。

## 第四代：Ralph Loop、`/goal`、Cherny 并行流——loop engineering 的产品化（2025-2026）

第四代是 practitioner loop engineering 时代，也是 loop engineering 这个词真正成型的时代。前三代是学术界和框架团队的工作，第四代是一线工程师（Geoffrey Huntley、Boris Cherny、Anthropic 的 `/goal` 团队）把循环本身当成可调度的工程对象。代表作有三个：Ralph Loop、`/goal` 命令、Cherny 的并行 loop 工作流。

### Ralph Loop：用文件系统和 stop hook 解决 context overflow 和 premature exit
 
Ralph Loop 由 Geoffrey Huntley 在 2025 年 7 月的一次 hackathon 上发布，6 个月内成为 coding agent 圈子的标准 pattern。它要解决的是两个第三代都没解决的老问题。

第一个问题是 context overflow。agent 跑得越久，context window 越满，到后面要么被截断（丢失早期信息），要么推理质量下降（注意力被稀释）。第三代的所有 pattern（ReAct、Reflexion、Magentic-One）都在同一个 context window 里累积历史，越跑越慢、越跑越蠢。

Ralph Loop 的解法很暴力但很有效：让 agent 在一个无限 shell loop 里运行，每次迭代从磁盘重新读同一个 prompt 文件，agent 改完代码就退出，loop 重启时 context window 是全新的——因为这是一个全新的 session。state 不放在 context 里，放在文件系统里。文件系统是持久层，context window 是易失层，两者职责分开。

这种设计把「记忆」从 context window 里剥离出来。ReAct 时代，记忆 = prompt 里的历史轨迹；Ralph Loop 时代，记忆 = 文件系统里的代码、测试、CLAUDE.md。context window 只负责当前一轮的推理，跑完就清空。

第二个问题是 premature exit。agent 经常在 goal 还没真正达成时就自己宣布完成、退出循环——「测试还没跑就说改完了」「type check 还没过就说提交了」。Ralph Loop 用 stop hook 解决：在 agent 试图退出时拦截，检查 tests green、coverage、type checks 是否真的通过，不达标就把 prompt 重新灌进去，强制再来一轮。agent 不能自己决定什么时候停，外部 verifier 才能决定。

Ralph Loop 的历史意义是它第一次把 stop hook（外部 verifier）和 file-based state（状态脊柱）这两个工程原语结合成一个可复用的循环模板。这两个原语后来都被 `/goal` 吸收。

### `/goal`：原生 loop engineering 进入主流工具

`/goal` 命令是 loop engineering 从个人脚本走向主流工具的标志。它有两个版本：Claude Code v2.1.139（2026 年 5 月 12 日发布）的 `/goal`，和 Codex CLI v0.128.0 的 `/goal`。两者都是原生 loop engineering——不需要自己搭 Ralph Loop，工具内置了循环结构。

`/goal` 的关键机制是 maker/checker 分离。每一轮结束时，不是由执行 agent 自己判断「goal 是否达成」，而是由一个独立的 evaluator model 检查。只有 evaluator 通过才停。这个设计和 Ralph Loop 的 stop hook 思路一致，但把它内置成了工具的一等功能，而不是外部脚本。

Data Science Dojo 文档化了几个极端案例。Codex `/goal` 的一次运行：25 小时不间断、1300 万 token、3 万行代码。这个数字说明 loop engineering 已经能处理以前需要整个团队几周才能完成的工作量——前提是 token 预算撑得住。`/goal` 默认是关闭的，需要通过 TOML 配置显式开启，这个设计选择本身就是一种声明：原生 loop engineering 不是给随手试用的，它有真实的成本和风险，需要开发者明确知情。

### Boris Cherny 的并行 loop 工作流

Boris Cherny（React 团队成员，现 Anthropic）的工作流是第四代里最激进的产品化形态，也是 Data Science Dojo 用作 loop engineering 极限案例的代表。

Cherny 的工作流有几个特征。第一，并行多 session：5 个 Claude Code 终端 tab 同时开，加 5 到 10 个浏览器 session，每个 session 跑一个独立的 loop。第二，按需通知：系统通知只在某个 loop 需要人类 input 时才弹，平时不打扰。第三，context 在本地和云端之间移交：通过一个叫 teleport 的命令，把当前 loop 的 context 从本地终端移到云端 session 继续跑，反之亦然。第四，CLAUDE.md 作为持久指令层：每个新 session 启动时必读 CLAUDE.md，把它当成跨 session 的项目宪法。

CLAUDE.md 这一层是 Cherny 工作流里最被低估的部分。它的核心洞察是：每次 agent 犯错，把纠正写进 CLAUDE.md，未来 session 不再重犯——CLAUDE.md 成为累积的项目知识。这和 Reflexion 的 critique memory 思路一致，但载体从自动生成的 critique 换成了人肉 curate 的文件。Data Science Dojo 给了一个很准确的定位：CLAUDE.md 是 human-curated semantic memory，比自动生成的更可靠，因为是人决定放什么进去。

把 Cherny 的工作流和 Ralph Loop 对比，能看到第四代内部的两个分支。Ralph Loop 是单 loop、长跑、文件系统存状态，适合深度任务（一个 bug 啃到底）。Cherny 是多 loop、并行、CLAUDE.md 存知识，适合广度任务（一个项目多条线同时推）。两者的共同点是都把 state 从 context window 剥离到外部持久层，都用外部机制（stop hook / evaluator / CLAUDE.md）而不是 agent 自我判断来决定循环边界。

### Memory 四分法：第四代的认知基础设施

第四代的另一个贡献是把 memory 显式分类。Data Science Dojo 整理了四种 memory 类型：

- Episodic memory：记录 prior actions 和 outcomes，即「之前做过什么、结果如何」。Reflexion 的 critique 属于这一类。
- Semantic memory：记录架构决策、命名规范、API 文档，即「项目的稳定知识」。CLAUDE.md 属于这一类。
- Vector memory：基于相似度检索，即「找相关的历史片段」。RAG 系统属于这一类。
- File-based memory：state 直接放在文件系统里，即「磁盘就是状态机」。Ralph Loop 属于这一类。

这四种不是互斥的，成熟的 loop engineering 系统会组合使用。但 Data Science Dojo 指出，对于 coding 任务，file-based memory 比 vector store 更简单可靠——因为代码本身已经是结构化的、可 diff 的、可版本控制的，不需要再用 embedding 去检索。这条判断解释了为什么第四代的代表作（Ralph Loop、Cherny 工作流）都把文件系统作为首选状态层，而不是上 vector database。

## 真实案例：把四代演进落到具体数字上

讲完四代结构，用几个有据可查的案例把演进落到具体数字上，方便判断每一代的实际能力边界。

第一个案例是 ReAct 的 benchmark 数字。ReAct 论文（Yao 等人，2022）报告，相比 action-only baseline，ReAct 在 ALFWorld 上提升 34%，在 WebShop 上提升 10%。这两个数字确立了「显式推理比纯行动好」的基准线，也是第二代能站住脚的学术证据。今天所有 coding agent 默认带 reasoning trace，根源就是这两个数字。

第二个案例是 LLMCompiler 的并行加速。LangChain 的 LLMCompiler（Kim 等人，ICML 2024）作为 Plan-and-Execute 的工业级实现，报告比串行 ReAct 快 3.6 倍。这个数字来自把独立子步骤并行执行。它证明了一件事：当任务有可识别的并行结构时，Plan-and-Execute 的收益是线性的、可预测的。

第三个案例是 Anthropic 多 agent 研究系统。Anthropic 在内部评测中报告，他们的多 agent 研究系统超过单 agent 90.2%。这是目前公开的多 agent vs 单 agent 最权威的对比数字之一。但同一份报告给出成本数字：单 agent 约 4 倍标准 chat token，多 agent 约 15 倍。质量提升和成本提升几乎同步——这是第三代多 agent 编排的根本张力。

第四个案例是 Codex `/goal` 的极限运行。文档化的一次运行：25 小时不间断、1300 万 token、3 万行代码。这是目前公开的 loop engineering 单次运行最极端的案例，也是 Data Science Dojo 用来论证「loop engineering 已经能承接团队级工作量」的核心证据。但这个案例的前提是 token 预算几乎不受约束——下一节会展开。

第五个案例是 Steinberger 的月度账单。Peter Steinberger 公开承认曾达到 130 万美元的月度 token 账单。这个数字单独看很吓人，但结合他的工作模式（持续用 loop engineering 推多个项目）就能理解。它也直接引出了本文的下一节：成本门槛。

第六个案例是 AutoGPT 时代的 silent failure。一个被多次引用的故障：agent 在 5 分钟内调用同一个坏工具 400 次。这个数字是第一代失控的典型画像，也是 Data Science Dojo 列出的六类失败模式之一（silent failure）。理解这个故障模式很重要，因为它至今仍是 loop engineering 最难抓的一类失败——工具在响，状态没变，监控看到的是正常流量。

## 权衡与局限：token 成本是 loop engineering 的硬门槛

讲完四代的进展和案例，必须面对 Data Science Dojo 在结尾给出的冷静判断——这一段是多数综述回避的，也是本文最想强调的部分。

loop engineering 的技术是真的，但它现在不是人人可用的。Cherny 和 Steinberger 能这么玩，是因为他们在 Anthropic、OpenAI 这种公司，对他们来说，token 预算 effectively does not exist as a constraint。普通团队抄这套工作流，第一步就是爆账单。前面提到的几个数字摆在一起就能感受到门槛：单 agent 4 倍 token、多 agent 15 倍 token、Steinberger 月账单 130 万美元、Codex `/goal` 单次 1300 万 token。这不是普通创业团队能承担的运营成本。

Data Science Dojo 对此的立场是乐观派：「That gap will close. It always has with compute.」计算成本总会下降，这是历史规律。但 skeptics 的反问也成立：在 gap close 之前，普通团队抄 Cherny 工作流会先死在账单上。loop engineering 目前锁定在头部公司，是一个结构性事实，不是一个会自动消失的临时现象。

第二个局限是 silent failure 仍是无解难题。Data Science Dojo 列出了六类失败模式：infinite loops（无限循环）、goal drift（目标漂移）、context overflow（上下文溢出）、silent failures（静默失败）、token cost explosion（token 成本爆炸）、error propagation（错误传播）。这六类全部会在生产中出现。其中 silent failure 最难抓——工具在调、流量在走、监控一片绿色，但状态没变。Data Science Dojo 列出了这个问题，但没有给出解法。这也正是共识框架里 maker/checker 分离和 deterministic verifier 必须存在的根本理由：你不能靠 agent 自己报告状态，必须有独立的外部验证。

第三个局限是「let the agent decide when it's done」是反 pattern。Data Science Dojo 明确警告，让 agent 自己决定什么时候停，会耗光 token。这和 Ralph Loop 的 stop hook、`/goal` 的独立 evaluator、Cherny 的 CLAUDE.md 持久指令层，指向同一个设计原则：循环的退出条件必须由外部 verifier 决定，不能由执行 agent 自己决定。这条原则是 loop engineering 区别于 AutoGPT 时代的根本工程化标志。

第四个局限是 Ralph Loop 的 hackathon 出身。Ralph Loop 是 2025 年 7 月在 hackathon 上发布的，至今很多 loop engineering pattern 仍是个人脚本，工业级工程化还没完成。这一代的代表作（Ralph Loop、Cherny 工作流）都是个体开发者或小团队的作品，不是企业级 runtime。企业需要的治理、审计、多租户、凭证管理、合规，这一代都没覆盖。这也为后续企业级 loop runtime（比如 Truefoundry 那条线）留出了空间。

第五个局限是 Data Science Dojo 本身的视角限制。这篇综述的全文视角是个体开发者和研究者，没有覆盖企业级场景。对治理、审计、凭证轮换、多租户隔离这些企业关切，文章一概未提。如果你在企业环境里推 loop engineering，这篇综述够用来理解技术演进，但不够用来做落地架构——后者需要补企业 runtime 的视角。

## 落地建议：从四代演进里吸取什么

讲完局限，给几条具体的落地建议。这些建议不是 Data Science Dojo 原文给出的，而是基于四代演进整理出来的工程判断。

第一，按任务复杂度匹配 loop 类型，不要一上来就上最复杂的。Data Science Dojo 给了一张选择表，整理如下：单步任务加 retry 用 ReAct；需要自我修正用 ReAct 加 Reflexion；长 refactor 或 build 用 Ralph Loop 或 `/goal`；并行独立研究用多 agent；已知依赖的复杂规划用 Plan-and-Execute；快速变化环境用 OODA；策略可能需要全 reset 用内外双循环。这张表的核心思想是 loop 的复杂度要匹配任务，过度工程化的 loop 反而更脆。最务实的一条是：「A single ReAct agent with four tools handles the majority of real-world tasks.」先用 ReAct 跑通，再根据实际瓶颈升级。

第二，把 state 从 context window 剥离到外部持久层。这是第四代给的最重要工程教训。无论你用文件系统（Ralph Loop 路线）还是 CLAUDE.md（Cherny 路线）还是数据库，核心是别让 state 堆在 context window 里。context window 是易失的、有上限的、越满越慢的；外部持久层是稳定的、可 diff 的、可版本控制的。第三代的所有 pattern 都吃了 context overflow 的亏，第四代的解法就是把 state 外置。

第三，用外部 verifier 决定循环退出，不要让 agent 自己决定。这是从 AutoGPT 到 `/goal` 的核心演进。AutoGPT 让 agent 自己判断「做完了吗」，结果是 infinite loop。Ralph Loop 用 stop hook、`/goal` 用独立 evaluator、Cherny 用 CLAUDE.md，都是把退出决策权交给外部。deterministic verifier（测试通过、type check、编译成功）比 non-deterministic verifier（LLM-as-judge）便宜且可靠，能用 deterministic 就别用 LLM-as-judge。

第四，把每一次 agent 犯错的纠正写进持久指令层。这是 Cherny 工作流里最值得抄的部分。CLAUDE.md 作为 human-curated semantic memory，比自动生成的 critique 更可靠，因为人决定放什么。每修一个 agent 反复犯的错误，就往 CLAUDE.md 加一条规则，未来 session 启动时必读。这条做法把 loop engineering 从「每次重新解释项目」变成了「项目知识跨 session 累积」。

第五，在成本门槛 close 之前，先从小范围试起。loop engineering 目前锁定在头部公司，普通团队抄全套工作流会爆账单。务实的路径是先用 ReAct 加少量工具跑通核心任务，再根据实际瓶颈（是 context overflow、是 silent failure、还是串行太慢）逐步引入第四代的某一个 pattern（比如先上 Ralph Loop 解决 context overflow，而不是一上来就上 Cherny 的 5 tab 并行）。演进是分代的，落地也应该是分代的。

第六，把 silent failure 当成头号工程敌人。工具在调、状态没变，是最难抓的失败模式。监控不能只看流量，要看状态变化——比如每轮 loop 结束后检查 git diff 是否真的有变化、测试是否真的跑过、目标文件是否真的被修改。如果连续 N 轮状态零变化，强制中断循环，而不是让它继续烧 token。

## 这套谱系和共识框架的关系

最后把 Data Science Dojo 的四代谱系和 loop engineering 的共识框架（6 原语、三层 context/harness/loop）对一下位，方便把这篇综述放进更大的知识地图。

6 原语里，schedule（调度）对应 DSD 三种 trigger 里的 scheduled 和 Cherny 的系统通知节奏；isolation（隔离）对应 Cherny 的 5 tab 并行和 Ralph Loop 的每次新 context；skills（CLAUDE.md / SKILL.md）对应 DSD 明确定义的 human-curated semantic memory；connectors（MCP）DSD 没直接讲，但多 agent 编排段提到 OpenAI Agents SDK 是构建编排层的最易用框架；verifier（maker/checker 分离）对应 `/goal` 的独立 evaluator、Reflexion 的 evaluator 角色、OODA 的 Orient 步骤；STATE（状态脊柱）对应 Ralph Loop 的 file-based state、CLAUDE.md 跨 session 持久层、四种 memory 分类。

三层结构里，context 层（模型上下文）在四代演进中越来越被刻意限制——从 AutoGPT 把所有历史塞进 context，到 Ralph Loop 每次重启清空 context，演进方向是 context 越来越薄、外部持久层越来越厚。harness 层（工具、MCP、skill、stop hook）从第二代开始逐步成型，到第四代成为 loop engineering 的主要工程对象。loop 层（循环结构本身）从 ReAct 的单线程，到 Magentic-One 的内外双循环，到 Cherny 的多 loop 并行，结构越来越丰富。

需要说明的是，Data Science Dojo 的四代谱系是「微观技术代际」分类——它按 loop 内部结构的技术演进分代。这和按「宏观概念层次」分代（比如把 loop engineering 分成 context/harness/loop 三层）是互补的两个视角，不是冲突。微观代际告诉你技术怎么一步步长出来的，宏观层次告诉你现在的系统怎么拆解。两个视角合起来，才是 loop engineering 的完整地图。

## 延伸阅读

- 原文：Data Science Dojo《Agentic Loops: From ReAct to Loop Engineering (2026 Guide)》https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/
- ReAct 论文：Yao 等人《ReAct: Synergizing Reasoning and Acting in Language Models》（2022-10-06，Princeton + Google Research）
- Reflexion 论文：Shinn 等人《Reflexion: Language Agents with Verbal Reinforcement Learning》（NeurIPS 2023）
- LLMCompiler：Kim 等人《An LLM Compiler for Parallel Function Calling》（ICML 2024，LangChain）
- Magentic-One：Microsoft《Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks》（2024）
- Ralph Loop：Geoffrey Huntley，hackathon 发布（2025-07）
- Peter Steinberger 推文（loop engineering 月度提醒，2026-06-07）
- 本系列其他文章：`01-what-is-loop-engineering.md`（loop engineering 定义）、`02-five-primitives-and-state.md`（六原语与状态脊柱）、`03-patterns-and-rollout-levels.md`（模式与落地分级）、`04-cross-tool-mapping.md`（跨工具映射）、`05-risks-costs-and-anti-patterns.md`（风险、成本与反 pattern）