什么是 Loop Engineering

前言

最近，我发现 AI 领域又出现一个新的概念，叫做 Loop（循环）或者叫 Loop Engineering（中文翻译一般叫 "循环工程"）。因此，今天想重点和大家聊聊这个话题，尽量稍微系统化地介绍一下 Loop 与 Loop Engineering 究竟是什么，以及它们背后有哪些思考？

之所以突然关注 Loop 以及 Loop Engineering 的技术概念，主要是因为最近 AI 行业里不少大佬都在密集讨论这个话题。

首先，作为 AI 领域的风向标，Anthropic 公司 Claude Code 的负责人 Boris Cherny 就明确表示，他在使用 Claude Code 时已经不再手写提示词 Prompt 了，而是转向编写 Loop，用 Loop 来驱动工作流的完成。与此同时，小龙虾 OpenClaw 的创始人 Peter Steinberger 也在 X 上指出过，我们不应该再用传统的提示词去指挥 Agent，而应该通过设计 Loop 来引导 Agent 的行为。此外，AI 大神、也是 Vibe Coding 和 LLM-Wiki 的提出者 Andrej Karpathy，也在同样强调说 "你必须把你自己从 Loop 的执行过程中移除出去"。就在 6 月初（也就是上周），Google AI 总监 Addy Osmani 专门写了一篇文章，正式定义了 "Loop Engineering" 这个概念，并在文章开头就给出了一句核心定义：

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

翻译：Loop Engineering 就是把你从 "给 Agent 提示词的人" 这个位置上替换掉。你不需要再亲自去写提示词，而是转而设计一套能够自动完成这件事的系统。

听到这里，可能很多同学会觉得：Loop？不就是循环吗？Agent 本身不就是一个 Loop 吗？但需要强调的是，此 Loop 非彼 Loop。接下来，我就重点为大家拆解一下这背后的区别与深意。

一、三个阶段演进：Coding → Vibe Coding → Loop Engineering

1. Coding（写代码）

核心动作：人写代码

完整流程：

需求分析：理解需求，设计方案
编写代码：手动编码实现功能
运行测试：手动运行，逐行调试
部署上线：打包编译，交付使用

特点：

从需求到交付，全程由人完成；耗时长、重复劳动多。

总结：人写代码，逐步实现。

2. Vibe Coding（提需求）

核心动作：人提需求，模型生成代码

完整流程：

提出需求：用自然语言描述要实现的功能
模型生成代码：AI 输出源码，生成代码文件
运行与调试：运行代码，验证结果
交付使用：打包提交交付使用

特点：

从 "写代码" 变成了 "提需求"，效率更高，但仍是一次性任务。

总结：人提需求，模型生成。

3. Loop Engineering（提一套闭环流程）

核心动作：人一套闭环流程，让模型自己转起来

完整流程：

开发 / 实现：模型自主完成开发、编码实现
测试 / 验收：基于测试用例自动验证结果
反馈 / 分析：收集错误、定位问题根源
调优 / 改进：重构系统、修复问题、优化方案

循环往复，直至达到预设终止条件；达标后自动收尾交付。

特点：

从 "提一个需求" 变成了 "提一套闭环流程"；模型在定义好的流程中自主完成开发、调试、验收、调优和迭代升级，无需人工反复干预。

总结：人定义流程，模型闭环迭代，达成目标。

这个演进脉络关键变化：

从 Coding 到 Vibe Coding：我们从「写代码」变成了「提需求」；

从 Vibe Coding 到 Loop Engineering：我们从「提一个需求」升级为「设计一套闭环流程」。

我们不再只告诉模型要做什么，而是把开发、测试、验收、调优、再到反馈迭代的完整链路全部定义好，让模型在这套流程里自主运转迭代，这是 Loop Engineering 最核心的价值。

二、Agent Loop vs Loop Engineering 本质区别

要理解 Loop Engineering，首先要厘清这个 Loop 和基础 Agent Loop 的本质差异。

1. Agent Loop（智能体内部循环）

本质：模型与工具之间的内部执行小循环 原理： Agent 本身天然就是一个 Loop，大模型单次运行是「输入一段话、输出一段话」，不会自动串联多轮工具调用与推理。想要 Agent 自动化持续运行，就必须封装成循环结构：

