# Tosea 四层演进：把 Loop Engineering 放进概念坐标的最清晰入门综述

> 来源：Tosea.ai《What Is Loop Engineering? A Complete Guide》(2026-06-16)
> 配套：本系列「深读 Loop Engineering」第 8 篇，综述入门向

## TL;DR

Tosea 的这篇指南是 2026 年中围绕 loop engineering 涌现的众多文章里，最适合做「第一篇读懂」的教科书式综述。它的核心贡献是把 loop engineering 放进一个宏观的概念四层演进框架：**prompt → context → harness → loop**。每一层向外包裹前一层而不取代它，loop engineering 是这条迁移链上目前最外、也最新的一环。

这篇文章值得深读，不因为它提出了什么独家概念——它没有。它值得深读，是因为它把分散在 Addy Osmani 长文、Anthropic 的 Building Effective Agents、Princeton 的 ReAct 论文、Reflexion 论文里的概念，重新组织成了一组可以直接教学的坐标：一个四层演进的图、一段十二行的可引用伪代码骨架、三大硬骨头（context / termination / verification）、以及 context engineering 的三个历史锚点。

读完这一篇，你应该能够：(1) 说清 loop engineering 在概念层级上的位置；(2) 默写一个 loop 的最小骨架并逐行解释；(3) 在设计任何 agent loop 之前，先回答 context、termination、verification 三个核心决策。

需要先声明口径：Peter Steinberger 那条引爆概念的 2026-06-07 推文，Tosea 写 6.5 million views，另一篇被广泛引用的 DSD 综述写 5 million。两次引用都是二手转述，本文统一保守写「据报道 500-650 万次浏览」，不再追求精确数字。

## 为何单独深读这一篇

2026 年 6 月 loop engineering 这个词突然火起来之后，文章很多，但视角各异。有的偏学术（讲 ReAct / Reflexion 谱系），有的偏企业（讲 runtime、治理、多租户），有的偏个体实战（讲 Claude Code 的 skills / worktrees 配方）。问题是：读者在还没建立坐标之前，先读任何一篇都会迷路——你会知道「loop engineering 重要」，但说不清它到底是从哪里长出来的、和 prompt engineering、context engineering 是什么关系、一个 loop 的最小形态长什么样。

Tosea 这一篇的独特价值，在于它**显式画出了概念的层级坐标**。它没有把 loop engineering 当成一个孤立的新事物来鼓吹，而是把它放进一条更长的迁移链：开发者注意力的焦点，过去四年一直在从「模型内部」向外迁移到「围绕模型的环境」。prompt 是模型输入；context 是模型在推理时看到的一切；harness 是围绕 agent 的脚手架（工具、约束、反馈回路）；loop 是 harness 中真正产生自治性的那部分——迭代周期。每一步都不是否定前一步，而是在前一步外面再包一层。

这个四层框架的清晰度，是其他几篇综述都没做到的。DSD 讲 loop 的技术代际谱系（四代 loop 类型的演进），是微观、技术维度；Tosea 讲四层概念演进，是宏观、概念维度。两个视角正交，合起来才完整。所以这一篇在系列里的定位是**宏观骨架**——读完它，再读 DSD、Truefoundry、OpenAI、MindStudio 的深读，你就有一张地图把它们的局部细节挂上去。

Tosea 的第二个独特贡献，是一段十二行的伪代码骨架。这段代码不是某个具体框架的实现，而是一个 loop 的最小可运行定义。Tosea 自己说：「Almost everything interesting in loop engineering is a decision about one of these lines」——loop engineering 里所有有意思的问题，都是关于这十二行里某一行的决策。这句话是对的。后面我会逐行展开。

第三个独特贡献，是把 loop 的核心难点教学化整理成三大硬骨头：context management、termination、verification。这三件事不是失败模式列表（DSD 给了六类失败模式，那更全），而是**设计 loop 时必须先回答的三个核心决策**。每个决策都给了 deterministic check 与 LLM-as-judge 之间的明确权衡，这是落地时最容易被忽视的判断点。

## 心智模型：俄罗斯套娃与温控器

要快速建立 loop engineering 的坐标，用两个类比最有效。

**第一个类比：俄罗斯套娃。** Tosea 的四层演进，结构上就是一组俄罗斯套娃。最内层是 prompt——你写给模型的那段文字。prompt 外面包着 context——模型在推理时实际看到的一切，包括 prompt、历史对话、工具结果、检索到的文档、系统消息。context 外面包着 harness——围绕 agent 的完整脚手架：工具集、权限约束、文件系统访问、worktree、sub-agent、外部状态存储、反馈回路。harness 外面包着 loop——harness 中真正让 agent 自治运行的那部分：一个会反复执行、对照真实环境信号自我纠正的迭代周期。

关键认知：每一层都不取代前一层。你做 loop engineering 的时候，仍然在做 harness engineering（决定 agent 用什么工具、在什么 worktree 里工作）、context engineering（决定每一步给模型看什么）、prompt engineering（决定系统消息怎么写）。套娃是从内到外逐层包裹，不是替换。这个「nested concerns, not replacing」的认知，是 Tosea 框架最容易被读者忽略但最重要的一句话——很多人一听到 loop engineering，就以为 prompt engineering 过时了，那是误读。

