Глибокий огляд керування сеансами

OpenClaw керує сеансами наскрізно в таких сферах:

• Маршрутизація сеансів (як вхідні повідомлення зіставляються з sessionKey)
• Сховище сеансів (sessions.json) і що воно відстежує
• Збереження транскриптів (*.jsonl) і їхня структура
• Гігієна транскриптів (провайдер-специфічні виправлення перед запусками)
• Обмеження контексту (контекстне вікно проти відстежуваних токенів)
• Compaction (ручна й автоматична Compaction) і де під’єднувати роботу перед Compaction
• Тихе обслуговування (записи пам’яті, які не мають створювати видимого для користувача виводу)

Якщо спершу потрібен огляд вищого рівня, почніть із:

• Керування сеансами
• Compaction
• Огляд пам’яті
• Пошук у пам’яті
• Обрізання сеансів
• Гігієна транскриптів

Джерело істини: Gateway

OpenClaw спроєктовано навколо єдиного процесу Gateway, який володіє станом сеансів.

• Інтерфейси (застосунок macOS, веб Control UI, TUI) мають запитувати в Gateway списки сеансів і підрахунки токенів.
• У віддаленому режимі файли сеансів розміщені на віддаленому хості; «перевірка локальних файлів Mac» не відображатиме те, що використовує Gateway.

Два шари збереження

OpenClaw зберігає сеанси у двох шарах:

1. Сховище сеансів (sessions.json)

   • Карта ключ/значення: sessionKey -> SessionEntry
   • Невелике, змінюване, безпечне для редагування (або видалення записів)
   • Відстежує метадані сеансу (поточний ідентифікатор сеансу, останню активність, перемикачі, лічильники токенів тощо)

2. Транскрипт (<sessionId>.jsonl)

   • Транскрипт лише для дописування з деревоподібною структурою (записи мають id + parentId)
   • Зберігає фактичну розмову + виклики інструментів + підсумки Compaction
   • Використовується для повторної побудови контексту моделі для майбутніх ходів
   • Контрольні точки Compaction є метаданими над ущільненим наступним транскриптом. Нові Compaction не записують другу копію .checkpoint.*.jsonl.

Зчитувачам історії Gateway слід уникати матеріалізації всього транскрипту, якщо поверхні явно не потрібен довільний історичний доступ. Історія першої сторінки, вбудована історія чату, відновлення після перезапуску та перевірки токенів/використання застосовують обмежені читання хвоста. Повні сканування транскриптів проходять через асинхронний індекс транскриптів, який кешується за шляхом файлу разом із mtimeMs/size і спільно використовується конкурентними зчитувачами.

Розташування на диску

Для кожного агента, на хості Gateway:

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

OpenClaw визначає ці шляхи через src/config/sessions.ts.

Обслуговування сховища та керування диском

Збереження сеансів має автоматичні засоби обслуговування (session.maintenance) для sessions.json, артефактів транскриптів і допоміжних файлів траєкторій:

• mode: enforce (типово) або warn
• pruneAfter: граничний вік застарілих записів (типово 30d)
• maxEntries: обмеження кількості записів у sessions.json (типово 500)
• Утримання короткоживучих проб запуску моделі Gateway фіксоване на 24h, але воно спрацьовує лише під тиском: воно видаляє застарілі рядки строгих проб лише тоді, коли досягнуто тиску обслуговування/ліміту записів сеансів. Це стосується лише строгих явних ключів проб, що відповідають agent:*:explicit:model-run-<uuid>, і виконується перед глобальним очищенням/обмеженням застарілих записів, коли воно запускається.
• resetArchiveRetention: утримання архівів транскриптів *.reset.<timestamp> (типово: те саме, що pruneAfter; false вимикає очищення)
• maxDiskBytes: необов’язковий бюджет каталогу сеансів
• highWaterBytes: необов’язкова ціль після очищення (типово 80% від maxDiskBytes)

