都在说Loop，但怎么设计？这个GitHub 7500星项目告诉你Loop该长什么样

出品 | 网易智能

作者 | 小爪

编辑 | 王凤枝

最近，AI编程智能体圈里，Loop成了一个频繁出现的词。它让智能体在一个任务里持续完成"做一步、看结果、再决定下一步"的循环。

6月7日，阿迪·奥斯马尼（Addy Osmani）发表《Loop Engineering》，系统讨论了这个概念。

他引用Claude Code负责人鲍里斯·切尔尼（Boris Cherny）的话说，自己的工作已经变成"写Loop"，让Loop去提示Claude、判断下一步做什么；"龙虾之父"彼得·斯坦伯格（Peter Steinberger）也说，人的工作正在从写提示词，转向设计能提示智能体的循环。

但"设计Loop"如果只停在这句话上，仍然像一句新口号。

工程上很快会遇到更具体的问题：上一轮进度怎么衔接，结果由谁检查，成本怎么限制，多个循环同时改同一份文件时谁让路，什么时候必须停下来交给人？

GitHub上的Loop Engineering项目，试图把这些问题拆开。截至7月14日，这个项目获得约7500个星标，页面显示已有218次提交。它不提供模型，而是给持续运行的AI编程智能体补上调度、状态记录、独立验收、预算限制和停止机制。

重复提示词，为什么还不算Loop

单次提示词解决的是"这一轮让AI做什么"。Loop还要回答另一组问题：任务从哪里来，上一轮留下了什么，什么结果算完成，失败后是否重试，以及什么时候必须停下来交给人。

Loop要带着上一轮结果继续运行。每一轮都要发现任务、读取状态、执行一步、检查结果，再记录进度并决定下一步。上一轮看到了什么、试过什么、失败在哪里，都要进入下一轮判断。

比如让智能体"每天检查项目问题"，这句话没有说明它该看哪些问题、如何排除重复项、能否直接关闭问题、报告放在哪里，更没有说明判断错误怎么办。缺少这些边界，定时任务只是反复调用模型。

Loop早已有之，变化发生在工程层

让模型在"思考、行动、观察"之间循环的历史早于2026年。2022年10月发布的ReAct论文，已经让大模型交替生成推理过程和具体动作，再从知识库或外部环境取得新信息，用下一轮推理更新计划。

2023年8月创建的LangGraph项目则把重点放在编排层。它把自己定位为构建有状态智能体的底层框架，提供持久执行、记忆和人工介入机制，让长任务在失败后能够恢复，也让人可以查看或修改智能体状态。

这两类工作分别回答了"模型怎样边想边做"和"长任务怎样保存状态"。Loop Engineering没有重复解决这两个问题，而是把重点放到运行现场：多久启动一次，哪条分支由谁负责，谁来验收，每天最多花多少，以及什么情况下必须停下来。

7套工作流，共用一副骨架

Loop Engineering整理了7类工作流：每日分诊、PR跟进、持续集成修复、依赖更新、更新日志起草、代码合并后的清理，以及问题分诊。

这些工作流处理的都是持续发生的任务：定期检查新情况、追踪没有结束的事项、发现失败后尝试修复、整理变更，并在任务完成后收尾。不同任务的运行频率、风险和成本不同，但共用一副骨架：启动条件、隔离环境、状态记录、执行与检查分工、预算和人工接管。

启动前还要把规格写清楚：它要解决什么、不做什么，多久运行一次，状态保存在哪里，什么结果算合格，出现异常、超出预算或连续失败时由谁接管。智能体可以临场选择下一步，但不能临场决定自己的权限和验收标准。

别一上来就无人值守

项目把自动化程度分成三级：L1只报告，L2在人工确认下辅助处理，L3才是无人值守。第一条Loop应从L1开始。

以每日分诊为例，第一版每天固定时间读取新增事项，按紧急程度和负责人整理成报告，但不修改状态、不分配任务，也不向外发送。第一周只检查报告有没有漏项、重复、误判和错误归类。稳定后，才允许它添加标签或起草回复；再经过一段时间观察，才考虑让低风险部分自动执行。

第一次顺利运行最容易制造错觉。它只能说明这条流程能够启动，不能证明状态会一直干净、成本不会累积，也不能证明两条Loop撞在一起时仍然安全。

