Долгоживущие агенты: передача работы

Александр Поломодов продолжает разговор об устройстве кодинговых агентов после выпуска о SWE-agent. В предыдущем разборе агент решал отдельную задачу через удобный интерфейс. Теперь требуется построить приложение, работа над которым занимает несколько сессий. Основа выпуска — инженерный пост Anthropic «Effective harnesses for long-running agents» от ноября 2025 года. Это описание опыта команды, а не научная статья с измеренным вкладом каждого компонента. Пример авторов — создание веб-приложения, повторяющего интерфейс claude.ai.

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

Anthropic делает первую сессию особенной: агент-инициализатор готовит среду, а последующие сессии выполняет агент-разработчик. Обвязка у них сходная, различается прежде всего промпт. Инициализатор создаёт список функций, журнал прогресса, скрипт запуска init.sh и начальный коммит. Эти артефакты находятся вне контекста модели и переживают его сброс. Речь идёт о последовательной работе во времени; две роли ещё не означают систему параллельно работающих агентов.

Каждый артефакт отвечает на свой вопрос. Список функций определяет, что должно работать и что осталось сделать. Журнал объясняет, чем занималась предыдущая сессия и где остановилась. Скрипт запуска избавляет от повторного выяснения способа поднять приложение. Git сохраняет изменения и позволяет вернуться к проверенному состоянию. Названия файлов могут меняться, но разделение обязанностей полезно и в других подходах: требования, история намерений, запуск среды и история кода не заменяют друг друга.

Без такого порядка агент берётся за многое сразу: чат, темы оформления, загрузку разговоров, обработку ошибок. Контекст заканчивается, оставляя несколько недоделанных функций. Новая сессия сначала восстанавливает работоспособность основы и пытается угадать намерения предшественника. Возможна и другая ошибка: увидев часть готового интерфейса, агент объявляет весь проект завершённым. Если требования живут только в беседе, готовность легко вывести из того, что уже существует.

Вместо пункта «сделать чат» нужен пользовательский путь: открыть главный экран, нажать New Chat, увидеть новый разговор и приветствие, проверить появление разговора в боковой панели. Получается одновременно требование и сценарий приёмки. Разработчику разрешено менять признак прохождения после выполнения всех шагов, но запрещено удалять пункты или переписывать их смысл. В обсуждаемом решении запрет задан промптом; отдельная внешняя проверка неизменности требований не показана.

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

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

Для веб-приложения недостаточно зелёных модульных тестов и ответа API на запрос curl. Нужно пройти интерфейс как пользователь. В статье для этого применяли Puppeteer MCP. Однако нативные диалоги alert оказались плохо доступны через использованный инструмент, и связанные с ними функции сохраняли больше ошибок. Пример возвращает к теме SWE-agent: качество результата ограничено тем, какие действия доступны агенту и какие последствия он способен увидеть. Подключённый браузер ещё не означает полное покрытие пользовательского поведения.

История Git становится последовательностью состояний: подготовка проекта, новый чат, отправка сообщения, смена темы. Если очередной шаг ломает приложение, можно вернуться к предыдущему проверенному состоянию. Журнал дополняет эту историю объяснением работы. Полезная запись сообщает, что сделано, какие тесты пройдены, какие проблемы остались, что делать дальше и сколько сценариев проходит. Указание коммита связывает запись с конкретной версией кода.

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

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

Продолжение истории меняет перспективу. Ведущий упоминает проект компилятора, где несколько агентов синхронизировали работу через Git, и последующий материал о длительном создании приложений. В нём уточняется, что ранняя обвязка строилась вокруг Sonnet 4.5. С Opus 4.5 преждевременное завершение работы в описанном опыте ослабло настолько, что явные перезапуски заменили непрерывной сессией со сжатием. Одновременно появилось отдельное принятие результата через браузер. Это не отменяет ценность внешнего состояния: меняется необходимый состав механизмов. При обновлении модели старые ограничения стоит проверять заново, сохраняя возможность установить, что действительно работает.