Во время длительной работы с ИИ-агентом можно столкнуться с неприятной ситуацией: после нескольких удачных шагов он начинает упускать требования, возвращаться к проверенным гипотезам и предлагать изменения, которые пользователь уже отклонил. Разработчик напоминает об ограничениях, прикладывает дополнительные пояснения и просит ещё раз проверить результат. История взаимодействия растёт вместе с количеством исправлений. Такое поведение может быть связано с тем, как модель использует накопленный контекст. В этой статье я рассмотрю причины возникновения проблемы и предложу способ организации длительной работы через передачу задачи агенту в новой сессии.
Контекст ИИ-агента включает инструкции, сообщения пользователя, предыдущие ответы, содержимое прочитанных файлов и результаты вызовов инструментов. Управляющая система собирает эти данные и передаёт модели при формировании очередного ответа. От состава входных данных зависит, какие требования и факты окажутся доступны на следующем шаге.
У каждого контекстного окна есть ограничение по объёму. При этом качество использования информации может снижаться ещё до достижения технического лимита. Термином «деградация контекста» обычно описывают подобное ухудшение работы с накопленной информацией. Для практической работы с агентами это означает, что доступный объём окна следует учитывать вместе с качеством его содержимого.
При разработке программного обеспечения история быстро наполняется промежуточными данными. Агент читает исходный код, получает журналы ошибок, проверяет предположения, меняет реализацию и запускает тесты. Каждый шаг добавляет сведения, полезность которых со временем меняется. После исправления ошибки её старый стек вызовов может занимать значительную часть истории. Отклонённое решение продолжает присутствовать рядом с действующими договорённостями. Результаты проверки относятся к определённой версии кода, которая уже могла измениться.
Представим задачу по оптимизации поиска заказов. Пользователь просит сохранить формат ответа API и существующие правила сортировки. Агент изучает запросы к базе данных, проверяет загрузку связанных сущностей и экспериментирует с пагинацией. Через некоторое время первоначальные ограничения оказываются окружены большим количеством технических подробностей. Если агент затем предлагает изменить структуру ответа или повторяет уже проверенный эксперимент, разработчик получает повод оценить состояние контекста.
Один из способов управлять этой ситуацией заключается в передаче работы другому агенту в новой сессии. Текущий исполнитель фиксирует актуальное состояние задачи и подготавливает материалы для продолжения.
Новый агент может использовать ту же модель, инструкции и инструменты. Он получает подготовленное описание задачи и доступ к рабочим материалам. Дальнейшее изучение проекта происходит по мере необходимости.
Подобный принцип применяется в системах для длительной автономной работы. Anthropic описывает организацию последовательных сессий через сохранение результатов в файлах состояния. Следующий агент читает эти материалы, проверяет окружение и выбирает очередной участок работы.
На практике такую передачу можно организовать с помощью передаточного документа. Перед завершением текущего диалога следует попросить агента сохранить состояние работы в отдельном файле, например HANDOFF.md. Документ должен находиться в каталоге, доступном следующему исполнителю.
В документе важно зафиксировать актуальную цель и ограничения пользователя. За время обсуждения требования могли измениться, поэтому следующему исполнителю нужна их действующая версия. Особое внимание стоит уделить поздним уточнениям, которые повлияли на выбранный подход.
Описание текущего состояния должно объяснять, что уже выполнено, какие файлы изменены и какая работа остаётся. Для проекта под управлением Git полезно указать ветку, текущий коммит и наличие незакоммиченных изменений. Эти сведения связывают текст документа с конкретным состоянием проекта.
Существенные решения также стоит сохранить вместе с их причинами. Если определённый вариант загрузки связанных сущностей привёл к дублированию строк при пагинации, документ должен описывать обнаруженный эффект и условия его возникновения. Это поможет следующему агенту учитывать результаты предыдущего исследования.
Неподтверждённые предположения необходимо обозначить как гипотезы. Открытые вопросы и ближайший шаг завершают описание состояния и задают точку продолжения.
Для подготовки передачи можно использовать короткий запрос:
Подготовь передачу текущей задачи в новую сессию.
Сохрани состояние работы в файле HANDOFF.md в корне проекта.
Зафиксируй актуальную цель, требования пользователя
и действующие ограничения.
Опиши выполненные изменения, затронутые файлы и оставшуюся
работу. Укажи рабочую ветку, текущий коммит и незакоммиченные
изменения, если эти сведения доступны.
Перед закрытием сессии разработчику стоит прочитать полученный документ. В первую очередь полезно проверить цель, ограничения и степень готовности результата. Агент мог пропустить уточнение пользователя, переоценить результат проверки или неточно описать незавершённое изменение. Исправления на этом этапе помогут следующему исполнителю получить согласованное описание.
После сохранения документа в работу вступает новая сессия с пустым контекстом. Для новой сессии достаточно одного предложения:
Прочитай /workspace/orders/HANDOFF.md и приступай к работе.
Такой запуск предполагает, что передаточный документ содержит сведения, необходимые для продолжения. Следующий агент читает его, знакомится с рабочими материалами и восстанавливает состояние задачи. При обнаружении расхождений между описанием и файлами потребуется уточнить фактическое состояние проекта.
Подготовку передачи удобно выполнять на границе содержательных этапов: после исследования проблемы, завершения изменения или получения результатов тестирования. В эти моменты проще описать достигнутое состояние и определить дальнейшее действие.
При длительной работе документ полезно обновлять по мере продвижения. Тогда подготовка следующей передачи опирается на уже записанные решения и результаты. Это особенно важно, если к концу сессии качество использования накопленной истории вызывает сомнения.
Любая передача сопровождается риском потери деталей. Сохранённое описание может содержать пропуски или ошибочные выводы, поэтому исходные требования, код и результаты проверок должны оставаться доступными. Следующий агент получает возможность уточнять сведения и проверять основания предыдущих решений.
Передаточный документ позволяет сохранять рабочее состояние задачи между сессиями. Качество продолжения зависит от точности этого описания, доступности исходных материалов и проверки фактического состояния проекта новым исполнителем.
