Гугл-разработчик ПО Адди Османи в статье от 7 июня дал определение «Loop Engineering» как подход к проектированию AI-агентов для Prompt, в котором методы с ручными действиями инженера заменяются автоматизированной системой, и который состоит из пяти строительных блоков: Automations, Worktrees, Skills, Plugins/Connectors и Sub-agents.
Определения и функции пяти блоков
Согласно описанию фреймворка Адди Османи:
Automations（автоматизация）: Задачи, запускаемые по расписанию, отвечают за автоматическое выполнение «обнаружения» (Discovery) и «сортировки» (Triage). Османи поясняет, что Automations — это ключевой механизм, который превращает цикл в настоящую итерацию, а не «разовое выполнение». В Codex app Automations представлены на отдельных страницах и поддерживают команду /goal (запустить до выполнения условий); Claude Code реализует то же самое через планируемые задачи, cron, /loop, /goal и GitHub Actions.
Worktrees（деревья рабочих директорий）: Используя механизм git worktree, создаются отдельные рабочие каталоги для параллельного выполнения агентами, чтобы предотвратить конфликты, когда несколько агентов одновременно изменяют один и тот же файл. В Codex app worktree встроены для каждого thread; Claude Code обеспечивает такую же изоляцию через git worktree и флаг --worktree.
Skills（навыки）: В формате SKILL.md проектные знания, принятые практики и шаги сборки записываются во внешние документы, так что агентам при каждом запуске не нужно заново выводить контекст проекта. Оба инструмента используют один и тот же формат SKILL.md; Османи отмечает, что точные описания лучше, чем размытые формулировки.
Plugins / Connectors（плагины и коннекторы）: Построены на базе MCP (Model Context Protocol), чтобы агент мог получать доступ к внешним системам, таким как трекер Issue, базы данных, API-эндпоинты и средства коммуникации. Codex app и Claude Code оба поддерживают MCP, а Османи подтверждает, что один и тот же connector обычно можно использовать напрямую в обоих инструментах.
Sub-agents（субагенты）: Разделяют «агента для выполнения» и «агента для проверки» на отдельные роли, которые могут взаимодействовать посредством разных команд и даже разных моделей. Это предотвращает ситуацию, когда один агент оценивает себя слишком снисходительно. В Codex app они определяются в .codex/agents/ в формате TOML; в Claude Code — в .claude/agents/ с описанием Task subagents и agent teams.
Внешняя память (State): определение и роль шестого компонента
Османи определяет внешнюю память как «любые сущности, живущие за пределами одного диалога и используемые для фиксации того, что было сделано, и что будет следующим», например, Markdown-файлы или доски Linear. Причина необходимости такова: крупные языковые модели не сохраняют память между запусками, поэтому прогресс нужно хранить вне модели, а не в контексте (контекстном окне) самого моделирования.
Оба инструмента поддерживают этот механизм: Codex app связывает Linear через Markdown или Connector; Claude Code связывает Linear через AGENTS.md, файл прогресса или MCP-соединение.
Частые вопросы
В чем ключевое различие Loop Engineering и традиционного Prompt Engineering?
Согласно фреймворку Адди Османи, традиционный Prompt Engineering предполагает, что инженер вручную пишет Prompt и по циклу взаимодействует с агентом; Loop Engineering же проектирует систему, где Automations автоматически запускают процессы, Worktrees изолируют параллельное выполнение, Skills дают знания, Connectors подключают инструменты, Sub-agents разделяют выполнение и верификацию, а роль инженера смещается с «прямого управления агентом» на «проектирование системы для запуска агентом».
Какие строительные блоки сейчас поддерживают Codex app и Claude Code?
Согласно сравнительному анализу Османи, на момент публикации статьи оба инструмента полностью поддерживают пять блоков и механизм внешней памяти; основное различие — в названиях и конкретных путях: функциональность Automations имеет соответствия, Worktrees основаны на git worktree, Skills используют формат SKILL.md, Plugins/Connectors основаны на MCP, Sub-agents используют конфигурации в каталоге .agents/.
Как реализовано «разделение выполнения и верификации» в Sub-agents?
По словам Османи, в дизайне Sub-agents «агент, пишущий код», и «агент, проверяющий код» разделены на два независимых роли: они могут использовать разные команды и даже разные модели. Принцип аналогичен в команде Claude Code /goal: новый моделм оценивает, завершена ли задача, а не модель, которая выполняла задание, самостоятельно оценивает результат. Османи называет это применением принципа «делающий vs проверяющий» к самим условиям остановки.
