大家好，我是王不二。
最近 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 框架 来解决这个问题。
简单说，就是给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 优化的是执行过程。
| 传统 Agent | Loop 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 终将不只是一个被动响应的工具，而会逐渐演变为能够自主执行、反馈和优化的智能系统。
但通往这个未来，并不会依靠某一个万能框架一步到位。