---
read_when:
    - Зміна виконання або паралелізму автовідповіді
summary: Проєктування черги команд, яка серіалізує вхідні запуски автовідповіді
title: черга команд
x-i18n:
    generated_at: "2026-04-27T08:45:01Z"
    model: gpt-5.4
    provider: openai
    source_hash: 8fa2d4953ba8a3d9be7080599e550c796ccedf622a9467bf77e50454b6ea4c4a
    source_path: concepts/queue.md
    workflow: 15
---

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

## Чому

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

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

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

## Режими черги (для кожного каналу)

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

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

Steer-backlog означає, що ви можете отримати наступну відповідь після спрямованого запуску, тому на поверхнях зі стримінгом це може виглядати як дублікати. Віддавайте перевагу `collect`/`steer`, якщо хочете
одну відповідь на одне вхідне повідомлення.
Надішліть `/queue collect` як окрему команду (для конкретної сесії) або встановіть `messages.queue.byChannel.discord: "collect"`.

Типові значення (якщо не задані в конфігурації):

- Усі поверхні → `collect`

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

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

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

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

- `debounceMs`: очікувати тиші перед початком наступного ходу (запобігає “continue, continue”).
- `cap`: максимальна кількість повідомлень у черзі на сесію.
- `drop`: політика переповнення (`old`, `new`, `summarize`).

Summarize зберігає короткий маркований список відкинутих повідомлень і інʼєктує його як синтетичний followup-промпт.
Типові значення: `debounceMs: 1000`, `cap: 20`, `drop: summarize`.

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

- Надішліть `/queue <mode>` як окрему команду, щоб зберегти режим для поточної сесії.
- Параметри можна комбінувати: `/queue collect debounce:2s 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` зберігають власну поведінку смуг. Ці відокремлені запуски відстежуються як [фонові завдання](/uk/automation/tasks).
- Смуги на рівні сесії гарантують, що лише один запуск агента одночасно працює з певною сесією.
- Жодних зовнішніх залежностей або фонових worker-потоків; лише TypeScript + promises.

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

- Якщо здається, що команди зависли, увімкніть докладні журнали та шукайте рядки “queued for …ms”, щоб підтвердити, що черга обробляється.
- Якщо вам потрібна глибина черги, увімкніть докладні журнали та відстежуйте рядки з таймінгами черги.

## Пов’язане

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