**第二个类比：温控器与 REPL。** Tosea 用一句话点破 loop 与传统 chat 的区别：a loop is「closer to a thermostat or a REPL than to a chat」。温控器不是问一句答一句的对话，它是一个持续运行、对照环境信号（温度）自我调整的系统。REPL（交互式 shell）也一样——你不是一次性把程序写完，而是写一行、执行、看结果、写下一行。Loop engineering 把 LLM agent 从「一次性问答」变成「持续运行的控制系统」。

这个类比为什么重要？因为它直接告诉你 loop 的设计本质是控制论问题，不是对话设计问题。一个温控器要回答的核心问题是：目标温度是多少（goal）、什么时候算到位（termination）、用什么传感器判断（verification）、传感器坏了怎么办（error handling）。一个 loop 要回答的核心问题完全同构：goal、termination、verifier、escalation。后面三大硬骨头里的 termination 和 verification，本质就是控制论里的稳定性与可观测性。

把这两个类比叠起来：loop engineering 是把 LLM agent 从「对话」升级成「控制系统」，而这个升级是套娃最外层的一层包裹，不是对前面三层的否定。

## 详细机制：四层演进逐层拆解

现在逐层展开 Tosea 的四层框架。理解每一层的天花板，才能理解为什么注意力会向外迁移到下一层。

### 第一层：Prompt engineering（2022-2024）——优化表达

最早，开发者和模型交互的全部艺术，集中在「怎么把指令写好」。给模型分配角色（「你是一个资深 Python 工程师」）、拆解步骤（「请按以下步骤思考」）、提供 examples（few-shot）、要求 step by step、加 chain-of-thought 提示。这一层的工程化产物是 prompt 模板、prompt 库、A/B 测试不同措辞。

Prompt engineering 的天花板，Tosea 用一句话点死：「a perfectly phrased prompt still cannot supply facts the model never received」——措辞再完美，也无法供给模型从不知道的事实。你可以把「请用中文回答」改一百遍，但如果你要模型回答「公司 2026 年 Q2 的内部销售数据」，无论 prompt 写得多漂亮，模型都不知道这个数据。

这个天花板是结构性的，不是技巧能突破的。一旦任务从「让模型用已有能力生成内容」变成「让模型基于它不知道的信息做判断」，prompt engineering 就到头了。注意力必须向外迁移：焦点从「怎么写指令」移到「模型在推理时到底能看到什么」。

### 第二层：Context engineering（2025）——优化模型看到的一切

Context engineering 把焦点从「措辞」移到「模型在推理时看到的一切」。Prompt 只是 context 的一部分；context 还包括历史对话、检索到的文档、工具调用的返回结果、系统消息、few-shot examples。Context engineering 的核心问题是：在有限的 context window 里，如何挑选、组织、维护「下一步推理最需要的那些 token」。

Tosea 在这一层给了三个明确的历史锚点，这是其他综述都没整理的：

**锚点一：2025 年 6 月 18 日，Shopify CEO Tobi Lütke 给出定义。** 他在内部备忘录里把 context engineering 定义为「providing all the context needed for the task to be plausibly solvable by the model」——为任务提供所有让模型有可能解决它所需的上下文。这个定义的关键词是 plausibly solvable：不是保证解决，而是让任务至少在模型的能力范围内变得可解。这是一个很克制、很准确的定义——它不承诺结果，只承诺输入的完备性。

**锚点二：Andrej Karpathy 背书。** Karpathy 把 context engineering 描述为「the delicate art and science of filling the context window with just the right information for the next step」——填充 context window 的精细艺术与科学，目标是给下一步推理恰好提供正确的信息。注意「just the right」——不是越多越好，而是恰好。这指向 context engineering 的核心张力：context window 是有限的，塞太多会稀释注意力，塞太少会缺信息。

**锚点三：2025 年 9 月 Anthropic 正式定义。** Anthropic 把 context engineering 定义为「curating and maintaining the optimal set of tokens during inference」——在推理过程中策展并维护最优的 token 集合。注意两个动词：curating（策展，强调挑选与组织）和 maintaining（维护，强调持续更新，不是一次性写入）。这个定义比 Tobi Lütke 的更动态——context 不是推理前一次性塞满，而是推理过程中持续在变。

三个锚点合起来，给出 context engineering 的完整轮廓：它是动态的、是关于「下一步」的、是策展而非堆砌的。Tosea 的结论是：prompt engineering 从此成为 context engineering 的子集——写 prompt 仍然重要，但它只是 context 工程里的一个子任务。

Context engineering 也有自己的天花板：它假设 agent 只做一次性推理。但现实里，agent 要做生产级多步工作——读文件、跑测试、改代码、再跑测试、看错误、再改。一次性 context 再精心策展，也无法覆盖一个会持续数十步、可能运行一小时的过程。注意力再次向外迁移：从「一次推理看到什么」到「agent 做多步工作的整个环境是什么」。

### 第三层：Harness engineering（2026）——优化 agent 的运行环境

Harness engineering 关注的是围绕 agent 的完整脚手架：scaffolding（脚手架）、tools（工具集）、constraints（约束）、feedback loops（反馈回路）。Harness 不是模型本身，也不是 prompt 或 context，而是 agent 运行所在的整个外部环境。

