# Addy Osmani《Loop Engineering》深读：五积木、一记忆与三条债

> 来源：Addy Osmani《Loop Engineering》，2026 年 6 月 7 日发布于 addyosmani.com。这是 loop engineering 话语圈的标杆奠基文，整个领域的「五积木 + 一记忆」心智模型与双产品映射表都出自这里。

## TL;DR

Addy 这篇《Loop Engineering》做了三件事，每一件都是后续所有 loop engineering 文献的地基：

- 把 loop 定义为「带终止条件的递归目标」（a recursive goal），并把它放在 harness 之上一层。loop = harness + 定时器 + 子 agent + 自喂养。
- 提出「五积木 + 一记忆」心智模型：Automations / Worktrees / Skills / Connectors / Sub-agents 五个原语，外加 State 这个常被忽视的脊柱。并用一张表把 Codex app 与 Claude Code 两个产品对每个原语逐一映射，证明「loop 的形状跨工具趋同」。
- 带着少见的怀疑论，命名三条人因张力：orchestration tax（编排税）、comprehension debt（理解债）、cognitive surrender（认知退让）。同一个 loop，懂的人加速，不懂的人加速坠落。

一句话定位：Addy 是把 Cherny、Steinberger 的口号落成可执行积木，并第一个画出怀疑论与成本纪律的人。后续 cobusgreyling 仓库的 6 原语、Anthropic 的成熟度分级，都建立在这张表之上。

## 这篇为何值得单独深读

在 loop engineering 这个话题里，大多数文章要么把它讲成「agent 自动跑起来」的营销稿，要么把它讲成一份工具评测。Addy 这篇之所以是标杆，原因有四：

第一，它是「五积木 + 一记忆」这个心智结构的发明源头。后续被反复引用的六原语（schedule / isolation / skills / connectors / verifier / STATE），骨架就来自这张表。读二手转述永远比读原表损失细节。

第二，它是唯一一篇用一张表证明「loop shape 跨工具趋同」的源。Addy 把 Codex app 和 Claude Code 对同一个原语的不同实现摆在一起，结论是「名字略有不同，能力是同一件事」。这个判断把 loop engineering 从「工具评测」升级成了「方法论」——你设计的应该是跨工具成立的 loop，而不是绑死在某个工具上的脚本。

第三，作者自带怀疑与成本限定。Addy 在定义文里就写「I'm skeptical」（我是怀疑的）和「you absolutely have to be careful about token costs」（你必须警惕 token 成本）。这种自我降温在 hype 文里几乎看不到。他没有把 loop 卖成银弹，反而明确指出它的可行性取决于你的 token 预算——「token rich 还是 token poor」会带来 wildly（剧烈）不同的使用模式。

第四，它提供了别处没有的人因维度。orchestration tax、comprehension debt、cognitive surrender 这三个概念是 Addy 原创，其他源至多只复述 cognitive surrender 一个。这三条是「为什么 loop 不是免费午餐」的最佳弹药，也是这篇文章区别于另外十篇源的核心。

一句话独特性：**Addy 是把 Cherny/Steinberger 的口号落成可执行积木、并第一个画出怀疑论与成本纪律的人。**

## 心智模型：先理解 loop 是个什么形状的东西

在拆积木之前，先建立一个可以讲给别人听的类比。这一节用费曼式的方式把 loop engineering 从黑盒拆成你能指着说「就是它」的东西。

### 类比一：从「你亲自按电钻」到「你设计一台会按电钻的机器」

Addy 的开场白是整个话题里最干净的一句定义：

> Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
> 循环工程就是把你这个「亲自 prompt agent 的人」替换掉，改为设计一个替你 prompt 的系统。

这句话的价值不在修辞，在于它点明了工作内容的转移。过去两年，开发者是人手握 agent、一轮一轮敲 prompt；loop engineering 把这件事定位为那个时代的终结。你不再是那个按电钻的人，你设计一台会按电钻的机器。你的产出从「一段段 prompt」变成了「一台能自己跑的机器」。

这个转移听起来像解放，但 Addy 立刻补了三个限定：① 这仍然是早期（it's still early）；② 他自己是怀疑的（I'm skeptical）；③ 必须警惕 token 成本。这三个限定是这篇文章最被低估的价值——他没有像后续许多转述文那样把 loop engineering 卖成银弹。

### 类比二：harness 是脚手架，loop 是脚手架加调度

Addy 在本文之前已经写过「agent harness engineering」（单次运行的脚手架）。本文明确画出层级关系：

> Loop engineering sits one floor above the harness... it runs on a timer, it spawns little helpers, and it feeds itself.
> 循环工程坐在 harness 的上一层。它跑在定时器上，会生出小帮手，还会自己喂养自己。

把这句话翻译成可操作的判断：

