Loop Engineering.
Автор оригинала: Addy Osmani
Компиляция: Peggy, BlockBeats

Редакционная заметка: способ использования AI-агентов для кодирования переходит от «человека, который вручную пишет промпты и пошагово выполняет задачи», к «человеку, который проектирует циклы, позволяя системе постоянно распределять задачи агентам». То, что Addy Osmani называет Loop Engineering (инженерией циклов), заключается в создании рабочего процесса, способного автоматически обнаруживать задачи, распределять их, проверять результаты, фиксировать прогресс и принимать решения о следующих шагах.

Этот цикл состоит примерно из пяти модулей: Automations (автоматическое обнаружение и распределение задач), Worktrees (изоляция нескольких параллельных сред разработки), Skills (накопление знаний о проектах и командных практик), Plugins/Connectors (интеграция с реальными инструментами, такими как GitHub, Linear, Slack, базы данных), Sub-agents (разделение исполнителей и рецензентов), а также внешний слой памяти, например, Markdown-файлы или доски Linear, для сохранения состояния и прогресса.

Статья напоминает, что смысл Loop Engineering заключается не только в «запуске ИИ на несколько циклов», а в том, чтобы перенести суждения инженеров на этап проектирования системы. Циклы могут значительно увеличить эффективность работы разработчиков, но не заменяют проверку, понимание и принятие решений. Настоящий риск заключается не в использовании циклов, а в том, чтобы использовать их как оправдание для избегания понимания кода и системы. Ключевым навыком для сотрудничества с ИИ в программировании в будущем, возможно, станет не просто написание хорошего запроса, а создание надежных, проверяемых и устойчиво работающих рабочих процессов агентов.

Следующий текст:

Loop engineering (循环工程) заменяет вашу роль как «человека, пишущего подсказки для агентов». Вам нужно спроектировать систему, которая будет вместо вас формулировать подсказки для ИИ. Здесь loop (цикл) можно понимать как рекурсивную цель: вы определяете цель, а ИИ постоянно итерирует, пока задача не будет выполнена. Она состоит примерно из пяти компонентов, и Claude Code и Codex уже обладают всеми пятью компонентами.

Я полагаю, это может быть тем способом, каким мы будем взаимодействовать с кодирующими агентами в будущем. Однако всё это всё ещё находится на ранней стадии, и я сохраняю скептицизм. Вам обязательно нужно внимательно следить за стоимостью токенов, поскольку расходы могут сильно различаться в зависимости от модели использования, особенно если вы «богаты токенами» или «испытываете их дефицит». Вам также нужен какой-то механизм, гарантирующий, что качество не снизится. Озабоченность по поводу «AI-мусора» (slop) также обоснована. Тем не менее, давайте разберёмся, в чём суть дела.

@steipete недавно сказал: «Вам больше не следует писать подсказки для кодирующих агентов. Вам нужно спроектировать циклы, которые будут подсказывать вашим агентам». Аналогично, руководитель Claude Code от Anthropic @bcherny сказал: «Я больше не подсказываю Claude. У меня есть набор циклов, которые подсказывают Claude и сами решают, что делать дальше. Моя работа — писать циклы».

Тогда что это вообще значит?

В течение последних примерно двух лет, чтобы заставить кодирующий агент что-то сделать, вы просто писали хороший промпт и предоставляли достаточный контекст. Вы вводили одно предложение, читали возвращаемый результат, а затем вводили следующее. Агент был инструментом, который вы держали в руках и поэтапно продвигали. Этот этап в какой-то мере подошёл к концу, по крайней мере, некоторые считают, что он вот-вот закончится.

Сейчас вы создаете небольшую систему: она самостоятельно обнаруживает задачи, распределяет их, проверяет результаты, фиксирует выполнение и решает, что делать дальше. То есть вы заставляете эту систему управлять агентами, а не сами постоянно давать им подсказки. Ранее я писал о ее «родственнике» — agent harness engineering (инженерия среды выполнения агентов), то есть создании среды для работы отдельного агента; а также factory model (фабричная модель), то есть системе построения программного обеспечения. Loop engineering находится на уровне выше harness. Она похожа на harness, но работает по таймеру, создает небольших помощников и способна к самоподпитке.

Меня удивило, что это уже больше не просто вопрос «инструментального уровня». Год назад, если вам нужен был цикл, вам приходилось писать кучу bash-скриптов и постоянно поддерживать их. Это было вашим собственным делом, принадлежало только вам. Сейчас эти компоненты непосредственно встроены в продукт. Способности, перечисленные Штейнбергером, почти один к одному соответствуют приложению Codex и почти так же точно — Claude Code. Как только вы осознаете, что их форма одинакова, вы перестанете думать, какой инструмент выбрать, и начнёте проектировать цикл: независимо от того, в каком инструменте вы находитесь, он будет продолжать работать.

