如何设计Loop GitHub 7500星项目给出标准答案与详细实例

最近，AI编程智能体圈子里，“Loop”这个术语出现的频率越来越高。简单来说，它让智能体在一个任务里持续完成“做一步、看结果、再决定下一步”的循环。 6月7日，Addy Osmani 发表了一篇题为《Loop Engineering》的文章，系统性地梳理了这个概念。他引用了Claude Code负责人Boris Cherny的话——自己的工作已经变成了“写Loop”，让Loop去提示Claude、判断下一步该做什么；“龙虾之父”Peter Steinberger也说，人的工作正从写提示词，转向设计能提示智能体的循环。 但“设计Loop”如果只停留在口号层面，那它跟其他新鲜词也没什么区别。工程上很快就会碰到一堆具体问题：上一轮进度怎么衔接？结果由谁检查？成本怎么控制？多个循环同时修改同一份文件时谁该让步？什么时候必须停下来交给人类？ GitHub上的LoopEngineering项目，正是试图把这些问号一个个拆开。截至7月14日，这个项目已经收获了约7500个星标，页面显示有218次提交。它不提供模型，而是给持续运行的AI编程智能体补上调度、状态记录、独立验收、预算限制和停止机制。

**重复提示词，为什么还不算Loop** 单次提示词解决的是“这一轮让AI做什么”。Loop还要回答另一组问题：任务从哪里来？上一轮留下了什么？什么结果算完成？失败后要不要重试？以及什么时候必须停下来交给人。 Loop要带着上一轮的结果继续运行。每一轮都要发现任务、读取状态、执行一步、检查结果，再记录进度并决定下一步。上一轮看到了什么、试过什么、失败在哪里，这些信息都得进入下一轮的判断依据里。 举个例子，如果你让智能体“每天检查项目问题”，这句话根本没说明它该看哪些问题、如何排除重复项、能否直接关闭问题、报告放在哪里，更别提判断错误时该怎么办了。缺少这些边界，定时任务本质上只是反复调用模型，跟真正的Loop差得远。 **Loop早已有之，变化发生在工程层** 让模型在“思考、行动、观察”之间循环，这个概念的历史比2026年早得多。2024年10月发布的ReAct论文，已经让大模型交替生成推理过程和具体动作，再从知识库或外部环境获取新信息，用下一轮推理更新计划。 2024年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可以不停地跑，但规则必须先于授权：能不能动手、谁来判定完成、发生冲突时谁让路、什么时候必须停下来，都要在人把操作权交出去之前写清楚。