Multi-agent
Параллельные специализированные направления
Параллельные специализированные линии позволяют одному 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 ornetwork work unless this lane explicitly owns it.