Messages and delivery

Черга команд

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

Чому

Запуски автовідповідей можуть бути дорогими (виклики LLM) і можуть конфліктувати, коли кілька вхідних повідомлень надходять майже одночасно.
Серіалізація уникає конкуренції за спільні ресурси (файли сесій, журнали, stdin CLI) і зменшує ймовірність обмежень швидкості з боку вищого рівня.

Як це працює

FIFO-черга з урахуванням смуг обробляє кожну смугу з налаштовуваним обмеженням паралельності (типово 1 для неналаштованих смуг; main типово 4, subagent типово 8).
runEmbeddedAgent додає до черги за ключем сесії (смуга session:<key>), щоб гарантувати лише один активний запуск на сесію.
Кожен запуск сесії потім ставиться в глобальну смугу (main типово), щоб загальний паралелізм обмежувався agents.defaults.maxConcurrent.
Коли ввімкнено докладне журналювання, запуски в черзі видають коротке повідомлення, якщо чекали понад ~2 с перед стартом.
Індикатори набору все одно спрацьовують одразу під час додавання до черги (коли це підтримує канал), тому користувацький досвід не змінюється, поки ми чекаємо своєї черги.

Типові значення

Коли не задано, усі вхідні поверхні каналів використовують:

mode: "steer"
debounceMs: 500
cap: 20
drop: "summarize"

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

Режими черги

/queue керує тим, що звичайні вхідні повідомлення роблять, коли сесія вже має активний запуск:

steer: вставляє повідомлення в активне середовище виконання. OpenClaw доставляє всі очікувані повідомлення скерування після того, як поточний хід асистента завершить виконання своїх викликів інструментів, перед наступним викликом LLM; Codex app-server отримує один пакетний turn/steer. Якщо запуск не транслює активно або скерування недоступне, OpenClaw чекає, доки активний запуск завершиться, перш ніж запускати запит.
followup: не скеровувати. Додає кожне повідомлення до черги для пізнішого ходу агента після завершення поточного запуску.
collect: не скеровувати. Об’єднує повідомлення в черзі в один подальший хід після тихого вікна. Якщо повідомлення призначені для різних каналів/гілок, вони обробляються окремо, щоб зберегти маршрутизацію.
interrupt: перериває активний запуск для цієї сесії, а потім запускає найновіше повідомлення.

Щоб дізнатися про специфічні для середовища виконання таймінг і поведінку залежностей, див. Черга скерування. Для явної команди /steer <message> див. Скерувати.

Налаштуйте глобально або для кожного каналу через messages.queue:

json5

{  messages: {    queue: {      mode: "steer",      debounceMs: 500,      cap: 20,      drop: "summarize",      byChannel: { discord: "collect" },    },  },}

Параметри черги

Параметри застосовуються до доставки з черги. debounceMs також задає тихе вікно скерування Codex у режимі steer:

debounceMs: тихе вікно перед обробкою подальших повідомлень із черги або пакетів collect; у режимі Codex steer це тихе вікно перед надсиланням пакетного turn/steer. Голі числа означають мілісекунди; одиниці ms, s, m, h і d приймаються параметрами /queue.
cap: максимальна кількість повідомлень у черзі на сесію. Значення нижче 1 ігноруються.
drop: "summarize": типово. Відкидає найстаріші записи черги за потреби, зберігає компактні підсумки й вставляє їх як синтетичний подальший запит.
drop: "old": відкидає найстаріші записи черги за потреби, без збереження підсумків.
drop: "new": відхиляє найновіше повідомлення, коли черга вже заповнена.

Типові значення: debounceMs: 500, cap: 20, drop: summarize.

Скерування та потокова передача

Коли потокова передача каналу має значення partial або block, скерування може виглядати як кілька коротких видимих відповідей, поки активний запуск досягає меж середовища виконання:

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

steer не перериває інструменти, що вже виконуються. Використовуйте /queue interrupt, коли найновіше повідомлення має перервати поточний запуск.

Пріоритет

Для вибору режиму OpenClaw визначає:

Вбудоване або збережене перевизначення /queue для сесії.
messages.queue.byChannel.<channel>.
messages.queue.mode.
Типовий steer.

Для параметрів вбудовані або збережені параметри /queue мають пріоритет над конфігурацією. Потім застосовуються специфічна для каналу затримка (messages.queue.debounceMsByChannel), типові затримки плагіна, глобальні параметри messages.queue і вбудовані типові значення. cap і drop є глобальними/сесійними параметрами, а не ключами конфігурації для каналу.

Перевизначення для сесії

Надішліть /queue <steer|followup|collect|interrupt> як окрему команду, щоб зберегти режим черги для поточної сесії.
Параметри можна комбінувати: /queue collect debounce:0.5s cap:25 drop:summarize
/queue default або /queue reset очищає перевизначення сесії.

Обсяг і гарантії

Застосовується до запусків агентів автовідповідей у всіх вхідних каналах, які використовують конвеєр відповідей Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, вебчат тощо).
Типова смуга (main) є спільною для процесу для вхідних повідомлень + основних Heartbeat; задайте agents.defaults.maxConcurrent, щоб дозволити кілька сесій паралельно.
Можуть існувати додаткові смуги (наприклад, cron, cron-nested, nested, subagent), щоб фонові завдання могли виконуватися паралельно, не блокуючи вхідні відповіді. Ізольовані ходи агента cron утримують слот cron, поки їхнє внутрішнє виконання агента використовує cron-nested; обидва використовують cron.maxConcurrentRuns. Спільні не-cron потоки nested зберігають власну поведінку смуги. Ці від’єднані запуски відстежуються як фонові завдання.
Смуги для сесії гарантують, що лише один запуск агента торкається певної сесії в один момент часу.
Без зовнішніх залежностей або фонових робочих потоків; чистий TypeScript + promises.

Усунення несправностей

Якщо команди здаються завислими, увімкніть докладні журнали й шукайте рядки "queued for ...ms", щоб підтвердити, що черга обробляється.
Якщо вам потрібна глибина черги, увімкніть докладні журнали й стежте за рядками таймінгу черги.
Запуски Codex app-server, які приймають хід, а потім припиняють видавати прогрес, перериваються адаптером Codex, щоб активна смуга сесії могла звільнитися замість очікування тайм-ауту зовнішнього запуску.
Коли діагностику ввімкнено, сесії, що залишаються в processing після diagnostics.stuckSessionWarnMs без спостереженої відповіді, інструмента, статусу, блока або прогресу ACP, класифікуються за поточною активністю. Активна робота журналюється як session.long_running; власні тихі виклики моделі також залишаються session.long_running до diagnostics.stuckSessionAbortMs, щоб повільні або непотокові провайдери не повідомлялися як завислі надто рано. Активна робота без нещодавнього прогресу журналюється як session.stalled; власні виклики моделі перемикаються на session.stalled на порозі переривання або після нього, а застаріла активність моделі/інструмента без власника не приховується як довготривала. session.stuck зарезервовано для відновлюваного застарілого обліку сесій, зокрема неактивних сесій у черзі із застарілою активністю моделі/інструмента без власника, і лише цей шлях може звільнити уражену смугу сесії, щоб робота в черзі оброблялася. Повторювані діагностики session.stuck відступають, поки сесія залишається незмінною.

Пов’язане

Was this useful?