Звичайні записи Gateway проходять через окремий для сховища записувач сеансів, який серіалізує внутрішньопроцесні мутації без взяття файлового блокування під час виконання. Допоміжні функції виправлень на гарячому шляху позичають перевірений змінюваний кеш, доки утримують цей слот записувача, тож великі файли sessions.json не клонуються й не перечитуються для кожного оновлення метаданих. Код виконання має надавати перевагу updateSessionStore(...) або updateSessionStoreEntry(...); прямі збереження всього сховища є інструментами сумісності та офлайн-обслуговування. Коли Gateway доступний, недемонстраційні openclaw sessions cleanup і openclaw agents delete делегують мутації сховища Gateway, щоб очищення долучалося до тієї самої черги записувача; --store <path> є явним офлайн-шляхом відновлення для прямого обслуговування файлів. Очищення maxEntries усе ще пакетне для лімітів виробничого розміру, тому сховище може ненадовго перевищувати налаштований ліміт, перш ніж наступне очищення верхньої межі знову зменшить його. Читання сховища сеансів не обрізають і не обмежують записи під час запуску Gateway; для очищення використовуйте записи або openclaw sessions cleanup --enforce. openclaw sessions cleanup --enforce усе ще негайно застосовує налаштований ліміт і обрізає старі непосилані артефакти транскриптів, контрольних точок і траєкторій, навіть коли дисковий бюджет не налаштовано.

Обслуговування зберігає довговічні зовнішні вказівники розмов, як-от групові сеанси та сеанси чатів у межах гілок, але синтетичні записи виконання для cron, хуків, heartbeat, ACP і субагентів усе одно можуть бути вилучені, коли вони перевищують налаштований вік, кількість або дисковий бюджет. Сеанси проб запуску моделі Gateway використовують окреме утримання запуску моделі 24h лише тоді, коли їхній ключ точно відповідає agent:*:explicit:model-run-<uuid>; інші явні сеанси не належать до цього утримання. Очищення запусків моделі застосовується лише під тиском ліміту записів сеансів. Ізольовані запуски cron зберігають власний контроль cron.sessionRetention, незалежний від утримання проб запуску моделі.

OpenClaw більше не створює автоматичні ротаційні резервні копії sessions.json.bak.* під час записів Gateway. Застарілий ключ session.maintenance.rotateBytes ігнорується, а openclaw doctor --fix видаляє його зі старіших конфігурацій.

Мутації транскриптів використовують блокування запису сеансу на файлі транскрипту. Отримання блокування очікує до session.writeLock.acquireTimeoutMs, перш ніж показати помилку зайнятого сеансу; типове значення — 60000 мс. Підвищуйте це лише тоді, коли легітимна підготовка, очищення, Compaction або дзеркалювання транскрипту довше конкурують на повільних машинах. session.writeLock.staleMs керує тим, коли наявне блокування можна повернути як застаріле; типове значення — 1800000 мс. session.writeLock.maxHoldMs керує порогом внутрішньопроцесного сторожового звільнення; типове значення — 300000 мс. Аварійні перевизначення середовища: OPENCLAW_SESSION_WRITE_LOCK_ACQUIRE_TIMEOUT_MS, OPENCLAW_SESSION_WRITE_LOCK_STALE_MS і OPENCLAW_SESSION_WRITE_LOCK_MAX_HOLD_MS.

Порядок застосування очищення дискового бюджету (mode: "enforce"):

1. Спочатку видалити найстаріші архівовані, осиротілі артефакти транскриптів або осиротілі артефакти траєкторій.
2. Якщо все ще вище цілі, витіснити найстаріші записи сеансів і їхні файли транскриптів/траєкторій.
3. Продовжувати, доки використання не буде на рівні або нижче highWaterBytes.

У mode: "warn" OpenClaw повідомляє про потенційні витіснення, але не змінює сховище/файли.

Запустіть обслуговування на вимогу:

openclaw sessions cleanup --dry-runopenclaw sessions cleanup --enforce

Сеанси cron і журнали запусків