Tosea 给 harness engineering 一句关键判断：「harness engineering is what makes agents reliable rather than merely clever」——harness engineering 让 agent 从「聪明」变成「可靠」。这句话点出了分水岭：一个没有 harness 的 agent，可能在 demo 里表现惊艳，但放进生产环境就崩——因为它没有可靠的工具、没有权限约束、没有错误恢复、没有反馈回路。可靠性，而不是聪明度，是 agent 能不能进生产的真正门槛。

Harness 的嵌套关系很清楚：harness ⊃ context ⊃ prompt。Harness 包含 context（context 是 harness 喂给模型的部分），context 包含 prompt（prompt 是 context 里开发者写的那部分）。所以做 harness engineering 时，你仍然在做 context engineering 和 prompt engineering，只是你的注意力焦点移到了更外层。

Harness engineering 涵盖哪些具体内容？Tosea 借用 Addy Osmani 提出的六件套来概括 harness 的结构组件：automations（自动化触发）、worktrees（隔离工作树）、skills（技能，即可复用的能力单元）、connectors（连接器，即外部系统集成）、sub-agents（子 agent）、external state（外部状态存储）。这六件套构成了一个 agent 能在生产环境里可靠运行所需的最小支撑结构。

Harness engineering 的天花板在哪里？它回答了「agent 需要什么环境」这个问题，但没回答两个更尖锐的问题：在这个环境里，agent 该按什么周期工作？什么时候该停？这两个问题就是 loop engineering 的领地。

### 第四层：Loop engineering（2026）——优化迭代周期本身

Loop engineering 聚焦 harness 中真正产生自治性的那部分：迭代周期。Harness engineering 问「agent 需要什么环境」，loop engineering 问「什么周期让它持续朝目标工作，什么时候停」。

Tosea 给 loop engineering 下的定义值得完整引用：「The unit of work is no longer a single prompt or even a single conversation. It is a loop: a repeating cycle in which the model takes an action, receives feedback from its environment, uses that feedback to decide the next move, and continues until a defined termination condition is met.」

拆解这个定义的四个要素：(1) 重复的周期——不是一次，是反复；(2) 模型采取动作——不只是生成文本，是调用工具改变环境；(3) 从环境接收反馈——动作的后果以测试结果、类型检查、运行错误等形式回到模型；(4) 明确的终止条件——不是无限循环，是有出口的。这四个要素合起来，才是 loop engineering 的对象。

Loop engineering 的学术祖先，Tosea 明确指向 ReAct（Reasoning + Acting，Princeton + Google，2022）。ReAct 的核心贡献是证明了一件事：一个能在动作之间观察结果的模型，和一个只回答一次的模型，行为完全不同。原话是「interleaved reasoning with action steps, showed that a model that observes results between actions behaves very differently from one that answers once」。这句话是 loop engineering 整个领域的起点——它确立了「观察-行动交替」这个基本结构。

Tosea 给了一个判断「为什么是现在」的答案：到 2026 年中，coding agent 终于「能自治运行足够久 + 从自己错误中恢复得足够好」。瓶颈因此转移——当单次 agent run 可能持续一小时、触碰几十个文件时，最高杠杆已经不是写更锋利的 prompt，而是设计一个让 agent 持续多产的 loop。Prompt engineering 的边际收益在递减，loop engineering 的边际收益在上升，这是注意力迁移的现实驱动力。

四层讲完，套娃成型。Loop engineering 不是凭空出现的新事物，它是开发者注意力向外迁移的最新一站。理解这一点，就不会把它当成营销概念，也不会把它当成对前几层的否定——它是套娃最外的一层。

## 详细机制：十二行伪代码骨架逐行讲解

Tosea 给出的这段十二行伪代码，是它最有实用价值的产物。它不是任何具体框架的代码，而是一个 loop 的最小可运行定义。理解每一行在做什么，就理解了 loop engineering 的全部决策点。

```python
state = init_state(goal)                  # recursive goal + scratchpad
for step in range(MAX_STEPS):             # hard cap: never loop forever
    thought = model.reason(state)         # ReAct: reason about what to do
    action  = model.choose_action(state)  # ...then choose a tool call
    result  = tools.execute(action)       # touch the real environment
    state   = update(state, thought, action, result)
    state   = compact(state)              # keep context under budget
    if verifier.passes(state):            # deterministic check = reward signal
        return success(state)
    if no_progress(state) or budget.exhausted():
        return escalate_to_human(state)   # stop circling a dead end
return escalate_to_human(state)           # ran out of steps -> hand back
```

Tosea 的关键评论先放在前面：「Almost everything interesting in loop engineering is a decision about one of these lines」——model 是中间固定的黑盒，engineering 全在围绕它的 loop 上。这句话是理解整段代码的钥匙：model 的能力是给定的，你能调的是这十二行的每一处。

**第一行：`state = init_state(goal)`**

初始化状态。State 包含两样东西：递归的 goal（可能被拆解成子目标）和 scratchpad（草稿本，记录中间结果）。这一行的核心决策是：goal 怎么表达？是「让测试通过」（可验证、好）还是「改进代码」（模糊、坏）？Goal 的表达质量，直接决定后面 verifier 能不能判断 termination。一个表达不清的 goal，会让 loop 在错误的胜利条件上无限打转。

