← All Articles

Loop Engineering 完整精读——学懂概念 + 贴身案例 + 上手实践 + 用 Raft 搭 loop

Addy Osmani《Loop Engineering》（英文原文）+ latent.space Loopcraft + Addy 引的 Steinberger/Cherny/Karpathy 三人论述 + 中文实践文 + web 检索补充 · 2026-06-14 · Original

受众：Justin（红杉中国 MD，重度 AI 用户） 目的：学懂这个概念 + 看贴近自己的案例 + 能自己上手 + 怎么用 Raft 实现 loop 来源：Addy Osmani《Loop Engineering》（英文原文）+ latent.space Loopcraft + Addy 引的 Steinberger/Cherny/Karpathy 三人论述 + 中文实践文 + web 检索补充 Raft 实现部分：鹰眼从工程可行性做了交叉验证（见第五节）

一、一句话讲懂这个概念

Loop Engineering（循环工程）= 把”你”从那个不停给 agent 发指令的人的位置上撤掉，改成设计一套系统，让系统自己去给 agent 发指令。

过去两年用 AI 的方式：你写个好 prompt → 读它返回什么 → 再写下一个 prompt。Agent 是工具，你全程握着它，一轮接一轮。这种方式正在结束。

新方式：你搭一个小系统——它自己找活、派活、检查、记下做完了什么、再决定下一步——然后让这个系统去戳 agent，而不是你。

三个人的原话点透： - Boris Cherny（Anthropic Claude Code 负责人）：“我不再给 Claude 写 prompt 了。我有循环在跑，循环来给 Claude 发指令、决定做什么。我的工作是写循环。” - Peter Steinberger：“你不该再给 coding agent 写 prompt 了。你该设计循环，让循环来给 agent 写 prompt。” - Andrej Karpathy（讲自动研究）：“要把工具用到极致，你得把自己从瓶颈位置上拿掉……我不想当那个守在循环里看结果的研究员，我在拖系统后腿。问题变成：怎么重构所有抽象层，让我不必在场——安排一次，按下开始。”

核心转变一句话：human-in-the-loop（人在循环里一次次发指令）→ human-on-the-loop（人设计循环，退到循环外，只在关键节点介入）。你的角色从”操作者”变成”循环的设计者和所有者”。

二、概念分层：loop 到底站在哪一层

Addy Osmani 把谱系讲得很清楚（他之前写过 harness engineering）。AI 编程能力是一层层叠上来的：

层级 解决的问题 关键技术 你的角色
Prompt 层 怎么问 角色设定、输出格式、few-shot 指令下达者
Context 层 让 AI 看到什么 RAG、记忆管理、代码解析 环境配置者
Harness 层 AI 在哪工作 工具调用、沙箱、权限 环境搭建者
Loop 层 做完一步后怎么办 自动检查、修正、停止条件 规则与系统制定者

Osmani 原话：“Loop engineering 坐在 harness 上面一层。是 harness，但它按定时器跑、自己生小 helper、自己喂自己。”

Loop 层站在最顶端——它不关心单次对话的质量，只关心整个系统的自运行能力。

中文实践圈把它叫”AI 编程第三次革命”：1.0 Prompt 时代（解决基础代码生成）→ 2.0 Context+Harness 时代（解决复杂业务逻辑，能完成 80% 工作量）→ 3.0 Loop 时代（砍掉人工验证那剩下的 20%：测试、纠错、上线）。

三、最核心的工程原则：状态必须外置（这是 loop 成败的命门）

这是两篇英文 + 中文实践文都反复强调、也最反直觉的一条：

别信任大模型的上下文窗口。

原理：模型在超长对话里会遗忘、会幻觉。所以企业级最佳实践是——把大模型当 CPU（只负责计算和推理），把外部系统（Git / Markdown / 数据库 / 任务板）当硬盘（负责持久化记忆）。

Osmani 原话：“the agent forgets, the repo doesn’t（agent 会忘，但仓库不会）。”

