大家好我是王不二。最近 Loop Engineering 风头一时无两各类营销炒作层出不穷。有人觉得代表了下一代 AI Agent 的终极形态也有人认为这不过是给已有 Agent Loop 换了一个新名字。那么 Loop Engineering 到底是什么它真的有技术突破吗该如何真正落地今天我结合自身经验以及一些实际案例带大家拆解 Loop Engineering 背后的技术逻辑、适用边界以及未来发展方向。Loop Engineering 概念的崛起你是否也有过这样的场景让 AI 干活你先说一遍AI 干一遍你看对不对验收一下。不对你得告诉它哪里不对、怎么调整AI 基于你的反馈再来一遍直到你满意为止。这个模式有个名字叫Human-in-the-Loop——人在回路。人始终待在循环里每一轮都由你来驱动、把控质量、给出调整方向。那么问题来了如果我们希望 Agent 连续运行几小时、几天甚至几个月呢人不可能永远坐在那里审核每一步。那我是不是可以设计一套机制让 AI 自己判断输出质量自己调整方向自己决定要不要继续这就是Loop Engineering想解决的问题。这种设计思想最早是 Claude Code 的负责人 Boris Cherny 提出。2026 年 6 月初他在一次公开演讲中说I don’t prompt Claude anymore. I have loops running. They’re the ones prompting Claude and figuring out what to do. My job is to write loops.“我不再 prompt Claude 了。我写好 Loop 让它们自己跑Loop 去 prompt Claude决定下一步做什么。我的工作就是写 Loop。” 这是第一次让 Loop Engineering 的设计思想走入视野。随后6 月中旬Google Chrome 的工程师 Addy Osmani在 Substack 发表长文正式把这种技术命名为Loop Engineering并系统化整理成完整的工程框架理论。这篇文章被广泛转发Loop Engineering 从大佬们的口头禅变成了一门可复用的工程方法论。注意这玩意是方法论哦用于指导Agent设计并不是可以直接拿来开箱即用的框架。内循环Inner Loop与外循环Outer Loop我发现搞技术的都有点仓颉在身上的特别喜欢造词。不过不要慌这两个的概念也很简单。要了解内循环和外循环我们先看看在Loop Engineering之前Agent 是怎么运行的。其实大家早就发现AI在执行的时候很多情况下没办法一次性把任务干好经常需要多次执行边做边思考。2022 年Yao Shunyu 提出了ReAct 框架来解决这个问题详细参考【一文读懂大模型三大核心技术ReAct、Function Call 与 MCP 的奥秘】。简单说就是给AI规定一个工作流程思考Thought→ 行动Action→ 观察Observation→ 再思考 → 再行动 → 再观察……直到AI觉得任务完成的差不多了可以停止了。这个就是内循环也就是AI主动循环保证任务的完成度。我们现在使用的Agent基本都是这样的给他一个指令AI需要执行执行完成以后再让你审核这个过程其实AI已经自己主动循环了好几次了。有时候AI自己执行完成虽然AI已经审核了好几遍但是还是不满意需要我们基于结果给AI下达新的指令让AI去完成。这个过程同样可能经过好几次才能达到最终的要求。这个就是外循环之前是由人主导循环Loop Engineering的思想是通过验证器替代人完成这一层的循环。所以内循环和外循环共同协作起来其实是这样的。Loop Engineering 与传统 Agent 的本质区别这是理解 Loop Engineering 最关键的一点。其实明白了前面的内外循环关系就可以明白 Loop Engineering 与传统 Agent 的最核心差异了。传统的Agent任务下达以后Agent 部分只负责内循环只关注指令是否完成完成的满不满意暂且不管。Loop Engineering 需要关注的是在指令完成以后整个任务是否还可以持续优化持续拿出更好的成果。传统 Agent 优化的是执行结果Loop Engineering优化的是执行过程。传统 AgentLoop Engineering关注点完成任务优化完成过程循环位置Agent内部系统级设计反馈来源AI执行结果自动验证机制停止方式模型判断验证器判断优化对象结果整个过程循环退出条件Loop 的适用边界Loop Engineering的核心思想其实就是Human-in-the-Loop 到 Human-as-Loop-Designer 的转变把人从循环的参与者变成循环的设计者。所以采用 Loop Engineering 的思想去指导落地的话那么就一定会面临一个重要问题什么时候退出循环。很多场景下退出条件很难说清楚。比如让 AI 帮你写文章你来审你能定义写到什么程度算满意吗思考一下就会发现清晰的退出条件就是 Loop Engineering 的适用边界。对于通用Agent每次的任务都不一样不可能提前规定好每次的退出条件即使可以规定一个大概这个Loop也很难达到较高的精度或者满意度。如果让用户在使用的时候自己去规定退出条件如何。那么又要面临用户能不能描述清楚退出条件甚至有些情况下根本就无法准确给出退出条件比如我刚才提到的写文章场景。这一类情况使用Loop Engineering的话显然具有较大的挑战难度。所以由此可以得出结论Loop Engineering在专项任务、退出条件可以明确给出的场景下能够更大的发挥作用这也是Loop Engineering本身的舒适区。我搜集整理了几组典型落地案例不论是 Boris Cherny 借助 Claude Code 实现零手写代码、自动提交 PR还是 Anthropic 在 8 张 H100 上开展模型训练实验严格依照 9 项检查清单完成闭环亦或是 GitHub 开源框架则内置七类标准工作流覆盖每日巡检、PR 管理、依赖更新、日志生成等场景。这些案例均集中在软件开发领域。这种场景任务目标明确类似编译通过、测试达标、模型指标满足等天然就是循环退出条件只需将现有校验规则接入循环即可无需额外设计。当然啦有一些骨骼惊奇的小伙伴可能会问。如果有一些场景不好规定退出条件我能不能先让AI简单搞几轮然后我再介入呢这样即减少了人力参与也可以让人兜底不是很好吗恭喜你有这个想法 你就已经和大佬们站在同一水平线上了这个就是吴恩达的三层Loop的思想利用循环外面再套一层循环的方式兜底。吴恩达的三层Loop目前三层Loop体系其实存在两套定义这也是网上相关解释参差不齐、容易让人混淆的主要原因。两套理论来源不同、划分维度也不同。最早的三层Loop概念由Boris Cherny提出这套体系的核心划分依据是人在Loop Engineering中的参与程度简单分为三个梯度人类完全参与、人类有限参与、人类完全不参与本质是对人机协作参与度的层级划分偏向定性的程度区分。后续吴恩达提出了另一套更通用、落地指导性更强的三层Loop模型。他跳出了单纯的参与度维度结合反馈时间尺度与人员角色差异对AI软件开发的Loop Engineering做了标准化分层内层Agent 编码循环分钟级这是AI自主运行的闭环。由AI Agent独立完成代码编写、自动化测试、Bug修复的全流程迭代无需人工介入是迭代频率最高的一层循环。中层开发者反馈循环小时级引入人工干预的中间闭环。开发者定期审核AI Agent的产出成果针对代码方向、逻辑偏差、细节问题给出修正指引与优化指令迭代周期明显拉长。外层用户反馈循环天/周级面向真实业务的终极闭环。产品上线后基于真实用户的使用行为、体验反馈结合A/B测试等数据结果为产品迭代提供依据是迭代频率最低、周期最长的一环。很多解读比较纠结三层Loop与前面提到的内外循环的对应关系到底哪层对应哪层。我觉得大可不必纠结。一方面提出的人不同情景不同本身两套理论就没有强制关联只是设计思想上类似。另一方面从落地角度来说两套理论的对应关系本身也无关紧要。不论是三层Loop还是内外循环都只是方法论层面的指导而非硬性标准。实际落地中只要贴合业务场景、Loop 逻辑完备就好。特此说明也希望能帮大家理清概念误区不必为细枝末节的定义差异过度纠结。Loop Engineering 六大组件Loop Engineering 还提到了一个六大组件的概念这些组件或者能力目前主流Agent都已具备这里只简单提一下。Automations 自动触发器循环启动源支持定时、条件、事件触发执行与结果判定相互独立。Worktrees 工作区隔离为多Agent划分独立空间避免并行操作冲突并行能力受审查效率限制。Skills 能力知识库沉淀规范、经验与问题方案Agent自动加载统一行为标准。Connectors 外部连接器对接各类第三方工具与服务打通完整业务流程。Sub-agents 子代理组拆分执行、审核角色做交叉校验保障长期运行可靠。State 持久化状态留存任务数据与进度实现断点续跑补足大模型长期记忆不足的问题。冷静看 Loop Engineering概念大于落地但方向没错首先要承认Loop Engineering 的方向是正确的。它的核心价值在于推动 Agent 从单轮任务执行走向多层反馈系统。通过验证器替代部分人工巡检让质量评估和退出条件变得可编程。这实际上代表着 Agent 架构的一次演进从过去的“人驱动循环”走向未来的“人设计循环机器自主运行”。但与此同时也必须保持清醒。目前 Loop Engineering 仍然处于概念先行、标准缺位、各凭手艺的阶段。真正能够在复杂生产业务中长期稳定运行的案例还非常有限。无论是 Addy Osmani 总结的经典模式还是目前开源社区提供的各种框架和脚手架本质上都仍然是在验证信号最丰富的软件工程场景中探索。一旦离开这个环境进入产品设计、内容创作、战略分析等复杂场景Loop Engineering 将会迎来他真正的挑战。认可 Loop Engineering 的方向审慎看待 Loop Engineering 的落地。它指向的未来是真实存在的Agent 终将不只是一个被动响应的工具而会逐渐演变为能够自主执行、反馈和优化的智能系统。但通往这个未来并不会依靠某一个万能框架一步到位。