State 的结构也是这里的决策。State 是存在内存里的字典？还是写到外部文件？长 loop 里，state 会膨胀到超出任何 context window，必须 externalize（外置）到文件或数据库。Tosea 在后面讲 context management 时会回到这点。

**第二行：`for step in range(MAX_STEPS):`**

硬上限循环。无论发生什么，loop 最多跑 MAX_STEPS 次。这一行是 loop engineering 最朴素也最重要的安全网：「never loop forever」——永不无限循环。一个没有 hard cap 的 loop，是生产事故的种子。MAX_STEPS 设多少？太小会过早升级人工，太大会烧钱。这是一个需要根据任务复杂度调的参数。

这一行还隐含一个决策：步数的预算是一次性给，还是动态调整？进阶的 loop 会引入 token budget、wall-clock budget，和 step budget 一起组成多重预算约束。任何一项耗尽都触发升级。

**第三行：`thought = model.reason(state)`**

模型基于当前 state 推理。这一行是 ReAct 模式的前半——Reason。模型在这一步不采取行动，只思考「现在该怎么办」。这一行的工程决策是：reasoning 显式分离出来，还是和 action 合并？显式分离的好处是可观测（你能看到模型在想什么），坏处是消耗 token、可能让 context 更快膨胀。Osmani 的 skills 设计、Anthropic 的 extended thinking 都是这个决策的不同回答。

**第四行：`action = model.choose_action(state)`**

模型选择一个动作（通常是工具调用）。这一行是 ReAct 模式的后半——Act。关键认知：reason 和 action 是两个独立的模型调用，不是一次调用里既思考又行动。分离让每一步都可观测、可干预。

这一行的工程决策很多：可用工具集是什么？工具描述怎么写（这本身就是 prompt engineering，但放在 loop 的语境里它决定 agent 能看到哪些 affordance）？工具的参数 schema 怎么设计？工具调用失败时怎么反馈给模型？这些都是 harness engineering 的内容，但它们在 loop 的每一步都会被触发。

**第五行：`result = tools.execute(action)`**

执行动作，触碰真实环境。这是 loop 和 chat 的分水岭——chat 只生成文本，loop 通过工具调用改变真实世界（读文件、写文件、跑测试、提交代码）。这一行的核心决策是执行环境的隔离度：在主仓库直接执行？在独立 worktree 里执行？在容器里执行？Tosea 后面讲 worktrees 时会强调，并行 loop 必须用 worktree 隔离，否则多个 agent 会互相覆盖。

执行失败怎么处理也在这里。一个 missing credential 是硬停（升级人工），一个 failing test 是反馈（继续 loop）——区分这两类错误是 error handling 的核心。Tosea 在六大失败模式里专门提到 objective misspecification：agent 可能学会删掉失败的 test 让 CI 变绿，这就是 termination criteria 没抓住真实 intent 的后果。

**第六行：`state = update(state, thought, action, result)`**

把这一步的思考、动作、结果写回 state。这一行看似简单，其实是 context engineering 在 loop 内运行的入口。Update 的策略决定了 context 如何增长：全量保留？摘要保留？按相关性筛选保留？长 loop 里 state 会爆炸，这一行的策略直接决定 loop 能跑多久。

进阶设计里，update 会区分「需要进 context window 给模型看的」和「只需要存在外部不一定要回灌的」。前者是 working memory，后者是 episodic memory。Reflexion 的 verbal lesson 就是 episodic memory 的一种形态——把上一轮的教训写成文字，供后续轮次回读。

**第七行：`state = compact(state)`**

压缩 state，让 context 保持在预算内。这一行是 context management 的核心操作。Compact 可以是摘要（把长 transcript 压成短摘要）、pruning（删除不相关的旧条目）、externalize（把状态写到文件，从 context window 里移出）、或 sub-agent isolation（把一段工作委派给子 agent，子 agent 在自己的 context window 里跑完只返回结论）。

这一行为什么独立成一步，而不是藏在 update 里？因为 compaction 是一个有损操作，它改变模型下一步能看到什么。把它显式化，意味着你承认「context 不是越多越好，context 是要主动管理的资源」。Karpathy 说的「just the right information」就在这一行落地。

**第八行：`if verifier.passes(state): return success(state)`**

验证器通过，成功退出。这一行是 loop 的第一个出口，也是 reward signal 的来源。关键决策：verifier 是什么？最强的是 deterministic verifier——测试、类型检查、编译器、linter。它们返回模型无法争辩的客观 pass/fail。Tosea 在三大硬骨头里会强调：「trust a deterministic verifier, never the agent's self-report」——永不信任 agent 的自报告，只信确定性验证器。

为什么这一行这么靠后（第八行，不是第一行）？因为验证是有成本的——跑全套测试可能要几分钟。所以典型的 loop 设计是：先做一步动作，再快速验证（比如只跑受影响的测试），频繁轻量验证，而不是只在最后跑一次全套。这呼应了 Tosea 第六类失败模式「compounding errors」的对策：早验证、勤验证，不要只在结尾验。

**第九行：`if no_progress(state) or budget.exhausted(): return escalate_to_human(state)`**

无进展或预算耗尽，升级人工。这一行是 loop 的第二个出口，也是最容易被漏掉的。Tosea 用一句金句点醒：「The signature bug of a naive loop is that it never stops」——朴素 loop 的标志性 bug，就是它永远不停。没有这一行的 loop，会陷入死循环：同一个错误改三遍、同一个测试失败三遍、state 不变但 loop 仍在跑。

