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

Documentation Index

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

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

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

​
Пов’язане