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

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

Потік повідомлень (загальний рівень)

Inbound message  -> routing/bindings -> session key  -> queue (if a run is active)  -> agent run (streaming + tools)  -> outbound replies (channel limits + chunking)

Основні параметри налаштовуються в конфігурації:

• messages.* для префіксів, черг і поведінки груп.
• agents.defaults.* для стандартних параметрів потокового передавання блоків і фрагментації.
• Перевизначення каналів (channels.whatsapp.*, channels.telegram.* тощо) для лімітів і перемикачів потокового передавання.

Повну схему див. у Конфігурації.

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

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

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

Швидкі послідовні повідомлення від того самого відправника можна об’єднувати в один хід агента через messages.inbound. Debounce обмежений каналом + розмовою і використовує найновіше повідомлення для прив’язки відповіді до гілки/ідентифікаторів.

Конфігурація (глобальне значення за замовчуванням + перевизначення для каналів):

{  messages: {    inbound: {      debounceMs: 2000,      byChannel: {        whatsapp: 5000,        slack: 1500,        discord: 1500,      },    },  },}

Примітки:

• Debounce застосовується до повідомлень лише з текстом; медіа/вкладення надсилаються негайно.
• Керівні команди обходять debounce, щоб залишатися окремими. Канали, які явно вмикають об’єднання DM від того самого відправника, можуть залишати команди DM у вікні debounce, щоб payload, надісланий кількома частинами, міг потрапити в той самий хід агента.

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

Сесіями керує gateway, а не клієнти.

• Прямі чати згортаються в ключ основної сесії агента.
• Групи/канали отримують власні ключі сесій.
• Сховище сесій і транскрипти зберігаються на хості gateway.

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

Докладніше: Керування сесіями.

Метадані результату інструмента

content результату інструмента — це результат, видимий моделі. details результату інструмента — це метадані runtime для рендерингу UI, діагностики, доставлення медіа та плагінів.

OpenClaw явно зберігає цю межу:

• toolResult.details вилучається перед повторним відтворенням у провайдера та вхідними даними Compaction.
• Збережені транскрипти сесій містять лише обмежені details; завеликі метадані замінюються компактним підсумком із позначкою persistedDetailsTruncated: true.
• Плагіни й інструменти мають розміщувати текст, який модель повинна прочитати, у content, а не лише в details.

Тіла вхідних повідомлень і контекст історії

OpenClaw розділяє тіло prompt і тіло команди:

• BodyForAgent: основний текст для поточного повідомлення, спрямований до моделі. Плагіни каналів мають тримати його сфокусованим на поточному тексті відправника, що містить prompt.
• Body: застарілий резервний варіант prompt. Він може містити обгортки каналу та необов’язкові обгортки історії, але поточні канали не мають покладатися на нього як на основний вхід моделі, коли доступний BodyForAgent.
• CommandBody: сирий текст користувача для розбору директив/команд.
• RawBody: застарілий псевдонім для CommandBody (залишений для сумісності).

Коли канал надає історію, він використовує спільну обгортку:

• [Chat messages since your last reply - for context]
• [Current message - respond to this]

Для непрямих чатів (груп/каналів/кімнат) до тіла поточного повідомлення додається префікс із міткою відправника (у тому самому стилі, що використовується для записів історії). Це робить повідомлення в реальному часі та повідомлення з черги/історії узгодженими в prompt агента.

Буфери історії є лише pending-only: вони містять групові повідомлення, які не запустили виконання (наприклад, повідомлення, пропущені через mention-gate), і виключають повідомлення, які вже є в транскрипті сесії.

Вилучення директив застосовується лише до розділу поточного повідомлення, щоб історія залишалася неушкодженою. Канали, які обгортають історію, мають задавати CommandBody (або RawBody) як початковий текст повідомлення та залишати Body як об’єднаний prompt. Структурована історія, відповіді, переслані повідомлення та метадані каналу рендеряться як ненадійні контекстні блоки з роллю користувача під час складання prompt. Буфери історії налаштовуються через messages.groupChat.historyLimit (глобальне значення за замовчуванням) і перевизначення для каналів, як-от channels.slack.historyLimit або channels.telegram.accounts.<id>.historyLimit (встановіть 0, щоб вимкнути).

