Очередь команд

​

Зачем

• Запуски автоответов могут быть дорогими (вызовы 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"

​

Режимы очереди

• steer: внедрять сообщения в активную среду выполнения. OpenClaw доставляет все ожидающие сообщения управления после того, как текущий ход ассистента завершит выполнение вызовов инструментов, перед следующим вызовом LLM; app-server Codex получает один пакетный turn/steer. Если запуск не выполняет активную потоковую передачу или управление недоступно, OpenClaw ждет завершения активного запуска перед запуском подсказки.
• followup: не управлять. Ставить каждое сообщение в очередь для более позднего хода агента после завершения текущего запуска.
• collect: не управлять. Объединять сообщения в очереди в один последующий ход после окна тишины. Если сообщения нацелены на разные каналы/потоки, они обрабатываются по отдельности, чтобы сохранить маршрутизацию.
• interrupt: прервать активный запуск для этого сеанса, затем выполнить самое новое сообщение.

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

​

Параметры очереди

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

​

Управление и потоковая передача

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

​

Приоритет

1. Встроенное или сохраненное переопределение /queue для сеанса.
2. messages.queue.byChannel.<channel>.
3. messages.queue.mode.
4. Значение по умолчанию steer.

​

Переопределения для сеанса

• Отправьте /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, webchat и т. д.).
• Полоса по умолчанию (main) действует в рамках процесса для входящих сообщений и основных Heartbeat; задайте agents.defaults.maxConcurrent, чтобы разрешить параллельную работу нескольких сеансов.
• Могут существовать дополнительные полосы (например, cron, cron-nested, nested, subagent), чтобы фоновые задания могли выполняться параллельно, не блокируя входящие ответы. Изолированные ходы cron-агента удерживают слот cron, пока их внутреннее выполнение агента использует cron-nested; оба используют cron.maxConcurrentRuns. Общие не-cron-потоки nested сохраняют собственное поведение полосы. Эти отсоединенные запуски отслеживаются как фоновые задачи.
• Полосы для сеанса гарантируют, что только один запуск агента одновременно обращается к данному сеансу.
• Никаких внешних зависимостей или фоновых рабочих потоков; только TypeScript + promises.

​

Устранение неполадок

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

​

См. также

• Управление сеансом
• Очередь управления
• Управление
• Политика повторных попыток