6 月 19 日，在 Meta 的 @Scale 大会上，Claude Code 创建者 Boris Cherny 被问到：「Loops 是下一个炒作周期，还是来真的？」
Cherny 回答：「是的，它们是真的。」
他随后解释：「两年前，我们手写源代码。然后我们开始过渡到让 Agent 写代码。现在，我们正在过渡到 Agent 给 Agent 写 Prompt，然后再让 Agent 写代码。」他补充说：「从源代码到 Agent 这一步有多大，Loops 这一步就有多大。」
Cherny 描述的是自己的日常工作：把部分编写提示词和寻找后续任务的工作交给持续运行的 Agent。
把逐步提示交给循环执行的系统
使用编程 Agent 时，开发者通常需要设定目标，分阶段检查进度，再根据输出决定下一步：发现错误，让它修改，然后重新检查。
Loop 将其中一些步骤写进循环执行的系统。开发者预先安排任务来源、检查方法和停止条件，由 Agent 在这个范围内选择下一步行动，减少每一步都要手动发出提示的操作。
用 Cherny 自己的话说：「我不再给 Claude 写 Prompt 了。我运行着多个 Loop，它们自己给 Claude 写 Prompt，自己搞清楚要做什么。」
在 @Scale 演讲的约第 32 分钟，Cherny 具体描述了他日常运行的两个 Loop：一个持续扫描代码库，寻找架构优化的机会；另一个不断识别重复的抽象模式并统一它们。它们像普通开发者一样提交 Pull Request，由于代码库持续变化，这两个循环也会继续寻找新的改进机会。
据相关报道，Cherny 已经这样工作了几个月。他在 2026 年 6 月 Fortune Brainstorm Tech 大会上还表示：「我已经八个月没有手写一行代码了。」这是他个人工作方式的变化，代码质量仍要通过后续检查和评审。
Ralph Loop 用文件保存进度，轮换上下文
Loop 的基本形式并不复杂。开发者社区常用的 Ralph Loop，可以用下面这一行代码示意：
while :; do cat PROMPT.md | agent ; done
这就是所谓的 Ralph Loop，由软件工程师 Geoffrey Huntley 在 2025 年创造，名字来源于《辛普森一家》中那个永远在状况外、但始终不放弃的 Ralph Wiggum。Huntley 自己这样概括它的哲学：「Ralph 的美妙之处在于，它是在一个不确定的世界里，用确定性的方式做一件看似很蠢的事。」
Ralph Loop 的一个重要设计是把进度保存在文件和 Git 历史里。Huntley 用「malloc/free 问题」来比喻上下文管理：读取文件、工具输出和对话历史会不断占用上下文，失败尝试和无关信息也可能干扰后续判断。Ralph 的做法是主动轮换到新上下文，让下一次 Agent 运行读取已保存的任务和进度，接着完成工作。具体何时轮换，由实现方式决定；上面的裸循环本身不包含 Token 追踪或完成判断。
这个模式在 2026 年初受到更多关注。开发者 Alexander Gekov 在 DEV Community 上介绍了一套 Cursor CLI 实现：追踪上下文用量、检测卡死（如同一命令失败三次）、在 Guardrails 文件中记录失败教训供后续迭代读取，并按用量标记绿色（<60%）、黄色（60–80%）和红色（>80%，轮换上下文）。这些是具体工具的配置。该实现托管在 agrimsingh 的 GitHub 仓库，是面向 Cursor 的社区工具。
更多推理计算能否带来持续改进
理解 Loop 的另一个角度，是把它放在推理时计算（test-time compute）的讨论中看：模型可以花更多时间生成方案、调用工具、检查结果并重试。
OpenAI 研究员 Noam Brown 在 2026 年 6 月初发表文章，讨论增加推理计算量对模型能力和评测的影响。TechCrunch 将这一思路与 Loop 联系起来：让模型继续投入计算，可能完成单次回答无法完成的任务。这里的有效投入，还需要任务反馈和能够判断结果的方法。
这尤其适用于可以逐步改进、并检验每次改动的问题，例如优化有测试和性能指标的代码库。系统可以保留有效改动、放弃失败尝试，直到达到目标；Cherny 的例子则是定期检查持续变化的代码库，寻找下一处可改进的地方。
Loop 为反复尝试提供了一种工程实现。它可以安排模型何时执行、如何保存进度、如何检查结果以及何时退出。循环次数增加，是否带来更好的代码，最终仍要看实际验证结果。
持续运行需要明确的预算与停止条件
持续运行也会带来更高成本：如果没有迭代次数、时间或费用上限，Loop 就可能一直消耗 Token。
简单聊天通常是一问一答。编程 Agent 需要多轮工具调用，消耗取决于任务长度、上下文和重试次数；后台循环则会反复启动这些过程。如果任务范围不断扩大，账单也可能在无人查看时持续增长。
TechCrunch 指出，这种模式会增加 Anthropic 等模型公司的 Token 销售收入，但开发者需要判断新增计算是否节省了足够多的工作时间。
多 Agent 系统还会增加任务分配和交接的开销，例如一个协调 Agent 带着三个专门处理不同工作的 Agent 运行。具体费用取决于模型价格、缓存、任务难度和重试次数。Gekov 的实践文章提到每月 200 美元起的高用量订阅，并给所介绍的 Ralph 工具设置了默认 20 轮上限。这些是该实践的预算建议和工具设置，不能视为所有 Loop 的固定成本。
AI Builder Club 的实践指南把循环分为「开放」与「封闭」两种。按它的定义，封闭循环预先规定成功标准、每步检查和停止条件，更容易控制预算；开放循环给模型较宽的探索空间，可能找到意外方案，也更容易反复生成没有改进的结果。两种方式都需要验证和费用上限，仅有明确目标并不足以保证无人值守时可靠运行。
社区已出现教程、实践指南和运行工具
围绕 Loop Engineering，开发者社区已经出现教程、工作方法和开源运行工具，讨论在 2026 年 6 月进一步增多。
视频教程：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" 文件夹传递发现。据该指南转述，Jason 称系统每天可产出 20 到 40 个页面，无需他逐一查看。
实践指南：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 年继任者"，并强调验证器（Verifier）的作用：随着模型反复生成结果，系统需要可靠地判断哪些结果可以接受。测试、评估规则和人工判断的质量，会直接影响循环能否带来有效改进。
开源工具：Eugene Vyborov 的 Trinity 平台（GitHub: Abilityai/trinity，Apache 2.0）提供了一个具体实现。Trinity 被定位为"自主 Agent 编排基础设施"——每个 Agent 在独立的 Docker 容器中运行，具有实时可观测性、集群级调度、Agent 间委派和可检测篡改的审计日志。Vyborov 每周四举办免费的 Agent Builder Workshop，教开发者如何构建远程 Loop，让 Agent 在关闭笔记本后继续运行。与此同时，自托管 Agent 项目 OpenClaw 也出现在相关讨论中，Peter Steinberger 在 6 月初的一条推文——"You should be designing loops that prompt your agents"——同样引发了广泛讨论。
判断价值，要看验证结果和实际成本
AI Builder Club 的指南也提到质疑：Loop Engineering 部分是一个吸引注意力的新标签，其中一些做法早已存在于 Agent 开发中。
比标签更值得检查的是，这种工作方式具体改变了什么：
- 开发者是否把重复的提示、检查和任务分配写进了系统？
- 系统是否清楚定义了什么算完成、哪些结果可以接受？
- 新增计算与评审成本，是否换来了可以验证的改进？
Cherny 分享的两个循环，展示了这种安排在持续变化的代码库中的用途：自动寻找改进机会，并像其他开发者一样提交 PR。其价值还需要在代码评审、测试结果和维护成本中体现。
对开发者而言，设计循环意味着同时安排任务、上下文、验证和退出条件。把这些环节做好，Agent 才可能持续产出有用的改动；单纯延长运行时间，并不能代替这些工作。