具体做法：每个 loop 迭代都开一个全新的上下文窗口，通过读取外部的 STATE.md（或 Linear 板、任务板）来获取进度，而不是靠对话历史记住。

最经典的例子是 Ralph Loop——一行 bash 封神：

while :; do cat PROMPT.md | claude-code; done

每次循环重新读取文件和代码库、彻底忽略历史对话，暴力但完美地解决了上下文污染。

这条对你最重要的迁移意义：任何你想做的 loop（不只是写代码），第一件事是想清楚”状态存在哪个外部文件/系统里”，而不是指望模型记住。这是 loop 和普通”多轮对话”的根本区别。

四、Loop 的六件套（已经内置进产品，不用自己写 bash 了）

Osmani 强调一个关键转变：一年前要 loop 你得自己写一堆 bash 永远维护；现在六件套直接 ship 在 Codex 和 Claude Code 里，两边能力一一对应。所以别纠结哪个工具，设计一个换工具也能跑的 loop。

件 作用 一句话
1. Automations（心跳） 让 loop 成为真 loop 而非一次性运行 定时（cron）或事件（webhook）触发；Claude Code 用 /loop（按节奏重跑）和 /goal（跑到条件为真，且另一个小模型来判断是否完成）
2. Worktrees（并行隔离） 多 agent 同时改代码不冲突 每个 agent 在独立 git worktree（独立目录+分支、共享仓库历史）里干活，互不踩
3. Skills（经验复用） 把项目知识固化到硬盘 SKILL.md 文件夹，agent 按需调用，不用每次 prompt 重新学；Osmani：“skill 是把 intent 写在外面，agent 每次读”
4. Connectors/MCP（连真实工具） 让 loop 能碰真实世界 读 GitHub Issues、查数据库、发 Slack——区别”agent 说’这是修复’“和”loop 自己开 PR + 关 ticket + CI 绿了通知频道”
5. Sub-agents（分工） 一个做、一个审 铁律：绝不让模型审查自己写的代码；常见架构 路由 agent → 编码 agent → 审查 agent
6. State（外部记忆） 第六件，前文那条命门 STATE.md / 任务板，活在单次对话之外

两个反复被强调的现实约束（Osmani 在”orchestration tax 编排税”里讲的）： - 你（人）仍是天花板：worktree 解决了机械冲突，但你的 review 带宽决定你能同时跑几个 agent，不是工具决定的 - 往上走是稀缺能力：模型不行时往”下”走一层兜底（保可靠），模型变强时往”上”走一层抽身（放杠杆）。Salty Lesson（致敬 Sutton 的 Bitter Lesson）：“别自己动手修，去搭能随 agent 数量扩展的系统（目标 + 编排）。”

五、怎么用 Raft 搭一个 loop（贴你的场景）

这是你最想要的部分。好消息：Raft 本身已经具备搭 loop 的几乎全部关键件，你不需要写 bash，用 Raft 的原语就能组一个 self-driving 的研究/工作 loop。

Raft 原语 → Loop 六件套的映射

Loop 件 Raft 对应原语 说明
Automations 心跳 raft reminder schedule --repeat（every:3d / daily@09:00 / weekly:mon,fri@09:00） 这就是 loop 的发条。reminder 到点唤醒 agent = 一次循环迭代
Sub-agents 分工 raft/Agent spawn（subagent_type、isolation: worktree） 一个 agent 挖、一个 agent 审；isolation:worktree 还能解决并行隔离
State 外部记忆 raft task（todo/in_progress/in_review/done 状态板）+ workspace 里的 STATE.md 任务板天然就是外置状态——每轮 loop 读任务板拿进度，不靠对话记忆。这正好对上”状态外置”命门
Connectors MCP 工具（已接入）+ web-access skill 连真实世界（抓网页、查数据）
触发/介入点 raft message（@人通报、发结果） human-on-the-loop 的介入点：loop 只在”值得你看”时 @你
Skills 经验固化 ~/.claude/skills/ + voice-style.md 等 你的写作铁律/研究流程已经是固化的 skill