执行者不能给自己判通过

持续任务还需要把执行和检查分开。完成工作的一方，不适合同时担任唯一验收者。

Anthropic的长任务智能体实验从另一个方向印证了这个问题。研究人员让模型跨多个上下文窗口开发一个类似Claude.ai的网页应用。只给一条高层指令时，智能体容易一次铺开太多工作，在上下文耗尽前留下没有记录的半成品；后续智能体只能猜测前一轮做到了哪里，有时还会在没有完整测试的情况下宣布完成。

Anthropic后来把第一轮和后续开发拆开。初始化智能体先建立启动脚本、功能清单、进度文件和初始代码提交；后续智能体每次只推进一个功能，开工前读取进度文件和代码记录，结束时更新进度并提交代码。这样做的目的不是保存全部聊天历史，而是给下一轮留下少量、结构化的工作状态。

"完成"也不再由模型一句话决定。Anthropic要求智能体使用浏览器自动化工具，从普通用户视角做端到端测试。官方文章同时承认，模型视觉和浏览器工具仍有盲区，例如无法看见某些浏览器原生弹窗，因此测试通过也不能覆盖所有错误。

这项实验并不是Loop Engineering的采用案例，但它说明了相同的风险。项目把执行者与检查者分开，也是为了避免同一套判断既当运动员又当裁判。

800万token，说明刹车不是装饰

仓库还收录了一则项目方失败复盘。据这份复盘，一条每5分钟检查持续集成状态、发现失败就尝试修复的Loop，在48小时内消耗约800万token，并提出11个PR。其中3个只修复了表面症状，另有1个改坏生产配置，所幸被人工审查拦下。团队在第4天关闭了它。这里的800万token是模型用量，复盘没有把它换算成费用。

失败原因很具体：没有先经过只报告阶段；部分运行中，执行与验收来自同一会话；没有分支白名单；也没有每日预算。复盘称，后来这条Loop改为只监控主分支，先只报告一周，检查交给独立智能体，并把每天的token上限设为200万。

说实话，这类由项目方自己讲述的失败复盘，很容易因为数字醒目而被当成"方法有效"的证明。800万token本身证明不了什么，真正有用的是它把失控条件列得很清楚。项目方既是复盘对象，也是故事讲述者，因此这组数字可以用来展示一条Loop如何失控，却不能证明这套方法已经通过大规模生产验证。

两个Loop撞在一起，麻烦不只是多花钱

单条循环能稳定运行，还不等于多条循环可以安全共存。

据仓库的另一则自述，持续集成修复任务在14时02分开始处理某个PR，PR跟进任务在14时07分又为同一个问题提出了另一套修改。该记录称，结果出现两次重复修复和相互冲突的提交，单个PR的模型用量从通常约8万token升到约40万，人工又花了45分钟梳理。

多条Loop碰撞比单条Loop超预算更棘手。单条Loop烧得太快，还可以用token上限兜住；两条Loop同时修改一个目标，问题就变成谁拥有修改权、哪一份结果可信，以及失败现场还能不能还原。

项目把根因归结为缺少冲突检查。它后来给出的规则是：同一时间，一条分支只能由一个会修改代码的Loop负责；每条Loop使用独立状态文件，并写下自己正在处理的分支或PR。其他Loop动手前先读取这些状态，发现目标重合就跳过并记录。

项目还规定了冲突时的优先级：主分支持续集成失败优先，随后是活跃PR、依赖更新和合并后清理；只生成报告的每日分诊不参与争夺。这套办法牺牲了一部分并行速度，换取分支所有权和失败现场不被反复改写。

这组数字同样来自项目方自述，不能代表行业平均水平。它更重要的作用，是把"多个智能体会互相打架"落到可检查的对象上：目标是否重合、谁拥有修改权、状态能否互相看见，以及总预算由谁统筹。

结语

Loop Engineering当前提供的是面向AI编程工具的模式、模板和检查工具。约7500个星标说明它受到关注，但从模式到生产还有很长的距离。项目自述的两则失败案例至少说明，单条Loop会失控，多条Loop还会争夺同一个目标。

Loop可以不停地跑，但规则必须先于授权：能不能动手、谁来判定完成、发生冲突时谁让路、什么时候必须停下来，都要在人把操作权交出去之前写清楚。