Перейти до основного вмісту

​
Черга команд (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: 
{
  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), щоб фонові завдання могли виконуватися паралельно, не блокуючи вхідні відповіді. Ці відокремлені запуски відстежуються як фонові завдання.
  • Lane для кожної сесії гарантують, що лише один запуск агента торкається конкретної сесії в певний момент часу.
  • Без зовнішніх залежностей або фонових worker thread; лише чистий TypeScript + promises.

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

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