- harness = 一次运行的环境。它管的是「这一次 agent 启动时，它的上下文、工具、权限边界长什么样」。
- loop = harness + 定时器 + 子 agent + 自喂养。它在 harness 之上加了三个东西：① 时间维度的调度（按 cadence 跑或按 condition 跑）；② 任务分解（spawns little helpers）；③ 状态自更新（feeds itself，把上一轮的产出喂给下一轮）。

这是共识框架「context → harness → loop」三层模型的直接来源。context engineering 解决「单点上下文怎么写」；harness engineering 解决「一次运行的脚手架怎么搭」；loop engineering 解决「怎么在时间维度上调度 harness」。

### 类比三：loop 是「带终止条件的递归目标」，不是定时任务

这是最容易被误解的一点。Addy 明确把 loop 定义为：

> A loop here can be thought of a recursive goal where you define a purpose and the AI iterates until complete.
> 这里的 loop 可以理解为一个递归目标：你定义一个目的，AI 反复迭代直到完成。

这句话把 loop 从「定时任务」提升为「带终止条件的递归目标」。后续 6 原语里 `/goal`（直到条件为真才停）和 `/loop`（按节奏跑）之分，源头就在这里。一个定时任务没有「完成」的概念，它只会按点触发；而一个递归目标有终止条件，它会自己判断什么时候算完。这个区分决定了 loop 是成本线性倍增的（cadence 跑），还是条件收敛的（condition 跑），后面会展开。

### 把这三个类比拼起来

现在你可以指着任何一个 loop 说出它的三个层次：

1. 它跑在什么 harness 上？（单次环境）
2. 它是 cadence 驱动还是 condition 驱动？（调度方式）
3. 它的 STATE 写在哪里、怎么喂给下一轮？（自喂养机制）

这三个问题答得上来，你就理解了 loop 的形状。接下来拆 Addy 给出的六个积木。

## 详细机制：五积木逐个拆

Addy 把一个完整 loop 拆成五个原语加一个记忆。这一节逐个拆开，每个积木说三件事：它是什么、它解决什么问题、它的人因或成本边界在哪。

### 积木一：Automations（按计划自己跑，做发现 + 分诊）

Addy 的原话：

> Automations go off on a schedule and do discovery and triage by themselves.
> Automations 按计划自己跑，做发现 + 分诊。

这是 loop 的时间触发器。它对应共识框架里的 schedule / cron 原语。Automations 不是「跑一次就完」，它是「每天早上 9 点跑、每小时跑、每次 push 跑」这种 cadence。

它的典型工作是发现 + 分诊（discovery + triage）：扫昨天的 CI 失败、看新开的 issue、读最近的 commit，然后把发现写进一个文件或看板。它不负责修复，只负责把「值得做的事」挑出来。

注意 Automations 本身不等于 loop。它是 loop 的触发器和入口，loop 的其他积木（worktree、sub-agent、connectors）才是真正干活的部分。把 Automations 等同于 loop 是最常见的误解。

### 积木二：Worktrees（让两个并行 agent 互不踩脚）

Addy 的原话：

> Worktrees so two agents working in parallel don't step on each other.
> Worktrees 让两个并行 agent 互不踩脚。

这对应 isolation 原语。两个 agent 同时改同一个仓库会撞车，worktree 给每个 agent 一个隔离的工作副本，互不干扰。

但 Addy 在这里给出了全文最被低估的一条人因洞察，叫 orchestration tax（编排税）：

> The worktrees take away the mechanical collision but YOU are still the ceiling, your review bandwidth decides how many you can actually run, not the tool.
> Worktree 消除了机械碰撞，但你才是天花板。你能并行几个 agent，取决于你的 review 带宽，不是工具。

这句话打掉了一个流行幻觉——「开 N 个 worktree 就能并行 N 个 agent」。工具能给你开 N 个隔离副本，但它不能给你 N 份 review 带宽。每个 agent 跑完都要你 review，你的 review 速度才是真正的并行度上限。这就是 orchestration tax：并行的成本不在 token，在你这个人。

这条洞察后续文很少复述，却是「孤立并行 ≠ 无限并行」的关键张力。后面「三条债」一节会展开。

### 积木三：Skills（把 agent 本来会瞎猜的项目知识写下来）

Addy 的原话：

> Skills to write down the project knowledge the agent would otherwise just guess.
> Skills 把 agent 本来会瞎猜的项目知识写下来。

这对应 SKILL.md 原语。Skill 是「外部化的意图」。Addy 给了一个关键的复合效应判断：

> A skill is that intent written down on the outside... Without skills the loop re-derives your whole project from zero every cycle, with skills it kind of compounds.
> Skill 是写在项目外部的意图。没有 skill，loop 每一轮都从零重新推导你的整个项目；有 skill，它才开始复利。

这句话连接到 Addy 另一篇里的概念——intent debt（意图债）。agent 每次启动都是冷的，它会用自信的猜测填满你意图里的空洞。skill 就是把这些猜测变成显式声明。没有 skill，loop 每一轮都在付一笔「重新理解项目」的税；有 skill，这笔税只付一次，之后每一轮都在复用。

