---
read_when:
    - Зміна виконання автовідповідей або паралельності
    - Пояснення режимів /queue або поведінки спрямування повідомлень
summary: Режими черги автовідповідей, типові значення та перевизначення для окремих сеансів
title: Черга команд
x-i18n:
    generated_at: "2026-07-12T13:10:53Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 309d149545aaba91d2248dd6354d82e3cb7ddd489817a5f84acbb0269a0815ec
    source_path: concepts/queue.md
    workflow: 16
---

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

## Навіщо це потрібно

- Запуски автовідповідей можуть бути ресурсомісткими (виклики LLM) і конфліктувати, коли кілька вхідних повідомлень надходять майже одночасно.
- Серіалізація запобігає конкуренції за спільні ресурси (файли сеансів, журнали, стандартний ввід 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 отримує один пакетний `turn/steer`. Якщо запуск не здійснює активне потокове передавання або керування недоступне, OpenClaw очікує завершення активного запуску, перш ніж запустити запит.
- `followup`: не виконує керування. Ставить кожне повідомлення в чергу для наступного ходу агента після завершення поточного запуску.
- `collect`: не виконує керування. Об’єднує повідомлення в черзі в **один** наступний хід після завершення вікна тиші. Якщо повідомлення призначені для різних каналів або гілок, вони обробляються окремо, щоб зберегти маршрутизацію.
- `interrupt`: перериває активний запуск для цього сеансу, а потім запускає найновіше повідомлення.

Докладніше про часові характеристики та поведінку залежностей для конкретного середовища виконання див. у розділі [Черга керування](/uk/concepts/queue-steering). Відомості про явну команду `/steer <message>` див. у розділі [Керування](/uk/tools/steer).

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

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

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

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

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

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

## Керування та потокове передавання

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

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

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

## Пріоритетність

Для вибору режиму OpenClaw застосовує такий порядок:

1. Вбудоване або збережене перевизначення `/queue` для окремого сеансу.
2. `messages.queue.byChannel.<channel>`.
3. `messages.queue.mode`.
4. Типовий режим `steer`.

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

## Перевизначення для окремого сеансу

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

## Скасування ходу в черзі

Поки запит перебуває в черзі `followup`/`collect` (наприклад, коли `chat.send` із TUI або вебчату надходить під час активного іншого ходу), Gateway зберігає **належний Gateway ідентифікатор скасування** для клієнтського `runId`, доки вміст із черги не буде запущено або видалено. Ідентифікатор слідує за вмістом, включеним до зведення про переповнення.

- `chat.abort` із конкретним `runId` скасовує цей хід, поки він ще перебуває в черзі, якщо запитувач авторизований (за тими самими правилами володіння, що й для активних запусків).
- `chat.abort` для сеансу без `runId` спочатку скасовує **авторизовані ходи в черзі**, а потім перериває авторизовані активні запуски. Такий порядок не дає обробці черги перевести роботу в частково зупинений сеанс.
- Очищення всієї черги сеансу без перевірки кожного запитувача не є способом зупинки для сеансів із кількома власниками.
- Очікування в черзі не відображаються як активні запуски агента в `sessions.list` і не мають семантики часу очікування активного запуску; вона застосовується лише до активної фази.

Клієнти (зокрема TUI) пересилають запити, що надходять під час запуску, і дають Gateway застосувати режим черги. Esc/`/stop` використовує переривання в межах сеансу, щоб втрата локальних дескрипторів не призвела до виконання запиту, який усе ще перебуває в черзі.

## Область дії та гарантії

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

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

- Якщо здається, що команди зависли, увімкніть докладні журнали та знайдіть рядки «queued for ...ms», щоб переконатися, що черга обробляється.
- Запуски сервера застосунку Codex, які приймають хід, а потім припиняють повідомляти про поступ, перериваються адаптером Codex, щоб активна смуга сеансу могла звільнитися, а не очікувала завершення зовнішнього часу очікування запуску.
- Коли діагностику ввімкнено, сеанси, які залишаються в стані `processing` довше за `diagnostics.stuckSessionWarnMs` без зафіксованого поступу відповіді, інструмента, стану, блока або ACP, класифікуються за поточною активністю:
  - Активна робота з нещодавнім поступом журналюється як `session.long_running`. Беззвучні виклики моделі з визначеним власником також залишаються `session.long_running` до `diagnostics.stuckSessionAbortMs`, щоб повільні постачальники або постачальники без потокового передавання не позначалися як завислі надто рано.
  - Активна робота без нещодавнього поступу журналюється як `session.stalled`; виклики моделі з визначеним власником, заблоковані виклики інструментів і завислі вбудовані запуски переходять у стан `session.stalled` після досягнення порога переривання. Застаріла активність моделі або інструмента без власника не приховується як довготривала.
  - `session.stuck` зарезервовано для відновлюваних застарілих облікових даних сеансу, зокрема неактивних сеансів у черзі із застарілою активністю моделі або інструмента без власника.
  - `session.stuck` завжди запускає відновлення, яке може звільнити відповідну смугу сеансу. Класифікація `session.stalled` після перевищення `diagnostics.stuckSessionAbortMs` (заблокований виклик інструмента, завислий виклик моделі або завислий вбудований запуск) також може запустити відновлення з активним перериванням, тому обидві класифікації можуть розблокувати чергу, а не лише `session.stuck`.
  - Для повторюваних рядків журналу попереджень `session.stuck` і `session.long_running` інтервал збільшується експоненційно, доки сеанс залишається незмінним; спроби відновлення однаково виконуються під час кожного такту Heartbeat незалежно від цього збільшення інтервалу.

## Пов’язані матеріали

- [Керування сеансами](/uk/concepts/session)
- [Черга керування](/uk/concepts/queue-steering)
- [Керування](/uk/tools/steer)
- [Політика повторних спроб](/uk/concepts/retry)