Пять компонентов и некоторые пояснения

Циклу нужно пять вещей плюс место для хранения информации. Сначала я перечислю их, а затем сопоставлю по порядку.

Во-первых, Automations (автоматизированные задачи): запускаются по расписанию, автоматически обнаруживают и распределяют.

Во-вторых, Worktrees (рабочие деревья): позволяют двум параллельно работающим агентам не перезаписывать файлы друг друга.

Третье, навыки: запишите информацию о проекте, чтобы агенту не приходилось каждый раз угадывать.

Четвертое, плагины и коннекторы: позволяют агентам подключаться к инструментам, которые вы уже используете.

Пятый: суб-агенты (субагенты): один отвечает за предложение решений, другой — за проверку решений.

Затем шестой элемент: memory (память). Это может быть Markdown-файл, доска Linear или любое другое место, независимое от отдельного диалога, где сохраняются «завершенные задачи» и «следующие шаги». Звучит просто, как будто это не важно, но это один и тот же прием, на котором основаны все долгосрочно работающие агенты. Я подробно описал это в разделе о long-running agents: модель забывает между каждым запуском, поэтому память должна храниться на диске, а не в контексте. Агенты забывают, но репозиторий кода — нет.

Сейчас оба продукта обладают этими пятью компонентами.

Их названия отличаются в некоторых местах, но по сути возможности одинаковы. Ниже я подробно объясню, потому что, честно говоря, зависит ли цикл в конечном итоге от стабильной работы или тайно протекает везде, ключевое значение имеют детали.

Автоматизации — это то, что превращает loop в настоящий loop, а не в одноразовую задачу, которую вы запустили вручную. В приложении Codex вы можете создать автоматизацию на вкладке Automations, выбрав проект, промпт, который он должен выполнять, частоту запуска и то, будет ли он работать в вашей локальной checkout-версии или в фоновом worktree. Результаты запусков, в которых обнаружены проблемы, попадают в Triage inbox (почтовый ящик для распределения), а запуски без проблем автоматически архивируются — это удобно. Внутри OpenAI его также используют для выполнения скучных, но необходимых задач, таких как ежедневное распределение issue, анализ причин сбоев CI, написание кратких отчетов по коммитам и отслеживание багов, введенных в прошлую неделю. Автоматизации могут вызывать навыки, поэтому вы можете поддерживать повторяющиеся задачи в актуальном состоянии: запускайте $skill-name, а не вставляйте целую стену инструкций в плановое задание, которое никто больше не будет обновлять.

Claude Code также может достичь того же эффекта, но другим путем: он использует планирование и хуки. Вы можете запускать запрос или команду с фиксированным интервалом с помощью /loop, настроить cron-задачу или вызывать shell-команды через хуки на определенных этапах жизненного цикла агента. Если вы хотите, чтобы он продолжал работать после закрытия ноутбука, вы можете развернуть всю систему на GitHub Actions. Идея та же самая: вы определяете автономную задачу, задаете ей ритм и позволяете результатам приходить к вам, вместо того чтобы самостоятельно проверять всё вручную.

Еще один полезный встроенный элемент, который ближе к основной теме этой статьи. /loop будет повторяться в ритме; /goal будет выполняться непрерывно, пока не будет выполнено указанное вами условие. После каждого цикла отдельная небольшая модель оценивает, завершена ли задача, поэтому агент, пишущий код, не является тем, кто сам себе выставляет оценку. Вы можете задать условие, например: «все тесты в test/auth проходят успешно, и lint чист», а затем отойти. Codex обладает такой же возможностью, также называемой /goal. Он будет работать на протяжении нескольких циклов, пока не будет выполнено проверяемое условие остановки, и поддерживает приостановку, возобновление и очистку. Один и тот же элемент присутствует в обоих инструментах. Это в основном и есть шаблон, который постоянно повторяется в статье.

Таким образом, Automations отвечают за выявление задач, а остальная часть цикла — за их выполнение.

Когда вы запускаете более одного агента, конфликты файлов становятся точкой отказа. Два агента, одновременно записывающие один и тот же файл, — это то же самое, что два инженера, изменяющие одну и ту же строку кода без общения. Git worktree решает эту проблему. Это отдельный рабочий каталог на отдельной ветке, но с общим историей репозитория кода, поэтому изменения одного агента физически не могут затронуть checkout другого агента.

