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

Messages and delivery

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

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 зберігає короткочасний кеш із ключем за каналом/обліковим записом/співрозмовником/сеансом/ідентифікатором повідомлення, щоб дублікати доставлення не запускали ще один запуск агента.

Дебаунс вхідних повідомлень

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

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

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

Примітки:

  • Дебаунс застосовується до повідомлень лише з текстом; медіа/вкладення скидають очікування негайно.
  • Керувальні команди обходять дебаунс, щоб залишатися окремими — окрім випадків, коли канал явно вмикає об’єднання DM від того самого відправника (наприклад, BlueBubbles coalesceSameSenderDms), де DM-команди чекають у межах вікна дебаунсу, щоб розділене надсилання могло приєднатися до того самого ходу агента.

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

Сеансами володіє Gateway, а не клієнти.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Черга та подальші ходи

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

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

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

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

Плагіни каналів можуть зберігати порядок, застосовувати дебаунс до вводу та транспортний зворотний тиск перед тим, як повідомлення потрапить у чергу сеансу. Вони не повинні накладати окремий тайм-аут навколо самого ходу агента. Щойно повідомлення скеровано до сеансу, довготривалу роботу регулюють життєві цикли сеансу, інструмента та 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 (пакетування на основі простою)
  • agents.defaults.humanDelay (людиноподібна пауза між блоками відповідей)
  • Перевизначення каналів: *.blockStreaming і *.blockStreamingCoalesce (канали не Telegram потребують явного *.blockStreaming: true)

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

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

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

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

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

Префікси, ланцюжки та відповіді

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

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

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

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

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

  • Прямі розмови стандартно забороняють тишу й переписують голу тиху відповідь у короткий видимий резервний текст.
  • Групи/канали стандартно дозволяють тишу.
  • Внутрішня оркестрація стандартно дозволяє тишу.

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

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

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

Пов’язане