都在说Loop，但怎么设计？这个GitHub 7500星项目告诉你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撞在一起时仍然安全。
执行者不能给自己判通过
持续任务还需要把执行和检查分开。完成工作的一方，不适合同时担任唯一验收者。