English简体中文繁體中文日本語EspañolPortuguês (BR)한국어DeutschFrançaisالعربيةItalianoTiếng ViệtNederlandsTürkçeУкраїнськаBahasa IndonesiaPolskiفارسیไทย

Sessions and memory

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

OpenClaw організовує розмови в сеанси. Кожне повідомлення маршрутизується до сеансу залежно від того, звідки воно надійшло -- приватні повідомлення, групові чати, завдання Cron тощо.

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

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

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

За замовчуванням усі приватні повідомлення використовують один сеанс для безперервності. Це підходить для налаштувань з одним користувачем.

Виправлення:

{
  session: {
    dmScope: "per-channel-peer", // isolate by channel + sender
  },
}

Інші варіанти:

  • main (за замовчуванням) -- усі приватні повідомлення використовують один сеанс.
  • per-peer -- ізолювати за відправником (між каналами).
  • per-channel-peer -- ізолювати за каналом + відправником (рекомендовано).
  • per-account-channel-peer -- ізолювати за обліковим записом + каналом + відправником.

Пристикування пов'язаних каналів

Команди пристикування дають користувачу змогу перенести маршрут відповіді поточного сеансу прямого чату до іншого пов'язаного каналу без запуску нового сеансу. Див. Пристикування каналів для прикладів, конфігурації та усунення несправностей.

Перевірте своє налаштування за допомогою openclaw security audit.

Життєвий цикл сеансу

Сеанси використовуються повторно, доки не спливе їхній строк дії:

  • Щоденне скидання (за замовчуванням) -- новий сеанс о 4:00 ранку за місцевим часом на хості Gateway. Щоденна актуальність базується на часі запуску поточного sessionId, а не на пізніших записах метаданих.
  • Скидання після простою (необов'язково) -- новий сеанс після періоду неактивності. Задайте session.reset.idleMinutes. Актуальність простою базується на останній реальній взаємодії користувача/каналу, тому Heartbeat, Cron і системні події exec не підтримують сеанс активним.
  • Ручне скидання -- введіть /new або /reset у чаті. /new <model> також перемикає модель.

Коли налаштовано і щоденне скидання, і скидання після простою, спрацьовує те, строк дії якого спливає першим. Heartbeat, Cron, exec та інші ходи системних подій можуть записувати метадані сеансу, але ці записи не подовжують актуальність щоденного скидання або скидання після простою. Коли скидання перемикає сеанс, поставлені в чергу сповіщення системних подій для старого сеансу відкидаються, щоб застарілі фонові оновлення не додавалися перед першим prompt у новому сеансі.

Сеанси з активним CLI-сеансом, яким володіє провайдер, не обрізаються неявним щоденним значенням за замовчуванням. Використовуйте /reset або явно налаштуйте session.reset, коли такі сеанси мають спливати за таймером.

Де зберігається стан

Усім станом сеансів володіє Gateway. UI-клієнти запитують дані сеансів у Gateway.

  • Сховище: ~/.openclaw/agents/<agentId>/sessions/sessions.json
  • Транскрипти: ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl

sessions.json зберігає окремі часові мітки життєвого циклу:

  • sessionStartedAt: коли почався поточний sessionId; щоденне скидання використовує це значення.
  • lastInteractionAt: остання взаємодія користувача/каналу, що подовжує час життя до скидання після простою.
  • updatedAt: остання зміна рядка сховища; корисно для списків і очищення, але не є авторитетним джерелом для актуальності щоденного скидання або скидання після простою.

Старіші рядки без sessionStartedAt за можливості визначаються з заголовка сеансу JSONL-транскрипту. Якщо старішому рядку також бракує lastInteractionAt, актуальність простою відраховується від часу початку цього сеансу, а не від пізніших службових записів.

Обслуговування сеансів

OpenClaw автоматично обмежує сховище сеансів із часом. За замовчуванням він працює в режимі warn (повідомляє, що було б очищено). Задайте session.maintenance.mode значення "enforce" для автоматичного очищення:

{
  session: {
    maintenance: {
      mode: "enforce",
      pruneAfter: "30d",
      maxEntries: 500,
    },
  },
}

Для виробничих обмежень maxEntries записи runtime Gateway використовують невеликий буфер верхньої межі й пакетами очищають сховище назад до налаштованого ліміту. Читання сховища сеансів не обрізають і не обмежують записи під час запуску Gateway. Це дозволяє уникнути повного очищення сховища під час кожного запуску або ізольованого сеансу Cron. openclaw sessions cleanup --enforce застосовує ліміт негайно.

Обслуговування зберігає довговічні зовнішні вказівники розмов, зокрема групові сеанси та чат-сеанси в межах thread, і водночас дає змогу синтетичним записам Cron, hook, Heartbeat, ACP і під-агентів застарівати.

Якщо раніше ви використовували ізоляцію прямих повідомлень, а потім повернули session.dmScope до main, перегляньте застарілі peer-keyed рядки приватних повідомлень за допомогою openclaw sessions cleanup --dry-run --fix-dm-scope. Застосування того самого прапорця виводить ці старі рядки direct-DM з ужитку й зберігає їхні транскрипти як видалені архіви.

Попередній перегляд: openclaw sessions cleanup --dry-run.

Перегляд сеансів

  • openclaw status -- шлях до сховища сеансів і нещодавня активність.
  • openclaw sessions --json -- усі сеанси (фільтруйте за допомогою --active <minutes>).
  • /status у чаті -- використання контексту, модель і перемикачі.
  • /context list -- що міститься в системному prompt.

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

Пов'язане