No-progress detection 的实现是这里的工程难点。最简单的版本：记录最近 N 步的 state 哈希，如果重复就 break。进阶版本：检测错误信息是否雷同、动作是否重复、verifier 结果是否在同一个失败点震荡。Budget exhausted 则是硬性兜底——token 花超了、时间跑超了、步数到顶了，都强制升级人工，避免在一个死胡同里烧钱。

**第十行：`return escalate_to_human(state)`**

循环结束（MAX_STEPS 用完）仍没成功，升级人工。这一行是 loop 的第三个出口。注意它和第九行的区别：第九行是「中途检测到无进展或预算耗尽」，第十行是「跑完了所有步数仍然没通过验证」。两种情况都升级人工，但语义不同——前者是 loop 主动判断「我卡住了」，后者是 loop 被动地「用完了机会」。

Escalate to human 的设计也有讲究：升级时给人工什么信息？完整的 state？最近 N 步的摘要？失败点的错误信息？好的升级会让人工能在几分钟内判断「这是 goal 表达不清、还是 verifier 不对、还是任务本身超出 agent 能力」。坏的升级只丢一个「loop failed」就完事，人工得从头复现。

十二行讲完。回过头看 Tosea 那句话——「loop engineering 里所有有意思的问题，都是关于这十二行里某一行的决策」——你会同意它。Model 是黑盒，你能工程的，就是这十二行。一个 loop engineering 的从业者，本质上就是在反复调这十二行的每一处：goal 怎么表达、MAX_STEPS 设多少、reason 和 action 怎么分离、工具集怎么设计、state 怎么 update、compact 用什么策略、verifier 用 deterministic 还是 LLM-judge、no-progress 怎么检测、budget 怎么分配、escalate 时给人工什么信息。每一处都是一个设计决策，合起来就是 loop engineering 的全部手艺。

## 详细机制：三大硬骨头

Tosea 把 loop 的核心难点教学化整理成三大硬骨头：context management、termination、verification。这三件事不是失败模式列表，而是设计任何 loop 之前必须先回答的三个核心决策。

### 硬骨头一：Context management

Tosea 的核心比喻：context window 是 agent 的 RAM，有硬上限。长 loop 每一步都往 context 里追加 thoughts、tool outputs、errors，window 装满之后会产生一种叫 **context rot** 的现象——「as the transcript grows, it attends less reliably to what actually matters」。Context rot 不是「装不下」（那个会直接报错），而是更隐蔽的「装得下但模型注意力被稀释」——模型开始忽略真正重要的信息，被无关的历史细节带偏。

Context rot 是 loop engineering 里最阴险的失败模式，因为它不报错。Loop 还在跑，验证器可能偶尔通过，但 agent 的判断质量在悄悄下降。开发者往往要等到 agent 做出一个明显荒谬的决策，才会回头发现 context 里堆了几万 token 的无关历史。

Tosea 给的对策是纯 context engineering 在 loop 内运行的四板斧：

- **Compaction（压缩）**：定期把长 transcript 摘要成短文字。摘要本身可以用一个 LLM 调用来做，但要意识到摘要是有损的——重要细节可能被丢掉。
- **Pruning（剪枝）**：删除明确无关的旧条目。比如早期的探索性工具调用，在 loop 后期已经无关的，可以直接删掉。
- **Externalize to files / scratchpad（外置到文件）**：把状态写到外部文件（plan.md、progress.md、findings.md），从 context window 里移出，只在需要时按需读回。这是 planning-with-files 这类技能的原理。
- **Sub-agent isolation（子 agent 隔离）**：把一段独立的工作委派给子 agent，子 agent 在自己的、干净的 context window 里跑完，只把结论返回给主 loop。主 loop 的 context 不被这段工作的中间细节污染。

这四板斧不是互斥的，实际 loop 会组合使用。但 Tosea 提醒：每一样都是有代价的。Compaction 丢细节，pruning 可能删错，externalize 增加读取成本，sub-agent isolation 引入委派开销和结果质量不确定性。Context management 不是「越多越好」的问题，是「在有限预算里做最优权衡」的问题。

### 硬骨头二：Termination and no-progress detection

Tosea 的金句已经引用过：「The signature bug of a naive loop is that it never stops」。这一节展开 termination 为什么是 loop 设计的一半（原话：「Termination is not an afterthought; it is half the design」）。

一个健壮的 loop 必须有多重独立的出口。Tosea 列出至少四种：

- **Verifier 通过**：loop 的正常成功出口。验证器判定目标达成，正常退出。
- **Hard iteration cap（MAX_STEPS）**：无论发生什么，步数用完就停。这是兜底安全网。
- **Token / wall-clock budget**：预算耗尽就停。比 step cap 更精确，因为不同步骤消耗差异大。
- **No-progress detection**：最近几步产生相同错误、或 state 不变，就 break 并升级人工。

第四种是最难做对的，也是最容易被漏掉的。No-progress detection 的难点在于判断「什么算无进展」。最朴素的版本——最近 N 步 state 哈希相同——会被合理但缓慢的探索触发误报（agent 在反复读同一个文件，但每次都在积累不同理解）。进阶版本要判断的是「朝目标的进展是否停滞」，这本身需要一个对「进展」的可操作定义。

