Разбор · OpenClaw

OpenClaw 2026.10.1: что proposed design говорит о живой истории сессии

Страница Session transcript working sets задаёт границу: активный SessionManager держит только контекст и навигацию. Что это значит для привычки одной бесконечной сессии.

· 4 мин чтения

Коротко

  • В OpenClaw 2026.10.1 появилась страница Session transcript working sets с пометкой proposed design. Схема, конфиг и поведение менеджера пока не меняются.
  • Активный SessionManager должен держать текущий контекст и ограниченные навигационные факты. Полная история в живой менеджер не ставится.
  • /u/moosepiss держит одну сессию при окне 1M+ и автосжатии. /u/DonShort5 после /new по темам получил заметно меньше токенов.
  • Разносите темы по сессиям через /new или явный выбор sessionKey. Приобретение истории воркером остаётся в проекте.

Сверено с документацией OpenClaw 2026.10.1, 11 октября 2026.

Документация OpenClaw 2026.10.1 добавила страницу Session transcript working sets с пометкой proposed design. Вытеснение при дописывании и перевод потребителей на новые контракты там не реализованы. Страница фиксирует границу, которую работающий SessionManager не должен нарушать: полная история в живой менеджер не ставится, канонический транскрипт остаётся в SQLite под существующими владельцами.

Что предлагает страница Session transcript working sets

Главный тезис страницы — канонический транскрипт живёт в SQLite под существующими владельцами. Активный SessionManager хранит текущий контекст и ограниченные навигационные факты. Запрос старой истории для операции не помещает всю историю в живой менеджер. Документация ссылается на страницу session state on disk и database access in workers.

Сейчас ограниченное открытие уже выбирает сырые записи по бюджету байтов и событий. Массив записей менеджера и индекс по ID делят один граф, а начальная загрузка контекста для модели гидратирует перекрывающиеся сообщения отдельно. Дописывания и полная загрузка истории раздувают резидентное представление сверх стартового бюджета. Файлы-владельцы: session-manager-core.ts, session-manager.ts, session-accessor.sqlite-active-context.ts под src/agents/sessions/ и src/config/sessions/.

Resident snapshot: что остаётся в менеджере

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

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

Отдельный случай описан в session-manager-retained-data.test.ts. Менеджер открыт с бюджетом 4096 байт, потом дописан пользовательский блок данных 5 МиБ. Синхронный removeTrailingEntries обязан снять прерванный ассистент, сохранить пользовательские данные байт-в-байт, починить его родителя и держать getEntry согласованным с хранилищем. Эти проверки устанавливают поведение, которое безусловное вытеснение изменило бы.

Как собрать на OpenClaw

  1. Выберите модель по окну контекста. Документация troubleshooting просит проверять окно провайдера: малые окна вызывают частые срабатывания автосжатия, а у GPT-5.5 и GPT-5.6 активный бюджет по умолчанию ограничен 272000 токенов.
  2. Включите Session pruning и настройте auto compaction. Документация по диагностике отдельно просит убирать раздутые результаты инструментов при частом автосжатии.
  3. Разнесите темы по сессиям через /new или явный выбор sessionKey. Документация по store уточняет: квалифицированный ключ вроде agent:main:global дописывает в уже существующую строку global, а если есть обе записи, запись отклоняется как неоднозначная. Выбирайте однозначный ключ сессии.
  4. Проверьте модель по /status и /usage tokens. Документация token use отмечает: всё, что получает модель, идёт в окно контекста — системный промпт, история, вызовы и результаты инструментов, вложения, сводки compaction и обрезки.
  5. Предлагаемые контракты чтения истории (пока не экспортируются) запрещают держать SQLite-транзакцию через асинхронную работу провайдера, плагина или другого воркера. Освобождайте страницу перед запросом следующей, а не копите весь транскрипт.

Что обсуждают на r-openclaw

/u/moosepiss держит одну сессию на множество тем при окне контекста 1M+ и автосжатии. Его агент говорит, что новая сессия не нужна: автосжатие держит окно, а кэшированные токены у провайдера дешёвые. /u/DonShort5 описал обратное: в Telegram разговор шёл одной лентой, токены уходили быстро, и /new по темам заметно уменьшил расход.

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

Когда это не подойдёт

Страница Session transcript working sets — предложенный проект. Вытеснение при дописывании не реализовано. Схема и конфиг не меняются, постоянные байты и идентичность сессии те же. Полный аудит экспортируемой поверхности чтения и её гарантий полноты впереди. Инкогнито в текущих сборках, пока не включена миграция на канонический воркер, работает на своей базе данных, принадлежащей процессу. Открывать ещё одну :memory: базу для чтения нельзя. По сроку жизни, потере при рестарте и удержанию incognito страница ничего не меняет.

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