Loop Engineering 全解: Loop 由什么组成, 怎么搭得靠谱？附开源 Loop Builder Skill

🎯 Главная суть

Loop Engineering — это следующий этап после prompt engineering, context engineering и harness engineering. Вместо того чтобы вручную писать длинные промпты для агентов, разработчик строит самовосстанавливающийся цикл: один агент выполняет задачу, другой независимо проверяет результат, и система повторяет процесс, пока не достигнет цели или не исчерпает бюджет. Ключевая проблема — агенты «забывают» всё между итерациями, поэтому состояние и правила нужно хранить вне контекста модели.

Что такое loop и почему его нужно проектировать как инженерную конструкцию

Loop — это не длинный промпт. Длинный промпт похож на письмо стажёру: вы объяснили всё сразу, ушли в отпуск, а результат — либо верный, либо нет, без возможности исправить. Loop же представляет собой миниатюрную систему, которая сама запускается, действует, получает оценку и корректируется. Минимальный loop состоит из трёх компонентов: генератора (исполнителя), оценщика (проверяющего) и контура обратной связи. Важнейший принцип — исполнитель не может сам себя проверять, как и студент не должен проверять собственную контрольную. «Работа» и «приёмка» должны быть разделены.

Агент «страдает амнезией»: между двумя запусками он полностью забывает предыдущую итерацию. Представьте коллегу с феноменальной памятью на навыки, но каждое утро он не помнит ни правил проекта, ни того, что уже сделано. Единственный способ справиться — выгружать всё важное за пределы контекста модели, на «жёсткий диск»: правила, команды, статус выполнения. Файлы не забывают. Почти все долгоживущие агенты работают по этому принципу, и значительная часть Loop Engineering посвящена борьбе с этой «амнезией».

Шесть компонентов зрелого loop

Энди Османнинг (Andy Osmanning) разложил loop на шесть элементов, которые удобно представить как станки на заводской линии:

1. Сердцебиение (heartbeat) — планировщик, который заставляет систему работать по расписанию (каждое утро в 8:00) или до выполнения условия. Без него loop был бы одноразовым.
2. Рабочие столы (gate/worktree) — изоляция параллельных агентов, чтобы они не конфликтовали при изменении одних и тех же файлов.
3. Инструкция (skill) — документ с правилами проекта: как компилировать, какие стандарты кода, критерии ревью. Этот файл почти не меняется и часто попадает в систему контроля версий.
4. Соединитель (MCP) — аналог водопровода и электричества: loop может читать доски задач, открывать pull request, писать в Slack. Без него агент будет только комментировать «этот баг надо исправить», но не исправит.
5. Контролёр качества (sub‑agent) — независимый проверяющий со своим свежим контекстом. Именно он гарантирует, что исполнитель не оценивает себя сам.
6. Стена прогресса (memory) — хранилище состояния вне контекста модели. Это может быть Markdown-файл или GitHub-доска.

Эти шесть компонентов собираются вокруг центрального цикла — и получается машина, которая крутится сама и не улетает в бесконечность.

Чем skill отличается от memory (и почему их путают — частая ошибка)

Skill — это «сотрудник»: он описывает, как мы делаем работу (команды компиляции, критерии код-ревью, шаблоны). Он редко меняется, хранится в репозитории и только читается каждой итерацией. Memory — это «стикер»: он показывает, что сделано на данный момент (какие тесты пройдены, какой файл уже изменён, что осталось). Memory меняется каждый цикл: и читается, и записывается. Типичная ошибка — записать изменяемое состояние в skill, то есть «вклеить стикер в устав». Нужно жёстко разделять: skill = «как мы работаем», memory = «где мы сейчас».

Какие архитектурные шаблоны используются для loop

Самый простой вариант — React + детерминированная проверка: код запускается, программа проверяет, прошёл ли он тесты или соответствует схеме. Если проверку можно запрограммировать чётко — так и надо делать. Для задач, требующих суждения, применяется Evaluator-Optimizer: независимый агент-критик выставляет баллы по шкале. Если работу можно распараллелить — подходит Orchestrator-Workers: один координатор раздаёт задачи нескольким исполнителям. Также существует RAFA — «while-цикл» до достижения цели. Главное правило: использовать самую простую схему, которая работает, и не лезть в тяжёлые многогенераторные фреймворки, если не понимаете, как их отлаживать. Loop с детерминированным верификатором почти всегда надёжнее сложной системы, которую вы сами не можете продиагностировать.

Где у этой архитектуры слабые места

