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

​
Основные принципы

Специализированная линия повышает пропускную способность только тогда, когда снижает конкуренцию за реальные узкие места:
  • Блокировки сеансов: только один запуск должен изменять конкретный сеанс одновременно.
  • Глобальная емкость модели: все видимые запуски в чатах по-прежнему совместно используют лимиты провайдера.
  • Емкость инструментов: работа с оболочкой, браузером, сетью и репозиторием может быть медленнее самого хода модели.
  • Бюджет контекста: длинные расшифровки делают каждый следующий ход медленнее и менее сфокусированным.
  • Неясность владения: агенты-дубликаты, выполняющие одну и ту же работу, тратят емкость впустую.
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.

​
См. также