Loop Engineering：谁在提示谁？——Addy Osmani 新概念深度拆解与社区撕裂全景图

> 2026 年 6 月，Peter Steinberger 一句话 48 小时内 220 万浏览：「你不应该再提示 Agent 了。你应该设计循环来提示 Agent。」全网炸了。有人说革命，有人说"cron job 戴了顶新帽子"，最诚实的是 Matthew Berman 那句：「Nobody knows but him and Boris.」 > > 三个问题：这到底是什么？社区为什么吵成这样？你需不需要它？

---

一、Loop Engineering 是什么

一句话讲清楚：过去是你给 Agent 打字——它回话——你再打字。Loop Engineering 把这个循环里的人删掉，放进一个程序里。

具体来说，一个 Loop 由六个零件拼成。缺一不可。

1. Automations，循环的心跳

没有定时器，你只是用了一次 Agent。有定时器，Agent 按自己的节奏一遍遍跑。

Osmani 把这叫"循环的心跳"。Boris Cherny（Anthropic Claude Code 负责人）的 Loop 跑在 cron 上——有的每分钟一次，有的每天一次，有的跑到条件满足才停。

Claude Code 给了两个原语。/loop：时间驱动，每 N 分钟重跑。/goal：条件驱动——「test/auth 所有测试通过且 lint 干净」才停。Codex 的同名 /goal 同理。

Cherny 的实战清单：PR babysitter 每几分钟检查所有 open PR；CI health 监控 flaky 和 broken 测试随时修；Feedback clustering 每 30 分钟拉 Twitter 反馈按主题聚类。

2. Worktrees：并行不撞车

两个 Agent 同时写一个文件，就是两个工程师 commit 同一行然后谁也不理谁。Git worktree 解决这个问题：每个 Agent 在自己的分支 checkout 里干活，物理上碰不到别人的文件。

Codex 内置 worktree 支持。Claude Code 给三种隔离方式。Osmani 补了一刀：worktree 消除了机械碰撞，但你的审查带宽才是真正的上限——你一次能审几个 PR，就能跑几个 Agent。工具不卡，你卡。

3. Skills——别再当金鱼

没有 Skills，每次 Loop 从零推导整个项目——构建命令、代码风格、那个因为某次事故才有的约定。有 Skills，每次站在前一次的肩膀上。

Skill 是一个 SKILL.md 文件加可选的脚本和引用。Codex 用 $skill-name 调用，Claude Code 同构。关键洞察：Loop 内可复用的单元是 Skill 不是 prompt。调用清晰命名 Skill 的 Loop 复合增长；每次从头推导的 Loop 只烧钱。

4. Connectors——Loop 伸手碰世界

一个只能看文件系统的 Loop 是个微型 Loop。Connectors（基于 MCP）让 Agent 读 Issue 追踪、查数据库、调 staging API、发 Slack。

没有 Connectors：Agent 修完代码，停在那里——它不知道开 PR，不知道关联 ticket，不知道 CI 绿了该 ping 谁。有 Connectors：修完代码 → 开 PR → 关联 ticket → CI 绿了自动通知频道。区别不在 Agent 聪明了多少，在于它能动手的范围大了多少。

5. Sub-agents：写的和查的，不是同一双眼睛

写代码的模型给自己打分太客气。Osmani 的原话：它天然倾向于说「我做完了」。

解法：maker-checker 分离。一个 Agent 写，另一个 Agent 审。第二个 Agent 用不同的指令（有时是不同的模型），能抓到第一个说服自己的东西。

Codex 在 .codex/agents/ 定义自定义 Agent，Claude Code 在 .claude/agents/。典型三分工：探索者调查问题，实现者写代码，验证者对照 spec 检查。

这个分工在 Loop 里为什么特别重要？Loop 跑的时候你不在旁边看。 你真正信任的验证者，是你走开的唯一理由。

/goal 的本质也是这个：干活的模型和验收的模型不是同一个。一个写，一个只回答一个问题——「条件满足了没有？」

6. State——Agent 会忘，仓库不会

一个 Markdown 文件，或一个 Linear board，存在于单次对话之外。明天早上的运行从今天停下的地方继续，不是从零开始。

## 2026-06-08
-[x] flaky: test_auth_timeout → 隔离到 @slow 标记
-[x] broken: test_payment_webhook → 修复 #1847
-[ ] flaky: test_search_index → 未复现

## 2026-06-07
-[x] broken: test_user_export → 依赖版本回退 #1843

每次 Loop 启动读这个文件，结束时写回去。这是整个 Loop 的脊柱。

---

二、社区为何分裂

2026 年 6 月的 Loop Engineering 讨论，是我见过 AI 工具话题中分裂最快的。

🔥 狂热派：「这就是未来」

Tural Gurbanov 说他基于 Hermes 搭了一个替代方案，想请 Osmani 看看实验文档。Thomas Reid 把 /goal、/loop、/half、fan-out、Dynamic Workflows 统称为「新东西」。Mohammed Wasif 更激进——「我厌倦了提示和监督 Claude Code」，于是自己搭了一个 Mac 应用叫 Supervisor，读语料库、生成 tailored principles.md、自动把提示喂进每个会话。

IndieKit 说他们做的 Codex skill for loop engineering 和 Osmani 的框架「几乎完美吻合」。Peter Steinberger 的 Mayhem Agent——就是那条 220 万浏览的推文背后——他自己列了几个跑的 Loop：Mantis（Agent 自己录 bug 视频然后修、录修复视频）、Auto Review（commit 落地前多轮审查直到干净）。

🧊 冷静派：「不过是 cron 戴了顶帽子」

最犀利的一句：「Cronjobs have funny re-branding rn.」

