Сообщения

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

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

Основные разделы конфигурации:

• 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 нет встроенного значения по умолчанию, поэтому задержка объединения активируется только после её настройки (глобально или для отдельного канала).
• Единственное исключение — включаемая настройка iMessage coalesceSameSenderDms: она достаточно долго удерживает весь текст личных сообщений от одного отправителя (включая команды), чтобы разделённая 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.

Ответы, содержащие только тихий токен, отбрасываются на всех поверхностях, поэтому родительские сеансы остаются безмолвными, а текст-маркер не преобразуется в запасную реплику.

Связанные разделы

• Рефакторинг жизненного цикла сообщений — целевая архитектура надёжной отправки и получения
• Потоковая передача — доставка сообщений в реальном времени
• Повторные попытки — поведение повторных попыток доставки сообщений
• Очередь — очередь обработки сообщений
• Каналы — интеграции с платформами обмена сообщениями