Ізольовані запуски cron також створюють записи сеансів/транскрипти та мають спеціальні засоби керування утриманням:

• cron.sessionRetention (типово 24h) обрізає старі сеанси ізольованих запусків cron зі сховища сеансів (false вимикає).
• cron.runLog.keepLines обрізає збережені рядки історії запусків SQLite для кожного завдання cron (типово: 2000). cron.runLog.maxBytes лишається прийнятним для старіших файлових журналів запусків.

Коли cron примусово створює новий ізольований сеанс запуску, він санітизує попередній запис сеансу cron:<jobId> перед записом нового рядка. Він переносить безпечні параметри, як-от налаштування thinking/fast/verbose, мітки та явні вибрані користувачем перевизначення моделі/автентифікації. Він відкидає навколишній контекст розмови, як-от маршрутизацію каналу/групи, політику надсилання або черги, підвищення прав, походження та прив’язку виконання ACP, щоб свіжий ізольований запуск не міг успадкувати застарілу доставку або повноваження виконання від старішого запуску.

Ключі сеансів (sessionKey)

sessionKey визначає, у якому контейнері розмови ви перебуваєте (маршрутизація + ізоляція).

Поширені шаблони:

• Основний/прямий чат (для агента): agent:<agentId>:<mainKey> (типово main)
• Група: agent:<agentId>:<channel>:group:<id>
• Кімната/канал (Discord/Slack): agent:<agentId>:<channel>:channel:<id> або ...:room:<id>
• Cron: cron:<job.id>
• Webhook: hook:<uuid> (якщо не перевизначено)

Канонічні правила задокументовано на /concepts/session.

Ідентифікатори сеансів (sessionId)

Кожен sessionKey вказує на поточний sessionId (файл транскрипту, який продовжує розмову).

Практичні правила:

• Скидання (/new, /reset) створює новий sessionId для цього sessionKey.
• Щоденне скидання (типово о 4:00 AM за місцевим часом на хості gateway) створює новий sessionId у наступному повідомленні після межі скидання.
• Завершення через неактивність (session.reset.idleMinutes або застарілий session.idleMinutes) створює новий sessionId, коли повідомлення надходить після вікна неактивності. Коли налаштовано і щоденне, і за неактивністю, перемагає те, що спливає першим.
• Відновлення після повторного підключення Control UI може зберегти поточний видимий сеанс для одного надсилання після повторного підключення, коли Gateway отримує відповідний sessionId від клієнта операторського інтерфейсу. Звичайні застарілі надсилання все одно створюють новий sessionId.
• Системні події (heartbeat, пробудження cron, сповіщення exec, облік gateway) можуть змінювати рядок сеансу, але не подовжують свіжість щоденного/неактивного скидання. Перехід скидання відкидає поставлені в чергу повідомлення системних подій для попереднього сеансу до побудови свіжого запиту.
• Політика форку батьківського елемента використовує активну гілку OpenClaw під час створення гілки або форку субагента. Якщо ця гілка завелика, OpenClaw запускає дочірній елемент з ізольованим контекстом замість збою або успадкування непридатної історії. Політика визначення розміру автоматична; застарілу конфігурацію session.parentForkMaxTokens видаляє openclaw doctor --fix.

Деталь реалізації: рішення ухвалюється в initSessionState() у src/auto-reply/reply/session.ts.

Схема сховища сеансів (sessions.json)

Тип значення сховища — SessionEntry у src/config/sessions.ts.

Ключові поля (не вичерпно):

