Как Codex продолжает длинную задачу: контекст, субагенты и рабочий журнал

Что помогает агенту работать через несколько контекстных окон, учитывать новые условия и собирать результат нескольких исполнителей. Разбор OpenAI DevDay 2026 с тремя промптами со слайдов.

Вы поручили Codex доработать приложение. Он изучил файлы, написал код, запустил тесты. По ходу дела вы добавили несколько уточнений. Последнее: старый формат данных нужно сохранить, потому что им пользуется другой сервис.

Через пару часов работа продолжается. Где теперь находится это уточнение? Как агент возвращается к задаче после заполнения контекстного окна? И кто передаст новое условие исполнителю, если их уже несколько?

Я работаю с Codex в том числе над многочасовыми задачами. Поэтому в выступлении What Comes After Loops?: Deep Dive Into Agentic Architecture меня заинтересовали именно механизмы продолжения работы. Сессия вошла в программу OpenAI DevDay, который прошёл 29 сентября 2026 года.

В статье разберу сжатие контекста, распределение задач и рабочий журнал. Три инструкции со слайдов приведу в переводе. Через весь текст пройдёт условный пример с выгрузкой заказов в CSV. Он нужен для объяснения; это не описание клиентского проекта или проведённого эксперимента.

Когда мы просим обычный чат написать программу, между ответом модели и результатом часто стоим мы сами: копируем код, запускаем его, возвращаем ошибку и просим исправить.

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

Рабочую оболочку вокруг модели называют harness. Она управляет инструкциями, доступными инструментами, средой исполнения и контекстом, который передаётся модели. Поэтому качество агента зависит и от того, может ли он прочитать нужный файл, запустить приложение и увидеть полный результат проверки.

В контексте накапливаются инструкции, переписка, фрагменты файлов, вызовы инструментов и результаты проверок. Его объём конечен. Для продолжения длинной работы используется compaction, или сжатие контекста.

Продолжение длинной задачи зависит и от устройства оболочки, и от обучения самой модели. Оболочка управляет переходом между контекстными окнами, а модель обучена работать с перенесённым состоянием.

В документации OpenAI описан специальный объект сжатого состояния. Он переносит существенную информацию и рассуждения, но не предназначен для чтения человеком. Представлять этот механизм только как короткий текстовый пересказ переписки было бы неточно.

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

Для нашей выгрузки общая задача "добавить экспорт" может оставаться понятной. Но уточнение о старом сервисе определяет, какой именно экспорт допустим. Оно должно попасть и в реализацию, и в проверку результата.

Другая проблема длинных задач: агент сделал часть работы и остановился, хотя полезные следующие шаги ещё остались.

В выступлении разбирают несколько способов поддерживать продолжение: внешние циклы с повторными командами, сохранение цели вне основной истории разговора и обучение модели настойчивости. На примере /goal показывают, как отдельно сохранённая цель помогает двигаться к результату через несколько контекстных окон. Сейчас этот подход описан и в руководстве OpenAI по Goals.

Для пользователя здесь три разных вопроса:

В примере с экспортом условие "готово, когда добавлена кнопка" оставляет много неопределённости. Проверка может быть конкретнее: файл скачивается, нужные поля на месте, кириллица читается, прежний потребитель данных продолжает работать.

Такую приёмку стоит задавать вместе с целью. Тогда у агента есть основания для следующего шага и для остановки. Конкретные команды и возможности зависят от используемой среды Codex.

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

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

Документация Multi-agent описывает отдельные контексты субагентов и объединение результатов главным агентом. Параллельность полезна для независимых направлений. Последовательные шаги и частые изменения общего состояния хуже подходят для такого разделения. Расход токенов при добавлении исполнителей может вырасти.

На слайде Coordinate Skill показана такая инструкция:

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

Лишние уровни управления могут мешать. В выступлении отдельно описывают ситуацию, когда агенты начинают ждать согласований между руководящими ролями, которые сами же и придумали.

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

Пример со слайда относится к очереди pull request, или PR. Так называют изменения, предложенные для включения в проект. Перевод промпта:

Такое поручение охватывает проверку, исправления и интеграцию. Но слово "безопасно" само по себе не задаёт проверки. Один PR может менять формат экспорта, другой - его обработку в соседнем компоненте. Их совместную работу тоже нужно проверить.

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

Проверяющему нужны условия, которые делают изменение правильным в конкретном проекте. Сам запуск второго агента этих условий не добавляет. Поручение на слияние в main относится к показанному примеру; права на такие действия в своём проекте задаёт пользователь.

Третий промпт связывает длинную работу, пользовательские уточнения и нескольких исполнителей:

Самая полезная часть здесь для меня - работа с новым указанием. Его нужно сопоставить с тем, что уже происходит.

Допустим, агент начал менять экспорт, когда появилось требование сохранить совместимость. Нужно выяснить: начатая реализация ему соответствует? Меняется ли план? Кто ещё работает с форматом? Какая проверка подтвердит совместимость?

Условная запись в журнале:

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

У промпта есть ещё одно требование: проверить текущее состояние перед продолжением. Код мог измениться, тест мог упасть, замечание могло остаться неисправленным. Журнал помогает ориентироваться, а состояние работы нужно сверить с файлами и результатами проверок.

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

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

Об экономии токенов я писал отдельно: сколько токенов помогает сэкономить LeanCTX в Codex - мой опыт.

Документация проверена 12 ноября 2026 года.