上周五，在 Meta 的 @Scale 大会上，Claude Code 的缔造者 Boris Cherny 走上台，第一个来自观众的提问就直击要害：「Loops 是下一个炒作周期，还是来真的？」
Cherny 的回答斩钉截铁：「是的，它们是真的。」
他随后抛出了一段足以重新定义 AI 开发范式的话：「两年前，我们手写源代码。然后我们开始过渡到让 Agent 写代码。现在，我们正在过渡到 Agent 给 Agent 写 Prompt，然后再让 Agent 写代码。」他顿了顿，补了一句：「从源代码到 Agent 这一步有多大，Loops 这一步就有多大。」
这不是一个产品经理在推销功能。这是一个在 Anthropic 内部掌管 Claude Code 的人，在公开描述自己每天的工作方式——而且他已经不再手动 Prompt 了。
什么是 Loop？
在传统的 Agent 编程中，你需要为 Agent 设定清晰的目标，分阶段检查进度，确保它不会偏离 Prompt 太远。你本质上是 Agent 的"监工"——按下回车，阅读输出，发现错误，决定下一步，让它再试一次。
Loop 把这个逻辑翻转了。你不再站在 Agent 和它的下一步之间。你退后一步，设计一个系统，让 Agent 自己决定下一步是什么、什么时候检查工作、什么时候停下来。你从"操作员"变成了"系统设计师"。
用 Cherny 自己的话说：「我不再给 Claude 写 Prompt 了。我运行着多个 Loop，它们自己给 Claude 写 Prompt，自己搞清楚要做什么。」
在 @Scale 演讲的约第 32 分钟，Cherny 具体描述了他日常运行的两个 Loop：一个持续扫描代码库，寻找架构优化的机会；另一个不断识别重复的抽象模式并统一它们。它们像普通开发者一样提交 Pull Request，而且因为代码库在持续变化，它们永远不会停下来。
这听起来像科幻小说的情节，但 Cherny 已经这样工作了好几个月。他在 2026 年 6 月 Fortune Brainstorm Tech 大会上甚至说过：「我已经八个月没有手写一行代码了。」
Ralph Loop：最简单的 Loop 模式
Loop 的核心逻辑并不复杂。事实上，2026 年开发者社区最流行的 Loop 模式之一，其核心代码只有一行：
while :; do cat PROMPT.md | agent ; done
这就是所谓的 Ralph Loop，由软件工程师 Geoffrey Huntley 在 2025 年创造，名字来源于《辛普森一家》中那个永远在状况外、但始终不放弃的 Ralph Wiggum。Huntley 自己这样概括它的哲学：「Ralph 的美妙之处在于，它是在一个不确定的世界里，用确定性的方式做一件看似很蠢的事。」
Ralph Loop 的精妙不在于循环本身，而在于状态的存储方式。传统的 LLM 对话存在 Huntley 所说的"malloc/free 问题"：读取文件、工具输出和对话历史就像 malloc()，但你无法 selectively free() 上下文——一旦上下文被污染，模型就会像保龄球滚入沟槽一样，再也救不回来。Ralph 的解法是：在上下文污染之前主动轮换到新上下文。进度不存储在 LLM 的上下文窗口中，而是在文件和 Git 历史中。每次上下文满了，就启动一个全新的 Agent，带着全新的上下文，从上一个 Agent 停下的地方继续。
这个模式在 2026 年初迅速发酵。开发者 Alexander Gekov 在 DEV Community 上详细记录了 Ralph 的架构：精确的 Token 追踪、卡死检测（同一命令失败三次即触发）、Guardrails 文件（Agent 从失败中学习并记录"Signs"供后续迭代参考），以及每轮迭代按照 Token 使用量标记为绿色（<60%）、黄色（60-80%）、红色（>80%，强制轮换上下文）。这套架构已经被实现为 Cursor 的官方插件，从实验品变成了正式工具。
从 Test-Time Compute 到 Loop：同一枚硬币的两面
理解 Loop 的另一个角度，是把它放在 test-time compute 的大趋势中看。
OpenAI 研究员 Noam Brown 在 2026 年 6 月初发表了一篇广受引用的文章，核心观点是：当代模型只要投入足够多的算力，几乎能解决任何问题。这意味着，确保一个问题被解决的方式之一，就是不断向它投入算力，直到解决为止。
这对于"爬山型"问题尤其适用——比如改进代码库，模型可以不断做增量改进，直到达到某个阈值。或者，像 Cherny 的例子那样，只要还有算力可以投入，就一直做增量改进。
Loop 就是这种思路的工程化落地。如果 test-time compute 提供的是理论上的算力可扩展性，那么 Loop 提供的就是把这种可扩展性变成持续运行的工程框架。Noam Brown 说的是"算力解决的极限在哪里"，Cherny 说的是"让算力别停下来"。
代价：Token 无上限
但这里有一个 Cherny 和他的支持者们都小心翼翼地提及的警告：Loop 烧 Token 的速度远超传统聊天机器人，而且没有消耗上限。
传统聊天机器人是你问一句、它答一句，每次交互消耗的 Token 是有限的。Agent 模式中，Agent 可能需要多轮工具调用才能完成一个任务，Token 消耗增长了一个量级。而在 Loop 模式下，Agent 被授权在后台持续运行、无限循环，Token 消耗完全开放——你可以在睡一觉之后醒来，发现账单多了几个零。
TechCrunch 的报道一针见血地指出：这对 Anthropic 来说不是坏事——Anthropic 本质上是卖 Token 的。但对其他所有人来说，这可能是一种昂贵的开发方式。
开发者社区已经开始量化这个成本。根据 X 上一位开发者的拆解，单个 Agent Loop 处理一个中等规模的编码任务消耗 50,000 到 200,000 Token。一个带有编排器和三个专家 Agent 的 Fleet Loop，消耗量级更高。Ralph Loop 的实践者也建议使用 Cursor 的 Ultra 或 Max 计划（月费 $200 起），并为循环设置默认的 20 轮迭代上限。
AI Builder Club 的实践指南中提出了一个实用的框架：开放 Loop vs 封闭 Loop。封闭 Loop 在启动前就锁定成功标准，每一步都评估，有明确的停止条件——可预测、预算友好、安全到可以无人值守。开放 Loop 给模型一个目标和宽松的条件，让它探索广阔的方案空间——可能产出真正新颖的结果，但极易退化为"昂贵的垃圾制造机"。选择哪种取决于一个问题：你需要多少创新，以及你愿意冒多少预算风险。
社区爆发：从教程到开源工具
Cherny 在 @Scale 的演讲不是孤立事件。Loop Engineering 这个概念在 2026 年 6 月的开发者社区中迅速发酵，形成了一套完整的生态。
YouTube 教程层：Harkirat Singh 在 6 月 19 日发布了"Loop Engineering: The Way Every Dev Will Code in 2026"，吸引了 16,000+ 次观看。AI Jason 在 AI Builder Club 上发布了"Loop Engineer: Systemization and Artifacts"深度教程，展示了他自己公司内部运行的多 Loop 系统——Support Loop（每 30 分钟拉取工单并回复）、SEO Loop（每日拉数据分析并发布内容页面）、Product Growth Loop（从分析和信号中优先排序实验）、Reddit Loop（定时起草品牌评论）——它们共享同一个文件系统，通过"Signals"文件夹互相传递洞察，每天产出 20 到 40 个高质量页面，完全不需要人工干预。
Substack 深度指南层：Linas Beliūnas 发布了"Loop Engineering: Design AI Loops That Ship While You Sleep"完整指南。AI Builder Club 的 Shirley 发布了"Loop Engineering Guide (2026)"，将 Loop Engineering 定义为"Prompt Engineering 的 2026 年继任者"，并提出了一个核心观点：在 Loop 中，验证器（Verifier）才是瓶颈，而不是模型。 模型是生成器，生成器运行成本越来越低；验证器——判断工作是否"足够好"的那个东西——才是决定所有运动是否产生价值的关键。
开源工具层：Eugene Vyborov 的 Trinity 平台（GitHub: Abilityai/trinity，Apache 2.0）是最引人注目的开源项目之一。Trinity 被定位为"自主 Agent 编排基础设施"——每个 Agent 在独立的 Docker 容器中运行，具有实时可观测性、集群级调度、Agent 间委派和防篡改审计日志。Vyborov 每周四举办免费的 Agent Builder Workshop，教开发者如何构建远程 Loop，让 Agent 在关闭笔记本后继续运行。与此同时，OpenClaw 成为 2026 年最活跃的自托管 Agent 框架之一，Peter Steinberger 在 6 月初的一条推文——"You should be designing loops that prompt your agents"——同样引发了广泛讨论。
是炒作，还是范式转移？
AI Builder Club 的指南中有一个值得注意的"反方观点"小节：一些敏锐的观察者指出，"Loop Engineering"这个词部分是新造的，目的是吸引注意力，而一些迅速涌向这个标签的内容，其实是在重新包装 Agent 开发者早就知道的东西。
但指南给出了一个过滤框架：忽略标签，看底层变化是否真实——
- 你是否越来越多地在设计运行 Agent 的系统，而不是直接给 Agent 写 Prompt？是的。
- 稀缺且有价值的部分，是否已经从"怎么提问"变成了"怎么定义'完成'和'好'"？是的。
- 一个验证器薄弱的 Loop，是否真的会可靠地产生昂贵的垃圾？也是的。
Cherny 本人的行动就是最好的注脚。当 Claude Code 的创造者公开表示自己已经八个月不写代码、不再手动 Prompt，而是让多个 Loop 持续运行、互相 Prompt、像普通开发者一样提交 PR——这已经不是一个需要辩论的命题。这是一个正在发生的现实。
Loop Engineering 的标签可以讨论，但底层的范式迁移已经很清晰：AI 开发的第三次跃迁已经到来。从手写代码到 Agent 写代码，从 Agent 到 Agent 的 Agent。而你要做的，不是写更好的 Prompt，而是设计一个让 Agent 自己跑起来不用停的系统。