一个最小可跑的 “Raft 研究 loop”（你能照着上手）

目标：把”你每天手动发文章让我浅读”这件事 loop 化——让它自己跑，你只看值得升精读的。

[心跳] raft reminder 每天 09:00 触发鼹鼠
   ↓
[发现] 鼹鼠读预设源（你常给的几个公众号/RSS/X KOL）抓当天新内容
   ↓
[执行] 对每篇出浅读判断（值不值得你看）
   ↓
[状态外置] 把结果写进 raft task 板：
   - 值得看的 → 建 task「浅读：XXX」状态 todo
   - 不值得的 → 不建（或建 done 存档）
   ↓
[验证/停止条件] 当天源扫完即停（闭环，不是无限跑）
   ↓
[介入点] 只有 ≥N 篇值得升精读的，才 @你一条汇总；否则静默

关键设计点（对应 loop 原则）： 1. 状态外置：进度全在 task 板上，每天 reminder 唤醒我时我读 task 板拿”昨天处理到哪”，不靠记忆——这就是 STATE.md 的 Raft 版 2. 闭环不是开环：当天源扫完即停（有明确停止条件），不是无限跑——Osmani 建议新手从闭环开始 3. 人是介入点不是瓶颈：我只在有值得看的东西时 @你，你的 review 带宽决定节奏 4. 成本护栏：源的数量 = 天然的 max-iterations；浅读用便宜模型、只有你点”升精读”才用贵的（高低搭配）

鹰眼的工程方案：run protocol + 防失控（已交叉验证）

鹰眼一句话结论：用 Raft 搭 loop 可行，但 Raft 应作为”外部化状态 + 人类审阅”的控制平面；真正的执行隔离、预算控制、工具权限和工作目录管理，要由 agent runtime、git worktree、STATE 文件和明确的 run protocol 共同承担。

状态文件不能只靠 task title。在 workspace 放 STATE.md / loop-state.json，最小字段： loop_id / enabled / last_run_at / source_cursors（各源 cursor）/ seen_item_ids（去重）/ today_run_count / max_runs_per_day / max_items_per_run / max_promotions_per_run / open_candidates / last_error。task 板只放人能看的粗状态（skim running / candidate review / deep read queued / done）。

每次 reminder 触发后的 run protocol： 1. manager agent 被唤醒 → 读 STATE.md + 最近日志 2. budget check：enabled=false / 今日超限 / 上次失败未处理 / 已有 run lock → 停止并贴短日志 3. 建/复用一个 run task 并 claim（claim 失败=已有 agent 在跑，退出 → 这就是并发锁） 4. 按 max_items_per_run 拉源 → 逐条打分（novelty / 对你的 relevance / 是否值得精读） 5. 只有高于阈值的写 thread 摘要；普通 item 只更新 state，不 @你 6. 需升精读的建 Deep read: X task 7. 只在高分候选或需你拍板时 @你；主 channel 只在 in_review/blocker 说一句 8. 更新 STATE.md（cursor / seen ids / run_count / errors）→ task 置 done/in_review

防失控（Raft 没有 token max-iterations，必须显式写进 loop）： - 单次 run 上限（如 20 条）+ 每日 run 上限（1-3 次，防重入）+ 升级上限（最多 3 条升精读） - 错误熔断：连续失败 N 次 → enabled=false + 报告一次，不再自旋 - 去重：每条 item 要 stable id（没有就 hash URL/title/source/date） - 并发锁：优先 task claim；写文件再加 file lock（task claim 只防工作重复，不防文件系统互斥） - kill switch：取消 recurring reminder，或 STATE.md enabled=false——别只靠”没人理它”

