本文整理自 B站「Loop Engineering循环工程，从理论到实践，它真的适合每个人吗？」，通过音视频总结 Ai好记 进行视频转图文整理，以下为AI润色整理后的内容。
大家好，本期我们来聊聊最近蛮火热的一个话题：Loop Engineering。
有人说这是AI Agent时代的范式转移，那究竟是什么？我们在日常的工作学习中有用到它吗？它能够怎么帮助到咱们？本期我们就来分享一下。
先给大家看一条推。这是在6月初，OpenAI 作者 Peter 发的两句话，没过几天就已经冲到了数百万的浏览。
他说，你不该再用提示词来驱动智能体为你编程了。你应该去设计那些循环来驱动智能体工作。
差不多同一时间，Claude Code那边的Boris Cherny说得更加直白。他说他已经不用提示词来驱动Claude Code了，他有一堆的loop，也就是循环在跑，是它们在驱动Claude Code自己来决定该干什么。
而Boris Cherny他自己的工作呢，也就只是写loop。
后来Addy Osmani写了一篇文章，把这波讨论收拢成了一个词叫Loop Engineering（循环工程）。
要理解Loop Engineering最好的入口就是Boris Cherny讲他自己这一年是怎么变的。
他描述了三个阶段。咱们可以对号入座一下，看看自己目前在哪个阶段。
第一阶段，逐行驾驶，或者逐行地驱动智能体工作。
你手写代码，模型给你自动补全。大家还记得最早的时期，咱们用AI工具不停地 tap tap tap。
第二个阶段，并行手动，你或许会同时开5个、10个Claude Code，每个都在干活。
但每次对话都是你亲手发起的。你成了一个调度员，在好几个窗口之间来回切换。很多重度用户现在应该就处在这个阶段，而我个人或许大概率也在这个阶段。
而第三阶段，你不再发起对话。你写了一个系统，让它自己去读你的仓库、读 issue、读 CIi的失败，自己决定该用什么样的提示词，驱动Agents工作。
你从Loop Engineering里打字的那个人变成了Loop Engineering的作者。
总的来说，循环工程就是这第三阶段：你不再亲手写每一条的提示词，而是去设计那个替你写提示词的系统。
那么，一个典型的循环系统是由什么搭建起来的呢？
adosmoney 把它拆成了 5 块，外加一根脊柱，我们来逐一过一下。
第一块是心跳，它用来自动触发，也就是定时任务。
到点它自己跑，自己去发现有什么活要干，并不需要你来手动的驱动它。
第二块，工作流，也就是workflow，这也是在AI时代慢慢开始兴起的一种使用方式。
当然它并不是新事物。多个智能体同时工作时，各自待在自己隔离的分支目录里，互相不踩踏对方的文件，就像两个工程师各开各的分支，不会同时修改同一行。
第三块就是Skills，可能大家已经非常熟悉了。把项目的规则规矩写进一个 Skills 的 MD 文件，写一次，每个 Agent 每次都会读。
第四块连接器靠MCP接到你真实在用的工具上，比如issue系统、数据库Slack。
有了他，Agent才不只是吐一句话说“这是修复方案，你该帮我去开 issue，帮我去开合并请求，或者帮我发通知”。取而代之的是，通过MCP通过工具，Agent 可以自己去完成这些工作。
第五块，子智能体，把写代码和审代码这两块拆开。
whatsmoney 有句话说的很到位：写代码的那个模型给自己的作业打分，有时候太宽容了。所以我们需要让另一个Agent来挑刺。
最后就是那根脊柱，支撑起整个Loop Engineering系统的记忆。它或许就是一个简单的 Markdown 文件，或许是一块 Linear 的看板。
把做过什么、试过什么、还差什么都记在对话之外。Agent 会忘，但如果我们用这种持久化的系统，则可以帮助它记住这一切。
那我们现在来看一个典型的流程，我们把这几块拼起来，Loop Engineering的一次循环应该是这样的。
比如早上定时出发任务，调度一个分诊 skill，去读昨天晚上的集成系统的失败，以及最近的提交。
每一个能处理的问题，开一个独立的worktree，一个子智能体来进行修复；而另一个子智能体对照 skill 和测试来审查，连接器把合并请求开出来，再把ticket更新掉。
一旦有搞不定的问题则丢进收件箱，等你来看；而状态文件则实时把这一切都记录下来，明天会接着跑。
Boris Cherny说，这一圈下来可以看得出来，你只设计了一次，中间的每一步你一条提示词都没有写，完全由这个循环系统自主地进行工作。
光听我说可能有点抽象，我们直接上手演示一番。先来个最小力度的演示吧——把循环，也就是loop这个词里最核心的概念先提取出来，是什么呢？
也就是目标/goal。
目标通常约定达到什么样的状态或目的才结束。
在Claude Code有这么一个命令叫slashgo。我们先打开一个Claude绘画，输入slashgo，大家就能看到这个命令。
这个命令的作用是：你给他一个可以判定真假的目标，他自己一轮一轮地执行。
每轮结束都会有一个判断：目标达到了没有？如果没有，再来一轮，直到达到目标自动收工。
我们现在给他一个小小的目标吧。现在，我给他这么一个目标。
用verysmallwoodsresearch获取过去的资讯和研究数据，提取其中OpenAI和Shop的数据，直到凑够5条。
这个 verysmallwoodsresearch 是我自己搭建的一个数据同步或获取的后端。通过这个技能把数据获取回来。现在他并不需要我每写一条就催他或驱动他，反复地做这个任务。
你看，它并不需要我额外的提示词驱动，就能够自动根据我提出的目标去完成工作，直到目标达成。现在只是完成了一个热身，目标达成了。
那下一步，我们希望实现一个真正的循环。我想专门演示一个不是写代码的loop。
因为很多人一听到Loop Engineering，就以为这只是程序员的事情。实际上并不是的。它本质是让一个长期进程替你做重复的脑力活。
写代码只是其中的一部分。我自己每天也会做一些重复的活，比如发现AI圈新发生的事情、一些资讯，挑出其中值得写成文章的选题。这件事每天都干，特别适合做成loop。
在这里要分清两个命令：go是现在就跑，跑到条件为真；而lo则不一样，它是按照时间表盲跑，到点就把你给他的那段提示词再跑一遍。
它并不判断完成没有，只负责准时的执行。这正好就是Addy Osmani说的那个“心跳”。
我们来做这么一个演示。事例是这样的：我期望通过loop做一个循环任务。
这个任务中用verysmaLLwoods-research拉取过去24小时的研究员和新闻，挑出能够写成深度文的，追加进一个叫inbox.md的文件。
再用一个叫topic-scorer的子智能体给每一条做评级，再写回 inbox。最后呢再用一个Scheduleθ81-5的表达式来约定是周一到周五工作日，每天早上8点做这个事情。为了演示，我们把这个调度的频度改得高一些，比如每分钟执行一次。
我们可以改dashdashschedule这个参数，也可以通过自然语言描述。那我们这样改：先删掉dashdashschedule参数，在上面提示词的最后添加一句“每分钟执行一次”。
这样在调度的时候，它就会实现一个每分钟执行一次的定时任务。
我们来执行一下。它首先会尝试找到其中引用的 MD 文件inbox.md，以及可用的Skills和Agents，还找到了topic-scorer这个子智能体的定义。
我把它放在了 demo 的目录中。我们再开一个终端，可以打开这个 MD 文件，来看看这里面有一些什么内容。
分别针对每个话题，他都用感叹号、勾或叉叉做了评级，并且标记了是通过Loop Engineering自动追加的。
到现在，本轮的循环已经完成，并且给到了我一些比较详细的信息：
- 调度任务是什么？他已经完成了注册，每分钟触发一次。
- 这种在绘画中的定时任务是 7 天后自动过期。
如果想要提前停用呢，用rome delete。
那下方呢，就给到了咱们这一次数据的处理后追加的一些资讯或者信息。在这里大家看到这个定时任务又触发了，那我们来看一下更新后的文件，在2026-06-12做了如下的追加。
接下来，他还应该对它进行打分评估。我在这里就暂时退出了这个绘画，不再执行。刚才咱们演示了这个定时任务是怎么工作的。
这样，每天早上我将能打开选题收件箱，看到的不是一堆原始的链接，而是已经分好级、带着理由的候选。
我只需要浏览这些资讯，按照它的评级打分，来决定哪些优先看、哪些放在后面，并且帮助我来筛选哪些可以进入后续的内容创作，或哪些更值得我进行进一步的阅读。
这就是Loop Engineering落到每一个普通人的工作流上大致的样子。
讲到这里，或许还是得泼盆冷水。有篇文章写得还是蛮直接的：多数开发者其实还并不需要Agent Loop。
我觉得他说的还是有一定的道理。
他给了4条测试条件，四条权重做Loop Engineering才划算。
第一，这个活每周以上都会重复，一次性的活不值得做这套的搭建。
第二，验证能够自动化。这点很重要，测试、lint、检查这些能够自己把坏结果挡掉的，不用你肉眼审的。
第三，你的token预算得扛得住，甚至扛得住浪费。Loop会反复重复地读取上下文，重试、来回试探，这些都需要花token花钱，不管最后代码用没用上。
第四，Agent手里有资深工程师那套工具：有日志，有能够浮现问题的环境，还有能够把自己写的代码跑起来的。看看在哪里它崩掉了。
基本上这4条都满足，Loop循环看起来才值得大。
Smoney 的文章中也给到了我们很重要的一些提醒。一个呢就是理解债：loop 越快的交付你没有亲手写的代码、亲手看的代码，仓库里有的东西和你脑子里真正搞懂的东西差距就越大。
另一个更加扎心的事实是，最危险的姿态是舒舒服服地接受 loop 凸出来的一切，这是非常危险的。
在 AI 生成的内容中，越多我们不了解的内容，对于我们来讲风险就越大。还有一个真实的失败样本。
Geo有个出了名的循环技术，或许大家也知道Loop Engineering，也就是拉尔夫循环这么一个概念。
它的特点就是锲而不舍、永不放弃，不停地执行。它也有个著名的失败模式叫bating（发酵过头）：你让它修个小的 bug，它会跑很久很久，最后自作主张地加上一堆没人要的功能，甚至把本来能编译的代码都改坏。
无人盯着的loop，也是无人盯着的犯错。所以验证这件事，永远还是在你自己的手上。即使定义成了循环任务，你也需要在适合的时间点、适合的环境上具备自我验证的能力。
我们回头看，Loop Engineering并不是又一个要追的新工具，它更像一个视角的切换：从“我来写提示词，驱动智能体”变成“我来设计那个用提示词驱动智能体的系统”。
必要的工具，其实你手上都有了。比如像Claude Code所提供的loop命令，git为我们提供的具有隔离能力的工作树worktree，能够驱动智能体工作的技能包skill，以及帮助我们在一个独立环境中独立工作的子智能体。
但别一上来就给所有这些事情都套上一个loop。先挑一件你每周都在重复，而且结果能够自动验证的小事，把它写成一个loop。就像我刚才那个选题的任务，这个任务的执行风险还是偏小的。
然后记住Addy Osmani说的那句话：当那个写loop的人，别当那个只会按启动键的人，写完Loop Engineering，我们还要有能力定时地、定期地在必要的环节上进行验证。