• sessionId: поточний ідентифікатор транскрипту (ім’я файлу виводиться з нього, якщо не задано sessionFile)
• sessionStartedAt: часова мітка початку для поточного sessionId; щоденне скидання актуальності використовує її. Застарілі рядки можуть виводити її з заголовка сеансу JSONL.
• lastInteractionAt: часова мітка останньої реальної взаємодії користувача/каналу; скидання актуальності під час простою використовує її, щоб події heartbeat, cron і exec не підтримували сеанси активними. Застарілі рядки без цього поля повертаються до відновленого часу початку сеансу для актуальності простою.
• updatedAt: часова мітка останньої зміни рядка сховища, використовується для списків, очищення та обліку. Вона не є джерелом істини для актуальності щоденного/простою скидання.
• archivedAt: необов’язкова часова мітка архівування. Архівовані сеанси залишаються в сховищі з незмінним транскриптом і виключаються зі звичайних списків активних сеансів.
• pinnedAt: необов’язкова часова мітка закріплення. Активні закріплені сеанси сортуються перед незакріпленими; архівування сеансу очищає його закріплення.
• Взаємодія з потоками Codex: обидва поля відповідають формі керування потоками Codex — булеві значення archived/pinned у передаванні завжди виводяться з часової мітки та проставляються на серверному боці, відповідно до семантики Codex threads.archived_at і серіалізації camelCase. Часові мітки OpenClaw — це мілісекунди епохи, тоді як Codex використовує секунди епохи, тому мости конвертують їх на межі plugin codex. Codex ще не має API закріплення (лише thread/archive/thread/unarchive); стан закріплення залишається на боці OpenClaw, доки такий API не з’явиться; тоді відповідна форма дасть змогу прив’язаним сеансам механічно виконувати round-trip стану закріплення.
• sessionFile: необов’язкове явне перевизначення шляху транскрипту
• chatType: direct | group | room (допомагає інтерфейсам і політиці надсилання)
• provider, subject, room, space, displayName: метадані для позначення груп/каналів
• Перемикачі:
  • thinkingLevel, verboseLevel, reasoningLevel, elevatedLevel
  • sendPolicy (перевизначення для окремого сеансу)
• Вибір моделі:
  • providerOverride, modelOverride, authProfileOverride
• Лічильники токенів (best-effort / залежні від провайдера):
  • inputTokens, outputTokens, totalTokens, contextTokens
• compactionCount: як часто автоматична Compaction завершувалася для цього ключа сеансу
• memoryFlushAt: часова мітка останнього скидання пам’яті перед Compaction
• memoryFlushCompactionCount: кількість Compaction, коли виконувалося останнє скидання

Сховище безпечно редагувати, але Gateway є джерелом істини: він може перезаписувати або відновлювати записи під час виконання сеансів.

Структура транскрипту (*.jsonl)

Транскриптами керує SessionManager з openclaw/plugin-sdk/agent-sessions.

Файл має формат JSONL:

• Перший рядок: заголовок сеансу (type: "session", містить id, cwd, timestamp, необов’язковий parentSession)
• Далі: записи сеансу з id + parentId (дерево)

Важливі типи записів:

• message: повідомлення користувача/асистента/toolResult
• custom_message: повідомлення, інжектовані розширенням, які входять у контекст моделі (можуть бути приховані від інтерфейсу)
• custom: стан розширення, який не входить у контекст моделі
• compaction: збережений підсумок Compaction з firstKeptEntryId і tokensBefore
• branch_summary: збережений підсумок під час навігації гілкою дерева

OpenClaw навмисно не «виправляє» транскрипти; Gateway використовує SessionManager для їх читання/запису.

Контекстні вікна проти відстежуваних токенів

Мають значення два різні поняття:

1. Контекстне вікно моделі: жорстке обмеження для кожної моделі (токени, видимі моделі)
2. Лічильники сховища сеансів: ковзні статистики, записані в sessions.json (використовуються для /status і панелей)

Якщо ви налаштовуєте ліміти:

• Контекстне вікно береться з каталогу моделей (і може бути перевизначене через конфігурацію).
• contextTokens у сховищі — це оцінка/звітне значення під час виконання; не сприймайте його як сувору гарантію.

Докладніше див. /token-use.

Compaction: що це

Compaction підсумовує старішу розмову в збережений запис compaction у транскрипті та залишає останні повідомлення без змін.

Після Compaction майбутні ходи бачать:

• Підсумок Compaction
• Повідомлення після firstKeptEntryId

