Длинные задачи: прогресс-файлы, циклы, перезапуск контекста

Задача на несколько часов или дней упирается не в способности модели, а в память. Контекстное окно конечно, компакция теряет детали, новая сессия начинается с чистого листа. Хорошая новость: эту проблему решают снаружи модели — файлами в репозитории и дисциплиной старта и завершения сессии. В уроке — три опубликованные схемы, напряжения между ними и рабочий цикл на codex exec.

Два режима отказа

Anthropic в статье Effective harnesses for long-running agents сравнивает длинную задачу со сменой инженеров, где каждый приходит без записки о передаче дел. Компакции, по их опыту, для этого недостаточно. Названы два типичных провала:

1. Агент пытается сделать всё за один заход и бросает фичу на полпути, когда кончается контекст.
2. Агент видит, что прогресс уже есть, и объявляет работу завершённой раньше времени.

Оба лечатся одинаково: объём работы задан явно и снаружи, а агент берёт по одному куску за раз.

Схема первая: длинный прогон и план в репозитории

В эксперименте OpenAI (Harness engineering) один запуск Codex регулярно работает над задачей больше шести часов, часто пока люди спят. Опоры у этого две.

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

План исполнения как артефакт. Сложная работа идёт по execution plan с журналом прогресса и решений, план коммитится. Если сессия оборвалась или контекст сжался, состояние не теряется — оно в файле. Формат и жизненный цикл таких планов — урок о планах исполнения.

Поверх этого — цикл, который авторы прямо называют циклом Ralph Wiggum: агент вносит изменения, запрашивает ревью у других агентов, отвечает на замечания и повторяет, пока все ревьюеры не будут удовлетворены.

В Codex для длинной работы есть режим цели: /goal задаёт долгосрочную цель до 4000 символов, её можно приостановить, возобновить и сбросить. Режим вышел из экспериментального статуса в мае 2026.

Схема вторая: инициализатор и прогресс-файлы

Anthropic делит работу на два типа сессий.

Инициализатор работает один раз: создаёт init.sh, который поднимает dev-сервер, файл прогресса, JSON-список фич — в их примере больше двухсот, все помечены как непроходящие — и первый коммит.

Рабочий агент в каждой следующей сессии берёт одну фичу, доводит её, коммитит и обновляет заметки. Старт сессии — ритуал: pwd, история git, файл прогресса, список фич, init.sh, базовая e2e-проверка — чтобы поймать то, что сломала предыдущая сессия, до начала новой работы.

Две детали стоит запомнить. Список фич хранится в JSON, потому что модель реже неуместно переписывает JSON, чем Markdown. И агенту разрешено менять в этом списке только поле passes — удалять или править тесты запрещено.

[
  {
    "id": "lead-form-utm",
    "description": "Форма заявки передаёт UTM-метки в CRM",
    "steps": [
      "Открыть /services/web?utm_source=test",
      "Отправить форму с валидным телефоном",
      "Проверить, что в тестовой CRM у лида source=test"
    ],
    "passes": false
  }
]

Схема третья: цикл Ralph

Джеффри Хантли описал самую простую версию: bash-цикл, который снова и снова подаёт агенту один и тот же промпт. Принципы:

• одна задача за итерацию, агент сам выбирает самую важную;
• спецификации — по файлу на тему, приоритизированный fix_plan.md, который автор регулярно стирает и генерирует заново;
• противодавление: тесты, типы и статический анализ отвергают плохой вывод;
• главный контекст работает как планировщик, поиск и запись отдаются субагентам;
• прямой запрет на заглушки и упрощённые реализации;
• коммит при зелёной сборке.

Хантли так же прямо пишет об ограничениях. Подход хорош для запуска greenfield-проекта с ожиданием «примерно 90% готовности», а в существующей кодовой базе он бы его применять не стал. Типичные сбои: поиск ошибочно решает «не реализовано», и появляется дубль; заглушки вместо реализации; сломанная сборка утром после ночного прогона; противоречие в спецификации, которое замечаешь слишком поздно.

