Sessions and memory
Керування сеансами
OpenClaw спрямовує кожне вхідне повідомлення до сеансу залежно від джерела: особисті повідомлення, групові чати, завдання Cron тощо. Увесь стан сеансу належить Gateway; клієнти інтерфейсу запитують дані сеансу в Gateway.
Як маршрутизуються повідомлення
| Джерело | Поведінка |
|---|---|
| Особисті повідомлення | Спільний сеанс за замовчуванням |
| Групові чати | Окремий для кожної групи |
| Кімнати/канали | Окремий для кожної кімнати |
| Завдання Cron | Новий сеанс для кожного запуску |
| Webhook-и | Окремий для кожного обробника |
Ізоляція особистих повідомлень
За замовчуванням усі особисті повідомлення використовують один сеанс для безперервності контексту, що підходить для конфігурацій з одним користувачем.
{ session: { dmScope: "per-channel-peer", // ізолювати за каналом і відправником },}Параметри session.dmScope:
| Значення | Поведінка |
|---|---|
main (за замовчуванням) |
Усі особисті повідомлення мають спільний сеанс |
per-peer |
Ізолювати за відправником у всіх каналах |
per-channel-peer |
Ізолювати за каналом і відправником (рекомендовано) |
per-account-channel-peer |
Ізолювати за обліковим записом, каналом і відправником |
Закріплення пов'язаних каналів
Команди закріплення переносять маршрут відповіді поточного сеансу особистого чату до іншого пов'язаного каналу без запуску нового сеансу. Приклади, конфігурацію та усунення несправностей див. у розділі Закріплення каналів.
Перевірте конфігурацію за допомогою openclaw security audit.
Життєвий цикл сеансу
Сеанси використовуються повторно, доки не завершиться їхній строк дії згідно з session.reset:
- Щоденне скидання (за замовчуванням
mode: "daily") — новий сеанс у налаштовану годину за місцевим часом (session.reset.atHour, за замовчуванням4, 0-23) на хості Gateway. Актуальність для щоденного скидання визначається часом початку поточногоsessionId, а не пізнішими записами метаданих. - Скидання через бездіяльність (
mode: "idle") — новий сеанс післяsession.reset.idleMinutesбездіяльності. Актуальність за бездіяльністю визначається останньою реальною взаємодією користувача або каналу, тому системні події Heartbeat, Cron та виконання команд не підтримують активність сеансу. - Ручне скидання — введіть
/newабо/resetу чаті./new <model>також перемикає модель.
Якщо налаштовано і щоденне скидання, і скидання через бездіяльність, застосовується те, строк якого завершиться першим. Ходи Heartbeat, Cron, виконання команд та інших системних подій можуть записувати метадані сеансу, але ці записи не подовжують строк актуальності щоденного скидання чи скидання через бездіяльність. Коли скидання змінює сеанс, сповіщення системних подій у черзі для старого сеансу відкидаються, щоб застарілі фонові оновлення не додавалися на початок першого запиту в новому сеансі.
Сеанси з активним CLI-сеансом, яким керує постачальник, не перериваються неявним
щоденним скиданням за замовчуванням. Використовуйте /reset або явно налаштуйте session.reset, якщо строк
дії цих сеансів має завершуватися за таймером.
Перевизначте типові налаштування для окремого типу чату чи каналу:
{ session: { reset: { mode: "daily", atHour: 4 }, resetByType: { group: { mode: "idle", idleMinutes: 120 }, thread: { mode: "daily", atHour: 6 }, }, resetByChannel: { discord: { mode: "idle", idleMinutes: 10080 }, }, },}resetByType підтримує direct (застарілий псевдонім dm), group і thread.
Застарілий параметр верхнього рівня session.idleMinutes досі працює як псевдонім
сумісності для типового режиму бездіяльності, якщо блок session.reset/resetByType не задано.
Де зберігається стан
- Рядки сеансів середовища виконання:
~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite - Архівні файли розшифрувань:
~/.openclaw/agents/<agentId>/sessions/ - Джерело міграції застарілих рядків:
~/.openclaw/agents/<agentId>/sessions/sessions.json
Рядки сеансів у базі даних SQLite кожного агента містять окремі часові позначки життєвого циклу:
sessionStartedAt: час початку поточногоsessionId; використовується для щоденного скидання.lastInteractionAt: остання взаємодія користувача або каналу, що подовжує строк активності.updatedAt: остання зміна рядка сховища; корисна для виведення списків і очищення, але не є визначальною для актуальності щоденного скидання чи скидання через бездіяльність.
Під час міграції зі старіших інсталяцій запуск Gateway і openclaw doctor --fix автоматично імпортують застарілі рядки sessions.json та активну історію розшифрувань JSONL
до SQLite. Для рядків без sessionStartedAt значення визначається із заголовка
сеансу в застарілому файлі розшифрування JSONL, якщо він доступний. Якщо старіший
рядок також не містить lastInteractionAt, актуальність за бездіяльністю визначається
за часом початку цього сеансу, а не за пізнішими службовими записами. Використовуйте
openclaw doctor --session-sqlite inspect --session-sqlite-all-agents та послідовність міграції Doctor,
якщо потрібні явна перевірка або докази валідації.
Обслуговування сеансів
OpenClaw з часом обмежує обсяг сховища сеансів за допомогою session.maintenance;
нижче наведено типові значення:
{ session: { maintenance: { mode: "enforce", // "enforce" виконує очищення; "warn" лише повідомляє pruneAfter: "30d", maxEntries: 500, }, },}Для виробничих обмежень maxEntries середовище виконання Gateway під час запису використовує невеликий
буфер верхнього порога й пакетно очищає сховище до налаштованого обмеження.
Читання сховища сеансів під час запуску Gateway не видаляє та не обмежує записи,
тому запуск і ізольовані сеанси Cron не спричиняють повного очищення сховища.
openclaw sessions cleanup --enforce застосовує обмеження негайно.
Сеанси перевірки запуску моделі Gateway за замовчуванням короткочасні. Рядки, що
відповідають agent:*:explicit:model-run-<uuid>, мають фіксований строк зберігання 24h,
але очищення залежить від навантаження: застарілі рядки перевірок видаляються лише
за наявності навантаження на обслуговування або обмеження кількості записів сеансів,
причому це відбувається до застосування загального граничного віку застарілих записів
і обмеження їхньої кількості. Звичайні особисті, групові, гілкові сеанси, а також
сеанси Cron, обробників, Heartbeat, ACP і підагентів не успадковують цей строк
зберігання 24h.
Обслуговування зберігає постійні зовнішні вказівники розмов, зокрема групові сеанси та сеанси чатів у межах гілок, водночас дозволяючи синтетичним записам Cron, обробників, Heartbeat, ACP і підагентів поступово видалятися за давністю.
Якщо раніше використовувалася ізоляція особистих повідомлень, а потім
session.dmScope було повернуто до main, попередньо перегляньте
застарілі рядки особистих повідомлень із ключами співрозмовників за допомогою
openclaw sessions cleanup --dry-run --fix-dm-scope. Застосування того самого прапорця
виводить ці старі рядки особистих повідомлень з експлуатації та зберігає їхні
розшифрування як видалені архіви.
Попередньо перегляньте будь-який запуск обслуговування за допомогою openclaw sessions cleanup --dry-run.
Перевірка сеансів
| Команда | Що показує |
|---|---|
openclaw status |
Шлях до сховища сеансів і нещодавню активність |
openclaw sessions --json |
Усі сеанси (фільтруйте за допомогою --active <minutes>) |
/status у чаті |
Використання контексту, модель і перемикачі |
/context list |
Вміст системного запиту |
Додаткові матеріали
- Пошук сеансів — повнотекстовий пошук у попередніх розшифруваннях
- Очищення сеансів — скорочення результатів інструментів
- Compaction — узагальнення довгих розмов
- Інструменти сеансів — інструменти агента для роботи між сеансами
- Поглиблений огляд керування сеансами — схема сховища, розшифрування, політика надсилання, метадані походження та розширена конфігурація
- Мультиагентність — маршрутизація та ізоляція сеансів між агентами
- Фонові завдання — як відокремлена робота створює записи завдань із посиланнями на сеанси
- Маршрутизація каналів — як вхідні повідомлення спрямовуються до сеансів