Повторне інжектування розділів AGENTS.md після Compaction вмикається явно через agents.defaults.compaction.postCompactionSections; коли не задано або [], OpenClaw не додає фрагменти AGENTS.md поверх підсумку Compaction.

Compaction є постійною (на відміну від очищення сеансів). Див. /concepts/session-pruning.

Межі фрагментів Compaction і парування інструментів

Коли OpenClaw розбиває довгий транскрипт на фрагменти Compaction, він зберігає виклики інструментів асистента в парі з відповідними записами toolResult.

• Якщо поділ за часткою токенів потрапляє між викликом інструмента та його результатом, OpenClaw зсуває межу до повідомлення асистента з викликом інструмента, а не розділяє пару.
• Якщо кінцевий блок результатів інструментів інакше перевищив би цільовий розмір фрагмента, OpenClaw зберігає цей очікуваний блок інструмента та залишає непідсумований хвіст без змін.
• Перервані/помилкові блоки викликів інструментів не утримують очікуваний поділ відкритим.

Коли відбувається автоматична Compaction (середовище виконання OpenClaw)

У вбудованому агенті OpenClaw автоматична Compaction запускається у двох випадках:

1. Відновлення після переповнення: модель повертає помилку переповнення контексту (request_too_large, context length exceeded, input exceeds the maximum number of tokens, input token count exceeds the maximum number of input tokens, input is too long for the model, ollama error: context length exceeded і подібні варіанти у формі провайдера) → compact → повторити. Коли провайдер повідомляє спробувану кількість токенів, OpenClaw передає це спостережене значення в Compaction відновлення після переповнення. Якщо провайдер підтверджує переповнення, але не надає доступної для розбору кількості, OpenClaw передає мінімально понадбюджетну синтетичну кількість до рушіїв Compaction і діагностики. Якщо відновлення після переповнення все одно не вдається, OpenClaw показує явні настанови користувачу та зберігає поточне зіставлення сеансу замість тихої ротації ключа сеансу на свіжий ідентифікатор сеансу. Наступний крок контролює оператор: повторити повідомлення, виконати /compact або виконати /new, коли бажаний свіжий сеанс.
2. Порогове обслуговування: після успішного ходу, коли:

contextTokens > contextWindow - reserveTokens

Де:

• contextWindow — контекстне вікно моделі
• reserveTokens — запас, зарезервований для промптів + наступного виводу моделі

Це семантика середовища виконання OpenClaw.

OpenClaw також може запускати попередню локальну Compaction перед відкриттям наступного запуску, коли задано agents.defaults.compaction.maxActiveTranscriptBytes і активний файл транскрипту досягає цього розміру. Це захист за розміром файлу для локальної вартості повторного відкриття, а не сире архівування: OpenClaw усе одно виконує звичайну семантичну Compaction, і для цього потрібен truncateAfterCompaction, щоб стиснений підсумок міг стати новим наступником транскрипту.

Для вбудованих запусків OpenClaw, agents.defaults.compaction.midTurnPrecheck.enabled: true додає необов’язковий захист циклу інструментів. Після додавання результату інструмента та перед наступним викликом моделі OpenClaw оцінює тиск на промпт, використовуючи ту саму логіку попереднього бюджету, що й на початку ходу. Якщо контекст більше не вміщується, захист не виконує Compaction всередині хука transformContext середовища виконання OpenClaw. Він підіймає структурований сигнал попередньої перевірки всередині ходу, зупиняє поточне подання промпта та дає зовнішньому циклу запуску використати наявний шлях відновлення: обрізати завеликі результати інструментів, коли цього достатньо, або запустити налаштований режим Compaction і повторити. Опція вимкнена за замовчуванням і працює з режимами Compaction default і safeguard, зокрема Compaction safeguard на базі провайдера. Це незалежно від maxActiveTranscriptBytes: захист за розміром у байтах виконується до відкриття ходу, тоді як попередня перевірка всередині ходу виконується пізніше у вбудованому циклі інструментів OpenClaw після додавання нових результатів інструментів.

