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

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Паралельні спеціалізовані лінії дають змогу одному 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.

​
Пов’язане