skill 的调用方式在两个产品里略有不同：Codex 里用 `$name` 显式调用或隐式触发；Claude Code 里通过 `SKILL.md` 加载。但本质都是同一件事——把项目知识从「agent 的猜测」变成「你写下来的事实」。

### 积木四：Plugins and Connectors（把 agent 接进你已有的工具）

Addy 的原话：

> Plugins and connectors to plug the agent into the tools you already use.
> Plugins 和 connectors 把 agent 接进你已有的工具。

这对应 MCP connectors 原语。connector 干的事很具体：让 loop 能开 PR、能在 CI 绿的时候 ping Slack、能更新 Linear ticket、能读 GitHub issue。没有 connector，loop 只能在仓库内部活动；有 connector，loop 才能和你真实的工作流接上。

Addy 给出的具体动作清单是「open the PR, ping Slack when CI green」——这些不是抽象描述，是 connector 的实际工作面。connector 是 loop 从「仓库内闭环」升级到「跨系统闭环」的那块积木。

### 积木五：Sub-agents（一个出主意，另一个检查）

Addy 的原话：

> Sub-agents so one of them has the idea and a different one checks it.
> Sub-agents 让一个出主意，另一个检查。

这对应 verifier / maker-checker 原语。这是 Addy 全文最干净的一句 maker/checker 表述：

> The agent that wrote the code isn't the one grading it.
> 写代码的 agent 不是给代码打分的那个。

maker/checker 分离是 loop 能无人值守的前提。如果写代码和验收代码是同一个 agent，它会有强烈的自我证实倾向——它会倾向于认为自己写的是对的。把验收交给另一个 agent（最好换一个模型、换一套指令），才能打破这个倾向。

Addy 还给出了「不同子 agent 用不同模型 / 不同力度」的具体写法：

> Your security reviewer can be a strong model on high effort while your explorer is some fast read-only thing.
> 你的安全审查 agent 可以是高强度运行的强模型，而你的探索 agent 可以是某个快速只读的弱模型。

这是 maker/checker 在工程上的落点：不是所有子 agent 都用最贵的模型。探索用快模型，审查用强模型，分诊用中等模型，这样成本和质量的分配才合理。

### 第六个积木：State（常被忽视的脊柱）

Addy 把前五个叫「五个积木」，但他特别强调第六个常被忽视：

> A markdown file, or a Linear board, anything that lives outside the single conversation and holds what's done and what is next.
> 一个 markdown 文件，或一个 Linear 看板，任何活在单次对话之外、记录已完成和下一步的东西。

> Sounds too dumb to matter. But it's the same trick every long running agent depends on.
> 听起来蠢到不值得提。但每个长跑 agent 都靠它。

这对应 STATE 原语。Addy 给了它一个被共识框架直接沿用的称呼：

> The state file is the spine of the whole thing.
> 状态文件是整个系统的脊柱。

为什么 STATE 是脊柱而不是附件？因为 agent 是健忘的。每一轮 agent 启动都是冷的，它不知道上一轮做了什么、还剩什么没做、哪些路走过不通。STATE 就是把这个记忆外化到对话之外的地方——一个 markdown 文件、一个 Linear 看板、一个数据库。Addy 用一句话点透：

> The agent forgets, the repo doesn't.
> agent 会忘，仓库不会。

这句话是 STATE 原语的精炼。仓库本身就是最可靠的记忆，因为它不会随对话消失。把 STATE 写进仓库（或写进与仓库同步的看板），loop 才能跨轮次累积，而不是每一轮都从零开始。

STATE 常被忽视的原因是它「听起来太简单」。一个 markdown 文件能有多重要？但 Addy 反复强调，这正是长跑 agent 的命门。没有 STATE，loop 只是一个会被遗忘的定时任务；有 STATE，loop 才是一个有记忆的递归系统。

## 详细机制：双产品映射表（全文最被引用的资产）

这一节是这篇文章区别于其他所有源的核心资产。Addy 用一张表把 Codex app 和 Claude Code 两个产品对每个原语的实现摆在一起。这张表是「loop shape 跨工具一致」这一判断的实证基础。

### 原始映射表（ cite 原表）

| 原语 | 在 loop 里的职责 | Codex app | Claude Code |
| --- | --- | --- | --- |
| Automations | 按计划做发现 + 分诊 | Automations 标签页：选 project、prompt、cadence、environment；结果进 Triage 收件箱；`/goal` 跑到完成 | Scheduled tasks 和 cron、`/loop`、`/goal`、hooks、GitHub Actions |
| Worktrees | 隔离并行特性 | 每个线程内建 worktree | `git worktree`、`--worktree`、subagent 上的 `isolation: worktree` |
| Skills | 编码项目知识 | Agent Skills（`SKILL.md`），用 `$name` 或隐式调用 | Agent Skills（`SKILL.md`） |
| Plugins / connectors | 接入你的工具 | Connectors（MCP）加 plugins 用于分发 | MCP servers 加 plugins |
| Sub-agents | 出主意和验证 | 在 `.codex/agents/` 下以 TOML 定义 subagent | `.claude/agents/` 下的 Task subagents、agent teams |
| State | 跟踪已完成 | Markdown 或通过 connector 接 Linear | Markdown（`AGENTS.md`、progress 文件）或通过 MCP 接 Linear |