Налаштування Compaction (reserveTokens, keepRecentTokens)

Налаштування Compaction середовища виконання OpenClaw містяться в налаштуваннях агента:

{  compaction: {    enabled: true,    reserveTokens: 16384,    keepRecentTokens: 20000,  },}

OpenClaw також застосовує безпечну нижню межу для вбудованих запусків:

• Якщо compaction.reserveTokens < reserveTokensFloor, OpenClaw підвищує його.
• Типова нижня межа — 20000 токенів.
• Задайте agents.defaults.compaction.reserveTokensFloor: 0, щоб вимкнути нижню межу.
• Якщо значення вже вище, OpenClaw залишає його без змін.
• Ручний /compact враховує явний agents.defaults.compaction.keepRecentTokens і зберігає точку відрізання недавнього хвоста середовища виконання OpenClaw. Без явного бюджету збереження ручна Compaction залишається жорсткою контрольною точкою, а перебудований контекст починається з нового підсумку.
• Задайте agents.defaults.compaction.midTurnPrecheck.enabled: true, щоб виконувати необов’язкову попередню перевірку циклу інструментів після нових результатів інструментів і перед наступним викликом моделі. Це лише тригер; генерація підсумку все одно використовує налаштований шлях Compaction. Це незалежно від maxActiveTranscriptBytes, який є захистом за розміром у байтах активного транскрипту на початку ходу.
• Задайте agents.defaults.compaction.maxActiveTranscriptBytes як значення в байтах або рядок на кшталт "20mb", щоб виконувати локальну Compaction перед ходом, коли активний транскрипт стає великим. Цей захист активний лише тоді, коли також увімкнено truncateAfterCompaction. Залиште його незаданим або задайте 0, щоб вимкнути.
• Коли agents.defaults.compaction.truncateAfterCompaction увімкнено, OpenClaw ротирує активний транскрипт у стиснений наступник JSONL після Compaction. Дії контрольної точки гілки/відновлення використовують цей стиснений наступник; застарілі файли контрольних точок до Compaction залишаються читабельними, доки на них є посилання.

Навіщо: залишити достатній запас для багатоходового «обслуговування» (наприклад, записів пам’яті), перш ніж Compaction стане неминучою.

Реалізація: applyAgentCompactionSettingsFromConfig() у src/agents/agent-settings.ts (викликається зі шляхів ходу вбудованого runner і налаштування Compaction).

Підключні провайдери Compaction

Plugins можуть реєструвати провайдера Compaction через registerCompactionProvider() в API plugin. Коли agents.defaults.compaction.provider задано як ідентифікатор зареєстрованого провайдера, розширення safeguard делегує підсумовування цьому провайдеру замість вбудованого конвеєра summarizeInStages.

• provider: ідентифікатор зареєстрованого plugin провайдера Compaction. Залиште незаданим для типового підсумовування LLM.
• Задання provider примусово вмикає mode: "safeguard".
• Провайдери отримують ті самі інструкції Compaction і політику збереження ідентифікаторів, що й вбудований шлях.
• Safeguard усе одно зберігає контекст суфікса останніх ходів і розділених ходів після виводу провайдера.
• Вбудоване підсумовування safeguard повторно дистилює попередні підсумки з новими повідомленнями замість збереження повного попереднього підсумку дослівно.
• Режим Safeguard за замовчуванням вмикає аудити якості підсумку; задайте qualityGuard.enabled: false, щоб пропустити поведінку повтору за некоректного виводу.
• Якщо провайдер зазнає помилки або повертає порожній результат, OpenClaw автоматично повертається до вбудованого підсумовування LLM.
• Сигнали переривання/тайм-ауту повторно викидаються (не поглинаються), щоб поважати скасування викликачем.

Джерело: src/plugins/compaction-provider.ts, src/agents/agent-hooks/compaction-safeguard.ts.

Поверхні, видимі користувачу

Ви можете спостерігати Compaction і стан сеансу через:

