Sessions and memory

Керування сеансами

OpenClaw спрямовує кожне вхідне повідомлення до сеансу залежно від джерела: особисті повідомлення, групові чати, завдання Cron тощо. Увесь стан сеансу належить Gateway; клієнти інтерфейсу запитують дані сеансу в Gateway.

Як маршрутизуються повідомлення

Джерело Поведінка
Особисті повідомлення Спільний сеанс за замовчуванням
Групові чати Окремий для кожної групи
Кімнати/канали Окремий для кожної кімнати
Завдання Cron Новий сеанс для кожного запуску
Webhook-и Окремий для кожного обробника

Ізоляція особистих повідомлень

За замовчуванням усі особисті повідомлення використовують один сеанс для безперервності контексту, що підходить для конфігурацій з одним користувачем.

json5
{  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, якщо строк дії цих сеансів має завершуватися за таймером.

Перевизначте типові налаштування для окремого типу чату чи каналу:

json5
{  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; нижче наведено типові значення:

json5
{  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 Вміст системного запиту

Додаткові матеріали

Пов'язані матеріали

Was this useful?
On this page

On this page