Перейти до основного вмісту

​
Повідомлення

Ця сторінка поєднує пояснення того, як OpenClaw обробляє вхідні повідомлення, сесії, постановку в чергу, streaming і видимість reasoning.

​
Потік повідомлень (високий рівень)

Вхідне повідомлення
  -> routing/bindings -> ключ сесії
  -> черга (якщо запуск уже активний)
  -> запуск агента (streaming + інструменти)
  -> вихідні відповіді (обмеження каналу + chunking)
Ключові параметри містяться в конфігурації:
  • messages.* для префіксів, постановки в чергу та групової поведінки.
  • agents.defaults.* для типових значень block streaming і chunking.
  • Перевизначення на рівні каналу (channels.whatsapp.*, channels.telegram.* тощо) для лімітів і перемикачів streaming.
Повну схему див. у Конфігурація.

​
Дедуплікація вхідних повідомлень

Канали можуть повторно доставляти те саме повідомлення після перепідключення. OpenClaw зберігає короткоживучий кеш із ключем за channel/account/peer/session/message id, щоб дубльовані доставки не запускали ще один запуск агента.

​
Debouncing вхідних повідомлень

Швидкі послідовні повідомлення від того самого відправника можуть бути об’єднані в один хід агента через messages.inbound. Debouncing виконується в межах channel + conversation і використовує найновіше повідомлення для thread reply/ID. Конфігурація (глобальне типове значення + перевизначення на рівні каналу): 
{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}
Примітки:
  • Debounce застосовується до повідомлень лише з текстом; медіа/вкладення скидаються негайно.
  • Керувальні команди обходять debouncing, щоб залишатися окремими.

​
Сесії та пристрої

Сесіями володіє gateway, а не клієнти.
  • Прямі чати згортаються в ключ основної сесії агента.
  • Групи/канали отримують власні ключі сесій.
  • Сховище сесій і транскрипти знаходяться на хості gateway.
Кілька пристроїв/каналів можуть відображатися на ту саму сесію, але історія не синхронізується повністю назад на кожен клієнт. Рекомендація: використовуйте один основний пристрій для довгих розмов, щоб уникнути розходження контексту. Control UI і TUI завжди показують транскрипт сесії, що зберігається в gateway, тому саме вони є джерелом істини. Докладніше: Керування сесіями.

​
Вхідні тіла та контекст історії

OpenClaw розділяє тіло prompt і тіло команди:
  • Body: текст prompt, надісланий агенту. Він може включати envelope каналу та необов’язкові обгортки історії.
  • CommandBody: сирий текст користувача для розбору directive/command.
  • RawBody: застарілий псевдонім для CommandBody (збережено для сумісності).
Коли канал надає історію, він використовує спільну обгортку:
  • [Chat messages since your last reply - for context]
  • [Current message - respond to this]
Для непрямих чатів (груп/каналів/кімнат) тіло поточного повідомлення має префікс із міткою відправника (у тому ж стилі, що використовується для записів історії). Це забезпечує узгодженість між повідомленнями в реальному часі та повідомленнями з черги/історії в prompt агента. Буфери історії є лише pending: вони включають групові повідомлення, які не запустили виконання (наприклад, повідомлення, відфільтровані через gating згадувань), і не включають повідомлення, які вже є в транскрипті сесії. Видалення directive застосовується лише до секції поточного повідомлення, щоб історія залишалася незмінною. Канали, які обгортають історію, мають задавати CommandBody (або RawBody) як оригінальний текст повідомлення, а Body залишати як об’єднаний prompt. Буфери історії налаштовуються через messages.groupChat.historyLimit (глобальне типове значення) і перевизначення на рівні каналу, як-от channels.slack.historyLimit або channels.telegram.accounts.<id>.historyLimit (задайте 0, щоб вимкнути).

​
Постановка в чергу та followup

Якщо запуск уже активний, вхідні повідомлення можна поставити в чергу, спрямувати в поточний запуск або зібрати для наступного ходу followup.
  • Налаштовується через messages.queue (і messages.queue.byChannel).
  • Режими: interrupt, steer, followup, collect, а також варіанти backlog.
Докладніше: Черга.

​
Streaming, chunking і batching

Block streaming надсилає часткові відповіді в міру того, як модель продукує текстові блоки. Chunking враховує текстові обмеження каналу й уникає розбиття fenced code. Ключові параметри:
  • agents.defaults.blockStreamingDefault (on|off, типово off)
  • agents.defaults.blockStreamingBreak (text_end|message_end)
  • agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
  • agents.defaults.blockStreamingCoalesce (batching на основі idle)
  • agents.defaults.humanDelay (людиноподібна пауза між block replies)
  • Перевизначення на рівні каналу: *.blockStreaming і *.blockStreamingCoalesce (для каналів, окрім Telegram, потрібне явне *.blockStreaming: true)
Докладніше: Streaming + chunking.

​
Видимість reasoning і токени

OpenClaw може показувати або приховувати reasoning моделі:
  • /reasoning on|off|stream керує видимістю.
  • Вміст reasoning все одно враховується у використанні токенів, якщо його продукує модель.
  • Telegram підтримує потік reasoning у draft bubble.
Докладніше: Директиви thinking + reasoning і Використання токенів.

​
Префікси, thread і відповіді

Форматування вихідних повідомлень централізоване в messages:
  • messages.responsePrefix, channels.<channel>.responsePrefix і channels.<channel>.accounts.<id>.responsePrefix (каскад вихідних префіксів), а також channels.whatsapp.messagePrefix (вхідний префікс WhatsApp)
  • Thread відповідей через replyToMode і типові значення для окремих каналів
Докладніше: Довідник конфігурації і документацію каналів.

​
Пов’язане

  • Streaming — доставка повідомлень у реальному часі
  • Retry — поведінка повторних спроб доставки повідомлень
  • Queue — черга обробки повідомлень
  • Channels — інтеграції платформ обміну повідомленнями