Codex непосредственно встроил поддержку worktree, поэтому несколько потоков могут одновременно обрабатывать один и тот же репозиторий без конфликтов. Claude Code также может достичь такой же изоляции с помощью git worktree: вы можете открыть сессию в отдельном checkout с помощью флага --worktree или установить isolation: worktree на субагенте, чтобы каждый помощник получал новый checkout и автоматически очищал его после завершения. Я писал об этом человеческом аспекте в the orchestration tax: worktrees устраняют механические конфликты, но вы всё ещё остаётесь лимитом. То, сколько агентов вы можете запускать одновременно, определяется не инструментами, а вашим review bandwidth (пропускной способностью на проверку).

Skill — это механизм, позволяющий вам не объяснять заново одну и ту же контекстную информацию на каждом сеансе, как золотой рыбке. Оба инструмента используют одинаковый формат: папка с файлом SKILL.md, содержащим инструкции и метаданные, а также необязательные скрипты, справочные материалы и ресурсы. Codex запускает skill, когда вы вызываете его с помощью $ или /skills, а также автоматически запускает его, когда ваша задача соответствует описанию skill. Именно поэтому лаконичное и простое описание часто лучше, чем сложное и изысканное. Claude Code действует точно так же — я уже описывал эту модель в agent skills.

Навыки также позволяют избежать постоянного расходования ваших усилий. Я уже говорил о долгах по намерениям: каждый раз, когда агент начинает сессию, он запускается с нуля, и если в вашем намерении есть пробелы, он заполнит их уверенными предположениями. Навыки — это вынесение таких намерений наружу: договоренности по проекту, шаги сборки, «мы так не делаем, потому что раньше произошел тот инцидент» и т. д. — всё это записывается один раз в место, которое агент читает при каждом запуске. Без навыков на каждом круге цикла нужно заново выводить весь ваш проект; с навыками это становится похожим на сложный процент.

Нужно четко различать: skill — это формат написания, а plugin — способ распространения. Когда вы хотите совместно использовать skill между несколькими репозиториями кода или объединить несколько skill в один пакет, вы упаковываете их в plugin. Так работает и Codex, и Claude Code.

Петля, которая видит только файловую систему, — это небольшая петля. Коннекторы, построенные на основе MCP, позволяют агентам читать ваш трекер задач, запрашивать базы данных, вызывать API стейджинга или отправлять сообщения в Slack. Codex и Claude Code поддерживают MCP, поэтому коннектор, написанный для одного из них, как правило, также работает и в другом. Плагины объединяют коннекторы и навыки, чтобы ваши коллеги могли установить полную конфигурацию одним кликом, а не воссоздавать её по памяти.

Вот в чём разница между «агент сообщает вам: „вот решение“» и «цикл автоматически открывает PR, связывает тикет в Linear и уведомляет канал после успешного прохождения CI». Connectors важны, потому что они позволяют циклу действовать в вашей реальной среде, а не просто говорить: «если бы я мог, я бы сделал это».

В цикле наиболее полезной структурной идеей является разделение «автора» и «проверяющего». Модель, пишущая код, слишком легко проявляет излишнюю снисходительность при оценке собственной работы. Другой агент с другими инструкциями, а иногда и с использованием другой модели, способен выявить проблемы, которые первый агент игнорирует после самовнушения.

Codex создает субагенты только по вашему запросу; они работают параллельно, а затем объединяют результаты в один ответ. Вы можете определить собственные агенты в файлах TOML в папке .codex/agents/: каждый агент имеет имя, описание, инструкции, а также необязательные параметры модели и интенсивности рассуждений. Таким образом, ваш проверяющий на безопасность может быть мощной моделью с высокой интенсивностью рассуждений, а ваш исследователь — быстрой, только для чтения легкой моделью. Claude Code также предоставляет аналогичную функциональность через субагенты и команды агентов в .claude/agents/, позволяя нескольким агентам передавать работу друг другу. Наиболее распространенная разбивка обязанностей на обеих сторонах: один агент исследует, один реализует, один проверяет соответствие спецификациям.

Я уже дважды излагал эту точку зрения: один раз в code agent orchestra, второй — в adversarial code review. Она особенно важна в loop, потому что loop будет работать, пока вы не смотрите, и поэтому единственный повод оставить его — это наличие проверяющего, которому вы действительно доверяете. Subagents действительно потребляют больше токенов, поскольку каждый агент выполняет собственные вызовы модели и инструментов, поэтому следует применять их там, где «второе мнение стоит того, чтобы заплатить». Именно это в основе и делает /goal Claude Code: новый модель оценивает, завершен ли loop, а не модель, которая выполняет работу. То есть она применяет разделение «создателя» и «проверяющего» непосредственно к условию остановки.