Первое — промпт-инъекции. Loop, который читает issue, email или веб-страницы, каждую итерацию заглатывает потенциально опасный текст. Защита — не умная модель, а обязательная ручная дверца: все необратимые действия (мёрж кода, отправка письма, списание денег) должны требовать человеческого подтверждения («красная кнопка»). Второе — верификация остаётся самым трудным звеном. Чем автономнее loop, тем надёжнее должен быть оценщик. Если можно сделать проверку программно — не доверяйте её LLM. Третье — стоимость. Loop крутится сам, счёт растёт незаметно. У каждого loop должен быть явный бюджет (лимит итераций, токенов или времени) и стоп-условие.

Loop Builder — инструмент, который собирает loop без пропусков

Когда автор начал создавать loop вручную, он постоянно что-то забывал: то проверяющего не назначил, то изменяемое состояние записал в skill, то не поставил стоп-условие. Все три ошибки — не проблема знаний, а проблема дисциплины. Поэтому появился Loop Builder — открытый skill для Cloud Code, который сначала интервьюирует пользователя, а затем генерирует готовую папку loop со всеми компонентами.

Процесс состоит из четырёх фаз. Сначала — опрос из 7 вопросов, которые покрывают все шесть компонентов: 1) цель и условие завершения (должно быть проверяемым — например, «90% требований из списка выполнены», а не «репозиторий здоров»); 2) триггер — по расписанию или до завершения; 3) как loop находит очередную задачу; 4) какие действия и инструменты доступны; 5) кто и по каким критериям проверяет; 6) где хранится состояние (вне контекста); 7) какие операции требуют ручного одобрения.

Вторая фаза — поиск готовых модулей. Loop Builder сканирует локально установленные компоненты (существующие skill, MCP-коннекторы, агенты) и затем обращается к встроенной библиотеке SkillBank, где лежат проверенные сторонние части. Для каждого внешнего компонента всегда создаётся запасной вариант (fallback), чтобы loop не сломался, если чужой skill изменится или исчезнет.

Третья фаза — выбор самого простого подходящего шаблона из описанных выше (React+validation, Evaluator-Optimizer, Orchestrator-Workers). Четвёртая — генерация файлов: все статические части (правила, проверятор, список необратимых действий, бюджет, команда запуска) помещаются в папку Cloud Skill; изменяемое состояние (текущий прогресс) — в отдельную папку loops. В результате каждая собранная система содержит полный референсный дизайн и не даёт забыть ни один из обязательных элементов.