### Addy 对这张表的评论

Addy 紧跟着这张表给了一句被反复引用的判断：

> The names are a bit different here and there but the capability is the same thing... once you notice the shape is the same you stop arguing about which tool, you just design a loop that still works no matter which one you happen to be sitting in.
> 名字略有不同，能力是同一件事。一旦你注意到形状是一样的，你就不再纠结选哪个工具，你只设计一个无论坐在哪个工具里都能跑的 loop。

这句话是 loop engineering 从「工具评测」升级为「方法论」的转折点。它把读者的注意力从「Codex 好还是 Claude Code 好」转移到「我设计的 loop 形状对不对」。形状对了，换工具只是换实现细节；形状错了，用哪个工具都救不回来。

### 两个产品的具体功能对照

为了让这张表不停留在抽象层面，下面把两个产品在每个原语上的具体形态再展开一层。

**Codex app 侧：**

- Automations 标签页：选 project、prompt、cadence、environment 四件事。有发现的进 Triage 收件箱，没发现的自动归档。OpenAI 内部用它跑 daily issue triage、CI 失败总结、commit briefing、上周引入的 bug 猎杀。
- Subagent 定义：`.codex/agents/` 目录下的 TOML 文件，每个有 name、description、instructions，可选 model 和 reasoning effort。这就是「不同子 agent 用不同模型 / 不同力度」的工程写法——安全审查 agent 可以是 high effort 的强模型，探索 agent 可以是快速的只读弱模型。

**Claude Code 侧：**

- Scheduled tasks 和 cron：对应 Automations 的 cadence 触发。
- `/loop` 和 `/goal`：这是区分 cadence 和 condition 的两个原语。`/loop` 按 cadence 重跑，`/goal` 跑到你写的条件为真。`/goal` 内部就是 maker/checker——Addy 的原话是「a fresh model decides if the loop is done instead of the one that did the work」（一个全新的模型决定 loop 是否完成，而不是干活那个）。
- Subagent：`.claude/agents/` 目录加 agent teams。
- Worktree：`git worktree`、`--worktree` 标志、subagent 上的 `isolation: worktree` 参数。

### `/loop` vs `/goal`：区分 cadence 和 condition 的关键

这两个原语值得单独展开，因为它们是成本结构的分水岭。Addy 的原话：

> `/loop` re-runs on a cadence. `/goal` keeps going until a condition you wrote is actually true, and after every turn a separate small model checks whether you are done, so the agent that wrote the code isn't the one grading it.

这句话同时定义了三件事：

1. **cadence 驱动（`/loop`）**：按节奏重跑。成本是线性倍增的——每小时跑一次，一天 24 次的 token。它的好处是可预测，坏处是即使没活干也在烧 token。
2. **condition 驱动（`/goal`）**：跑到条件为真才停。成本是收敛的——条件满足就停。它的好处是省 token，坏处是条件写错了会跑飞或者永远停不下来。
3. **maker/checker 内建于 `/goal`**：每一轮之后，一个独立的小模型检查是否完成。这就是「写代码的 agent 不是打分的 agent」这句原话的出处。

`/loop` 适合做「持续的发现 + 分诊」（每天扫一遍 issue、每小时看一次 CI）；`/goal` 适合做「收敛到一个具体结果」（修掉这个 bug、把这个特性实现到测试通过）。两者经常配合：一个 `/loop` 负责 discovery，发现值得做的事之后再起一个 `/goal` 去收敛。

## 详细机制：一个完整 loop 长什么样

抽象地讲完六个积木，Addy 给了一个非常具体的 loop 形态描述。这一段是「loop 长什么样」最完整的叙事，可以直接当作设计模板。原文（ cite 整段）：

> An automation runs every morning on the repo. Its prompt calls a triage skill that reads yesterday's CI failures, the open issues, the recent commits, and writes the findings into a markdown file or a Linear board. For each finding that is worth doing the thread opens an isolated worktree and sends a sub-agent to draft the fix, and a second sub-agent reviews that draft against the project skills and the existing tests. Connectors let the loop open the PR and update the ticket. Anything the loop can not handle lands in the triage inbox for me. The state file is the spine of the whole thing.

把这段拆成结构化的步骤：

1. **Automations（schedule）**：每天早上跑一次。
2. **Skill（知识）**：调用 triage skill，读昨天的 CI 失败、open issue、最近 commit。
3. **State（脊柱）**：把发现写进 markdown 或 Linear。
4. **Worktree（isolation）**：每个值得做的发现开一个隔离 worktree。
5. **Sub-agent 起草**：第一个 sub-agent 写修复草稿。
6. **Sub-agent 验证（maker/checker）**：第二个 sub-agent 对照项目 skill 和现有测试审查草稿。
7. **Connectors（MCP）**：让 loop 开 PR、更新 ticket。
8. **兜底**：loop 处理不了的进 triage 收件箱，等人处理。
9. **State 是脊柱**：整个流程的状态都记在 state 文件里。