输入内容进入 LLM
模型输出分为两种结果：
- Response 自然文本回复：循环终止，输出最终结果
- FunctionCall 工具调用：把工具结果重新喂入模型，开启下一轮循环
  
  只要存在工具调用，就会持续循环执行，直到模型输出纯文本 Response，整个流程结束。
  
  ReAct、Ralph Loop 都是 Agent Loop 的经典实现变种。

流程图：

粒度：单次任务内多轮调用，属于小循环
目标：完成用户单条具体诉求

2. Loop Engineering（外部验收大循环）

本质：人设计控制、面向需求验收的外部大循环 在原生 Agent / HarnessAgent 外层，封装「开发 - 测试 - 反馈 - 调优」完整闭环迭代流程。

流程图：

粒度：任务 / 迭代完整生命周期，属于大循环
目标：交付一套可验收、稳定合格的最终系统
对比差异：
- 旧模式 HITL（人在循环里）：人工在循环内验证、纠错、调校
- 新模式自动化闭环：模型在外部 Loop 中全自动运行、闭环迭代

核心差异总结

那问题来了，既然 Agent Loop 早就有了，为什么最近各路 AI 大佬又开始密集讨论它？他们口中的 Loop 和 Loop Engineering 到底是什么？

其实，大佬们说的这个 Loop，跟刚才讲的底层 Agent Loop 完全不是一回事。底层的 Agent Loop 是 Agent 最核心的基础循环，现在已经是默认的基础设施，没必要再单独拿出来强调。而他们真正想表达的 Loop 以及 Loop Engineering，是构建在 Agent 之上或者说 Harness 之上的，是一种由人来设计和控制 Agent 使用方式的新范式。

举个例子，正常情况下我们用 Agent，大概率是这样的流程：你提一个需求，比如 "帮我实现某某系统的代码" 或者 "搭建一个某某系统"，然后 Claude Code、Codex 这些工具就开始执行。虽然底层有 Agent Loop 在跑，中间也做了各种任务拆解，但最终它会把一个完整的系统交付给你。整体来看，这依然是一个 "一次性" 的过程：你提需求，模型干活，最后交付结果。这时候人要做的就是验收：跑一下系统、看看效果、调试一下是否满足预期。

但在实际使用中，你经常会发现一次提出的需求，Agent 最后的产出结果并不能完全满足你的需求，或者说在测试过程中暴露出来很多问题。于是网上就出现了一个很火的梗：以前写代码用的是标准的 QWERTY 键盘，到了 AI 时代，我的 "键盘" 变成了几个固定按钮，比如 "说中文"、"继续"、"还是报错"、"你改了啥"、"先别重构"、"回滚" 等等。当你使用 Claude Code 或 Codex 时，你的指令大概率就是这些。虽然是个梗，但这确实是我们当下使用 AI 的真实常态。

维度	Agent Loop（内层小循环）	Loop Engineering（外层大循环）
定义	模型与工具之间的内部执行循环,通过 function call 调用工具，将结果作，将结果作为输入继续循环，直到模型给出最终 response	人设计和控制的、面向需求验收的外部大循环;在 Agent（或 Harness）之上，围绕「开发 - 测试 - 反馈 - 优化」的完整流程进行循环迭代
本质	LLM + 工具执行闭环	人定义规则，多层级自动化业务闭环
层级	单次任务内部执行链	完整项目全生命周期迭代链
人力介入	一次需求交付后人工验收	定义完规则后极少人工介入
定位	Agent 底层基础能力	Agent 上层工程化设计范式

三、Loop Engineering 诞生背景：把「人机协同循环」升级为「自动化验收闭环」

日常使用 Agent 编码的真实现状：

我们给 AI 提一个开发需求，Agent 完成代码编写交付之后，我们需要手动运行测试、发现 bug、然后反复输入指令：说中文``继续``还是报错``你改了啥``先别重构``回滚代码

这是典型 Human-in-the-loop 人机协同循环

Loop Engineering 要解决的核心问题：

能不能在最开始定义整套闭环规则，让模型不需要人反复下发纠错指令，自主完成测试、校验、排错、优化迭代，直到满足验收标准