Tosea 的实战建议：多重独立出口并存，任意一个触发就退出。不要指望单一 termination 判断——任何一个单独的 termination 逻辑都可能被某种边界情况绕过。多层独立的兜底，才是可靠的 termination。

Termination 设计的另一个维度是「升级到谁」。Escalate to human 是默认选项，但在更复杂的系统里，升级可以分层：升级到更强的模型、升级到人工审核、升级到完全中止任务。不同严重程度对应不同升级路径，这是 orchestrator-workers 架构里 orchestrator 的职责之一。

### 硬骨头三：Verification as the reward signal

第三大硬骨头是 verification——loop 怎么知道自己做对了。Tosea 的核心论点：反馈必须可信。

Tosea 区分两类验证器：

**黄金标准：deterministic verification。** 测试、类型检查器、编译器、linter——它们返回模型无法争辩的客观 pass/fail。一个测试要么通过要么不通过，没有「基本上通过」的灰色地带。Deterministic verifier 是 loop 最可靠的 reward signal，因为它们对模型的修辞免疫。模型不能通过争辩让一个 failing test 变绿。

**更灵活但危险：LLM-as-judge。** 用另一个 LLM 来评估 agent 的产出。更灵活——可以判断测试覆盖不了的维度（代码可读性、架构合理性）。但 Tosea 明确警告：LLM-as-judge「can be gamed or can collude with the actor」——可能被 agent 绕过，也可能和 agent 共谋（两个 LLM 共享类似的盲点，互相认可彼此的错误产出）。

Tosea 给的最强 loop 的配方是：**凡是有 deterministic check 可用的，就把它放进 cycle；model judgment 留给真正不可机械验证的部分。** 这句话是 loop engineering 在 verification 上的核心原则。它不是说 LLM-as-judge 不能用，而是说 deterministic check 优先，能用就别用 LLM-judge 替代。

这个原则的一个推论：如果你发现自己在一个任务上只能用 LLM-as-judge、没有任何 deterministic check 可用，那这个任务可能不适合做成自动 loop。它更需要人工评审，或者更适合做成「agent 起草 + 人工审核」的半自动流程，而不是全自治 loop。Verification 的可机械化程度，直接决定一个任务适合多大程度的自治。

这三大硬骨头——context、termination、verification——是 loop 设计里必须先回答的三个核心决策，不是事后的优化点。Tosea 的教学价值在于，它没有把这三件事埋在失败模式列表里，而是把它们提到「设计前必须先想清楚」的位置。一个没想清楚这三点的 loop，再多 prompt 调优也救不回来。

## 详细机制：三种 loop pattern 的学术谱系

Tosea 整理了五种 loop pattern 的谱系。这里挑三种对实战影响最大的展开，另两种（Plan-and-Execute、Orchestrator-Workers）简单带过。

**ReAct（Yao et al., 2022）——所有现代 loop 的祖先。** ReAct 的核心结构就是前面十二行伪代码里 reason 和 action 交替的那两行。它的贡献不是某个具体技巧，而是确立了「观察-行动交替」这个基本范式。后面所有的 loop pattern，都是对 ReAct 的某种扩展或修改。ReAct 本身适合简单任务——单 agent、单 context window、目标明确可验证。Tosea 给了一条实战建议：「A single ReAct loop with a deterministic verifier beats an elaborate multi-agent system you cannot debug」——一个带确定性验证器的单 ReAct loop，胜过一个你无法 debug 的复杂多 agent 系统。这是对过度工程的明确警告。

**Reflexion（Shinn et al., 2023）——把教训写入记忆。** Reflexion 在 ReAct 基础上加了第三个角色：self-reflection。架构变成三角色：Actor（执行动作）、Evaluator（评估结果）、Self-Reflection（反思并把教训写成 verbal lesson）。关键创新是 verbal lesson 被写入 episodic memory buffer，供后续尝试回读。这意味着 agent 在单 session 内、无需重训就能变好——它把自己的失败教训记下来，下一轮尝试时读出来，避免重复犯错。Reflexion 是 loop engineering 里「学习」机制的雏形，它把 agent 从「每次都从头开始」变成「会积累经验」。

**Evaluator-Optimizer（出自 Anthropic 的 Building Effective Agents，2024-12）——生成-评估-反馈循环。** 一个模型生成候选方案，另一个模型评估并给反馈，循环直到通过。这个 pattern 适合有清晰、可表达验收标准的场景——标准越清晰，评估模型越能给有用的反馈。它是 deterministic verifier 不可用时的一种替代，但要意识到它的评估模型本身是 LLM，会有 LLM-as-judge 的所有风险。

另外两种 pattern 简述：**Plan-and-Execute**——planner 把长任务拆成子任务，executor 逐个执行，分离减少长任务的漂移；**Orchestrator-Workers**——中央 orchestrator 动态拆任务、委派给 worker sub-agent（每个有自己的 fresh context window）、合成结果，这是 Osmani「sub-agents + worktrees」的形式化，是「agents that run while you sleep」的并行舰队架构。

Tosea 在 pattern 选择上的总建议是：「prefer the simplest pattern that works, and compose patterns rather than reaching for a heavy framework」——优先用能工作的最简单 pattern，组合 pattern 而不是抓重型框架。这个建议和 ReAct 那条「单 loop 胜过无法 debug 的多 agent 系统」是一致的：简单优先，可 debug 优先。