这就是六个原语一次跑通的完整范例。你可以拿这个模板对照自己的 loop：你的 loop 有没有 schedule？有没有 skill？有没有 isolation？有没有 maker/checker？有没有 connector？有没有 STATE？缺哪一块，那一块就是你的瓶颈。

## 详细机制：三条债逐条拆

这是这篇文章区别于其他源的核心部分。Addy 在定义 loop 的同时，命名了三条人因张力。这三条债不是 bug，是 loop 工作方式的系统性后果。把它们讲清楚，是理解「为什么 loop 不是免费午餐」的关键。

### 债一：orchestration tax（编排税）——你的 review 带宽是隐藏天花板

这条债已经在 worktree 积木里提过，这里展开它的系统性含义。

Addy 的原话：

> The worktrees take away the mechanical collision but YOU are still the ceiling, your review bandwidth decides how many you can actually run, not the tool.

这句话的杀伤力在于它打掉了「并行度 = worktree 数量」的幻觉。工具可以给你开 20 个 worktree，但你一天能 review 几个 PR？这个数字才是你真正的并行上限。

orchestration tax 的本质是：loop 把生成成本压低了（token 便宜），但把判断成本集中在人身上（review 贵）。生成可以无限扩展，判断不能。这就是为什么「多 worktree 并行」在演示里很美，在生产里经常撞墙——撞的不是工具的墙，是你这个人的墙。

这条债的对策不是「提高 review 速度」（人的带宽是有上限的），而是「调整 loop 的并行度，让它和你的 review 带宽匹配」。一个健康的 loop 不是并行度越高越好，是并行度刚好让你的 review 跟得上。超过这个点，多开的 worktree 只是在堆积 comprehension debt（见下一条）。

### 债二：comprehension debt（理解债）——loop 越顺滑，你和代码库的鸿沟越大

Addy 的原话：

> The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually get. That's comprehension debt and a smooth loop just makes it grow faster unless you read what the loop made.
> loop 越快地交付你没写过的代码，「代码库里实际存在的东西」和「你真正理解的东西」之间的鸿沟就越大。这就是理解债。一个顺滑的 loop 只会让这个债涨得更快，除非你主动读 loop 生成的东西。

这条债是对「loop 自动化 = 解放」叙事的直接对冲。loop 不是在替你写代码，是在替你产生你不理解的代码。每一行你没读过的代码，都是一笔欠款。loop 跑得越快，欠款涨得越快。

理解债的危险在于它是隐性的。代码在仓库里，测试在跑，CI 在绿，看起来一切正常。但你不知道这些代码为什么这么写、边界条件是什么、在什么情况下会崩。当下一次需要改这些代码的时候，你面对的不是自己写的代码，而是一堆你需要重新理解的外星产物。

Addy 给的对策很简单也很硬性：「unless you read what the loop made」（除非你读 loop 生成的东西）。这不是可选的卫生习惯，是还债的唯一方式。如果你不读，债会复利增长，直到某一天你面对一个自己完全无法维护的代码库。

这条债和 orchestration tax 是耦合的：review 带宽决定了你能还多少理解债。所以 loop 的健康度不取决于它跑多快，取决于「生成速度 / review 速度」这个比值是不是大于 1。大于 1，你在欠债；小于 1，你在积累理解。

### 债三：cognitive surrender（认知退让）——舒适姿态就是危险姿态

这是三条债里最被频繁引用的一条，也是 Addy 全文最锋利的一段。原话（ cite 整段）：

> When the loop runs itself it's very tempting to stop having an opinion and just take whatever it gives back. I called that cognitive surrender. Designing the loop is the cure when you do it with judgement and the accelerant when you do it to avoid thinking, same action, opposite result.
> 当 loop 自己跑起来，停止持有自己的观点、直接收下它给的东西，是非常诱人的。我把这叫做认知退让。带着判断力去设计 loop 是解药，为了逃避思考去设计 loop 是加速器。同一个动作，相反的结果。

关键的措辞是「same action, opposite result」（同一个动作，相反的结果）。设计 loop 这个动作本身是中性的——它既可以是主动的认知投入（你把自己的判断写进 skill、写进 condition、写进 STATE），也可以是被动的认知撤退（你把决策权整个交给 loop，自己不再思考）。loop 本身分不清这两种情况。

Addy 在结尾给了一个更锐利的版本（ cite 整段）：

> Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn't know the difference. You do.
> 两个人可以搭出完全一样的 loop，得到完全相反的结果。一个人用它加速自己深刻理解的工作。另一个人用它逃避理解工作。loop 不知道区别。你知道。