Cloud Code的负责人Boris Cherney最近在一个采访中有提到他说他最近基本上不怎么一句一句给模型写prompt了他的工作是写loop什么是loop回顾过去这一年我们这些天天跟模型打交道的人手艺一直在变一开始是prompt engineering怎么与模型chad比较高效后来是context engineering思考如何管理上下文再后来是harness engineering给模型增加更多的工程指引而Boris说到的这个写loop是这条线上最新的一站有人给他起了一个名字loop engineering这个词是谷歌的工程师Andy Osmanning在2026年6月前后叫响的今天这期我们就来看一下loop engineering第一把loop engineering这件事从头讲明白它到底是什么一个loop有哪些零件构成为什么需要这些零件第二介绍一个我自己已经开源的小工具叫loop builder它帮助我们按照这套理念把一个靠谱的loop直接给搭出来什么是loop一个loop不是一句很长的prompt一句很长的prompt就像我们给一个实习生发了一封超长的邮件把要求写的明明白白然后我们可能就去度假了回来一看错了对了都是一锤子买卖loop是另一回事它是一个会自己赚起来的小系统agent会自己去找活动手做然后被另一个独立的裁判按明确的标准打分不合格就改改完再来一遍直到达标或者预算用完为止整个过程中间没人一句一句的敲键盘所以一个最小的loop就有三个部件一个负责干活的generator一个负责验收的evaluator还有把这俩连接起来让它转下去的回路本身需要注意的是不能让干活的自己给自己打分就如同让学生自己批自己的卷子可能会看到门门高分模型给自己的输出打分保持客观也不容易干活和验收得分开这是后面靠谱的执行的基础那问题来了不就是做一个回路吗为什么还需要专门搞一个工程因为有一个挺扎心的事实这个agent每一轮都是从零开始的他在两次运行之间会把上一轮忘得干干净净他有点像那种鲸鱼记的同事能力很强可昨天教过的是我们的项目的规矩任务完成到哪里今天上班可能又完全不记得了那怎么办呢别指望他脑子里可以把这些东西记下来需要写到上下文之外写到硬盘上规矩命令哪些已经做完了通通落成文件还是那句话人会忘但文件不会忘几乎所有能长时间自己跑的agent靠的都是这个思路loop engineering之所以是工程很大一部分就是在认真对付这个失忆的问题好核心循环有了但一个能在真实环境里面跑出来的loop光有循环还不够Andy Osman把他拆成了六个零件我喜欢把一个loop想象成一条工厂的流水线我们来走一遍这六个工位第一个是心跳也就是调度他让这条线按节奏自己开工每天早上八点或者一直跑到某个条件成立为止没有它这就是一次性的工作算不上loop第二个是独立工位数语叫做gatework tree几个agent一起干活的时候得各做各的桌子不然两人可能会抢着改同一个文件造成冲突第三个操作手册也就是skill把项目的规矩写下来一次省得loop每一轮都得重新猜咱们这儿到底是怎么干活的第四个连接器一般是mcp你把它当成水电网络接口就行让loop能真正的连接到外面的系统读看板查数据库开pr发slag这个零件特别关键因为没有它agent只会在那评论这个bug应该怎么修但它不会真的动手去修改第五个质检源也就是子agentsubagent还记得刚才那句不要自己批自己卷子吗就是把干活的和验收拆分成两个独立的subagent各有个全新的上下文第六个进度墙也就是memory把做完了什么接下来做什么记在上下文之外可以是markdown文件也可以是github看板六个零件围绕着中间的那个循环一台能自己转又不会跑飞的机器就完成了这六个里面有两个长得很像特别容易混淆我得单独拎出来讲讲这就是第三个skill和第六个memory打个比方skill是员工手册里面写的是我们这怎么做事编译命令评审标准代码规范它很少改动是打印出来纳入版本管理贴墙上的东西每一轮agent进来都只读它memory是类似于便利贴上面写的可能是今天这个项目做到了哪里哪个试过了哪个还需要再完成它每一轮都在变又读又写那个最经典的错误是什么呢就是会把便利贴塞进了员工手册里也就是把每天都在变的状态写进了那个本该只读稳定的skill我们需要区分的是skill管理我们怎么做而memory管理现在做到了哪里零件都齐了接下来该怎么搭loop呢?业界有几个成熟的套路大多能在anthropic那篇building effective agent里面找出来最简单的是react加一个确定性的验证器有没有完成由一段程序说了算比如跑测试过了schema检测需要判断力的场景用Evaluator Optimizer的模式让一个独立裁判按评分表打分那些能并行的工作可以采用Orchestrator Workers的模式一个总指挥派给若干个员工各种不同可以并行的任务另外还有RAFA循环可以理解为朴素的while循环直到目标达成但贯穿这一切的是条特别朴素的纪律用最简单的能跑通的那套避免一上来就去够一个我们自己都debug不动的重型框架一个带确定性的验证器的简单的loop几乎永远好过一个我们根本不理解多agent大系统回顾整个loop架构在另一面我们也来看一下这套架构设计还不足的地方需要打什么补丁第一提示注入到现在没有解决一个会读issue读邮件读网页的loop等于每一轮都在吞外面的不可信的文字真的被人塞进了坏指令怎么办可靠的防线不是聪明的模型而是一套永久的人工gate凡是不可逆的动作合并代码发邮件花钱删东西都必须有人来点头给他装了一个红色的按钮这类操作人签字才能放行第二个验证是最难的那一部分一个loop能有多自主也取决于他的那个裁判有多可靠所以才反复的说验证器要独立能用程序判定的就别让模型靠推理来判断第三成本会悄悄失控loop是会自己赚的赚的勤输出多账单就上去了所以每个loop都得有明确的预算和停止条件最多赚几圈用多少token跑多久所以loop engineering确实是一个工程框架如何平衡模型升级与工程框架约束是一个值得持续观察的问题第一部分我们介绍了什么是loop与loop engineering当我自己真上手搭的时候撞到了一个很现实的问题每次手搓一个loop太容易遗漏东西了于是我做了这个loop builder来避免设计理念的遗漏也方便在实践当中逐步来优化loop设计我们先来看手挫loop最常踩的三个坑第一个忘了配那个独立验证器变成了自己改自己作业第二把会变的状态显进了skill也就是刚才的那个员工手册里塞便利贴第三忘了设停止条件这三个坑有个共同点它们都不是能力问题是流程问题是那种每次都得记得做但可能会忘的事而容易忘的固定流程恰恰最该交给工具来兜底那loopbuilder是什么呢它是一个cloud code的skill它会先采访用户然后把一个自己能跑的loop点同所有文件给搭出来它像是一个带工程监理的装修队用户不用懂水电怎么走沉重墙在哪里只要说一句比如每天早上帮我把Github上的项目的issue分个类他就开始问我们的需求然后把这套房子给盖好而且水电验收也就是验证器还有例如想动这面墙就得问我的规矩也就是人工闸门gate给配置好还有一个小细节我们不用说loop这个词说帮我们自动处理定时跑一下盯着点定期对比一下等等都会触发这个skill他工作的时候严格走四个阶段先问清楚用户再看看有没有现成的可以使用的模块然后选择最简单的loop套路最后把零件落实成文件第一阶段他会问我们7个问题从不同的角度来梳理第一目标是什么样的可验证的条件算暂时完成注意这得是一个能判定真假的东西比如满足需求列表里面90%的需求而不是泛泛而谈的话比如让仓库保持健康等第二触发如何驱动loop是定时事件出发还是一直跑到做完为止第三发现每一轮他怎么找到要干的活第四动作他能做什么通过哪些工具第五验证谁来检查按什么标准必须是独立的裁判第六状态做完了什么还开着什么记在上下文之外的哪里第七人工闸门哪些动作不可逆必须先问用户第二阶段问完这7个问题他会翻翻仓库看看有没有现成的原料他分两遍扫描第一遍看计算机上已经安装了什么比如现成的skill mcp连接器the agent等能直接拿来用的当某个零件的就不需要再重新造一遍了第二遍他会拍一个搜索subagent他会去翻找loopbuilder自带的一个材料库叫做skillbank里面有精选的清单也有分门别类的目录看看有没有别人的已经造好的被验证过的打磨过的部件为了保持loop的弩棒性凡是用了外面的部件它都会留一个明确的备胎因为别人的skill对于我们来说是会变的哪天它没了或者改了我们的loop在失忆能启动的时候也需要避免中断第三阶段它从第一部分讲过的那几种套路里挑一个最简单能跑通的loop模式第四步它会把六个零件变成我们硬件上真实的文件搭建这个loop持久的东西放进一个cloud skill底下的文件夹里比如这个loop自己的规矩独立的验证器不可逆动作的清单加预算还有启动它的内行命令会变的东西比如做到了哪里的状态单独放进一个loops文件夹里通过loopbuilder这个skill我们搭出来的每一个loop都自带完整的参考设计里的各种模块和设计理念最后总结一下今天的内容第一部分我们讲了loop engineering一个loop不是一句长的prompt而是一个会自己赚的小系统它需要工程化是因为那个aget会失忆它有六个组件构成其中skill管怎么做而memory管做到了哪里搭建的时候优先使用简单的能跑通的套路并且永远给它留一道人工闸门和一个预算门槛第二部分我们把这套理念做成了一个会先采访用户再帮用户把loop盖好的工具loopbuilder它最大的意义是让我们在搭建loop的时候不容易遗漏不容易犯错这个工具已经开源了地址也放在了简介里面loop engineering作为一个新的实践到现在也就几个月的时间里面有不少细节还在快速的更新欢迎大家在评论区里讨论我们下期再见