## 真实案例：payments-refactor 分支让 CI 变绿

Tosea 给的最具体实战案例，是把 loop engineering 用在让一个 payments-refactor 分支的 CI 变绿这个任务上。这个案例很有教学价值，因为它直接对比了「传统方式」和「loop-engineered 方式」。

**传统方式（hand-prompted）：** 开发者写一个详细的 prompt 给 agent，然后 babysit（守在旁边盯）一小时。过程中开发者要反复介入——agent 跑偏了拉回来、agent 卡住了给提示、agent 改错地方了纠正。这一小时里，开发者的注意力被锁定，做不了别的事。

**Loop-engineered 方式：** agent 拿到一个独立的 worktree（隔离工作树，不影响主仓库）、一个 terminal（可以执行命令）、一个 test runner（可以跑测试）、一个 type checker（可以查类型）。这些是 harness 的组件。然后 loop 启动：agent 读第一个失败的 test，定位问题，打补丁，重跑测试。如果还是红，继续读新的失败输出，继续改。如果绿了，跑全套测试，再跑 linter，全部通过就开一个 draft PR，然后停下来通知人工。

两种方式的差异不在 agent 本身（用的是同一个模型），而在围绕 agent 的 loop 设计。Loop-engineered 版本里有几个关键设计决策值得点出：

第一，**独立 worktree**——agent 在隔离环境工作，不会污染主仓库。这对应 Osmani 六件套的 worktrees。

第二，**维护外部日志记录已试过的东西**——agent 不在 context window 里靠记忆避免重复，而是把「试过什么」写到外部文件。这是 context management 里 externalize 策略的实战应用，避免 context rot。

第三，**同一 test 失败 3 次就升级人工**——这是 no-progress detection 的具体落地。不是泛泛的「卡住就升级」，而是具体的、可操作的触发条件（同一 test 失败 3 次）。这种具体化是 termination 设计好坏的分水岭。

第四，**成功的定义是全套测试 + linter 都通过**——这是 verification。注意它用的是 deterministic verifier（测试 + linter），不是 LLM-as-judge。payment 重构这种任务，有现成的测试和类型检查可用，deterministic verification 是正确选择。

第五，**成功后停下来开 draft PR，而不是继续找事做**——这是 termination 的成功出口。Loop 知道什么时候算完，不会无限优化。

这个案例的教学价值在于，它把抽象的四层框架和三大硬骨头，落到了一个具体的、可复现的工作流上。每个设计决策都能对应回前面的某个概念：worktree → harness 的 isolation、外部日志 → context management 的 externalize、失败 3 次升级 → termination 的 no-progress detection、全套测试通过 → verification 的 deterministic check。一个好的 loop engineering 实现，就是这些决策的具体组合。

## 权衡与局限：综述的通病是广而不深

Tosea 这一篇作为入门综述非常出色，但它有自己的局限，读的时候要保持清醒。

**第一，四层演进的线性叙事可能过度简化。** Tosea 把 prompt / context / harness / loop 描述成相继出现的四层，叙事节奏暗示了一种线性替代。但现实里，这四层在 2025-2026 年是并行演化的，不是严格替代。Context engineering 在 2025 年火起来时，prompt engineering 并没有消失——它在 context engineering 内部继续演化。Harness engineering 和 loop engineering 在 2026 年也是并行的，不是先 harness 后 loop。Tosea 自己也说「nested concerns, not replacing」，但叙事节奏仍然暗示线性，读者容易误读成「新一层取代旧一层」。

**第二，6.5M vs 5M views 的数据口径不一致。** Steinberger 那条推文的浏览量，Tosea 写 6.5 million，DSD 综述写 5 million。这种传播数据在二手转述里被放大或缩小是常态，引用时应该保守。更重要的是，views 数量本身不证明概念的有效性——一个概念可以病毒式传播但实操上有问题。Views 是热度的指标，不是质量的指标。

**第三，「最简单 pattern 优先」可能低估了企业复杂度。** Tosea 的视角偏个体开发者或小团队。它的建议「单 ReAct loop 胜过无法 debug 的多 agent 系统」对个人脚本和小项目是对的，但放到企业级场景——多租户、多 agent 并发、需要审计追踪、需要治理——简单 ReAct loop 就是灾难。企业级 loop engineering 需要 orchestrator、需要 worktree 编排、需要状态持久化、需要权限隔离，这些 Tosea 都没深入。Truefoundry 那种企业 runtime 视角的综述，是 Tosea 的必要补充。

**第四，Tosea 是 AI slide 工具厂商。** 文章后半段把 loop engineering 套到「document-to-deck generation」上有明显的产品自推销（zero-hallucination AI slides 这类宣传）。研究 loop engineering 本身时这部分可以忽略，但要意识到作者有商业立场——它有动机把 loop engineering 描述得比实际更成熟、更普适。

**第五，没有讲企业级 / 治理 / 多租户。** 这是 Tosea 视角的盲区。它的视角停在「单个开发者设计自己的 loop」。但 loop engineering 一旦进入生产、进入团队、进入企业，问题集就完全不同：多个 loop 之间怎么防碰撞？loop 的执行需要什么权限边界？loop 的产出怎么审计？loop 跑偏了怎么回滚？这些问题 Tosea 都没触及，需要读 Truefoundry 那一篇来补。