Напряжение: компакция или перезапуск

Здесь источники расходятся, и это полезно понимать.

Anthropic в статье о дизайне обвязки описывает «тревогу контекста»: Sonnet 4.5 сворачивал работу, приближаясь к лимиту, и одной компакции не хватало — нужен был полный сброс контекста со структурированной передачей состояния. У Opus 4.5 проблема почти исчезла, и сбросы убрали. OpenAI делает ставку на нативную компакцию, обученную вместе с моделью. Хантли перезапускает контекст на каждой итерации по построению.

Наш вывод. Ответ зависит от модели и меняется с каждым её поколением. Но внешнее состояние — план, список фич, прогресс-файл, история коммитов — полезно в любой схеме: с ним компакция теряет меньше, а перезапуск стоит дешевле. Делайте так, чтобы новая сессия могла продолжить работу, прочитав три файла.

Свой цикл на codex exec

codex exec подходит для цикла: финальное сообщение идёт в stdout, прогресс — в stderr, промпт можно передать через stdin аргументом -. Ниже цикл с тремя предохранителями, которых нет в исходном однострочнике: условие остановки, лимит итераций и остановка при красной сборке.

#!/usr/bin/env bash
set -euo pipefail
max_iter=${MAX_ITER:-15}
features=docs/agent/features.json
mkdir -p logs/agent

for i in $(seq 1 "$max_iter"); do
  left=$(jq '[.[] | select(.passes == false)] | length' "$features")
  if [ "$left" -eq 0 ]; then
    echo "Все фичи проходят, итераций: $((i - 1))"; exit 0
  fi
  echo "Итерация $i, осталось фич: $left" >&2

  codex exec --sandbox workspace-write -o "logs/agent/iter-$i.md" - < docs/agent/PROMPT.md

  if ! make test-agent >/dev/null 2>&1; then
    echo "Сборка красная после итерации $i — нужен человек" >&2; exit 1
  fi
  git add -A && git commit -qm "agent: итерация $i" || true
done
echo "Лимит итераций исчерпан, осталось фич: $left" >&2; exit 2

Ты продолжаешь длинную задачу. Начни с ритуала:
1. Прочитай docs/agent/progress.md и последние 10 коммитов.
2. Подними стенд: scripts/env/up.sh. Прогони make test-agent.
   Если красно — сначала почини то, что сломала прошлая итерация.
3. Выбери ОДНУ фичу с passes=false из docs/agent/features.json.

Сделай её целиком. Никаких заглушек и TODO вместо реализации.
Прежде чем решить, что чего-то нет, найди это поиском по коду.
Проверь фичу по шагам из steps в браузере. Только после этого
поменяй passes на true. Другие поля и тесты не трогай.

В конце допиши в docs/agent/progress.md: что сделано, что осталось,
что неочевидного ты узнал о проекте.

Флаги проверяйте по codex exec --help — состав меняется от версии к версии. В CI тот же цикл лучше запускать с --ephemeral, чтобы не копить файлы сессий.

Где это уместно в агентстве

Хорошие кандидаты — работа с ясным объёмом и механической проверкой: перевод двух десятков Twig-партиалов на BEM по готовому правилу, миграция плагина на новую версию API OctoberCMS при хорошем покрытии тестами, вынос всех строк мобильного приложения в ресурсы локализации, генерация серии посадочных из плана.

Плохие кандидаты — всё, где объём или критерий готовности неясны: «улучшить производительность сайта», «переделать личный кабинет». Для них сначала нужна спецификация и список фич, то есть работа человека с агентом в интерактиве. Предупреждение Хантли о существующих кодовых базах относится ко всем клиентским проектам: длинный цикл на легаси без тестов размножит проблемы быстрее, чем решит.