这句话是 cognitive surrender 的哲学收尾。loop 不改变工作的难度，它只移动杠杆点（leverage point）。懂的人借这个杠杆点放大自己的理解；不懂的人借这个杠杆点放大自己的无知。结果是相反的，但 loop 看不出区别。

cognitive surrender 之所以是三条债里最危险的一条，因为它不可被系统检测。orchestration tax 会以 review 积压的形式显形；comprehension debt 会以维护困难的形式显形；但 cognitive surrender 不会显形——它会以「一切看起来都很顺」的形式隐藏。你以为自己在用 loop 加速，实际在用 loop 逃避，而没有任何指标会告诉你这一点。唯一的检测方式是诚实的自我审视：我是在把自己的判断写进 loop，还是在把判断权整个交给 loop？

## 详细机制：loop 仍然不会替你做的事

除了三条债，Addy 还明确列出了 loop 不会自动解决的边界。这一节是对 L3（完全无人值守）乐观叙事的对冲。

### 边界一：verification 仍然是你的事

Addy 的原话：

> A loop running unattended is also a loop making mistakes unattended.
> 无人值守的 loop 也是无人值守地犯错。

> 'done' is a claim and not a proof.
> 「完成」是一个声明，不是一个证明。

这两句话点透了 maker/checker 的局限。maker/checker 能让验收更可靠（写代码的不是打分的那个），但它不能保证「完成」是真的完成。「完成」只是 loop 自己声明的一个状态，不是客观证明。最终确认代码真的能跑、真的解决问题，仍然是人的事。

这条边界直接关系到 L2 到 L3 的跨越。maker/checker 分离是 L3 的准入条件（没有它你连走开都不敢），但即使有了 maker/checker，L3 也不是「完全放手」——它是「可以走开，但回来之后仍然要确认」。把 L3 理解成「完全不用管」是最危险的误解。

### 边界二：token 成本会剧烈分化

Addy 在开头就强调：

> It's still early, I'm skeptical and you absolutely have to be careful about token costs (usage patterns can vary wildly if you are token rich or token poor).

这句话和其他源默认「人人都能跑 unattended loop」形成张力。Addy 明确指出 loop 的可行性依赖你的 token 预算。token rich（预算充足）的人可以跑高频 cadence、跑多个并行 worktree、用强模型做审查；token poor（预算紧张）的人只能跑低频 cadence、串行处理、用便宜模型。这两种使用模式是 wildly（剧烈）不同的，跑出来的 loop 也是两种东西。

这条边界经常被忽略，但它决定了 loop engineering 不是普适的。一个小团队和一个大团队跑同样的 loop，成本结构完全不同。设计 loop 的时候，必须先问「我的 token 预算允许我跑多频繁、并行多少、用什么模型」，而不是直接抄别人的 loop 形态。

### 边界三：直接 prompt 仍然有效

Addy 在结尾给了一个容易被忽略的让步：

> Don't forget that prompting your agents directly is also effective. It's all about finding the right balance.
> 不要忘了直接 prompt 你的 agent 也是有效的。关键是找到对的平衡。

这句话的意义在于：定义 loop engineering 的人没有宣布 prompt engineering 死亡。loop 不是 prompt 的替代品，是 prompt 在时间维度上的扩展。有些任务适合一轮 prompt 解决（一次性、明确、不需要累积），有些任务适合 loop 解决（持续、需要状态、需要收敛）。把所有任务都塞进 loop，和把所有任务都用一轮 prompt 解决，都是错的。

这个让步让 Addy 的文章不像 hype。他没有为了推销 loop 而否定 prompt，而是把两者放在一个谱系上：prompt 是 loop 的退化形式，loop 是 prompt 在时间维度上的推广。选哪个，取决于任务的形状。

## 详细机制：杠杆点判断

最后一条机制层面的内容，是 Addy 全文的哲学收尾。他引用 Cherny 的判断，然后给出自己的解读（ cite 整段）：

> Cherny's point isn't that the work got easier. It's that the leverage point moved. That's what makes loop design harder than prompt engineering, not easier.
> Cherny 的观点不是工作变简单了，是杠杆点移动了。这正是 loop 设计比 prompt 工程更难的原因，不是更容易。

这句话和「same action, opposite result」是同一个意思的两个面向。杠杆点移动意味着：过去你的产出和你的劳动时间成正比（一小时 prompt 一小时产出）；现在你的产出和你的判断质量成正比（一个好的 loop 设计可以无限跑，一个坏的 loop 设计也可以无限跑——但方向相反）。

这就是为什么 loop 设计比 prompt 工程更难。prompt 工程的反馈是即时的——这一轮 prompt 不好，下一轮马上能看到。loop 设计的反馈是延迟的——一个设计错误的 loop 可能在跑了一周之后才暴露问题，而这时候它已经产生了一堆你不理解的代码。判断的杠杆被放大了，但错误的杠杆也被放大了。

## 真实案例

