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

Вхідні повідомлення проходять через маршрутизацію, дедуплікацію/затримку, запуск агента та вихідну доставку:

Вхідне повідомлення  -> маршрутизація/прив’язки -> ключ сеансу  -> дедуплікація + затримка  -> черга (якщо запуск уже активний)  -> запуск агента (потокове передавання + інструменти)  -> вихідні відповіді (обмеження каналу + поділ на фрагменти)

Основні поверхні конфігурації:

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

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

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

Канали можуть повторно доставити те саме повідомлення після повторного підключення. OpenClaw зберігає кеш у пам’яті, ключем якого є область агента, маршрут каналу (канал + співрозмовник + обліковий запис + гілка) та ідентифікатор повідомлення, тому повторно доставлене повідомлення не запускає агента вдруге. Запис кешу видаляється через 20 хвилин або після накопичення 5000 записів — залежно від того, що станеться раніше.

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

Швидкі послідовні текстові повідомлення від одного відправника можна об’єднати в один хід агента за допомогою messages.inbound. Затримка застосовується окремо для кожної комбінації каналу й розмови, а для гілки відповіді та ідентифікаторів використовується найновіше повідомлення.

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

• Затримка застосовується лише до текстових повідомлень; медіафайли й вкладення надсилаються негайно.
• Керівні команди (зупинка/переривання/стан тощо) оминають затримку й надсилаються негайно.
• Стандартно вимкнено: messages.inbound.debounceMs не має вбудованого стандартного значення, тому затримка активується лише після її налаштування (глобально або для окремого каналу).
• Винятком є увімкнення coalesceSameSenderDms в iMessage: воно затримує весь текст особистих повідомлень від одного відправника (включно з командами) достатньо довго, щоб розділене Apple надсилання команди й URL надійшло як один хід. Групові чати завжди надсилаються негайно незалежно від цього параметра.

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

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

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

Кілька пристроїв або каналів можуть відповідати одному сеансу, але історія не синхронізується повністю з кожним клієнтом. Для тривалих розмов використовуйте один основний пристрій, щоб уникнути розбіжностей у контексті. Інтерфейс керування та TUI завжди показують стенограму сеансу з Gateway, тому саме вона є джерелом істини.

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

Тіла запитів і контекст історії

Плагіни каналів заповнюють кілька текстових полів у вхідному контексті в порядку від найбільш до найменш пріоритетного:

Коли канал надає історію, він обгортає її такими елементами:

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

Для непрямих чатів (груп/каналів/кімнат) до тіла поточного повідомлення додається префікс із міткою відправника в тому самому стилі, що й у записах історії. Видалення директив застосовується лише до розділу поточного повідомлення, тому історія залишається незмінною. Канали, які обгортають історію, мають встановлювати BodyForCommands (або застарілі CommandBody / RawBody) у вихідний текст повідомлення та зберігати об’єднаний запит у Body.

Буфери історії містять лише повідомлення, що очікують обробки: до них входять групові повідомлення, які не спричинили запуску (наприклад, повідомлення, для яких потрібна згадка), але не входять повідомлення, уже наявні в стенограмі сеансу. Структурована історія, відповіді, переслані повідомлення та метадані каналу під час формування запиту відображаються як ненадійні контекстні блоки з роллю користувача.

Розмір історії налаштовується через messages.groupChat.historyLimit (глобальне стандартне значення) або поканальні перевизначення, як-от channels.slack.historyLimit і channels.telegram.accounts.<id>.historyLimit (установіть 0, щоб вимкнути).

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

content результату інструмента — це результат, видимий моделі; details — метадані середовища виконання для відображення в інтерфейсі, діагностики, доставки медіафайлів і плагінів.

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

Постановка в чергу та наступні повідомлення

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

Стандартні значення: messages.queue.debounceMs становить 500ms (однаково застосовується до спрямування, наступних повідомлень і пакетного збирання), messages.queue.cap — 20 повідомлень у черзі, а messages.queue.drop — summarize (також доступні old і new). Поканальні перевизначення налаштовуються через messages.queue.byChannel і messages.queue.debounceMsByChannel.

Докладніше: Черга команд і Черга спрямування.

Керування запуском на рівні каналу

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

Потокове передавання, поділ на фрагменти та пакетне об’єднання

Блокове потокове передавання надсилає часткові відповіді в міру створення моделлю текстових блоків; поділ на фрагменти враховує текстові обмеження каналу й не розділяє огороджені блоки коду.

• agents.defaults.blockStreamingDefault (on|off, стандартно off)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (пакетне об’єднання на основі бездіяльності)
• agents.defaults.humanDelay (людиноподібна пауза між відповідями блоками)
• Перевизначення каналів: *.streaming.block.enabled і *.streaming.block.coalesce у вбудованих каналах; застарілі пласкі ключі переносяться за допомогою openclaw doctor --fix. Блокове потокове передавання вимкнено, якщо його явно не ввімкнути, у кожному каналі, включно з Telegram. Виняток — QQ Bot: він не має ключів streaming.block і передає блокові відповіді потоково, якщо channels.qqbot.streaming.mode не має значення "off".

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

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

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

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

Префікси, гілки та відповіді

• Каскад вихідних префіксів: messages.responsePrefix, channels.<channel>.responsePrefix, channels.<channel>.accounts.<id>.responsePrefix. WhatsApp також має channels.whatsapp.messagePrefix для вхідного префікса.
• Гілки відповідей через replyToMode і стандартні поканальні параметри.

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

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

Тихий токен NO_REPLY (без урахування регістру, тому no_reply також збігається) означає «не доставляти видиму користувачеві відповідь». Якщо хід також має медіафайли інструментів, що очікують надсилання, наприклад створене аудіо TTS, OpenClaw видаляє тихий текст, але все одно доставляє медіавкладення.

Політика тиші визначається за типом розмови:

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

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

OpenClaw також використовує тихі відповіді для загальних внутрішніх збоїв засобу запуску в непрямих чатах, тому групи/канали не бачать шаблонного повідомлення про помилку Gateway. Класифіковані збої з видимими користувачеві інструкціями з відновлення, як-от повідомлення про відсутність автентифікації, обмеження частоти або перевантаження, усе одно можуть доставлятися. У прямих чатах стандартно показується стислий опис збою; необроблені подробиці засобу запуску показуються лише тоді, коли ввімкнено /verbose full.

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

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

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