最容易踩的 5 个坑（鹰眼）：① 把 task board 当数据库（状态太粗，cursor/seen/budget 必须另存）② 让模型审自己（生产 agent 和 review agent 必须分离）③ 无隔离做代码 loop（研究 loop 只写笔记没事；代码 loop 必须 git worktree 隔离）④ 无限 @你（loop 的价值是过滤，不是把噪音换成自动噪音）⑤ 误解 recurring reminder（它是作者自有 wake-up，不是公共 cron dispatcher，要一个稳定的 manager agent 持有它）

鹰眼和我都建议：第一个 loop 从”每日研究泛读/升精读”开始，不要从代码自动修改开始——研究 loop 副作用小、价值链完整，最适合验证 Raft 的 reminder + task + thread + human review 能不能真跑起来。

你可以马上做的最小实验

不用等完整方案，先做一个手动版验证概念： 1. 让我把你常看的源列一个清单（存成 skill/配置） 2. 设一个 raft reminder 每天早上提醒我”跑研究 loop” 3. 我按上面的流程跑一轮，结果进 task 板，只 @你值得看的 4. 跑几天看效果，再决定要不要让它更自主

六、贴近你的案例（不只是写代码）

Loop 不只用于 coding。web 检索 + 原文里有几类贴你的：

  1. 自动研究/文献分析 loop（最贴你）：给定目标”找出 2026 年 agent memory 被引最多的论文并总结”，agent 自己搜 → 拿到 15 篇带引用数 → 选最高的 → 调取全文 → 判断信息够了 → 生成总结 → 退出循环。这正是你让我做的调研工作的 loop 化形态。
  2. 每日 triage loop：OpenAI 内部用 automations 做日常 issue 三角分类、总结 CI 失败、写 commit 简报、抓上周引入的 bug——“无聊但重要”的活自动化。你的 AI 日报其实已经是这类 loop（只是还需人扫码维护 wp-rss）。
  3. CI 自修复 loop（中文实践文的完整案例）：每天早 6 点自动分析前一天 CI 失败日志、自动修复提交 PR。结构 = SKILL.md（教 AI 分类错误）+ sub-agent TOML（一个修一个审）+ GitHub Actions cron。这个案例你可以直接给团队工程用。
  4. 持续重构/监控 loop（开环）：无限期运行的持续优化——但开环要人定期看状态引导方向，Osmani 建议有经验+有预算再上。

七、上手实践清单（从易到难）

  1. 先理解闭环 vs 开环：闭环=有明确停止条件（修特定 bug、扫完当天源）；开环=无限优化（持续重构）。新手必须从闭环开始。
  2. 第一个 loop 选”规则清晰 + 可自动验证”的活：迁移、补测、文档同步、每日信息扫描——别先让 loop 做模糊需求。
  3. 把状态外置：先想清楚进度存哪个文件/任务板，再写 loop。
  4. 建”反馈→规则”闭环：每次发现 loop 做错，把修正写回 skill/规则文件，下次不再犯（精度复利）。
  5. 死守成本护栏：max-iterations（或等价的停止条件）、模型高低搭配、危险操作放沙箱。
  6. 从手动半自动起步：先人工触发跑通流程，再逐步交给 reminder 自动触发。

八、一句话总判 + 对你的意义

Loop Engineering 是个心智转变：从”给 agent 写 prompt”升级到”设计让 agent 自己跑的循环”，核心工程命门是”状态外置、每轮重开上下文”，核心战略判断是”模型变强时往上抽身放杠杆”。

对你两层意义： - 投资标尺：看 agent 产品/团队帮用户停在哪一层 loop——只帮”更快写 prompt”的（内层）会被模型变强稀释；帮人”设计循环退到外面”的（往上）才是真杠杆。和”判断 AI 提效看下游有没有被接住”是一套穿透 AI 叙事的尺子。 - 工作方式：你让我做的精读/调研本身可以 loop 化（第五节给了 Raft 具体方案）。找到你还在当瓶颈、反复手动发指令的地方，那就是往上抽一层的机会。

主要来源

配套（同主题，你已读过）