这一节把上面所有抽象机制落到两个具体场景里，让你能指着说「这就是 loop 在真实工作里的样子」。

### 案例一：OpenAI 内部的 daily issue triage

Addy 在介绍 Codex Automations 时提到，OpenAI 内部用它跑四种日常 loop：

- daily issue triage（每天扫一遍 issue，分诊哪些值得做）
- CI 失败总结（CI 挂了之后自动总结失败原因）
- commit briefing（每天早上把昨天的 commit 汇总成简报）
- 上周引入的 bug 猎杀（扫上周的 commit，找可能引入的 bug）

这四种 loop 的共同点：都是 discovery + triage 类型，都是 cadence 驱动，都不做修复只做发现。它们是 Automations 积木最典型的用法——loop 不是替你修 bug，是替你把「哪些 bug 值得修」挑出来。修复仍然由人或更专门的 loop 来做。

这个案例的价值在于它展示了 loop 的保守用法：先让 loop 做信息收集和分诊，把判断权留给人。这是 L1（只报告）到 L2（自动执行但要人确认）之间的健康起点。不要一上来就追求 L3（完全无人值守），那会让三条债同时爆发。

### 案例二：Addy 自述的完整 morning loop

就是前面「一个完整 loop 长什么样」那一节引用的那段。这里再从案例角度复述一遍，强调它作为模板的价值：

每天早上，一个 automation 在仓库上跑起来。它的 prompt 调用一个 triage skill，这个 skill 读昨天的 CI 失败、open issue、最近 commit，然后把发现写进一个 markdown 文件或 Linear 看板。对每一个值得做的发现，loop 会开一个隔离的 worktree，派一个 sub-agent 起草修复，再派第二个 sub-agent 对照项目 skill 和现有测试审查草稿。connector 让 loop 开 PR、更新 ticket。loop 处理不了的，进 triage 收件箱等人处理。state 文件是整个流程的脊柱。

这个案例之所以重要，是因为它把六个原语串成了一个端到端的工作流。你可以拿它当 checklist，逐项检查自己的 loop：你有没有 triage skill？你有没有 maker/checker？你有没有 connector 让 loop 自己开 PR？你的 state 写在哪里？每一项的缺位，都是一个明确的改进点。

### 案例三：两条创世引语

最后，Addy 在文里引用了整个 loop engineering 话语圈最常被转述的两句话。这两句话是 loop engineering 从「少数人的实践」变成「一个领域」的起点，必须精确引用：

- Peter Steinberger（PSPDFKit 创始人）：「You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.」（你不应该再亲自 prompt 编程 agent 了。你应该设计 prompt agent 的 loop。）
- Boris Cherny（Anthropic Claude Code 负责人）：「I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.」（我不再 prompt Claude 了。我有 loop 在跑，它们 prompt Claude、自己想该做什么。我的工作是写 loop。）

这两句话之所以重要，不是因为它们说得对，而是因为它们出自两个有公信力的人（一个是独立开发者社区的标杆，一个是 Claude Code 的负责人）。它们把「loop engineering」这个原本只在少数实践者之间的做法，命名成了一个领域。Addy 是第一个把这两句话和「五积木」拼在一起的人——这个拼接动作让 loop engineering 从口号变成了方法论。

## 权衡与局限

这一节把 Addy 文章里和隐含的局限性收拢，给你一个「什么时候不该照搬」的判断。

### 局限一：这是 2026 年 6 月的快照

Addy 自己说「it's still early」（还很早）。这篇文章发布于 2026 年 6 月 7 日，里面的产品功能（Codex Automations 标签页、Claude Code 的 `/goal`）都是当时的形态。两个月或半年之后，这些功能可能已经变了。但五积木 + 一记忆的形状、三条债的判断，是抽象层面的，不会随产品功能变化而过时。读这篇文章的时候，把产品细节当作 2026 年 6 月的快照，把心智模型当作长期成立的骨架。

### 局限二：token 成本决定了这不是普适方案

Addy 反复强调 token rich / token poor 的分化。一个 token poor 的个人开发者，很难照搬 OpenAI 内部那种 daily issue triage + CI 总结 + commit briefing + bug 猎杀的四路 loop。对个人开发者来说，更现实的起点是：一个低频 cadence 的 discovery loop（比如每天跑一次），加一个手动触发的 `/goal` 做收敛。先把成本压到能承受，再谈扩展。

### 局限三：没有显式的 L0-L3 成熟度分级

Addy 这篇文章没有显式给出 L0-L3 的成熟度分级（这是 cobusgreyling 仓库和 Anthropic PDF 后来的贡献）。但他给出了两个关键的成熟度判断：

- 「a loop running unattended is also a loop making mistakes unattended」——这是 L3 的核心风险定义。
- maker/checker 分离是「the only reason you can walk away」（你能走开的唯一原因）——这是从 L2 跨到 L3 的前提。

读 Addy 这篇时，可以把这两条当作 L3 准入条件的原始表述。他没有画分级表，但他划了线：没有 maker/checker，就不要谈 L3；即使有 maker/checker，L3 也不是「完全放手」。