把原本人工来做的验收、纠错、反馈、调优环节全部自动化封装进 Loop 流程，人只需要定义目标、验收标准、循环终止条件，后续全流程由模型自主闭环运行。

更进一步：

普通单次 Agent 调用很容易出现幻觉、死循环、结果不达标等问题；Loop Engineering 在原生 Agent 外层增加多层校验、子 Agent 评审、终止判定、定时调度、状态追踪能力，从工程层面规避原生 Agent 缺陷，让复杂长任务可以全自动稳定跑完。

说白了，Loop Engineering 本质上就是一种可以循环起来的 Pipeline。这种 Pipeline 的触发方式主要有两种：

人工触发：直接编写 Loop 流水线，手动启动执行
定时触发：Cron 定时、事件 Hook 触发，周期性自动运行

案例：每日代码评审合并、自动生成周报日报、定时数据盯盘交易等，都可以封装成 Loop 自动执行。

四、Loop Engineering 六大核心框架（Addy Osmani 定义）

一个标准完整 Loop 包含六大核心组成单元：

核心模块	释义	Codex 实现	Claude Code 实现
Automations 自动化	定时 / 手动触发循环执行	定时任务、Triage 收件箱、goal 指令	Cron 定时、Hook 触发、/loop/goal 指令
Worktrees 工作树隔离	多任务并行环境隔离，避免文件冲突	内置多线程独立工作树	--worktree 参数、isolation 隔离配置
Skills 进化技能包	可沉淀、可迭代升级的能力单元	SKILL.md 技能定义文件	Agent Skills 技能配置
Connectors / Plugins 连接器插件	外部系统、API、工具接入层	MCP 连接器 + 各类插件	MCP Server + 插件生态
Sub-agents 子智能体	拆分独立子角色分工协作、交叉校验	TOML 配置定义子 Agent	.claude/agents 拆分多子 Agent 团队
State 状态管理	记录任务进度、完成节点	Markdown / 线性项目工具对接	AGENTS.md、MCP 对接项目管理平台

1. Automations（自动化）

有了 Automations（自动化），Loop 就可以定时循环了，不然就只是手动跑一次的一次性操作。比如使用 Codex 就可以创建一个自动化任务：选好项目、定好要跑的 Prompt、设定频率，还能选择是在本地代码上跑还是在云端后台分支上跑。要是跑出来发现问题了，它就进 Triage 收件箱；没发现问题就直接自动归档。比如每天的一些问题分类、CI 失败总结、写提交简报，还有排查上别人引入的 Bug 等等。Codex 还有个命令，叫做 /goal，会在多轮对话里持续工作，一直跑到你设定的条件真正满足为止，还支持暂停、恢复和清除。

Claude Code 也类似，只不过它是靠 Cron 调度和 Hook 实现的。你可以用 /loop 命令让某个 Prompt 或命令间隔跑，可以设置 Cron 定时任务，也能在 Agent 生命周期的特定节点用 Hook 触发 Shell 命令。核心逻辑也一样：定义一个自主任务，给它定好节奏，然后等着看结果就可以了。另外，Claude Code 也支持 /goal 命令，每轮交互之后，会有个独立的小模型来检查是不是完成了，因此写代码的 Agent 不是给自己打分的那个。你只要给它定个目标，比如test/auth 下所有测试都通过且 lint 检查无误，然后就可以不管了。

2. Worktrees（工作树隔离）

只要你同时跑多个 Agent，就很容易有文件冲突的问题，也很容易导致任务失败。两个 Agent 同时改同一个文件，就有点像两个工程师没打招呼就往同一行代码里提交修改一样，那么怎么解决呢？其实很简单，使用 Git 的 Worktree 就能解决这个问题，它本质上是一个独立的工作目录，有自己的分支，但共享同一个仓库历史，所以一个 Agent 的改动根本碰不到另一个 Agent 的代码。

Codex 是直接把 Worktree 支持内置进去了，这样多个线程可以同时操作同一个仓库而不会互相打架。

Claude Code 也提供了相同的隔离能力：你可以用 --worktree``isolation: worktree

3. Skills（可进化的技能包）

