---
read_when:
    - Зміна виконання автоматичних відповідей або паралельності
    - Пояснення режимів /queue або поведінки скерування повідомлень
summary: Режими черги автовідповідей, значення за замовчуванням і перевизначення для окремих сеансів
title: Черга команд
x-i18n:
    generated_at: "2026-05-01T23:48:20Z"
    model: gpt-5.5
    provider: openai
    source_hash: c59ea6802d8bf526f4005db3b1baa87d96a23d561c916f91520e8e641fbaf74f
    source_path: concepts/queue.md
    workflow: 16
---

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

## Навіщо

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

## Як це працює

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

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

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

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

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

## Режими черги

Вхідні повідомлення можуть керувати поточним запуском, чекати наступного ходу або робити і те, і інше:

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

Steer-backlog означає, що ви можете отримати подальшу відповідь після керованого запуску, тому
поверхні потокової передачі можуть виглядати як дублікати. Віддавайте перевагу `collect`/`steer`, якщо хочете
одну відповідь на вхідне повідомлення.

Про специфічну для середовища виконання синхронізацію та поведінку залежностей див.
[Черга керування](/uk/concepts/queue-steering).

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

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

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

Параметри застосовуються до `followup`, `collect` і `steer-backlog` (а також до `steer` або застарілого `queue`, коли керування повертається до подальшого ходу):

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

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

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

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

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

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

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

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

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

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

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

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

## Пов’язане

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