### 局限四：怀疑论本身也可能被过度引用

Addy 的怀疑论是这篇文章的价值，但也有一个反向风险——它可能被过度引用成「loop engineering 不成熟，等等再说」。Addy 自己的立场不是「不要用」，而是「带着怀疑用，同时警惕三条债」。把他的怀疑论当成拖延的理由，和把别人的 hype 当成冲锋的号角，是同样错误的两个方向。Addy 在结尾明确说「find the right balance」（找到对的平衡），这个平衡点是动手试，不是袖手旁观。

## 落地建议

基于 Addy 的框架，下面是给中级读者的几条可操作建议。

### 建议一：先从六个积木的 checklist 开始

不要一上来就设计一个完整 loop。先拿六个积木当 checklist，逐项检查你现有工作流的缺口：

- 你有没有 schedule？（每天/每小时/每次 push 触发什么？）
- 你有没有 isolation？（多任务并行时怎么避免撞车？）
- 你有没有 skill？（项目知识写在哪里？agent 是猜的还是读的？）
- 你有没有 connector？（loop 能不能自己开 PR、更新 ticket？）
- 你有没有 maker/checker？（写代码和验收代码是不是同一个 agent？）
- 你有没有 STATE？（跨轮次的状态写在哪里？）

每一项的缺位都是一个明确的改进点。从最缺的那一项开始补，不要追求一步到位。

### 建议二：先做 L1（只报告），再谈 L2 / L3

Addy 的案例（OpenAI 内部的 daily triage）都是 L1——loop 只做发现和分诊，不自己做修复。这是最健康的起点。在 L1 跑稳之前，不要跳到 L2（自动执行要人确认），更不要跳到 L3（完全无人值守）。L1 的好处是它不产生 comprehension debt——loop 只给你信息，不给你代码，你不需要 review 你没写过的东西。等 L1 的 cadence、skill、state 都跑顺了，再逐步把执行权下放给 L2 / L3。

### 建议三：把 STATE 写进仓库，不要写进对话

Addy 反复强调「the agent forgets, the repo doesn't」。STATE 的最佳位置是仓库内的一个 markdown 文件（Codex 的 `AGENTS.md`、Claude Code 的 progress 文件），而不是对话历史。原因有二：① 仓库是持久的，对话是健忘的；② 仓库可以被 git 追踪，对话不能。把 STATE 写进仓库，你就能看到 loop 每一轮的状态变化历史，这是检测 loop 是否跑飞的最佳手段。

### 建议四：把 review 预算算进 loop 设计

orchestration tax 是隐藏成本。设计 loop 的时候，先问自己：「我一天能 review 几个 PR？」这个数字就是你的并行度上限。loop 的并行度不要超过这个上限，超过的部分就是在堆积 comprehension debt。一个健康的 loop 是并行度匹配 review 带宽的 loop，不是并行度拉满的 loop。

### 建议五：每周期读一遍 loop 生成的东西

这是还 comprehension debt 的唯一方式。每周抽一段时间，把 loop 这一周生成的东西完整读一遍。不读，债就复利增长；读了，债就停止增长。这个动作看似费时，但它比「让 loop 跑飞然后面对一个自己无法维护的代码库」便宜得多。

### 建议六：用 cognitive surrender 做自我审查

每个月问自己一次：「我是在用 loop 加速自己理解的工作，还是在用 loop 逃避理解工作？」loop 不会告诉你答案，只有诚实的自我审视会。如果答案是后者，停下来，把判断权重新拿回手里——把判断写进 skill、写进 condition、写进 STATE，而不是把判断整个交给 loop。

## 延伸阅读

- **Addy Osmani《Loop Engineering》原文**：https://addyosmani.com/blog/loop-engineering/ —— 本文所有引语、表格、案例的来源。英文全文约 4200 词，无 paywall，是 loop engineering 话题的标杆奠基文。
- **Peter Steinberger 关于「design loops, not prompts」的原始表述**：在 Addy 文中首次被系统化引用，是 loop engineering 话语圈的创世引语之一。
- **Boris Cherny（Anthropic Claude Code 负责人）关于「my job is to write loops」的引语**：同样在 Addy 文中首次被系统化引用，和 Steinberger 的引语并列为领域起点。
- **Addy Osmani《agent harness engineering》**（前作）：本文「loop sits one floor above the harness」的参照系。读完本文再读前作，能看清 context → harness → loop 三层模型的完整脉络。
- **cobusgreyling loop engineering 仓库**：在 Addy 这篇之后系统化了 6 原语和 L0-L3 成熟度分级。Addy 的「五积木 + 一记忆」是这个仓库 6 原语的直接前身。
- **本系列其他篇目**：本系列后续文章会在 Addy 这篇的骨架上，分别展开 6 原语、成熟度分级、跨工具映射、风险与成本。Addy 这篇是入口，后续篇目是纵深。