• /status (у будь-якому чат-сеансі)
• openclaw status (CLI)
• openclaw sessions / sessions --json
• Журнали Gateway (pnpm gateway:watch або openclaw logs --follow): embedded run auto-compaction start + complete
• Детальний режим: 🧹 Auto-compaction complete + кількість Compaction

Тихе обслуговування (NO_REPLY)

OpenClaw підтримує «тихі» ходи для фонових завдань, де користувач не повинен бачити проміжний вивід.

Конвенція:

• Асистент починає свій вивід із точного мовчазного токена NO_REPLY / no_reply, щоб позначити "не доставляти відповідь користувачу".
• OpenClaw вилучає/пригнічує це на рівні доставки.
• Точне пригнічення мовчазного токена не враховує регістр, тож NO_REPLY і no_reply обидва зараховуються, коли весь payload є лише мовчазним токеном.
• Це призначено лише для справді фонових ходів без доставки; це не скорочення для звичайних дієвих запитів користувача.

Починаючи з 2026.1.10, OpenClaw також пригнічує потокове передавання чернетки/набору тексту, коли частковий фрагмент починається з NO_REPLY, тому мовчазні операції не розкривають частковий вивід посеред ходу.

Перед-Compaction "скидання пам'яті" (реалізовано)

Мета: перш ніж відбудеться автоматична Compaction, запустити мовчазний агентний хід, який записує довговічний стан на диск (наприклад, memory/YYYY-MM-DD.md у робочому просторі агента), щоб Compaction не могла стерти критичний контекст.

OpenClaw використовує підхід скидання перед порогом:

1. Відстежуйте використання контексту сесії.
2. Коли воно перетинає "м'який поріг" (нижче порогу Compaction середовища виконання OpenClaw), запустіть мовчазну директиву "запиши пам'ять зараз" для агента.
3. Використайте точний мовчазний токен NO_REPLY / no_reply, щоб користувач нічого не бачив.

Конфігурація (agents.defaults.compaction.memoryFlush):

• enabled (за замовчуванням: true)
• model (необов'язкове точне перевизначення провайдера/моделі для ходу скидання, наприклад ollama/qwen3:8b)
• softThresholdTokens (за замовчуванням: 4000)
• prompt (повідомлення користувача для ходу скидання)
• systemPrompt (додатковий системний prompt, доданий для ходу скидання)

Примітки:

• Стандартний prompt/системний prompt містять підказку NO_REPLY для пригнічення доставки.
• Коли model задано, хід скидання використовує цю модель без успадкування активного ланцюжка fallback сесії, тому локальне лише службове обслуговування не буде мовчки fallback до платної розмовної моделі.
• Скидання виконується один раз на цикл Compaction (відстежується в sessions.json).
• Скидання виконується лише для вбудованих сесій OpenClaw (бекенди CLI пропускають його).
• Скидання пропускається, коли робочий простір сесії доступний лише для читання (workspaceAccess: "ro" або "none").
• Див. Пам'ять щодо структури файлів робочого простору та шаблонів запису.

OpenClaw також надає hook session_before_compact в API розширень, але логіка скидання OpenClaw наразі живе на боці Gateway.

Контрольний список усунення несправностей

• Неправильний ключ сесії? Почніть із /concepts/session і підтвердьте sessionKey у /status.
• Невідповідність сховища й transcript? Підтвердьте хост Gateway і шлях сховища з openclaw status.
• Спам Compaction? Перевірте:
  • вікно контексту моделі (замале)
  • налаштування Compaction (reserveTokens завелике для вікна моделі може спричинити ранішу Compaction)
  • розростання результатів інструментів: увімкніть/налаштуйте обрізання сесії
• Мовчазні ходи протікають? Підтвердьте, що відповідь починається з NO_REPLY (точний токен без урахування регістру) і що ви використовуєте збірку, яка містить виправлення пригнічення потокового передавання.

Пов'язане

• Керування сесіями
• Обрізання сесії
• Рушій контексту