关于 Skill，我在之前的文章中讲过很多次了，这里就不赘述了。Skill 就是一种可渐进式披露、可复用的能力包，基本上由 Markdown 文档、代码脚本这些组成。但在 Loop Engineering 这里，如果 Skill 具备自我沉淀的能力，它就能在 Loop 的每一次循环中不断更新、积累经验，变成一种 "活的知识"。这样 Agent 就不会每次都在同一个坑里跌倒，而是越跑越聪明，真正实现能力的迭代与复用。

4. Connectors / Plugins（连接器 / 插件）

Connectors / Plugins 本质上就是 MCP 及其延伸的各类工具，负责把各种外部 API 工具接入 Agent。有了这些，模型才能真正 "伸手" 触达现实世界中的各类服务与数据源。没有 Connectors 或者 Plugin，Agent 就只是一个封闭的推理引擎；有了它，Agent 才具备完成实际任务的行动能力。这也就是目前大家最熟悉、落地最广泛的基础设施了。

5. Sub Agents（子智能体）

第五个核心部分是 Sub Agents，也就是子 Agent。你可以把它理解为在主 Loop 运行过程中动态生成的 "分支智能体"，它们各司其职，共同支撑整个循环的高质量运转。

举个典型的例子：当主 Agent 完成开发任务后，我们可以生成一个独立的验收 Sub Agent 来检查结果。这个验收 Agent 拥有自己专属的 Prompt 和验证标准，与主 Agent 完全解耦。这种设计刻意制造了一种 "博弈" 的关系，如果主 Agent 的产出不符合需求，验收 Agent 就会提出质疑和挑战。之所以不让主 Agent 自我检查，是因为它往往 "当局者迷"，就有点像我们，我们自己写完代码总觉得完美无缺，但换个人一看就能发现问题。引入独立的验证的 Sub Agent，本质上就是用角色隔离来打破这种认知盲区。

当然，Sub Agent 的价值远不止于验证。在复杂任务中，探索、设计、实现等环节都可以拆分为独立的 Sub Agent 并行执行。它们各自拥有更大的发挥空间，又能通过相互制衡提升整体产出质量。不过需要注意的是，Sub Agent 并非越多越好。如果缺乏主 Agent 的有效调度，多个子 Agent 很容易各干各的，导致结果分崩离析、失去一致性。因此，是否拆分、如何拆分，必须根据具体任务特性来决定。

核心原则是：对于探索性、分析性的子任务，可以大胆生成 Sub Agent 来分担；但最终结果必须汇总回主 Agent 进行整合；而验证类 Sub Agent，务必保持独立，避免 "既当运动员又当裁判员"。只有这样，Loop 才能在自动化运转的同时，守住质量的底线。

6. 状态（State）

最后，是状态管理，也就是怎么追踪 "哪些事已经做完了"。这块可以用 Markdown 文件来记录，比如搞一个 AGENTS.md 或者专门的进度文件；要是习惯用 Linear 这类项目管理工具，也可以通过 MCP 连接器直接对接上去，让 Agent 自动同步状态。

五、实战案例：文本分类任务两种模式对比

传统人工驱动模式

编写提示词：定义分类规则、评判标准
模型批量输出分类结果
人工校验准确率，标注错误样本
手动修改提示词，重新投喂样本迭代
迭代稳定后沉淀为 Skill，后续复用

痛点：大量人工介入校验修正，效率低，人力成本高

Loop 自动化闭环模式

定义 Loop 规则：分类标准、验收指标（如准确率≥95%）、迭代上限
Agent 第一轮批量分类输出结果
内置校验子 Agent 自动核验准确率，定位错误案例
模型自主优化分类逻辑，迭代新一轮结果
循环往复，指标达标自动终止，沉淀优化后的分类 Skill

优势：全程无人工干预，自主闭环打磨，迭代效率更高

Loop 模式和 Skill 自进化框架核心区别：

Loop 不依赖外部框架，只需要定义闭环流程，Agent 在循环内自主搭建校验逻辑、测试流程、优化代码，完全自主驱动迭代，自由度更高、落地门槛更低。

在 AI 时代，你未必需要先造一个全新的框架才能实现高级能力，只要用 Claude Code 或 Codex 写一个结构化的 Loop，很多原本需要工程化封装的能力，现在可以直接 "跑" 出来。

