--- read_when: - Ви хочете зрозуміти маршрутизацію та ізоляцію сеансів - Ви хочете налаштувати область DM для багатокористувацьких конфігурацій - Ви налагоджуєте щоденні або неактивні скидання сеансів summary: Як OpenClaw керує сеансами розмови title: Керування сеансами x-i18n: generated_at: "2026-06-27T17:28:46Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: f65249b17c8b45f569531134471683e9f458015b02af29ddf4aa6e1e5c2eac05 source_path: concepts/session.md workflow: 16 --- OpenClaw упорядковує розмови в **сеанси**. Кожне повідомлення спрямовується до сеансу залежно від того, звідки воно надійшло -- прямі повідомлення, групові чати, завдання Cron тощо. ## Як маршрутизуються повідомлення | Джерело | Поведінка | | --------------- | ------------------------- | | Прямі повідомлення | Типово спільний сеанс | | Групові чати | Ізольовано для кожної групи | | Кімнати/канали | Ізольовано для кожної кімнати | | Завдання Cron | Новий сеанс для кожного запуску | | Webhook | Ізольовано для кожного hook | ## Ізоляція DM Типово всі прямі повідомлення мають один спільний сеанс для безперервності. Це нормально для налаштувань з одним користувачем. Якщо кілька людей можуть надсилати повідомлення вашому агенту, увімкніть ізоляцію DM. Без неї всі користувачі спільно використовуватимуть той самий контекст розмови -- приватні повідомлення Alice будуть видимі Bob. **Виправлення:** ```json5 { session: { dmScope: "per-channel-peer", // isolate by channel + sender }, } ``` Інші варіанти: - `main` (типово) -- усі прямі повідомлення мають один спільний сеанс. - `per-peer` -- ізолювати за відправником (між каналами). - `per-channel-peer` -- ізолювати за каналом + відправником (рекомендовано). - `per-account-channel-peer` -- ізолювати за обліковим записом + каналом + відправником. Якщо та сама людина зв'язується з вами з кількох каналів, використовуйте `session.identityLinks`, щоб зв'язати її ідентичності, аби вони мали один спільний сеанс. ### Пристикування пов'язаних каналів Команди пристикування дають користувачу змогу перемістити маршрут відповіді поточного сеансу прямого чату до іншого пов'язаного каналу без запуску нового сеансу. Дивіться [пристикування каналів](/uk/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 { session: { maintenance: { mode: "enforce", pruneAfter: "30d", maxEntries: 500, }, }, } ``` Для production-розмірів лімітів `maxEntries` записи під час виконання Gateway використовують невеликий буфер верхньої межі та очищаються пакетами назад до налаштованої межі. Читання сховища сеансів не обрізають і не обмежують записи під час запуску Gateway. Це уникає повного очищення сховища під час кожного запуску або ізольованого сеансу Cron. `openclaw sessions cleanup --enforce` застосовує обмеження негайно. Пробні сеанси запуску моделей Gateway типово короткочасні. Відповідні рядки зі строгими явними ключами на кшталт `agent:*:explicit:model-run-` використовують фіксоване зберігання `24h`, але очищення прив'язане до тиску: воно видаляє застарілі пробні рядки лише тоді, коли досягнуто тиску обслуговування/ліміту записів сеансів. Коли виконується очищення запусків моделей, воно виконується перед ширшим віковим порогом застарілих записів і лімітом записів. Звичайні прямі, групові, потокові, Cron, hook, Heartbeat, ACP і субагентські сеанси не успадковують це 24-годинне зберігання. Обслуговування зберігає довговічні зовнішні вказівники розмов, зокрема групові сеанси та чат-сеанси, обмежені потоком, водночас дозволяючи синтетичним записам Cron, hook, Heartbeat, ACP і субагентів старіти й видалятися. Якщо ви раніше використовували ізоляцію прямих повідомлень, а потім повернули `session.dmScope` до `main`, перегляньте застарілі рядки DM з ключами peer за допомогою `openclaw sessions cleanup --dry-run --fix-dm-scope`. Застосування того самого прапорця виводить ці старі рядки прямих DM з обігу та зберігає їхні транскрипти як видалені архіви. Попередній перегляд: `openclaw sessions cleanup --dry-run`. ## Перегляд сеансів - `openclaw status` -- шлях до сховища сеансів і остання активність. - `openclaw sessions --json` -- усі сеанси (фільтруйте за допомогою `--active `). - `/status` у чаті -- використання контексту, модель і перемикачі. - `/context list` -- що є в системному запиті. ## Додаткове читання - [Обрізання сеансів](/uk/concepts/session-pruning) -- скорочення результатів інструментів - [Compaction](/uk/concepts/compaction) -- підсумовування довгих розмов - [Інструменти сеансів](/uk/concepts/session-tool) -- інструменти агента для роботи між сеансами - [Поглиблений огляд керування сеансами](/uk/reference/session-management-compaction) -- схема сховища, транскрипти, політика надсилання, метадані походження та розширена конфігурація - [Мультиагентність](/uk/concepts/multi-agent) — маршрутизація та ізоляція сеансів між агентами - [Фонові завдання](/uk/automation/tasks) — як від'єднана робота створює записи завдань із посиланнями на сеанси - [Маршрутизація каналів](/uk/channels/channel-routing) — як вхідні повідомлення маршрутизуються до сеансів ## Пов'язане - [Обрізання сеансів](/uk/concepts/session-pruning) - [Інструменти сеансів](/uk/concepts/session-tool) - [Черга команд](/uk/concepts/queue)