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

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

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

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

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

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

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

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

OpenClaw відокремлює тіло запиту від тіла команди:
  • BodyForAgent: основний текст поточного повідомлення для моделі. Plugins каналів мають тримати його сфокусованим на поточному тексті відправника, що містить запит.
  • Body: застарілий резервний текст запиту. Він може містити оболонки каналу та необов’язкові обгортки історії, але поточні канали не повинні покладатися на нього як на основний вхід моделі, коли доступний BodyForAgent.
  • CommandBody: сирий текст користувача для розбору директив/команд.
  • RawBody: застарілий псевдонім для CommandBody (залишений для сумісності).
Коли канал надає історію, він використовує спільну обгортку:
  • [Chat messages since your last reply - for context]
  • [Current message - respond to this]
Для непрямих чатів (груп/каналів/кімнат) тіло поточного повідомлення має префікс із міткою відправника (у тому самому стилі, що й записи історії). Це забезпечує узгодженість повідомлень реального часу та повідомлень із черги/історії в запиті агента. Буфери історії є лише очікуваними: вони містять групові повідомлення, які не запустили прогін (наприклад, повідомлення, обмежені згадкою), і виключають повідомлення, які вже є в транскрипті сесії. Вилучення директив застосовується лише до розділу поточного повідомлення, тому історія залишається неушкодженою. Канали, які обгортають історію, мають встановлювати 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 «по одному за раз».
Докладніше: Черга команд і Черга спрямування.

​
Володіння прогоном каналу

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

​
Потокове передавання, розбиття на фрагменти та пакетування

Потокове передавання блоків надсилає часткові відповіді, коли модель створює текстові блоки. Розбиття на фрагменти дотримується текстових обмежень каналу й не розділяє огороджені блоки коду. Основні налаштування:
  • 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 для постійного виведення міркувань.
Докладніше: Директиви мислення + міркування і Використання токенів.

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

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

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

Точний тихий токен NO_REPLY / no_reply означає «не доставляти видиму для користувача відповідь». Коли хід також має очікуване медіа інструмента, як-от згенероване TTS-аудіо, OpenClaw вилучає тихий текст, але все одно доставляє медіавкладення. OpenClaw визначає цю поведінку за типом розмови:
  • Прямі розмови за замовчуванням забороняють мовчання та переписують голу тиху відповідь у короткий видимий резервний текст.
  • Групи/канали за замовчуванням дозволяють мовчання.
  • Внутрішня оркестрація за замовчуванням дозволяє мовчання.
OpenClaw також використовує тихі відповіді для внутрішніх збоїв runner, які трапляються до будь-якої відповіді асистента в непрямих чатах, щоб групи/канали не бачили шаблонного тексту помилки Gateway. Прямі чати за замовчуванням показують компактний текст про збій; сирі подробиці runner показуються лише коли /verbose має значення on або full. Типові значення містяться в agents.defaults.silentReply і agents.defaults.silentReplyRewrite; surfaces.<id>.silentReply і surfaces.<id>.silentReplyRewrite можуть перевизначати їх для кожної поверхні. Коли батьківська сесія має один або більше очікуваних прогонів породжених субагентів, голі тихі відповіді відкидаються на всіх поверхнях замість переписування, тож батьківська сесія мовчить, доки подія завершення дочірнього агента не доставить справжню відповідь.

​
Пов’язане