Как выглядит цикл?

Соединив всё это вместе, отдельный поток превращается в небольшую панель управления. Ниже — структура, которую я часто использую.

Каждое утро автоматизация запускается в репозитории кода. Её промпт вызывает навык триажа, который анализирует сбои CI за вчера, открытые задачи и последние коммиты, а затем заносит найденное в Markdown-файл или доску Linear. Для каждой проблемы, требующей внимания, поток открывает изолированный worktree, запускает подагент для подготовки решения и затем второго подагента для проверки этого решения на основе навыков проекта и существующих тестов.

Коннекторы позволяют этому циклу автоматически открывать PR и обновлять тикет. Всё, что не может обработать цикл, попадает в входящую папку triage для моей обработки. Файл состояния является основой всей системы: он запоминает, что уже пробовалось, что прошло, а что всё ещё не завершено. Поэтому утренний запуск на следующий день продолжится с того места, где остановился сегодня.

Обратите внимание, что вы действительно сделали. Вы просто спроектировали один раз. Эти шаги не были вами пошагово запрограммированы. Это и есть реальная версия фразы Штейнбергера. И тот же цикл может работать как в Codex, так и в Claude Code, поскольку сами компоненты являются одними и теми же.

Loop всё ещё ничего не сделает за вас

Loop изменил способ работы, но не удалил вас из процесса. На самом деле, по мере того как loop становится сильнее, три проблемы становятся более острыми, а не менее.

Проверка всё ещё зависит от вас. Цикл, работающий без присмотра, может также ошибаться без присмотра. Вы разделили sub-agent verifier и maker именно для того, чтобы фраза цикла «завершено» имела хоть какой-то смысл. Даже тогда «завершено» остаётся утверждением, а не доказательством. Я постоянно повторяю одно и то же в статье «Code review in the age of AI»: ваша задача — доставить код, который вы подтвердили как рабочий.

Если вы оставите это без внимания, ваше собственное понимание всё равно будет разлагаться. Чем быстрее Loop доставляет вам код, который вы не писали сами, тем больше разрыв между тем, что вы действительно понимаете, и тем, что реально существует в системе. Это называется comprehension debt (долг понимания). Если вы не читаете то, что производит Loop, гладкий Loop только ускоряет рост этого долга.

И да, наиболее удобная позиция, скорее всего, является и самой опасной. Когда цикл может работать самостоятельно, легко перестать формировать собственные суждения и просто принимать всё, что он возвращает. Я называю это когнитивной капитуляцией. Если вы проектируете цикл с использованием суждений, он становится лекарством; если вы создаете цикл только для того, чтобы избежать мышления, он становится ускорителем. Одно и то же действие может привести к совершенно противоположным результатам.

Создавайте цикл, но всё ещё будьте инженером

Я считаю, что это предвещает эволюцию направления нашей будущей работы. Тем не менее, если я не проверю код самостоятельно или полностью полагаюсь на автоматизированный цикл для исправления кода, качество моего продукта пострадает. Я очень скоро попаду в порочный круг: буду всё глубже и глубже закапываться в проблемы.

Так что, конечно, вы можете создать собственный цикл, но не забывайте, что прямое указание вашему агенту по-прежнему эффективно. Ключ в том, чтобы найти правильный баланс.

Результаты Loop также различаются у разных людей. Два человека могут создать абсолютно одинаковый loop, но получить совершенно противоположные результаты. Один использует его для ускорения работы, которую глубоко понимает; другой — чтобы избежать понимания самой работы. Loop не знает разницы между этими двумя случаями. Вы знаете.

Вот почему loop design (циклический дизайн) сложнее, чем prompt engineering (инженерия подсказок), а не проще. Подразумевается не то, что работа стала легче, а то, что точка рычага сместилась.

Создавайте цикл. Но создавайте его так, как будто вы всё ещё стремитесь быть инженером, а не просто человеком, который нажимает кнопку «Запуск».

[Оригинальная ссылка]

Нажмите, чтобы узнать о вакансиях BlockBeats

Добро пожаловать в официальное сообщество律动 BlockBeats:

Телеграм-канал с подпиской: https://t.me/theblockbeats

Телеграм-чат: https://t.me/BlockBeats_App

Официальный аккаунт Twitter: https://twitter.com/BlockBeatsAsia