摘要
很多人第一次接触 Loop Engineering，容易把它想成 “让 Agent 自动跑起来”。但真正的分水岭，其实是你站在哪个位置：是继续当那个在旁边逐句下指令、盯着每一步的人，还是退后一步，搭一个能替你转动的机制。
这个机制要替你做的，是一连串原本得你亲自来回操作的事：它得自己醒过来开工，而不是等你点一下；它得知道资料藏在哪、怎么去取；它得在干完之后回头掂量一下成果到底成不成；遇到失败，它得自己判断值不值得再试一遍；它还得随时把 “现在进展到哪儿” 这件事记下来，免得下一轮又从头来过。
而最容易被忽略的一点是：它得懂得在恰当的时候停手，把决定权重新交回到人手上。
把这些拼到一起，你会发现，Loop Engineering 并没有发明什么新东西：它依旧是一套工作流，只不过这套流程的驱动者，从 “你” 换成了 “AI”。
前言
过去几个月，很多人其实都在反复做同一件事：
-
写一段 Prompt → 交给 Coding Agent
-
等它跑完 → 查看结果、做个测试
-
不对 → 再写下一段 Prompt，直到满足心中的要求
时间一长你会意识到：这本身就是一个循环。 只不过那个负责“再来一轮”的循环体，是坐在屏幕前的人。
如果连“看守”这一步也交给 AI 呢？ 把屏幕前的用户也换成 AI Agent，就引出了最近常被提起的热词：Loop Engineering。
这个名字听上去抽象，落到实处其实只有一句话：把 Loop 的执行者从人换成 Agent。
原本由你亲自跑的“发现问题—想办法—动手—检查”循环，现在交给 Agent 去跑。你要做的，只剩开头把目标（验收标准）说清楚。
不少 Coding Agent 重度用户早已通过 Skill 实践类似做法，只是叫法不一、颗粒度不同。
直到 Claude Code 作者 Boris 和 OpenClaw 作者 Peter 反复提及“Loop Engineering”，它才逐渐流行。
本文是把这套做法的骨架梳理出来，让它从“Early Adopter 的先进工作流”变成“你也能照做的步骤”。
有的人说：Loop Engineering 就是数字员工的开始。
先看一张全景图，后文要展开的环节都在这幅 Closed Loop 里：
-
目标由用户设定
-
之后 Discovery → Plan → Execute → Verify 依次接力
-
达标就 Ship，不达标就回到 Discovery 再来一轮
-
Memory 位于对话之外，为每一轮递上进度的“接力棒”
手工循环：你就是循环的执行者
回想过去几个月，与 Coding Agent 打交道的节奏大概是这样：
你写 Prompt → Agent 干活 → 产出结果 → 你读结果、判断哪里不对 → 再写下一段 Prompt……如此往复，直到做完。
这套节奏熟练到让人忽略了一个事实：它本身就是一个完整的循环。
发现问题、想办法、动手、检查结果，每个环节都在，循环也确实在转。区别只在于：循环体的执行者是你自己。
Agent 干完一轮就停下，安静等着。
真正负责“判断、决定、再来一轮”的角色，由人来扮演。换句话说：这一轮里，是机器在等你。
图里最关键的是那条折返线：从“你读结果”回到“你写 Prompt”，标着“人肉轮询”。
人，被绑在了循环里最频繁的那个位置上。
代价就藏在这条红线里：
-
Agent 每跑完一轮，你都得回到屏幕前查看，否则循环就停在那儿不动
-
注意力被反复切走又切回，刚开始写另一份文档，那边一声“完成”提示音，又得切回来
-
一天下来，注意力被切得很碎，上下文在几件事间反复搬运，真正连续投入的时间反而不多
在 macOS “灵动岛”中查看不同 Coding Agent 的进度
在 ESP32 单片机上查看和控制 Agent
社区里甚至出现过用软件通知、ESP32 硬件来提醒“Agent 已经跑完了”的小工具，从侧面也可以证“人盯着循环”这件事有多普遍。
当你把代价摆在手工循环旁边，问题就清楚了：循环本身没问题，问题在于让人去当那个一刻不能离开的循环体。
既然其余环节 Agent 都能跑，那个“再来一轮”的位置，是不是也能交给 Agent？这正是循环工程要回答的问题。
循环工程：把循环体交给 Agent
手工循环里那个一刻不能离开的位置，现在让 Agent 顶上。你要做的，是从“每一轮都判断、都接力”，缩减成“开头把目标说清楚一次”。
这个新循环并不神秘，就是把你脑子里那几步，显式地交给 Agent 去走：
-
目标：由 human 通过 /goal 设定一次。这是整个循环里 human 唯一必须做、也唯一不该交出去的事：方向得你来定。你也可以借助 grill-me 等机制，让 AI 采访你之后总结成最终目标。
-
Discovery：Agent 自己去发现这一轮要做什么，而不是等你逐条派活。
-
Plan：把发现的事，拆成清晰、可执行的步骤。
-
Execute：动手做。可以采取 fan-out 模式，同时开多个 Agent 并行，各自完成一件互不相干的子任务。
-
Verify：检查目标有没有达成。这是 Loop Engineering 里我认为最重要的一环。 它是 AI 充分理解需求后拆出的验收条件（Rubric），极其考验模型的推理能力，包括但不限于 Lint、编译、单元测试、E2E 测试等。达标就Ship，不达标就带着这一轮暴露的问题回到前面 Iterate（用的正是前面说的 self-prompting）。
-
Memory：最容易被忽视的一环，下一节重点展开。
-
可选一步：Ship 之后，让 Agent 想想”接下来该做什么”，把下一轮入口也备好，循环就能自己续下去。
Memory：活在对话之外
一轮循环跑完，进展得留下来，下一轮才接得上。
问题是：进展该留在哪里？失败的教训放在哪里？
Memory 不在对话里，循环才稳得住。
在我看来，Memory 才是真正区别于“前几个月大家自行探索的 Loop” 与 “Boris 等人提出的 Loop Engineering”的地方：它让 Agent 看上去更像真人了。
Orchestrator（编排）：掌管目标的那个 Agent
Fan-out、验收、接力这些环节，需要一个总控角色统一管起来。
它掌管目标、负责派活，等各路 Agent 干完后汇总结果，再决定是 ship 还是 iterate（迭代）。
这个角色就是 Orchestrator（编排）。
到这里，循环工程的轮廓就完整了：
用户设定目标 → Orchestrator 接手 → fan-out 并行执行 → 验收后 Ship 或 Iterate → 进度写进对话之外的 Memory，让循环接力下去。
接下来的问题是：这个 Loop 该敞开探索，还是该框定边界？
这就要分 「Open Loop」 和 「Closed Loop」 两种形态来谈。
Open Loop 与 Closed Loop：预算花在哪里
把循环体交给 Agent 之后，最先要面对的不是“它能不能干”，而是“它要花多少”。
同样一句目标，落到不同形态的 Loop 上，开销能差出一个量级。
业界把这两类形态叫做 Open Loop 与 Closed Loop：差别不在谁更聪明，而在于预算花在哪里、花到什么时候为止。
Open Loop：探索面广，但开销难预估
Open Loop 的入口很轻，你只需要给一句话：“去看看该做什么，然后把它做了”，剩下的全交给 Agent 自己展开。
它的运转方式是：
-
先观察现状（你需要给它一系列 Connectors 或 Probes）；
-
列出一堆候选方向，挑一个动手；
-
做完不停，回头看看还有什么可做，接着展开下一个。
第一次听到 Open Loop，多数人会觉得有些玄乎。但我朋友的创业公司 Crewlet 在这条路上已经走了 2 个月。
Crewlet 的 Agent 正在管理一个名为 SuperDesign 的创业公司
他们把这些数据源全部交给了一个类似中央处理器的 OpenClaw Agent：
GitHub 代码仓库、Sentry 日志、Google Analytics 埋点与行为数据、Supabase 业务主库、AB 实验数据，以及 Stripe 支付、X / Discord 社交数据、SEO、GEO……
这个 Agent 每隔一段时间“醒来”，自主查看核心经营数据与近期错误日志，能做的事包括：
-
发现经营指标问题并归因
-
从错误日志中定位 Bug，直接改 GitHub 代码并提交 PR 上线
-
发现大量用户卡在付费这一步，原因是 Max / Pro 账号页面说明不清
-
给即将到期的用户发送挽回邮件
-
改 Agent 代码、增强 Prompt Caching，提性能、省开支
-
发起 AB 实验并分析报告，进而迭代自身功能
效果出奇地好。
-
好处：探索面广。 Agent 常会发现你事先没想到的方向，例如某个被忽略的边界条件、一处可顺手改进的地方、一个你没意识到的依赖。它不受“我只想要 X”的约束，能把问题空间走得更远。
-
代价：开销难估。 因为没有清晰的终点，它可以朝任意方向持续展开，Token 消耗难以事前预估，只能靠一个外部预算上限兜住。
所以 Open Loop 更适合预算充裕、以探索为目的的场景：你要的本就是“它能帮我发现什么”，而不是“在固定开销内交付一件确定的事”。
Closed Loop：有界目标，开销可控
Closed Loop 换了个起点：从一个有界目标出发。
-
目标确定，路径大致看得清
-
每一步做完都有明确验收
-
Agent 沿路径推进，用验收结果决定是收敛、还是回上一步重做，达标即停
正因为终点和验收事先定好，开销也跟着可控：你能比较有把握地估出“大概几轮收敛”，也不太担心它绕到无关方向上去。
代价是探索面窄：它基本不会给你意外惊喜。
但这恰恰是交付场景想要的：把一件确定的事，在可预期的开销内做完。
两类循环对照
接下来，我将用一个验收标准明确的研发任务来演示 Closed Loop。
需要特别说明的是：TRAE 当前还不支持 Loop（很快会支持），大家可以先从这两个 Case 中更直观了解 Loop。
实践场景 1：为工具库补测试
它的好处是验收标准天然客观：这三条都能由机器给出 0/1 判定，不需要任何人主观拍板“算不算做完了”：
-
一组 acceptance test 全过
-
typecheck 通过
-
不破坏现有测试
这正是 Closed Loop 最干净的示范。
从定义目标开始
把循环工程的解剖（目标 → Discovery → Plan → Execute → Verify → Ship/Iterate，Memory 在对话之外）放进这个任务，每一步都落得很实：
把这套流程画出来，就是下面这个环：红就回到实现，绿就交付，没有第三种出口。
Closed Loop 为什么能成立
关键就一条：验收是客观的。
测试、typecheck、benchmark 给出的是 0/1 信号：要么全绿，要么有红，没有中间地带。Agent 不需要去猜“我做完了没”“够不够好”，那个判断被外包给了一套确定性检查。
Open Loop 开销难估，根源在于“何时停”由 Agent 自己回答。
而这里，“何时停”被一句 npm test 全绿替代了。
循环有了必须收敛的客观靶子，轮数和开销也就有了大致上界。
把模糊的”做好”换成可判定的”全绿”，Closed Loop 就立住了。
循环 Prompt 的骨架
下面是这个循环的 Prompt 骨架，去掉细节只留结构。它干的事很简单：先把目标和验收标准摆明，再给一个硬性循环条件：只要测试不全绿就继续修，全绿才停。
/goal 目标：为 <工具库> 补齐测试并修复其中的 bug。验收标准（全部满足才算完成）：- tests/acceptance/ 下的所有用例通过- `npm run typecheck` 无报错- 现有测试不出现新的失败循环规则：- 跑 `npm test`。- 若未全绿：读取失败用例与报错，定位并修复，然后重跑。- 只要不全绿，就重复上一步，直到全绿再停。- 中途若验收标准本身有歧义，先提问，不要自行猜测。
实践中，这个“把验收结果塞回循环”的动作可以自动化：用 hook 或 CLI 命令的退出码来驱动。比如约定退出码非 0 即失败，配合 Claude Code 的 PostToolUse 钩子，让每次测试结果自动回流到下一轮，省去人工搬运。骨架是同一个，只是接缝处更顺滑。
在真实工作中，你并不需要自己写出这么清晰的验收标准和循环规则——模型已经足够聪明，能从仓库里自行推理出这些规则。
实践场景 2：网店做增长
前面那个研发循环好讲，是因为验收标准足够硬：测试全绿就达标，红了就再转一圈。
可现实里不是每件事都这么干净利落。
一个想自我增长的电商小店，目标是“让网店 GMV 持续增长”。
我们给它装上循环条件，让它在一个收敛的范围里运转。
这一轮，主角换成了一个 Orchestrator（编排）。它掌管这个开放目标，但真正做的事很具体：
开工前，先读上一轮留下的 next_steps——那是一份记忆，记着上次没做完、值得这轮接着做的事。读完才决定，这轮派谁去干什么。
Orchestrator（编排） 派出三个 Sub-Agent，并行工作、各管一摊：
三个 Sub-Agent 各自跑完，产出还是散的。汇总与记忆由 Orchestrator 收口：
-
把 Builder 的 quiz、Scout 的选题排序、Growth 的落地动作，合并成一份统一的行动计划；
-
写回 next_steps——这份文件就是这套循环的跨周期记忆。
下一轮开工，Orchestrator 第一件事就是再读它。于是这轮的尾，接上了下轮的头。
剩下的是定时和循环条件。这套环每周由定时器触发一次（Claude Code 里可用 /Loop 命令），不必时刻盯着。
每轮结束时，Orchestrator 用几条简单条件判断要不要继续：
-
站点这周是否还在增长？
-
Scout 手里是否还压着 ≥3 条未消化的新选题？
-
下一个 lead magnet 是否已经定下来？
条件没满足就接着转；都满足了就暂停，等下个周期再来。开放目标的收敛，靠的就是这几条人为设定的边界。
落到操作上，这件事并不需要特殊基建：
-
省力做法：让一个 Orchestrator Agent 在同一会话内自动 spawn 出 Builder、Scout、Growth，由它统一派活、收口；
-
手动做法：自己开三个 tab，各跑一个 Agent，最后把结果汇到一处。
两种方式做的是同一件事，只是前者把编排也交给了机器。
你还可以这样玩转 Loops
研发循环和增长循环看着差别不小，框架却是同一副。抽干净后，剩下的就是这条线：
这副骨架并不专属于写代码，能套到很多别的事情上。下面是四个速写场景，每个都按”触发时机 → 读什么 → 怎么处理 → 循环条件“来看。
最后提一句：这些循环跑得再顺，AI 也不是每一步都对。
尤其像“判断哪个选题会火”这种事，它并不可靠，给出的排序更多是一种有依据的猜测，而非结论。
所以更稳妥的用法，是把循环产出当作“多了一个有理有据的参考意见”，而不是一个说了算的 Oracle。它替你把信息收齐、把初步判断摆出来；至于最后怎么取舍，仍留给自己。
写在最后
绕了一圈回到开头：Loop Engineering 其实没那么神秘。
它做的，无非是把你一直在手工跑的那个循环，连同一条明确的验收标准都交还给 Agent。
从前那个“再来一轮”的循环体是你；现在你从循环体里退出来，退回到设目标、定边界的位置。
变的不是循环本身，是谁来当那个一刻不能离开的执行者。
今天就能开一个最小 Closed Loop 试起来。建议的顺序是：
-
先 Closed，别一上来就放开边界
-
先小，挑一件验收标准能写清楚的事
-
先把“什么算达标”那条线划明白。
等这个小循环跑顺了，再考虑放开目标边界、加上 Orchestrator、接上定时触发，让它慢慢长成前面那种增长循环的样子。
说到底，这件事的乐趣或许就在于：你亲手把自己从循环里请了出来，又看着它替你转了起来。