企业官网建设流程全解析

大家好，我是王不二。

最近 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优化的是执行过程。

循环退出条件：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都已具备，这里只简单提一下。

1. Automations 自动触发器：循环启动源，支持定时、条件、事件触发，执行与结果判定相互独立。

2. Worktrees 工作区隔离：为多Agent划分独立空间，避免并行操作冲突，并行能力受审查效率限制。

3. Skills 能力知识库：沉淀规范、经验与问题方案，Agent自动加载，统一行为标准。

4. Connectors 外部连接器：对接各类第三方工具与服务，打通完整业务流程。

5. Sub-agents 子代理组：拆分执行、审核角色做交叉校验，保障长期运行可靠。

6. State 持久化状态：留存任务数据与进度，实现断点续跑，补足大模型长期记忆不足的问题。

冷静看 Loop Engineering：概念大于落地，但方向没错

首先要承认，Loop Engineering 的方向是正确的。

它的核心价值，在于推动 Agent 从单轮任务执行走向多层反馈系统。通过验证器替代部分人工巡检，让质量评估和退出条件变得可编程。

这实际上代表着 Agent 架构的一次演进，从过去的“人驱动循环”，走向未来的“人设计循环，机器自主运行”。

但与此同时，也必须保持清醒。目前 Loop Engineering 仍然处于概念先行、标准缺位、各凭手艺的阶段。真正能够在复杂生产业务中长期稳定运行的案例，还非常有限。

无论是 Addy Osmani 总结的经典模式，还是目前开源社区提供的各种框架和脚手架，本质上都仍然是在验证信号最丰富的软件工程场景中探索。一旦离开这个环境，进入产品设计、内容创作、战略分析等复杂场景，Loop Engineering 将会迎来他真正的挑战。

认可 Loop Engineering 的方向，审慎看待 Loop Engineering 的落地。

它指向的未来是真实存在的，Agent 终将不只是一个被动响应的工具，而会逐渐演变为能够自主执行、反馈和优化的智能系统。

但通往这个未来，并不会依靠某一个万能框架一步到位。