Loop Engineering 的核心意义：它不是取代 AI Coding，而是在 AI Coding 的基础上，进一步压缩了 Human-in-the-Loop 的比例。人不再需要全程盯着、反复纠错，只需设定清晰的目标和验收标准，然后等待 Agent 自主达到预期水位后再做最终确认。所以 Loop Engineering 概念也没那么复杂，它可以被普通人快速上手，并在真实任务中显著提升自动化程度与交付质量。

比如你这个文本分类任务每天都要跑，也可以设定成定时 Loop 每天去运行。但个人还是更推荐把这类成熟任务沉淀成脚本或者 Skill，而不是每天新开一个 Loop 去跑。原因很简单：一是每天重跑 Loop 太费 token；二是大模型每次跑 Loop 的实现路径不一定一样，哪怕需求没变，今天和明天的代码、实现方式也可能有较大差别，结果就容易漂移，不好复现。

所以建议是：如果流程是固定的、不需要模型每次都重新推理，那就直接写成脚本；如果确实需要模型每天介入、做动态判断，那就把它做成可复用的 Skill。这样既用上了 Loop Engineering 的思路，又能保证运行的稳定、成本可控。

六、Loop Engineering 的优势与边界局限

核心优势

大幅降低人工干预成本

把反复纠错、调试、验收、优化的人力工作全部封装进循环，人只做顶层设计和最终验收，中间流程全自动执行。
标准化工程落地能力

在原生 Agent 外层增加流程约束、校验机制、环境隔离、状态追踪，让随性的大模型输出变得工程化、稳定可控。
长任务复杂场景适配性更强

长链路多步骤任务，依靠单层 Agent 极易中途跑偏、幻觉崩坏；多层闭环 Loop 可以分段校验、阶段性复盘，保障超长任务稳定跑完。
能力沉淀迭代

循环过程中自动沉淀优化 Skill，同一个任务运行越多，模型适配性越强，后续调用效果越来越好。

适用边界与坑点

对需求 & 验收标准清晰度要求极高

传统 HITL 模式下，需求模糊也没关系，人工可以在迭代过程中不断纠偏；

Loop 全自动闭环模式下，如果需求定义模糊、验收规则含糊不清，循环会全程跑偏，大量浪费 Token 成本，最终结果完全不符合预期。
模糊需求场景不建议直接上 Loop

如果业务需求经常变动、验证标准无法量化，更适合使用人工穿插反馈的 HITL 模式；需求明确、指标量化、流程固定的场景，Loop 才是最优解。
Loop 不是银弹，是现有 Agent 体系的上层封装

Loop Engineering 没有颠覆原有 Agent、ReAct 技术，只是在现有基础上做工程范式升级，底层依然依赖 LLM 推理、工具调用、中间件机制，不存在颠覆性黑科技。

选型建议

流程固定、判断逻辑明确、指标可量化 → 优先设计 Loop 闭环自动化运行
需求多变、标准模糊、业务探索期 → 先用人工介入的人机循环模式迭代
成熟稳定后的高频任务，可以把 Loop 迭代后的最优能力沉淀为 Skill，兼顾运行稳定与低成本

七、全文总结

技术演进链路：手动 Coding → Vibe Coding 提需求 → Loop Engineering 定义闭环流程，AI 自动化程度逐层升级，人的工作从编码执行转向流程顶层设计。
两层 Loop 区分：
- Agent Loop：LLM + 工具底层小循环，是所有智能体的基础能力
- Loop Engineering：业务流程外层大闭环，属于工程化设计范式
Loop Engineering 核心思想：把「人反复提示纠错驱动模型优化」改成「人定义闭环规则，模型自主循环迭代、自检优化」，把人从重复调试、验收的劳动里释放出来。
落地关键：清晰的需求定义、量化可落地的验收标准、分层拆解的闭环链路、环境隔离与状态追踪、多子 Agent 交叉校验，是一套成熟 Loop 方案必备的五大要素。
技术没有万能方案，Loop 适合标准化、长周期、高自动化诉求的场景；模糊探索类业务，人工介入迭代依然是更稳妥经济的选择。

Loop 本质是 AI Agent 工业化落地的一种工程思路，依托现有技术，通过流程设计进一步释放大模型自动化价值，也是当前 AI 工程领域最热门的实践方向之一。