Паралельні спеціалізовані напрями

Паралельні спеціалізовані лінії дають одному Gateway змогу спрямовувати різні чати або кімнати до різних агентів, зберігаючи швидкий користувацький досвід. Суть у тому, щоб розглядати паралелізм як задачу проєктування для дефіцитних ресурсів, а не просто як «більше агентів».

# Базові принципи

Спеціалізована лінія покращує пропускну здатність лише тоді, коли зменшує конкуренцію за справжні вузькі місця:

• Блокування сесій: лише один запуск має змінювати певну сесію одночасно.
• Глобальна ємність моделі: усі видимі запуски чатів усе одно спільно використовують ліміти провайдера.
• Ємність інструментів: робота із shell, браузером, мережею та репозиторієм може бути повільнішою за сам хід моделі.
• Бюджет контексту: довгі стенограми роблять кожен майбутній хід повільнішим і менш сфокусованим.
• Неоднозначність власності: дублікати агентів, які виконують ту саму роботу, марнують ємність.

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

# Рекомендоване впровадження

# Етап 1: контракти ліній + важка фонова робота

Дайте кожній лінії письмовий контракт у її робочому просторі та системному prompt:

• Призначення: робота, якою володіє ця лінія.
• Нецілі: робота, яку вона має передавати далі замість того, щоб виконувати самостійно.
• Бюджет чату: швидкі відповіді залишаються в чаті; довгі завдання слід коротко підтвердити, а потім виконати у фоновому субагенті або задачі.
• Правило передачі: коли роботою володіє інша лінія, скажіть, куди її слід спрямувати, і надайте стислий підсумок для передачі.
• Правило ризику інструментів: віддавайте перевагу найменшій поверхні інструментів, здатній виконати завдання.

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

# Етап 2: пріоритети та керування конкурентністю

Налаштуйте ємність черги й моделі навколо бізнес-цінності кожної лінії:

{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8 },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}

Використовуйте прямі/особисті чати та агентів production-ops для високопріоритетної роботи. Дозволяйте дослідженням, чернеткам і пакетному кодуванню переходити у фонові задачі, коли система завантажена.

# Етап 3: координатор / диспетчер трафіку

Додайте невеликий патерн координатора, коли активні кілька ліній:

• Відстежуйте активні задачі ліній і власників.
• Виявляйте дублікати запитів у різних групах.
• Спрямовуйте підсумки передачі між лініями.
• Показуйте лише блокери, завершені результати та рішення, які має ухвалити людина.

Не починайте з цього. Координатор без контрактів ліній лише координує хаос.

# Мінімальний шаблон контракту лінії

# Lane contract

## Owns

- <job this lane is responsible for>

## Does not own

- <work to hand off>

## Chat budget

- Answer quick questions directly.
- For multi-step, slow, or tool-heavy work: acknowledge briefly, spawn/background
  the work, then return the result when complete.

## Handoff

If another lane owns the request, reply with:

- target lane
- objective
- relevant context
- exact next action

## Tool posture

Use the smallest tool surface that can complete the task. Avoid broad shell or
network work unless this lane explicitly owns it.

# Пов’язане

• Маршрутизація між кількома агентами
• Черга команд
• Субагенти