---
read_when:
    - Зміна виконання автовідповідей або конкурентності
summary: Дизайн черги команд, який серіалізує вхідні автозапуски відповідей
title: Черга команд
x-i18n:
    generated_at: "2026-04-23T22:59:00Z"
    model: gpt-5.4
    provider: openai
    source_hash: aa442e9aa2f0d6d95770d43e987d19ce8d9343450b302ee448e1fa4ab3feeb15
    source_path: concepts/queue.md
    workflow: 15
---

# Черга команд (2026-01-16)

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

## Чому

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

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

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

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

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

- `steer`: негайно ін’єктує в поточний запуск (скасовує відкладені виклики інструментів після наступної межі інструмента). Якщо потокове передавання не виконується, повертається до `followup`.
- `followup`: ставить у чергу на наступний хід агента після завершення поточного запуску.
- `collect`: об’єднує всі повідомлення в черзі в **один** наступний хід (`followup`) (типово). Якщо повідомлення націлені на різні канали/потоки, вони обробляються окремо, щоб зберегти маршрутизацію.
- `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` зберігає короткий маркований список відкинутих повідомлень і ін’єктує його як синтетичний prompt для наступного ходу.
Типові значення: `debounceMs: 1000`, `cap: 20`, `drop: summarize`.

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

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

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

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

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

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

## Пов’язане

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