别再问我什么是循环工程：从 Prompt 到 Loop，工程师的下一站
本文欲回答的核心问题： 循环工程到底是什么？它和提示词工程有什么本质区别？为什么说它正在改变工程师的工作方式？
如果你还在一句一句地给 AI 喂 Prompt，那你可能正在错过一个巨大的范式转移。过去两年，我们经历了从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering 的层层递进。但今天我们要聊的 Loop Engineering（循环工程），不是教你把活干得更好，而是让你彻底从那个干活的位置上退出来。
简单来说：你不再亲自指挥 agent，而是设计一个会自动指挥 agent 的系统。 你的工作不再是“写提示词”，而是“写会写提示词的循环”。这是一个位置的转移——以前你是发动机，现在你是设计发动机的人。
第一部分：循环工程不是又一个新词，而是一次位置转移
本段核心问题： 循环工程究竟改变了工程师在开发流程中的什么位置？
要理解 Loop Engineering，必须先看清它叠在哪一层上。过去两年的“XX Engineering”不是互相替代，而是层层叠加：
每往上一层，你操心的东西就大一号——从“一句话”到“一个窗口”，再到“一次运行”，最后到“一整套自动跑的循环”。
这就是 Loop Engineering 的核心位置：它坐在 harness 的上一层楼。 下面那层负责武装 agent 的单次运行，上面这层负责让 agent 一遍遍自己跑起来。你不再在循环里，你在循环外面，负责造那个循环。
“
反思： 刚接触这个概念时，我也觉得不过是又一个包装出来的术语。但当我把“自己还在手动触发 agent”和“设计一个早上自动起床干活的三轮系统”对比之后，才真正理解了区别。后者省下的不是几分钟，而是每天都要做的那几百次微小决定。
第二部分：一个循环的五个动作——拆开看它怎么转
本段核心问题： 一个循环跑一圈，内部到底发生了什么？（用户可能会问：循环是怎么工作的？）
“循环”这个词容易让人想到一段反复执行的代码。但在 Loop Engineering 里，每一圈都在干一件具体的活。拆开看，只有五个动作：发现、交付、验证、持久化、调度。少一个，循环就转不起来，或者转起来也是空转。
我们用一个真实例子把这五个动作串起来——一个每天早上自动跑的分诊（triage）循环：
动作一：发现（Discovery）
循环转一圈，第一件事是搞清楚“这一圈该干什么”。在这个例子里，一个自动化的 skill 去读三样东西：昨天的 CI 失败记录、还开着的 issue、最近的 commits。这三样合起来，就是“昨天到今天，系统里出了哪些值得管的事”。关键点：让 agent 自己去找活，而不是你把活喂给它。
动作二：交付（Handoff）
发现了活，得把它交出去让人干。这里每个值得做的发现，单独开一个隔离的 worktree（Git 工作树）。为什么要隔离？因为两个 agent 同时改同一个文件，跟两个工程师往同几行代码上提交，是一模一样的麻烦。交付之后，一个子 agent 负责起草修复，另一个专门审查。
动作三：验证（Verification）
这是整个循环里最容易被偷工减料、也最不能省的一步。第一个 agent 写完代码后，第二个 agent 来审查——指令不同，有时连模型都不同。因为写代码的那个 agent，给自己的作业打分时太手软了。 一个没有真正检查的循环，不过是 agent 在那儿反复跟自己点头。
动作四：持久化（Persistence）
验证通过，结果得落到一个能活过这次对话的地方。改动本身通过连接器自动开 PR、更新工单。处理不了的发现进收件箱等人工。还有一个贯穿始终的状态文件，记着“转到哪了”。agent 会忘，仓库不会——记忆得待在磁盘上，不能只活在上下文里。
动作五：调度（Scheduling）
前四个动作合起来是“转一圈”。但真正让它成为“循环”的，是第五个动作：调度。上面这个分诊循环是早上自动跑的，不用人每天去点。那个状态文件让今天没处理完的留到明天，明天的那一圈自动接着这里开始。自动化，才是让循环成为真正循环的东西，而不只是你手动跑过一次的那一次。
第三部分：六个零件——搭一个能自己转的 Loop 需要什么
本段核心问题： 要搭建一个循环系统，需要哪些核心组件？（用户可能问：我该准备哪些东西？）
动作描述的是“转一圈发生了什么”，零件描述的是“你手里得攥着哪些东西才转得起来”。六个零件，对应五个动作，少哪一样，循环都会在某个地方瘸。
零件一：Automations（自动化/调度）
Automation 是让循环自己动起来的东西——挂在一个时间表或触发器上，到点自动发现、自动分诊。没有调度，你手里那套东西只是一次运行，不是一个 loop。注意一个细节：automation 里该触发的是一个 skill（有名字的技能文件），而不是一整面墙的指令。逻辑变了改 skill 就行，没人会去更新一个贴死在定时任务里的长 prompt。
零件二：Worktrees（Git worktree 隔离）
Worktree 让你在同一个仓库里开出多个互相独立的工作目录。每个 agent 在自己的 worktree 里改代码，互不干扰。这个零件的价值随并行规模放大——一个 loop 只跑一个 agent 时可有可无，但早上同时修五个 bug、五个 agent 各改各的，没有隔离就是五份改动搅在一起。
零件三：Skills（用 SKILL.md 复用知识）
Skill 是把项目知识固化成一个文件，让 agent 每次都能直接取用，不必每一圈都重新推一遍上下文。不固化，你就得在每次运行里重新告诉 agent“这个项目是怎么回事、规矩是什么、坑在哪”。这种反复交代的成本，叫作意图债。skill 就是在还这笔债。
零件四：Plugins & Connectors（MCP 连接器）
Connector 让 loop 接到外部世界——issue tracker、数据库、staging 环境的 API、Slack。技术底座是 MCP。一个只能看见文件系统的循环，是个很小的循环。 每多接一个外部系统，loop 能自主完成的链条就长一截。
零件五：Sub-agents（生成者和评判者分开）
子 agent 的关键用法，是把“写东西的”和“评判东西的”拆成两个。一个 agent 负责生成，另一个指令不同、有时模型也不同的 agent 负责挑刺。因为同一个 agent 既当运动员又当裁判，裁判会偏心。 写代码的模型给自己批作业态度太好，换个“怀疑论者”才能抓出它自我说服放过去的问题。
零件六：Memory（持久化状态）
Memory 是 loop 活在单次对话之外的记忆——一份 markdown 文件，或者一块 Linear 看板。agent 的上下文窗口一清空，它就什么都不记得了。loop 要想今天接着昨天跑，记忆就不能只待在上下文里，得落到磁盘上。没有它，每一圈都是失忆后重新睁眼。
第四部分：为什么写代码的 AI 不能给自己打分？——生成器与评判器
本段核心问题： 如何防止 AI 自我催眠，确保循环输出的质量？（用户可能问：怎么让 AI 自己检查自己写的代码？）
一个 loop 最难的地方，不是让 agent 跑起来，而是往里面放一个能说“不行”的东西。可写代码的那个 agent，恰恰是最不会说“不行”的。
你让一个 agent 写完代码再评价自己写得怎么样，它会自信地夸一通，哪怕在人看来质量明显一般。 这不是模型不够聪明，是它在给自己的作业打分。写代码的那个上下文里已经塞满了“我为什么这么写”的理由，它看到的不是结果，是一路推导过来的自我说服。
那怎么办？答案是：调一个独立的评判器（evaluator），让它变得怀疑，比让生成器自我批判要容易得多。 你没法靠一句“请严格一点”让作者跳出自己的视角，但你可以换一个 agent，给它完全不同的指令，让它从零开始看这段代码。它没参与写，就没有那套自我说服。
这套思路借鉴了生成对抗网络（GAN）的结构——一个网络负责造，一个网络负责挑刺。搬到 agent 上，就是一个 generator 写，一个 evaluator 审，结构上把“写”和“判断写得好不好”彻底分开。
更近一步：光换个 agent 还不够。如果 evaluator 只是把代码读一遍，它判断的还是“代码看起来对不对”，不是“跑起来对不对”。一个会动手的评判器，会像真人 QA 那样去用这个东西——打开页面、点按钮、截图、查 DOM，看的是行为，不是意图。
在产品层面，已经有一个命令把这套结构做成了原语：/goal。用法是给 agent 一个条件，让它一直跑到条件满足为止。关键在于：每跑完一轮，一个又小又快的模型来检查条件成立没有。是否完成，由一个全新的模型判定，不是由干活的那个判定。 这就是 maker-checker（生产者-检查者）原则——干活的 agent 是 maker，那个 fresh model 是 checker，它没有自我说服的包袱。
“
反思： 我自己踩过的坑就是一开始只配了一个 agent 自审自改。结果它把同一个 bug 改了三轮，每次都说“已修复”，测试也自己写成了绿色。换了一个独立的评判器之后，五分钟就指出了第一个 agent 绕过去的核心问题。一个 loop 的下限，是它的评判器。
第五部分：循环在你睡觉时跑——三个真实案例
本段核心问题： 循环工程在现实世界中是如何运作的？（用户可能问：有没有真实的落地案例？）
前面讲的都是“应该怎么搭”，下面看三个“真的搭好了在跑”的案例——从一个人的早晨，到一家公司每周一千多个 PR。
案例一：一个人的早晨分诊循环
天亮时一个 automation 自己醒来，读 CI 和 issue，开 worktree，子 agent 起草和审查，过了就自动开 PR，没把握的丢进收件箱等人，状态写进文件留给第二天。这里的关键细节：automation 调用的是一个 skill，不是把一大段指令贴死在日程里。一个人，一台机器，每天早上替你把脏活先过一遍。
案例二：Stripe 的 Minions——每周 1300 个 PR
把 loop 推到企业规模，最值得看的是 Stripe 的 Minions。数字：每周合并 1300 多个 PR，没有一行是人手写的。 触发方式很轻：在 Slack 里 @ 一下 Minion bot，或者给某条消息加个 emoji 反应，发完就不用管了。
但真正让它靠谱的，不是触发轻，是 LLM 醒来之前那一段：一个确定性的 orchestrator 先把上下文备齐——扫消息里的链接、拉 Jira、找文档、用 Sourcegraph 加 MCP 把相关代码搜出来。等 agent 上场，桌上已经摆好了它要的所有材料。 这一步为什么重要？因为让 LLM 自己去找上下文是最不可控的环节。Stripe 的做法是把“找资料”这种能写死规则的活从 LLM 手里拿走，交给确定性代码去办。
最反直觉的一点：Minions 不是建在某个更强的模型上，而是开源工具 Goose 的一个 fork。核心论点就一句：AI 的可靠性来自约束的质量，不是模型的大小。 它的架构是六层，确定性的 gate 和 LLM 的创造步骤交替咬合。agent 写完代码，一段硬编码的 pipeline 跑 linter，agent 跳不过去；修完，硬编码的步骤执行 git commit。
最后注意：人没退场，人换了工位。这 1300 个 PR 仍然由工程师 review，时间从“写”挪到了“审”。
案例三：“睡觉时跑”到底靠什么？
本地 /loop 命令也好，桌面的定时任务也好，它们都要你的机器开着。机器一关，loop 就停了。真要做到关机也跑、睡着也跑，正解是 Cloud Routines 或 GitHub Actions 的 schedule 触发。
没有一种调度通吃。你想让 loop 每分钟盯一下本地正在跑的开发服务器，那只能是本地 /loop；你想让它每天凌晨三点扫一遍仓库的 open issue，该提 PR 提 PR，这种活根本不该绑在你的笔记本上。
第六部分：循环替你干活，也在替你欠债——四笔不得不算的账
本段核心问题： 无人看管的循环会带来哪些风险和代价？（用户可能问：用循环工程有什么坑？）
一个能自己跑的循环，同时是一个能自己犯错的循环。它跑得越欢，错也错得越安静。下面这四笔账，每一笔都不会自己消失。
第一笔：验证债
你让循环自动开 PR、自动改代码、自动合并，每一步都省了你的时间。但省下来的时间不是白来的，它变成了一堆“还没人验证过”的产出，堆在那儿等你还。循环的难点不在循环本身，难的是往里面放一个能说“不”的东西。 一个没有真正检查的循环，不过是 agent 在那儿反复跟自己点头。
第二笔：理解腐烂
循环每天替你写一堆你没写过的代码。代码能跑、测试能过、PR 能合。但有个东西在背后慢慢变质：你对这个项目的理解。 循环交付你没写的代码越快，“实际存在的东西”和“你真正理解的东西”之间的差距就越大。你不再被迫一行行读过去，代码库在长大，你脑子里的地图却停在三个月前。等出事的那天，你打开文件，发现自己像在看别人的项目。
第三笔：认知投降
当循环自己跑起来，你会很想停止有自己的判断，它给什么你就收什么。循环越可靠，你越容易把判断这件事整个外包出去。 每个 PR 都要自己想一遍对不对，比直接点“合并”累多了。这是个会自我加速的滑坡。循环可以替你执行，不能替你拿主意。你递回来的东西，你至少得有能力说一句“这个不对”。
第四笔：token 失控
一个自主跑的循环，消耗很难提前算准。用量会剧烈波动，取决于你是 token 富人还是 token 穷人。同一个循环，富人跑得起，穷人可能一夜醒来发现账单爆了。一个 bug 让它空转一整晚，你睡醒看到的就不是修好的代码，是一张陌生的账单。怎么防？ 上线前给循环设几个硬上限：单次预算、每日预算、最大重试次数，到顶就停。
“
反思： 这四笔账里，我觉得最阴险的是“理解腐烂”。它不像 token 账单那样会疼，也不像验证债那样有明显的前后对比。它只是让你慢慢变成一个对自己项目的外人，而你甚至不会察觉到这个过程。我现在的习惯是：每周挑两个 loop 提交的 PR，不看 diff，先自己口述一遍“这段代码应该干了什么”，再对照看。讲不出来的地方，就是地图要更新的地方。
第七部分：当工程师，不只是按下启动键——造循环的人决定结局
本段核心问题： 同样的循环，为什么结局截然相反？（用户可能问：我和别人用同样的工具，结果差在哪？）
两个人造出一模一样的循环，得到的结果可以完全相反。 这句话听着有点反直觉——系统是中立的，同样的代码跑出来不该是同样的东西吗？但这里说的不是循环本身，是循环之外那个人。
一个人用循环，是为了在自己已经吃透的事情上跑得更快。代码他读得懂，方向他拿得准，循环只是替他把手动的活包了。循环帮他扩大的，是他本来就有的判断。
另一个人用同样的循环，是为了不必再去理解。看不懂没关系，循环会写；判断不了没关系，循环会合。他用循环把“理解”这件麻烦事整个绕过去了。
循环本身不偏向任何一边，它只是个忠实的乘号，乘的是你。
当一样东西可以被无限生成（代码、方案、PR），它就不再值钱。那什么还稀缺？判断力——知道哪个方案是对的、哪行代码该拦下来、哪个产出虽然能跑但根上错了。循环能生成一百个选项，但它没法替你选。或者更准确地说，它可以替你选，但它选的依据是“看起来合理”，不是“真的对”。
所以循环工程不是让判断力贬值，恰恰相反——它把所有不需要判断的活都拿走了，剩下的全是判断。你的价值被压缩、被提纯到只剩这一件事。工具越强，对赌你判断力的赌注就下得越大。
造循环的时候，你用什么心态去设计，它就长成什么样。如果你是抱着“赶紧把自己解放出去”的心态造的，你会把所有检查都省掉，因为检查碍事。如果你是抱着“我还要在这儿当工程师”的心态造的，你会主动给它留几道你能说不的关口，哪怕那意味着它慢一点。
“
反思： 这个选择不是造循环那天一次性做完的，它每天都在重做。你今天多读了一个 PR，多问了一句“这真的对吗”，你就还在工程师那一边。你今天图省事，闭着眼合了，你就往“按钮”那边滑了一格。没有谁是天生的工程师，也没有谁一劳永逸地是。它是个需要每天续费的身份。
第八部分：今天就动手——搭你的第一个 Loop
本段核心问题： 如何从零开始搭建一个真正能运行的循环？（用户可能问：第一个循环怎么搭？给我具体步骤。）
很多人一听 Loop Engineering，脑子里立刻浮现 Stripe 那种每周一千多个 PR 的流水线，然后觉得离自己太远，放弃了。这是个误会。 第一个 loop 应该小到几乎不像个系统，就是一个会定时帮你看一眼的小东西。
第一步：跑一个 /loop
/loop 在 Claude Code v2.1.72 之后可用。作用就一个：按时间间隔，把同一件事重跑一遍。三种形态：
-
/loop 5m check the deploy—— 固定 5 分钟一次 -
/loop check the deploy—— Claude 自己决定节奏（1 分钟到 1 小时之间） -
/loop—— 裸跑，执行内置的维护任务或你写在.claude/loop.md里的内容
时间单位是 s/m/h/d，cron 间隔最小 1 分钟。两个细节：它是 session-scoped，recurring 任务 7 天后过期；它跑在你本机，机器关了就停。
第二步：让它读 CI 和 issue，先做 triage
光重跑一句话不算 loop，得让它读点东西、做点判断。最朴素的起点是一个 triage（分诊）任务。给它一个 prompt，让它每天早上去看三样东西：昨天的 CI 有没有失败、有哪些新开的 issue、最近的 commit 改了什么。看完，挑出值得处理的，列个清单。定时 + 自动发现，才算 loop 入门。
第三步：加一个状态文件，让它有记忆
分诊跑完，结果别留在对话窗口里——开一个 markdown 文件，把每次的发现、处理到哪一步都写进去。这个文件就是 loop 的记忆。有了它，今天没处理完的事，明天这个 loop 醒来还能接着干。
第四步：加一个 evaluator，让它能说“不”
这一步是整个 loop 里最关键的。在 Claude Code 里有一个现成的工具叫 /goal（v2.1.139 之后可用），专门干这个。用法：
/goal all tests in test/auth pass and the lint step is clean
判断条件成立的是另一个 fresh 模型，不是干活那个。 为什么非得换一个模型？因为干活的那个太容易夸自己。
第五步：加 worktree，让它并行
办法是 git worktree。Claude Code 用 --worktree（或 -w）给每个后台 agent 开一个独立 worktree，互不踩脚。两个 agent 写同一个文件，跟两个工程师改同一行一样头疼。隔离开，它们才能并行而不打架。
工具现状速查（2026 年 6 月）
第一个 loop 检查清单
前两条决定你的 loop 能不能跑，后四条决定它跑起来会不会闯祸。第一个 loop，宁可小，也要把那个会说“不”的检查和人工复核点装齐。
实用摘要 / 操作清单
-
确认位置：你不在循环里，你在循环外面负责造循环。 -
五个动作：发现 → 交付 → 验证 → 持久化 → 调度，缺一不可。 -
六个零件：Automation、Worktree、Skill、Connector、Sub-agents、Memory。 -
评判器必须独立：写代码的 agent 不能给自己打分，换一个怀疑论者来审。 -
先从小 triage 开始：一个定时读 CI 和 issue 的小 loop，比大而全的强。 -
四笔账要还：验证债、理解腐烂、认知投降、token 失控。 -
工程师的底线：循环可以替你执行，不能替你拿主意。
一页速览
常见问答（FAQ）
Q1：Loop Engineering 和 Prompt Engineering 是一回事吗？
不是。Prompt Engineering 管“一次怎么写”，Loop Engineering 管“怎么让它自己一遍遍跑”，你从写话的人变成了造循环的人。
Q2：我只有一台笔记本，能跑 loop 吗？
能。本地 /loop 命令可以跑，但机器关了它就停。要关机也跑，得上 Cloud Routines 或 GitHub Actions schedule。
Q3：怎么防止 loop 空转烧 token？
上线前钉死单次预算、每日预算和最大重试次数。这些硬上限是安全绳。
Q4：一定要用两个不同的模型做生成和评判吗？
不一定，但推荐。同一个模型哪怕换指令，思维盲区往往还在。换一个底座，连它习惯性绕过去的坑都可能换一批。
Q5：循环跑出来的代码，我还要 review 吗？
要。Stripe 每周 1300 个 PR 仍然由工程师 review。人没退场，只是从“写”换到了“审”。
Q6：第一个 loop 搭多大合适？
越小越好。就从 /loop 5m "check CI failures" 开始，加一个状态文件，再加一个 /goal 条件。先跑起来，再慢慢加零件。
Q7：理解腐烂怎么避免？
每周挑两个 loop 提交的 PR，不看 diff 先自己口述“这段代码应该干了什么”，讲不出来就是地图该更新了。
Q8：循环工程会让我失业吗？
不会。它会把你从重复劳动里解放出来，然后把你的价值压缩到只剩判断力。判断力才是你真正需要比拼的东西。