Boris Cherny 说他现在基本不写 prompt 了,工作是写 loop。这支视频讲清楚 Loop Engineering 是什么:一个 loop 不是一句长 prompt,而是一个会自己转的小系统——它需要工程,是因为 agent 每轮都会失忆。

第一部分,我们拆一个 loop 由哪些零件组成:核心回路(干活 + 独立验收)、对付失忆的外部状态、以及把规矩写下来一次的 Skill。其中最容易混的一条线是:Skill 管「我们怎么做」,Memory 管「现在做到哪」。

第二部分,我介绍一个我自己做、已经开源的 Claude Code skill —— Loop Builder。它会先采访你,再照着这套参考设计把一个 loop 连同所有文件搭出来,让搭建时不容易漏、不容易犯错。

Loop Engineering 作为一个新的实践,细节仍在快速更新,具体命令请以最新文档为准。

—— 资源 ——
Loop Builder(开源 · MIT):https://github.com/AaronLPS/loop-builder

—— 章节 ——
0:00 开场:从 prompt 到 loop
1:05 什么是 loop
1:39 最小回路:干活与独立验收
2:07 为什么需要工程:agent 会失忆
3:02 一个 loop 的六个零件
4:35 Skill vs Memory:手册与便利贴
5:28 怎么搭:四种套路
6:31 需要打什么补丁:闸门 · 验证 · 成本
7:48 为什么做 Loop Builder:三个坑
8:34 Loop Builder 是什么
9:20 它怎么工作:四个阶段与七个问题
11:49 总结

#loop  #LoopEngineering #claudecode  #skills  #aiagents