С ростом возможностей ИИ-агентов разработчики всё чаще поручают им сложные задания, которые требуют усилий на протяжении часов или даже дней. Но обеспечение стабильного продвижения агентов через несколько контекстных окон по-прежнему остаётся нерешённой задачей.
Основная трудность с долгоживущими агентами заключается в том, что они функционируют в отдельных сессиях, и каждая новая сессия начинается без воспоминаний о предыдущей. Представьте проект по разработке ПО, где инженеры работают посменно, а каждый новый специалист приходит без знаний о том, что происходило раньше. Из-за ограничений контекстных окон и невозможности завершить большинство сложных проектов в одном окне агентам нужен механизм, чтобы связывать сессии кодирования.
Разработчики создали двухкомпонентное решение, чтобы Claude Agent SDK эффективно работал через множество контекстных окон: инициализатор-агент, который настраивает окружение при первом запуске, и кодирующий агент, который отвечает за постепенное продвижение в каждой сессии, оставляя чёткие следы для следующей. Примеры кода доступны в сопутствующем быстром старте.
Проблема долгоживущих агентов
Claude Agent SDK — это мощная универсальная рамка для агентов, которая хорошо справляется с кодированием и другими задачами, где модель использует инструменты для сбора контекста, планирования и выполнения. У неё есть функции управления контекстом, такие как сжатие, которое позволяет агенту работать над задачей, не исчерпывая окно контекста. Теоретически при такой настройке агент должен выполнять полезную работу неограниченно долго.
Однако сжатие само по себе недостаточно. Даже передовая модель кодирования вроде Opus 4.5 на базе Claude Agent SDK в цикле через несколько контекстных окон не сможет построить полноценное веб-приложение производства, если дать только общий промт вроде «построй клон claude.ai».
Сбои Claude проявлялись в двух типичных сценариях. Во-первых, агент часто пытался сделать слишком много за раз — по сути, реализовать приложение целиком за один подход. Это приводило к тому, что модель исчерпывала контекст посреди реализации, оставляя следующую сессию с наполовину готовой функцией без документации. Тогда агенту приходилось гадать, что произошло, и тратить время на восстановление базового функционирования приложения. Такое случается даже со сжатием, которое не всегда передаёт идеально ясные инструкции следующему агенту.
Во-вторых, позже в проекте, после реализации некоторых функций, очередная инстанция агента осматривалась, видела проделанную работу и объявляла задачу завершённой.
Это разбивает проблему на две части. Сначала нужно создать начальное окружение, которое закладывает основу для всех функций, указанных в промте, чтобы агент работал поэтапно и по функциям. Во-вторых, каждый агент должен продвигаться к цели постепенно, оставляя окружение в аккуратном состоянии к концу сессии. Под «аккуратным состоянием» подразумевается код, подходящий для слияния в основную ветку: без серьёзных ошибок, организованный, хорошо задокументированный, чтобы разработчик мог сразу взяться за новую функцию, не разбирая чужой бардак.
В внутренних экспериментах эти проблемы решили с помощью двухэтапного подхода:
- Инициализатор-агент: Первая сессия агента использует специальный промт, чтобы модель настроила начальное окружение: скрипт
init.sh, файл claude-progress.txt для лога действий агентов и начальный коммит в git, показывающий добавленные файлы. - Кодирующий агент: Каждая последующая сессия просит модель сделать постепенный шаг, затем оставить структурированные обновления.1
Ключевой идеей стало дать агентам быстрый способ понять состояние работы при старте с чистого контекстного окна — через файл claude-progress.txt и историю git. Эти приёмы вдохновлены повседневными практиками эффективных инженеров-программистов.
Управление окружением
В обновлённом руководстве по промтингу Claude 4 описаны лучшие практики для рабочих процессов с несколькими контекстными окнами, включая структуру рамки с «отдельным промтом для самого первого окна контекста». Этот «отдельный промт» просит инициализатор-агента подготовить окружение со всем необходимым контекстом для будущих кодирующих агентов. Здесь мы углубимся в ключевые элементы такого окружения.
Список функций
Чтобы избежать сценария, когда агент пытается реализовать приложение целиком или преждевременно считает проект завершённым, инициализатор-агент создаёт полный файл с требованиями к функциям, расширяя исходный промт пользователя. В примере с клоном claude.ai это более 200 функций, например «пользователь может открыть новый чат, ввести запрос, нажать enter и увидеть ответ ИИ». Все функции изначально отмечены как «непрошедшие», чтобы последующие кодирующие агенты имели чёткий план полной функциональности.
{ "category": "functional", "description": "New chat button creates a fresh conversation", "steps": [ "Navigate to main interface", "Click the 'New Chat' button", "Verify a new conversation is created", "Check that chat area shows welcome state", "Verify conversation appears in sidebar" ], "passes": false }Кодирующим агентам разрешается редактировать этот файл только путём изменения поля passes, с жёсткими инструкциями вроде «Недопустимо удалять или редактировать тесты, поскольку это может привести к пропущенным или ошибочным функциям». После экспериментов выбрали JSON, потому что модель реже некорректно меняет или перезаписывает JSON-файлы по сравнению с Markdown.
Постепенное продвижение
С таким каркасом начального окружения следующая итерация кодирующего агента фокусируется только на одной функции за раз. Этот постепенный метод оказался ключевым для преодоления склонности агента хвататься за всё сразу.
При постепенной работе модель всё равно должна оставлять окружение в аккуратном состоянии после изменений в коде. В экспериментах лучший способ добиться этого — просить модель коммитить прогресс в git с описательными сообщениями и писать саммари в файл прогресса. Это позволяло модели использовать git для отката плохих изменений и восстановления рабочих состояний кодовой базы.
Такие методы также повышали эффективность, избавляя агента от необходимости гадать о предыдущих действиях и тратить время на перезапуск базового приложения.
Тестирование
Ещё один распространённый сбой — склонность Claude отмечать функцию завершённой без должного тестирования. Без явного указания в промте Claude вносил изменения в код, даже проводил unit-тесты или команды curl против dev-сервера, но не замечал, что функция не работает целиком.
При создании веб-приложения Claude хорошо справлялся с end-to-end проверкой функций, если явно просить использовать инструменты автоматизации браузера и тестировать как реальный пользователь.
Предоставление Claude таких инструментов для тестирования сильно улучшило результаты, поскольку агент мог выявлять и исправлять ошибки, неочевидные по коду.
Некоторые проблемы сохраняются, например ограничения зрения Claude и инструментов автоматизации браузера, из-за которых трудно ловить все виды багов. К примеру, Claude не видит нативные модальные окна браузера через Puppeteer MCP, и функции, зависящие от них, выходили баггированными.
Вход в рабочий ритм
С учётом всего вышеперечисленного каждый кодирующий агент проходит серию шагов для ориентировки в ситуации — некоторые простые, но полезные:
- Запустите
pwd, чтобы увидеть текущую директорию. Редактировать файлы можно только в ней. - Прочитайте логи git и файлы прогресса, чтобы узнать о недавней работе.
- Изучите файл со списком функций и выберите приоритетную незавершённую для работы.
Этот подход экономит токены в каждой сессии, поскольку агенту не нужно заново разбираться, как тестировать код. Также полезно, если инициализатор-агент напишет скрипт init.sh для запуска dev-сервера и базового end-to-end теста перед новой функцией.
В случае с клоном claude.ai агент всегда запускал локальный dev-сервер и использовал Puppeteer MCP, чтобы начать новый чат, отправить сообщение и получить ответ. Это позволяло быстро выявить, если приложение оставлено в сломанном состоянии, и сразу исправить баги. Если бы агент сразу взялся за новую функцию, проблема только усугубилась бы.
Типичная сессия начинается с таких сообщений ассистента:
[Assistant] Я начну с ориентировки и понимания текущего состояния проекта. [Tool Use] <bash - pwd> [Tool Use] <read - claude-progress.txt> [Tool Use] <read - feature_list.json> [Assistant] Давайте проверим лог git, чтобы увидеть недавнюю работу. [Tool Use] <bash - git log --oneline -20> [Assistant] Теперь посмотрим, есть ли скрипт init.sh для перезапуска серверов. <Запускает dev-сервер> [Assistant] Отлично! Теперь перейдём к приложению и проверим, что базовые функции работают. <Тестирует базовую функциональность> [Assistant] По результатам проверки базовая функциональность в порядке. Основные чат-функции, переключение тем, загрузка разговоров и обработка ошибок — всё функционирует правильно. Теперь разберёмся подробнее с файлом tests.json, чтобы понять, что реализовать дальше. <Начинает работу над новой функцией>| Проблема | Поведение инициализатор-агента | Поведение кодирующего агента |
|---|---|---|
| Claude преждевременно объявляет весь проект завершённым. | Создаёт файл со списком функций: на основе спецификации формирует структурированный JSON с описаниями end-to-end функций. | В начале сессии читает файл со списком функций. Выбирает одну функцию для работы. |
| Claude оставляет окружение с багами или без документации прогресса. | Создаёт начальный git-репозиторий и файл с заметками о прогрессе. | Начинает сессию с чтения файла заметок и логов git-коммитов, запускает базовый тест на dev-сервере, чтобы поймать недокументированные баги. Завершает сессию коммитом в git и обновлением прогресса. |
| Claude отмечает функции завершёнными слишком рано. | Создаёт файл со списком функций. | Самостоятельно проверяет все функции. Отмечает как «прошедшие» только после тщательного тестирования. |
| Claude тратит время на разбор, как запустить приложение. | Пишет скрипт init.sh для запуска dev-сервера. | Начинает сессию с чтения init.sh. |
Перспективы развития
Это исследование показывает один возможный набор решений для рамки долгоживущего агента, чтобы модель продвигалась постепенно через множество контекстных окон. Однако остаются открытые вопросы.
В частности, неясно, эффективнее ли один универсальный кодирующий агент во всех ситуациях или лучше использовать многоагентную архитектуру. Логично, что специализированные агенты — для тестирования, контроля качества или очистки кода — справятся с подзадачами жизненного цикла разработки ПО ещё лучше.
Кроме того, этот демо оптимизирован для разработки полнофункциональных веб-приложений. Дальнейшее направление — обобщить выводы на другие области. Вероятно, часть или все уроки применимы к долгоживущим агентным задачам в научных исследованиях или финансовом моделировании.