LLM как Stateless-процесс: как я перестал полагаться на память нейросети и вынес состояние в файлы
Проблема: Иллюзия памяти и стохастический хаос
Большинство проблем при работе с AI-ассистентами (Cursor, Windsurf, Kiro и др.) проистекают из одной иллюзии: мы ждем от них «памяти». Но LLM по своей природе — это стохастический stateless-исполнитель с эфемерным контекстом.
Любая сессия со временем подвергается «гнили контекста» (Context Rot). IDE автоматически суммаризирует историю, при этом важные детали реализации просто выбрасываются. Один сбой сессии или обрыв связи — и вы тратите время на повторное «обучение» модели. Я подошел к этому как к задаче проектирования отказоустойчивых систем: если процесс не может надежно хранить состояние — состояние должно быть внешним.
Парадигма: External State vs Embedded Memory
Вместо того чтобы пытаться запихнуть в модель побольше контекста, я внедрил архитектуру, где модель не обязана помнить ничего. Она каждый раз читает актуальный стейт извне. Это превращает ассистента из «умного собеседника» в предсказуемый инженерный инструмент.
Протокол SESSION_RECOVERY
Система состоит из трех компонентов, которые делают процесс разработки детерминированным.
1. Оперативная память (файловый уровень)
Состояние вынесено в Markdown-файлы. Это позволяет контролировать «hot working set» (рабочее множество) данных:
CURRENT_SESSION_TASKS.md: Текущий стек задач (не более 150 строк). Это ваш Dashboard. Его можно вынести на отдельный монитор, чтобы всегда видеть текущий интент системы и точку, в которой находится разработка.YYYY_MM_DD__PROMPT_HISTORY.md: Event log всех входящих директив. Это ваш Write-Ahead Log.YYYY_MM_DD__SESSION_COMPLETED.md: Архив, куда вытесняются завершенные задачи, чтобы не замусоривать контекст отработанным топливом.
2. Статусная машина (The Orchestrator)
Файл задач — это не просто TODO-лист, а стейт-машина исполнения: PLANNING → IN_PROGRESS → BLOCKED → COMPLETED
Агент обязан обновлять статус перед каждым действием. Если сессия обрывается на этапе IN_PROGRESS, в новой сессии агенту достаточно прочитать этот файл, чтобы продолжить работу с точностью до строки кода. Без вводных вопросов и потери фокуса.
3. Автоматизация (Hooks)
Для исключения человеческого фактора используются хуки на событие promptSubmit:
Logger Hook: Автоматически пишет каждый промпт в историю. Это дает 100% аудит процесса.
Task Manager Hook: Принуждает агента синхронизировать внешний стейт (
CURRENT_SESSION_TASKS.md) перед генерацией ответа.
Почему это работает?
В отличие от модного сейчас «вайб-кодинга», где всё строится на ощущениях и удачных промптах, этот подход вносит в процесс детерминизм. Мы не «просим» модель помнить — мы даем ей физический носитель состояния.
Профиты для инженера и менеджмента
Восстановление за 0 секунд: Обрыв сессии больше не является инцидентом.
Observability: Вы всегда видите, «что он там себе вообразил», просто глядя в файл задач.
Management & Audit: История промптов и изменений стейта — это готовый «Proof of Work». Этот лог можно отправить тимлиду для аудита или заказчику как прозрачный отчет о проделанной работе.
Side Tasks (0.x): Возможность внедрять мелкие правки в середине процесса без разрушения основного стека задач.
Вывод
AI-ассистенты не обязаны быть эфемерными. Если относиться к ним как к stateless-процессам и управлять состоянием извне, они начинают вести себя предсказуемо. Это не магия — это обычная инженерия.
Репозиторий проекта (на примере Kiro IDE): llm-session-recovery