Multi-agent

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

Status: active

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фаза 3: координатор / контролер трафіку

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

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

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

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

md
# 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 ornetwork work unless this lane explicitly owns it.

Пов’язане

Was this useful?