---
read_when:
    - Зміна виконання auto-reply або паралелізму
summary: Дизайн черги команд, який серіалізує вхідні запуски auto-reply
title: Черга команд
x-i18n:
    generated_at: "2026-04-05T18:01:45Z"
    model: gpt-5.4
    provider: openai
    source_hash: 36e1d004e9a2c21ad1470517a249285216114dd4cf876681cc860e992c73914f
    source_path: concepts/queue.md
    workflow: 15
---

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

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

## Чому

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

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

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

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

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

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

Steer-backlog означає, що ви можете отримати відповідь followup після
запуску steered, тому на поверхнях зі streaming це може виглядати як дублікати. Віддавайте перевагу `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`: чекати тиші перед запуском циклу followup (запобігає “continue, continue”).
- `cap`: максимальна кількість повідомлень у черзі на сесію.
- `drop`: політика переповнення (`old`, `new`, `summarize`).

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

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

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

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

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

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

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