Sead Dzambegovic 的质疑最诚实：「我的技能已经能让我在每个任务上达到大约 90% 的完成度。循环的其余部分只会消耗更多令牌，还给我一堆需要清理的东西。你自己也说了，我还是得检查所有代码。」

John Gouin 的观点更底层：「我一直在用自己的方式做这件事——我是那个连接一切的人肉 loop。一旦 loop 跑通了，目标应该是把逻辑转成代码（做 app），而不是维护一个昂贵的 loop。」

Peace Not War 一刀戳进心脏：「所以我们在把 RL 重新包装成 loops——而 Agent 声称要取代 workflow 时，做的也正是这件事。Literally RL 101.」

⚠️ 安全/风险派：「验证才是真正的天花板」

Evan Pappas 话最短但最重：「能力越大，漏洞越大。安全控制策略必须成为 loop orchestrator 的控制平面的一部分。」他附了自己写的《Building a Secure Agentic System》，展示了一个防止 Agent 删生产数据库的系统。

Keane 的观察最精准：「代码 loop 有免费的 oracle（测试、编译器）——其他每个领域的 oracle 都是人，而这部分还没有人搞定。」

这句话切中了 Loop Engineering 最深的裂缝：软件工程是唯一一个 Agent 能自动验证自己工作的领域。 你放到任何其他领域——写作、设计、决策、产品——没有 test suite 替你当裁判，你得亲自看。Loop 烧了 token，你还是得审。

🤔 实践者的试错笔记

黑猫 Sens 的踩坑记录很真实：「我让一个 Agent 跑一次然后为下一个 Agent 写提示，但那种情况下我需要把上一轮的提示复制粘贴到下一个。它自己决定我需要粘贴给谁。」——半自动半手动，卡在最难跨越的那一步。

Mengxue 作为非程序员提出了另一个视角：「作为非程序员，我还没找到一个需要同时使用所有 6 个复杂循环的实际用例。」这个观察暗示了 Loop Engineering 的适用面可能比狂热派想的窄得多。

---

三、三个核心判断

判断一：不是新东西，是新产品化

Peace Not War 说得对——RL 101。ReAct 循环（2022）、AutoGPT（2023）、Ralph Loop（2025）……Loop Engineering 的每一项核心技术都在历史上出现过。

但新产品化不等于没有价值。Claude Code 把 /goal 做成了产品——停止条件从「我觉得做完了」变成「所有测试通过」，评判模型从「自己给自己打分」变成「另一个模型验收」。这个产品化把一件概念上可能但操作上不可行的事，变得可以。

诚实的说法：Loop 是 cron 触发 + 一个每次触发后看情况决策的 AI。 真正要花心思的工程，是确保那个 AI 不会跑下悬崖。

判断二：适合谁、不适合谁——AlphaSignal 的四条件

AlphaSignal AI 在一周的狂热后发了冷静分析。四个条件，全部满足才值得建 Loop：

1. 任务重复。 Loop 把设置成本分摊到多次运行。一次性工作，好 prompt 更快更便宜。 2. 验证自动化。 需要测试套件、类型检查器、linter——能不用你出场就拒绝差工作的东西。 3. Token 预算能吸收浪费。 Loop 重读上下文、重试、探索都烧 token。Uber 烧完年度 AI 预算后设了每人每工具月费 1500 美元上限。 4. Agent 已有资深工程师的工具。 日志、复现环境、能跑自己的代码并看到哪里坏了。

四个都 yes，值得。缺一个，你在自动化一个还没准备好被自动化的流程。

好的首个 Loop：CI 失败分诊、依赖升级 PR、lint-and-fix、flaky test 复现。坏的第一个 Loop：架构重写、认证/支付代码、生产部署、「完成」靠判断的任务。

判断三：真正的天花板不是你想象的那个

Worktree 消除了机械碰撞。Sub-agent 提供了 maker-checker 分离。但 Osmani 自己指出了三个 Loop 无法替你解决的问题——而且这三个问题随着 Loop 变好变得更尖锐：

验证仍然在你身上。 「完成了」是声称，不是证明。你的工作是交付你确认能用的代码。

理解债务（Comprehension Debt）。 Loop 越快交付你没写的代码，仓库里存在的东西和你真正理解的差距越大。顺畅的 Loop 只是让这个差距长得更快——除非你读。

认知投降（Cognitive Surrender）。 Loop 自己跑着的时候，人很自然就停止形成意见，接受它返回的任何东西。Osmani 说：设计 Loop 用判断力是解药，用逃避思考是加速剂。同一动作，相反结果。

---

四、结语

Loop Engineering 不是谎言，也不是革命。它是那个逻辑上必然出现、产品化上终于可用的东西。

Steinberger 和 Cherny 没有发明新算法。他们只是做了那件最难的工程判断——知道什么时候把自己从反馈路径里删掉，什么时候不能。

Cherny 自述过去 30 天里 100% 贡献由 Claude Code 自己写，合并了 259 个 PR，2025 年 11 月删掉 IDE 没再打开过。但你要注意他删的是什么——是 IDE，不是判断力。他仍在决定做什么、和用户沟通、协调团队。工作没有消失。上升了一个高度——从写代码，到写那个写代码的东西。

Keane 的观察最值得在这结尾处重复一遍：代码 loop 有免费 oracle——测试、编译器。其他领域的 oracle 是人。 这意味着 Loop Engineering 有一个天然边界。在软件工程里它跑得起来；在需要人类判断的领域——写作、产品决策、设计评审——它只是多了一个「带 LLM 的 cron job」。

你可以建 Loop，但别想靠它取代理解。Loop 让你快。判断力让你对。两个都要。

---

> 参考：Addy Osmani「Loop Engineering」(2026-06-07)、知乎十二章《AI时代的软件工程》解读、AlphaSignal 四条件分析，以及 X 社区讨论 thread。