Черги та followups

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

• Налаштування через messages.queue (і messages.queue.byChannel).
• Режим за замовчуванням — steer, із debounce 500 мс для пакетів steering Codex і черг followup/collect.
• Режими: steer, followup, collect і interrupt.

Докладніше: Черга команд і Черга steering.

Володіння запуском каналу

Плагіни каналів можуть зберігати порядок, застосовувати debounce до вводу та керувати backpressure транспорту перед тим, як повідомлення потрапить у чергу сесії. Вони не мають накладати окремий timeout навколо самого ходу агента. Після маршрутизації повідомлення до сесії довготривала робота керується життєвим циклом сесії, інструмента та runtime, щоб усі канали узгоджено повідомляли про повільні ходи та відновлювалися після них.

Потокове передавання, фрагментація та пакетування

Потокове передавання блоків надсилає часткові відповіді в міру того, як модель створює текстові блоки. Фрагментація враховує текстові ліміти каналу та уникає розбиття fenced code.

Основні параметри:

• agents.defaults.blockStreamingDefault (on|off, за замовчуванням off)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (пакетування на основі idle)
• agents.defaults.humanDelay (людиноподібна пауза між блоками відповіді)
• Перевизначення каналів: *.blockStreaming і *.blockStreamingCoalesce (канали не Telegram потребують явного *.blockStreaming: true)

Докладніше: Потокове передавання + фрагментація.

Видимість міркувань і токени

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

• /reasoning on|off|stream керує видимістю.
• Вміст міркувань усе одно враховується у використанні токенів, коли його створює модель.
• Telegram підтримує потік міркувань у тимчасову чернеткову бульбашку, яка видаляється після фінального доставлення; використовуйте /reasoning on для постійного виводу міркувань.

Докладніше: Директиви thinking + reasoning і Використання токенів.

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

Форматування вихідних повідомлень централізоване в messages:

• messages.responsePrefix, channels.<channel>.responsePrefix і channels.<channel>.accounts.<id>.responsePrefix (каскад вихідного префікса), плюс channels.whatsapp.messagePrefix (вхідний префікс WhatsApp)
• Reply threading через replyToMode і стандартні значення для каналів

Докладніше: Конфігурація і документація каналів.

Тихі відповіді

Точний тихий токен NO_REPLY / no_reply означає «не доставляти відповідь, видиму користувачу». Коли хід також має pending media інструмента, наприклад згенероване TTS-аудіо, OpenClaw вилучає тихий текст, але все одно доставляє медіавкладення. OpenClaw визначає цю поведінку за типом розмови:

• Прямі розмови ніколи не отримують prompt guidance NO_REPLY. Якщо прямий запуск випадково повертає голий тихий токен, OpenClaw пригнічує його замість переписування або доставлення.
• Групи/канали за замовчуванням дозволяють тишу лише для автоматичних групових відповідей. У режимі видимої відповіді message_tool тиша означає, що модель не викликає message(action=send).
• Внутрішня оркестрація за замовчуванням дозволяє тишу.

OpenClaw також використовує тихі відповіді для загальних внутрішніх помилок runner у непрямих чатах, щоб групи/канали не бачили шаблонний текст помилки gateway. Класифіковані збої з user-facing recovery copy, як-от відсутня автентифікація, rate-limit або сповіщення про перевантаження, усе ще можуть доставлятися. Прямі чати за замовчуванням показують компактний текст збою; сирі деталі runner показуються лише коли увімкнено /verbose full.

Стандартні значення розташовані в agents.defaults.silentReply; surfaces.<id>.silentReply може перевизначати політику груп/внутрішніх поверхонь для кожної поверхні.

Голі тихі відповіді відкидаються на всіх поверхнях, тому батьківські сесії залишаються тихими замість переписування sentinel text у fallback chatter.

Пов’язане

• Рефакторинг життєвого циклу повідомлення - цільовий довговічний дизайн надсилання й отримання
• Потокове передавання — доставлення повідомлень у реальному часі
• Повторна спроба — поведінка повторної спроби доставлення повідомлень
• Черга — черга обробки повідомлень
• Канали — інтеграції з платформами обміну повідомленнями