主题
25 - 循环不息：Loop Engineering 导读
2026 年 6 月，Addy Osmani、Anthropic Claude Code 团队与社区几乎同时指向同一件事：别再一句句 prompt agent，去设计替你去 prompt 的系统。 花叔把这套能力写进了 《Loop Engineering 橙皮书》（中英文 PDF 免费，MIT）。
本讲是 Harness 的上一层楼。学完 13-Harness 之后，Loop 是自然延伸；本仓库离线专题见 15-Loop/（6 小课 + Morning triage 毕业项目，持续更新中）。
Loop 是什么
| Harness | Loop | |
|---|---|---|
| 管什么 | 单次 agent 运行 | 让 agent 自己一圈圈跑 |
| 典型问题 | 给哪些工具？什么算干完？ | 定时发现任务、隔离交付、独立验证、写盘记忆、自动调度 |
| 本课程落点 | 13-Harness 五子系统 | 15-Loop + /loop · /goal · worktree |
一句话：你搭一次 loop，然后让它替你去戳 agent。
Stop being the person who prompts the agent. Design the system that does it for you.
四层栈
每往上一层，你离现场越远，错攒得越久——loop 在你睡觉时也会跑，所以 loop 层必须装「能说不」的检查。
┌─────────────────────────────────────────────────────────┐
│ Loop engineering 怎么让它自己一遍遍跑？ │
│ /loop · worktree · /goal · 状态文件 · automations │
├─────────────────────────────────────────────────────────┤
│ Harness engineering 单次运行武装什么？ │
│ 工具 · 权限 · 完成定义 · CLAUDE.md · Hooks │
├─────────────────────────────────────────────────────────┤
│ Context engineering 这一刻窗口里放什么？ │
│ 检索 · 摘要 · 清理 · @ 引用 · Skills 按需加载 │
├─────────────────────────────────────────────────────────┤
│ Prompt engineering 这一次告诉模型什么？ │
│ 用户消息 · 任务描述 · 一次性指令 │
└─────────────────────────────────────────────────────────┘| 层 | 本课程主要章节 |
|---|---|
| Prompt | 对话本身、Command |
| Context | 记忆系统、Skills、渐进式披露 |
| Harness | 13-Harness、Hooks、SubAgents |
| Loop | 本讲 + 15-Loop |
一个循环的五个动作
发现 → 交付 → 验证 → 持久化 → 调度（前四个是「转一圈」，第五个把它变成「循环」）
| 动作 | 干什么 | Morning triage 里的样子 |
|---|---|---|
| 发现 | agent 自己找出这圈该干什么 | Skill 读 CI 失败 / open issue / 最近 commit |
| 交付 | 把任务隔离着交给 agent | 每个发现开一个 worktree |
| 验证 | 换一个 agent 来说「不」 | 第二个子 agent 对照测试审查 |
| 持久化 | 状态写到对话之外 | 开 PR + 收件箱 + 状态文件 |
| 调度 | 让它一圈圈自动转 | 早上 automation / /loop 自动跑 |
六个零件
| 零件 | 对应动作 | Claude Code 落点 |
|---|---|---|
| Automations | 调度 | /loop、Cloud Routines |
| Worktrees | 交付 | --worktree / -w |
| Skills | 发现 | $skill-name，不是贴死的指令墙 |
| Connectors (MCP) | 发现 / 持久化 | 接 CI、Issue、Linear 等 |
| Sub-agents | 验证 | 生成者与评判者分离 |
| Memory | 持久化 | 磁盘上的状态文件（agent 会忘，仓库不会） |
全书最核心洞察：生成器 vs 评判器
写代码的 agent 不能给自己打分——上下文里全是「我为什么这么写」的自我说服。
四步让 loop 长出「说不」的能力：
- 结构上把「写」和「判断」拆成两个 agent（maker-checker）；
- 评判器默认怀疑论者（代码是坏的，除非被证明能跑）；
- 评判器要动手验证（跑测试 / Playwright），不只读 diff；
- 判定「完成」交给没参与干活的 fresh 模型——对应 Claude Code 的
/goal。
Loop 的难点不是把循环搭起来，而是往里面放一个能说「不」的东西。
⚠️ /loop ≠ /goal：/loop 按时间间隔重跑（调度）；/goal 跑到条件满足为止（评判）。
四笔代价（上手前必读）
共同点：不会在循环跑的当下报警。
| 代价 | 症状 | 防御 |
|---|---|---|
| 验证债 | 自动 PR 堆成没人验过的错误 | 独立评判者 |
| 理解腐烂 | 项目地图停在三个月前 | 定期读产出，讲不出就更新地图 |
| 认知投降 | loop 给啥收啥 | 执行可外包，拿主意不行 |
| token 失控 | 空转一整晚，账单爆炸 | 单次/每日预算 + 最大重试，到顶就停 |
第一个 loop：五步 + 六条检查清单
别想一步到位——Stripe 每周 1300 PR 是终点，不是起点。
- 跑一个
/loop，感受定时重跑； - 让它读 CI / issue / commit，做 triage（分诊）；
- 加 状态文件（跨轮记忆在磁盘上）；
- 加 evaluator（
/goal或独立子 agent）——最易被跳过、最关键； - 加 worktree，让它并行。
| 要素 | 问自己 |
|---|---|
| 发现源 | 定时去读什么？ |
| 状态文件 | 跨轮记忆落在哪个文件？ |
| evaluator | 有没有独立的、会说「不」的检查？ |
| 隔离 | 并行 agent 是否各自 worktree？ |
| token 上限 | 预算与重试上限设了吗？ |
| 人工复核点 | 哪一步停下来等你？ |
前两条决定 loop 能不能跑；后四条决定 会不会闯祸。
与橙皮书、本仓库专题对照
| 橙皮书 | 15-Loop 小课 | 状态 |
|---|---|---|
| §01–02 定义与四层栈 | 01-mindset | ✅ 已发布 |
| §03 五动作 | 02-five-moves | 编写中 |
| §04 六零件 | 03-six-parts | 编写中 |
| §05 生成器 vs 评判器 | 04-maker-checker | 编写中 |
| §06–07 案例与代价 | 05-cases-costs | 编写中 |
| §08–09 第一个 loop | 06-first-loop + triage 项目 | 编写中 |
仓库离线跟练：github.com/yuezheng2006/cc-engineering/tree/main/15-Loop
本讲小结
- Loop 是 harness 之上的调度层，不是更好的 prompt。
- 五动作 + 六零件是搭任何 loop 的骨架；maker-checker 是 loop 能否可信的分水岭。
- Stay the engineer：同一个 loop，两个人搭，结果可以截然相反——loop 乘的是你。
- 判断力是 loop 时代唯一稀缺物：循环能生成一百个选项，但它没法替你选。
思考题
- 你现在的 workflow 主要停在四层栈的哪一层？往上走一层，最缺发现源、验证还是调度？
- 若只加一条护栏，你会先加 evaluator 还是 token 上限？为什么？
- Morning triage 里，哪些步骤必须有人工复核点，哪些可以全自动？
建议先修：02 - 记忆系统 · 15 - Hooks · 13-Harness 前四课 · 再跟 15-Loop/01-mindset。