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

​
Основні принципи

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

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

​
Фаза 1: контракти ліній + важка фонова робота

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

​
Фаза 2: пріоритети та керування паралельністю

Налаштуйте чергу та місткість моделі відповідно до бізнес-цінності кожної лінії: 
{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8, delegationMode: "prefer" },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}
Використовуйте прямі/особисті чати й агентів виробничих операцій для високопріоритетної роботи. Дозвольте дослідженням, чернеткам і пакетному кодуванню переходити у фонові задачі, коли система завантажена.

​
Фаза 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.

​
Пов’язане