三代范式：
这不是替代，是分层
提出「设计循环而非 prompt」这句话的是 OpenClaw 作者 Peter Steinberger，2026 年 6 月初一条推文一周内突破 650 万次浏览。Anthropic Claude Code 负责人 Boris Cherny 紧接着背书：「我已经不 prompt Claude 了，我有一堆循环在跑，是它们在 prompt Claude、决定下一步该干嘛——我的工作是写循环。」几天后，Google Cloud AI Director、前 Chrome 工程负责人 Addy Osmani 写下《Loop Engineering》一文，给这件事起了名字、拆出了解剖结构。
一句话定义：Loop Engineering = 把"那个 prompt Agent 的人"换成"一套你设计的系统"。过去两年，从 Agent 拿结果的方式是你写好提示词、塞够上下文，读它返回什么再敲下一句——Agent 是工具，你全程握在手里，一轮接一轮。Loop Engineering 说的是：你搭一个小系统，让它去找活、派活、验活、记下做了什么、再决定下一步，然后让这套系统去戳 Agent，而不是你。
| 代际 | 核心问题 | 杠杆所在 |
|---|---|---|
| Prompt Engineering（2022–23） | 我该说什么才能拿到最好的输出？ | 措辞 |
| Context Engineering（2024–25） | 该把哪些信息、按什么顺序喂进上下文窗口？ | 信息编排 |
| Loop Engineering（2026–） | 我该搭什么系统，让 Agent 自己找活、干活、验活、记住——全程不用我？ | 系统架构 |
Osmani 原话最精炼：「你其实不太需要擅长 prompt 了。要擅长的，是那个替你 prompt 的循环。」但他也立刻补了一句警告——这事还很早、他自己也持怀疑，而且必须当心 token 成本，token 富裕和拮据的人，用法天差地别。
四条线在同一时间收束：写代码本身正在变免费（生产成本趋零，成本压到维护与架构债）；人机分工第一次被实测出来（Anthropic 对 40 万次 Claude Code 会话的分析显示，人做约 70% 的"做什么"，Agent 做约 80% 的"怎么做"）；模型终于可靠到值得让它自己转（半年前一个循环空转 40 次才找到解，现在常 3–5 轮落地）；以及一次外部冲击（最强模型一夜因监管消失）把"你到底是在用 AI，还是在 prompt 然后祈祷"这个方法论问题逼到了台前。
从 ReAct 到 /loop /goal：
一条四步的演化
Loop Engineering 不是凭空冒出来的术语，而是一条工程血脉成熟后被命名的时刻：2022 年 ReAct 式推理循环让模型交替「推理+行动」；2023 年 AutoGPT 第一次大规模实验「让 Agent 自己跑下去」；2025 年，独立工程师 Geoffrey Huntley 命名的 Ralph loop——一行 bash 脚本把 Agent 塞进死循环——成为草根玩法的代表；2026 年，Codex、Claude Code 把这些模式直接做进产品命令 /loop、/goal。Osmani 指出最意外的一点：一年前你想要循环得自己写一堆 bash 私货维护，现在这些零件直接随产品出厂——Steinberger 列的清单几乎一对一映射到 Codex app，又几乎原样映射到 Claude Code。
Ralph loop 的反直觉洞见：上下文即资源
Ralph loop 的核心创新不是记忆，而是每一轮都开一个全新的上下文窗口。原因是 LLM 质量会随上下文填满而下降——大约 10–15 万 token 后质量就可测量地掉，这被称为 context rot（上下文腐烂）。主流循环靠「把记忆落盘」对抗遗忘；Ralph 反过来靠「每轮重置上下文、只从磁盘上的 PROMPT.md/AGENTS.md + git 历史重新载入」对抗腐烂。两种策略是一枚硬币的两面：外部记忆解决"会忘"，fresh context 解决"记太多反而烂"——好的循环两样都要。
这里有个微妙但关键的原语区分：/loop 按节奏重跑；/goal 一直跑到某个可验证条件真的成立为止——而且每一轮之后，由另一个独立的小模型来判断是否完成。写代码的那个 Agent，不是给它打分的那个。同一个原语，Codex 和 Claude Code 都在做，这几乎是整件事的范式缩影。
一个 loop 的
五个零件，加一个记忆
Osmani 把一个能跑的循环拆成五个基本要素 + 一个外部记忆，Codex 和 Claude Code 里都能对照到几乎同名的实现：
| 要素 | 职责 |
|---|---|
| Automations（自动化） | 按时间表自己发现+分诊；是让循环成为"循环"而非"跑过一次"的心跳，且 automation 可以直接调用一个 skill |
| Worktrees（工作树） | 隔离并行的多个 Agent（git worktree） |
| Skills（技能） | 把项目知识写成 SKILL.md，省得 Agent 每次猜 |
| Plugins / Connectors | 基于 MCP 把 Agent 接进你已经在用的工具 |
| Sub-agents（子 Agent） | 一个出主意，另一个来检查——maker/checker 分离 |
| State（状态/记忆） | Markdown 或经连接器写入 Linear——Agent 会忘，仓库不会 |
一个正例模板：Osmani 自己反复用的"晨间三诊循环"——automation 每天早上在仓库上跑，读 CI 失败、未关 issue、最近提交，把发现写进状态文件；对每个值得做的发现，开一个隔离 worktree，派子 Agent 起草修复，再派第二个子 Agent 审查；连接器自己开 PR，搞不定的落进收件箱等人。状态文件是整件事的脊柱——它让明早的运行能从今天停下的地方接着跑，而你只设计了一次，没有 prompt 其中任何一步。
「两个人搭一模一样的循环，可能得到完全相反的结果。一个用它在自己深刻理解的工作上跑得更快，另一个用它来逃避理解这份工作。循环分不出区别，你能。」
Addy Osmani · 《Loop Engineering》让循环真正工作，
而不是"昂贵的无限重试"
社区在这波讨论里沉淀出"能跑的循环"和"烧钱的空转"之间的分水岭，就四条：
| 要素 | 要点 | 反面 |
|---|---|---|
| 可验证的退出条件 | 测试通过、diff 小于 N 行、eval 分数过阈值——系统不靠人就能判 | 「看起来还行吗？」——这不是检查，是聊天 |
| 便宜的检查 | 先用确定性检查（编译、lint、单测），AI-as-judge 只用于它们覆盖不了的部分 | 拿前沿模型当裁判，每一轮都付旗舰价 |
| 硬性熔断 | 最大轮数、最大 token、最大墙钟时间——每个循环都要有天花板 | 最糟的不是失败的循环，是没人发现地跑了 6 小时、烧了 40 美元的循环 |
| 人闸在对的层级 | 人站在"定义规格"和"验收结果"两端 | 人钻进每一轮去手动点头 |
fashn.ai 联合创始人 Dan Bochman 用一段被转发数千次的对话精准描绘了这条线的反面：给 Claude 讲任务（5 分钟）→ Claude 实现（10 分钟）→ 「这步为什么必要？」→「你说得对！我过度设计了！」→ 重复 ×87 次，耗时 13 小时。这不是 loop engineering 的失败，恰恰是它的缺席——这里的"检查"是"人觉得合理吗"，那不是检查，是对话。真正的循环有可编程判据，人只在判据满足后才进来。
最危险的反面：
loopmaxxing
循环的快速流行不是没有代价。最大的陷阱叫 loopmaxxing——和早先的 tokenmaxxing 是同一种错觉：以为只要让 Agent 在无限循环里跑下去，最终总会跑出正确答案。它在三个地方必然失败：
- 主观/不可量化目标——「改善这个登录页的体验」没有二元判据，模型算不出停止点，循环无限跑，把云预算变成天价账单
- 局部最优——即便在软件工程这种确定性环境里，无监督循环也会卡死。Karpathy 自承 autoresearch 里 Agent 遇到开放式难题会"变怂"，在学习率上挪零点几个百分点换取名义改善
- 理解债——当循环几百行代码的生成速度超过团队 review 能力，开发者继承的是一个"设计决策全是空白"的代码库
学术标尺印证了这条边界的真实存在：2026 年初的 SWE-EVO 基准（arXiv 2512.18470）不像 SWE-Bench 那样考"改一个 bug"，而是从 7 个成熟项目构造出 48 个"软件演进"任务，平均要改 21 个文件、用 874 个测试验收——正是循环要啃的那种活。同一梯队模型，SWE-Bench Verified 上最好成绩 72.8%，换到 SWE-EVO 长时程演进任务上掉到仅 25%。这不否定循环工程，反而正是它存在的理由——但也提醒一句：别把「能跑很久」错当成「能做对很久」。
Total TypeScript 作者 Matt Pocock 对一个特定变种提出了精准反对——自我改进循环：自动生成的记忆、每次会话后自动套用的 CLAUDE.md 建议。他的担忧是自我改进循环里一条坏建议不只产出一个坏回复，而是被写进 Agent 的永久上下文，从此污染之后每一个回复，循环把错误放大、伤害复利。实践含义很清楚：循环用于任务验证，不用于无监督的自我改写；任何 Agent 写的指令变成持久上下文之前，必须人工过目。
综合判断
Osmani 那句总结值得记住：智能不在循环的空转里，而在触发器的质量、目标的精确度、验证步骤的设计里。四阶段渐进法给出了生产环境的安全路径——先人在环中观察，再引入确定性退出，加停滞熔断器，最后把可预测动作蒸馏成主 harness 里的确定性脚本。一句话原则：LLM 能做很多事，但未必是每件事最可靠的工具；在 Agent 会失败的地方加上确定性代码和人类监督，才能既拿到循环的好处，又避开它的坑。
从代码循环
到公司循环
一个公司的运行，能不能也说成一个巨大的、层层叠叠的 loop？管理控制论几十年的老传统早已给出答案——Stafford Beer 的可生存系统模型、Deming 的 PDCA 环、Boyd 的 OODA 环、Argyris & Schön 的双环学习，本质上和 Loop Engineering 给软件的那套东西同构，只是执行者正从人换成 agent。战略 loop（年/季：愿景→战略→结果→复盘）、运营 loop（月/周）、团队 loop（日/小时：ticket→PR→review→merge）、个人 loop（分钟级，正是 agent 现在开始替你跑的那一层）——按节奏分层，每一层都是一个完整循环。
更有意思的是失败模式也一一对应，而且管理学早给它们起过名字：loopmaxxing 对应"没有清晰指标的项目让团队无限期耗着"；局部最优对应"增量主义、不敢做架构级重组"；reward hacking 对应经典的 Goodhart 定律（指标一旦变成目标就失效）；理解债对应管理层不再理解一线实际在干什么。
但这个类比有一处关键断裂，必须守住：公司的"agent"是人，有自己的目标、情绪和政治，不是干净的奖励最大化器；公司的目标函数本身是争议性的，不像 autoresearch 那样有一个钉死的验证指标；最重要的产出（品牌、信任、文化）没有紧致退出条件，硬塞进 KPI 去逼恰恰是最大的陷阱。所以结论是：所谓"自进化公司"，本质就是把公司显式地当作一套被工程化的 loop 来设计——把有可验证退出条件的循环交给 agent，把没有的留给人。Steinberger 那句「你仍然需要 BRAIN 当主控模型」在公司层面照样成立：那个 BRAIN 就是判断力，以及对目标本身的质询——再多层循环也替代不了人的位置。
搭你的循环，
但像一个工程师那样
Loop Engineering 把一个事实正式化了：大语言模型是更大软件系统里的一个组件，不是独立应用。一个自主 Agent 的效率，完全由工程师设计的确定性约束、测试 harness 和执行护栏决定——再多轮循环也救不回一个说不清的目标，或一套没有原则的架构。当写代码本身趋近免费、当实测证明人该守在"做什么+验收什么"两端，开发者的核心责任不再是找到那串完美的形容词提示词，而是搭出让自主循环始终朝可验证终点收敛的验证系统。
接下来最值得追踪的三个变量：/loop /goal 这类原语会不会成为跨工具的事实标准；第一起由 loopmaxxing 造成的公开重大账单事故何时出现；企业选型会不会从"哪家模型更强"转向"谁的循环原语+护栏+可观测更成熟"。