> ## Documentation Index > Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt > Use this file to discover all available pages before exploring further. # Управление сеансами OpenClaw организует разговоры в **сеансы**. Каждое сообщение направляется в сеанс в зависимости от того, откуда оно пришло: личные сообщения, групповые чаты, задания Cron и т. д. ## Как маршрутизируются сообщения | Источник | Поведение | | ---------------- | ------------------------------- | | Личные сообщения | Общий сеанс по умолчанию | | Групповые чаты | Изоляция для каждой группы | | Комнаты/каналы | Изоляция для каждой комнаты | | Задания Cron | Новый сеанс для каждого запуска | | Webhook-и | Изоляция для каждого hook | ## Изоляция личных сообщений По умолчанию все личные сообщения используют один сеанс для сохранения непрерывности. Это подходит для установок с одним пользователем. Если несколько человек могут писать вашему агенту, включите изоляцию личных сообщений. Без нее все пользователи используют один и тот же контекст разговора: личные сообщения Алисы будут видны Бобу. **Исправление:** ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { session: { dmScope: "per-channel-peer", // isolate by channel + sender }, } ``` Другие варианты: * `main` (по умолчанию) -- все личные сообщения используют один сеанс. * `per-peer` -- изоляция по отправителю (между каналами). * `per-channel-peer` -- изоляция по каналу + отправителю (рекомендуется). * `per-account-channel-peer` -- изоляция по учетной записи + каналу + отправителю. Если один и тот же человек связывается с вами из нескольких каналов, используйте `session.identityLinks`, чтобы связать его идентификаторы и дать им один общий сеанс. ### Стыковка связанных каналов Команды стыковки позволяют пользователю перенести маршрут ответа текущего сеанса прямого чата в другой связанный канал без запуска нового сеанса. См. [Стыковка каналов](/ru/concepts/channel-docking) с примерами, конфигурацией и устранением неполадок. Проверьте настройку с помощью `openclaw security audit`. ## Жизненный цикл сеанса Сеансы используются повторно, пока не истекут: * **Ежедневный сброс** (по умолчанию) -- новый сеанс в 4:00 утра по местному времени на хосте Gateway. Ежедневная свежесть основана на времени начала текущего `sessionId`, а не на более поздних записях метаданных. * **Сброс по бездействию** (необязательно) -- новый сеанс после периода бездействия. Задайте `session.reset.idleMinutes`. Свежесть по бездействию основана на последнем реальном взаимодействии пользователя/канала, поэтому события Heartbeat, Cron и системные события exec не поддерживают сеанс активным. * **Ручной сброс** -- введите `/new` или `/reset` в чате. `/new ` также переключает модель. Когда настроены и ежедневный сброс, и сброс по бездействию, срабатывает тот, чей срок истекает первым. Heartbeat, Cron, exec и другие ходы системных событий могут записывать метаданные сеанса, но эти записи не продлевают свежесть ежедневного сброса или сброса по бездействию. Когда сброс переводит сеанс, уведомления системных событий в очереди для старого сеанса отбрасываются, чтобы устаревшие фоновые обновления не добавлялись в начало первого промпта в новом сеансе. Сеансы с активным CLI-сеансом, принадлежащим провайдеру, не обрываются неявным ежедневным значением по умолчанию. Используйте `/reset` или явно настройте `session.reset`, когда такие сеансы должны истекать по таймеру. ## Где хранится состояние Все состояние сеансов принадлежит **Gateway**. UI-клиенты запрашивают данные сеансов у Gateway. * **Хранилище:** `~/.openclaw/agents//sessions/sessions.json` * **Транскрипты:** `~/.openclaw/agents//sessions/.jsonl` `sessions.json` хранит отдельные метки времени жизненного цикла: * `sessionStartedAt`: когда начался текущий `sessionId`; ежедневный сброс использует это значение. * `lastInteractionAt`: последнее взаимодействие пользователя/канала, продлевающее срок жизни по бездействию. * `updatedAt`: последняя мутация строки хранилища; полезно для списков и очистки, но не является авторитетным источником свежести для ежедневного сброса/сброса по бездействию. Старые строки без `sessionStartedAt` при наличии берутся из заголовка сеанса JSONL-транскрипта. Если в старой строке также нет `lastInteractionAt`, свежесть по бездействию откатывается к времени начала этого сеанса, а не к более поздним служебным записям. ## Обслуживание сеансов OpenClaw автоматически ограничивает объем хранилища сеансов со временем. По умолчанию он работает в режиме `enforce` и выполняет очистку во время обслуживания. Задайте `session.maintenance.mode` как `"warn"`, чтобы сообщать, что было бы очищено, без изменения хранилища/файлов: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { session: { maintenance: { mode: "enforce", pruneAfter: "30d", maxEntries: 500, }, }, } ``` Для производственных лимитов `maxEntries` записи среды выполнения Gateway используют небольшой буфер верхней отметки и пакетно очищают обратно до настроенного предела. Чтения хранилища сеансов не сокращают и не ограничивают записи во время запуска Gateway. Это позволяет избежать полной очистки хранилища при каждом запуске или изолированном сеансе Cron. `openclaw sessions cleanup --enforce` применяет предел немедленно. Пробные сеансы запуска моделей Gateway по умолчанию недолговечны. Совпадающие строки со строгими явными ключами, такими как `agent:*:explicit:model-run-`, используют фиксированное хранение `24h`, но очистка ограничена давлением: она удаляет устаревшие пробные строки только тогда, когда достигнуто давление обслуживания/лимита записей сеансов. Когда выполняется очистка model-run, она запускается до более широкого отсечения устаревших записей по возрасту и до лимита записей. Обычные прямые, групповые, потоковые, Cron, hook, Heartbeat, ACP и сеансы субагентов не наследуют это 24-часовое хранение. Обслуживание сохраняет долговечные внешние указатели разговоров, включая групповые сеансы и чат-сеансы в рамках потоков, при этом позволяя синтетическим записям Cron, hook, Heartbeat, ACP и субагентов устаревать и удаляться. Если вы ранее использовали изоляцию личных сообщений, а затем вернули `session.dmScope` к `main`, предварительно просмотрите устаревшие строки личных сообщений с ключами peer с помощью `openclaw sessions cleanup --dry-run --fix-dm-scope`. Применение того же флага выводит из обращения эти старые строки прямых личных сообщений и сохраняет их транскрипты как удаленные архивы. Предварительный просмотр: `openclaw sessions cleanup --dry-run`. ## Проверка сеансов * `openclaw status` -- путь к хранилищу сеансов и недавняя активность. * `openclaw sessions --json` -- все сеансы (фильтр через `--active `). * `/status` в чате -- использование контекста, модель и переключатели. * `/context list` -- что находится в системном промпте. ## Дополнительное чтение * [Обрезка сеансов](/ru/concepts/session-pruning) -- сокращение результатов инструментов * [Compaction](/ru/concepts/compaction) -- суммаризация длинных разговоров * [Инструменты сеанса](/ru/concepts/session-tool) -- инструменты агента для работы между сеансами * [Подробный обзор управления сеансами](/ru/reference/session-management-compaction) -- схема хранилища, транскрипты, политика отправки, метаданные происхождения и расширенная конфигурация * [Мультиагентность](/ru/concepts/multi-agent) — маршрутизация и изоляция сеансов между агентами * [Фоновые задачи](/ru/automation/tasks) — как отсоединенная работа создает записи задач со ссылками на сеансы * [Маршрутизация каналов](/ru/channels/channel-routing) — как входящие сообщения маршрутизируются в сеансы ## Связанные материалы * [Обрезка сеансов](/ru/concepts/session-pruning) * [Инструменты сеанса](/ru/concepts/session-tool) * [Очередь команд](/ru/concepts/queue)