**第六，cognitive surrender 风险被轻描淡写。** Tosea 提到了 comprehension debt（理解债务）——「comprehension debt grows faster as the loop improves」，以及「a loop that optimizes a badly specified objective will pursue the wrong thing with great efficiency」（一个优化错误目标的 loop，会以极高的效率追求错误的事）。这两句话精准描述了 cognitive surrender 的两种形态：一种是人对自己 agent 行为的理解在 loop 变好后加速流失，另一种是 loop 把错误目标执行得太好。但 Tosea 只是点到，没有展开这是 loop engineering 最深的长期风险。在系列里会有专门一篇深读 cognitive surrender，这里只是提示 Tosea 在这点上写得不够。

**第七，坦诚的冷静对冲。** 值得肯定的是，Tosea 引用了 AlphaSignal 的「Most Developers Do Not Need Agent Loops Yet」作为冷静对冲——大多数开发者目前还不需要 agent loop。这是负责任的写法。Loop engineering 是有适用边界的，不是所有任务都值得做成 loop。一次性代码生成、简单问答、明确无歧义的任务，用 one-shot prompt 就够了，做成 loop 反而是过度工程。

## 落地建议

读完 Tosea 这一篇，如果要落地 loop engineering，我的建议分三步。

**第一步：先判断你的任务是否需要 loop。** Tosea 引用的 AlphaSignal 标题是对的——大多数开发者目前不需要 agent loop。Loop 的适用场景是：任务多步、有可验证的成功条件、需要触碰真实环境（文件、测试、运行时）、单次 one-shot 做不好。如果你的任务是「翻译这段话」「总结这篇文章」「生成一个函数」，one-shot 就够了，做成 loop 是浪费。判断标准：你能不能为这个任务写出一个 deterministic verifier？能，且任务多步，就值得做成 loop；不能，就别勉强。

**第二步：从最简单的 ReAct loop + deterministic verifier 开始。** Tosea 的「单 ReAct loop 胜过无法 debug 的多 agent 系统」是金句。第一个 loop 不要上 orchestrator-workers，不要上多 agent 编排，就一个 agent、一个 context window、一个 deterministic verifier、一个 MAX_STEPS、一个 no-progress detection。把这十二行伪代码的最小版本跑起来，把四大 termination 出口都接上（verifier 通过、step cap、budget、no-progress），然后再看哪里需要扩展。

**第三步：三大硬骨头按顺序解决。** 先解决 verification（用什么 deterministic check），再解决 termination（多重出口），最后解决 context management（长 loop 的 compaction / externalize / sub-agent isolation）。这个顺序不是随意的——verification 决定 loop 能不能知道对错，没有可靠的 verification，其他都无意义；termination 决定 loop 会不会失控，没有 termination 的 loop 是定时炸弹；context management 决定 loop 能跑多久，它影响的是 loop 的上限，不是下限。先保下限，再提上限。

还有一个跨步骤的原则：**全程保持可 debug。** Tosea 反复强调「a loop you cannot debug is worse than no loop」。每一个设计决策——引入 sub-agent、引入 orchestrator、引入复杂 context management——都要问自己：这个决策之后，loop 出问题时我能定位吗？如果不能，先不要引入。简单可 debug 的 loop，比复杂不可 debug 的 loop 价值高得多。

最后一条心理准备：**loop engineering 不会让你立刻变快。** 第一个 loop 上线，你大概率会花更多时间——调 termination、debug context rot、修 verification 的边界情况。收益是滞后才来的：当 loop 稳定后，它能在你睡觉时跑一小时触碰几十个文件，这种 leverage 是 one-shot prompt 永远给不了的。但要先熬过调试期，别在第一个 loop 还没稳定时就放弃。

## 延伸阅读

- 原文：Tosea.ai《What Is Loop Engineering? A Complete Guide》(2026-06-16) — https://tosea.ai/blog/loop-engineering-ai-agents-complete-guide-2026
- Addy Osmani《Loop Engineering》长文（2026-06-08）——Tosea 四层框架和六件套的主要来源，把病毒式观点变成可构建的词汇表
- Anthropic《Building Effective Agents》(2024-12)——Evaluator-Optimizer 和 Orchestrator-Workers 两种 pattern 的出处
- ReAct 论文（Yao et al., Princeton + Google, 2022）——loop engineering 的学术起点，确立「观察-行动交替」范式
- Reflexion 论文（Shinn et al., 2023）——verbal reinforcement learning，把教训写入 episodic memory 的机制
- Tobi Lütke 内部备忘录（2025-06-18）——context engineering 第一个明确定义
- Anthropic context engineering 正式定义（2025-09）——「curating and maintaining the optimal set of tokens during inference」
- AlphaSignal《Most Developers Do Not Need Agent Loops Yet》——Tosea 引用的冷静对冲，loop engineering 适用边界的讨论
- 本系列 DSD 深读：loop 类型的四代技术代际谱系（微观骨架，与本文宏观骨架正交互补）
- 本系列 Truefoundry 深读：企业级 loop runtime、治理、多租户（补 Tosea 的视角盲区）
- 本系列 cognitive surrender 专题深读：loop engineering 最深的长期风险