Как координировать несколько ИИ-агентов и не разориться на токенах

КРАТКАЯ ИНФОРМАЦИЯ


Сложность	Средняя
Время	45–60 минут
Что нужно знать	Хотя бы один работающий агент уже собрали, знакомы с асинхронным JavaScript или Python
Инструменты	Node.js 18+ или Python 3.9+, доступ к API какой-нибудь LLM (Claude, GPT-4 и т.д.)

Чему научитесь:

Выбирать паттерн оркестрации под конкретную задачу
Реализовывать общее состояние и передачу сообщений между агентами
Контролировать расходы на токены без сюрпризов в счетах
Отлаживать сбои в мультиагентных системах до того, как они пойдут каскадом

Одиночные агенты быстро упираются в потолок. Контекстное окно забивается, дерево решений превращается в кашу, а отлаживать цепочку рассуждений на 50 шагов не хочется никому. Мультиагентные системы распределяют работу между специализированными агентами, каждый из которых делает что-то одно, но хорошо. Подвох в том, что теперь эти агенты должны координироваться между собой, а это отдельный класс проблем.

В этом гайде разберём три паттерна оркестрации, которые реально используются, когда какой применять и какие уроки вынесли из систем под настоящей нагрузкой. Предполагается, что у вас уже есть работающий одиночный агент.

Зачем вообще несколько агентов

Честный ответ: скорее всего, поначалу не нужны. Одиночный агент справляется с большинством задач. Но вы упрётесь в ограничения, когда задачи требуют настоящей специализации (финансовый анализ vs генерация кода), параллельной обработки (четыре источника данных одновременно) или поддерживаемости (понять, какой компонент сломался).

О чём молчат в самом начале: накладные расходы на координацию. Агенты общаются, делят состояние, избегают конфликтов. Накосячите с координацией, и получите более дорогой способ упасть.

Три паттерна оркестрации

Три паттерна покрывают большинство реальных развёртываний. Выбирайте по требованиям к координации, а не по тому, что звучит круче.

Паттерн супервизора

Центральный агент-супервизор получает задачи, разбивает их на подзадачи, маршрутизирует работу специализированным воркерам, валидирует результаты и синтезирует финальный ответ.

Запрос пользователя
    ↓
[Агент-супервизор]
    ↓
Декомпозиция → Маршрутизация → Мониторинг → Валидация → Синтез
    ↓              ↓               ↓
[Воркер 1]    [Воркер 2]     [Воркер 3]

Супервизор отвечает за стратегию. Воркеры за исполнение. На практике это выглядит как четыре финансовых аналитика, работающих параллельно, пока координатор собирает их находки воедино:

// Супервизор координирует параллельный анализ
const analyses = await Promise.all([
  fundamentalAgent.analyze(ticker),
  portfolioAgent.analyze(ticker),
  riskAgent.analyze(ticker),
  technicalAgent.analyze(ticker)
]);

// Супервизор синтезирует результаты
const report = await supervisorAgent.synthesize(analyses);

Проблема супервизорного паттерна в том, что он становится узким местом. Каждое координационное решение проходит через одного агента. Расходы на токены растут вместе со слоями координации, потому что вы платите за рассуждения супервизора поверх выводов воркеров.

Используйте супервизора, когда нужна прозрачность и чёткая декомпозиция задач. Работает нормально примерно до 8 воркеров, потом накладные расходы на координацию начинают доминировать.

Паттерн роя

Никакого центрального контроллера. Агенты общаются напрямую, обмениваются информацией и самоорганизуются. Думайте о муравьиных колониях, а не об оргструктурах.

[Агент A] ←→ [Агент B]
    ↕  ↘     ↙  ↕
[Агент C] ←→ [Агент D]

Каждый агент может говорить с любым другим. Информация течёт через сеть, пока задача не выполнена или не достигнут консенсус. Система планирования путешествий может иметь шесть агентов (направление, перелёты, отели, рестораны, маршрут, бюджет), которые читают и пишут в общее состояние:

class TravelState {
  destination: string;
  flightOptions: Flight[];
  hotelOptions: Hotel[];
  budget: BudgetConstraints;
}

// Каждый агент читает общее состояние, делает свою работу, обновляет состояние
await destinationAgent.explore(state);
await flightAgent.search(state);  // Использует направление из предыдущего шага
await hotelAgent.search(state);   // Использует направление и даты

Рой тяжело отлаживать. Без координатора вы трассируете поток информации через сетку, а не через дерево. Агенты могут дублировать работу или создавать циклы. Я бы избегал этого паттерна, если вам не нужны именно несколько перспектив, сходящихся без чёткой декомпозиции задачи.

Иерархический паттерн

Паттерн супервизора, но рекурсивный. Агент верхнего уровня управляет агентами среднего уровня, которые управляют воркерами. Три или более слоёв.

[Супервизор верхнего уровня]
              ↓
    ┌─────────┴─────────┐
    ↓                   ↓
[Средний уровень A]  [Средний уровень B]
    ↓                   ↓
[Воркеры 1-3]      [Воркеры 4-6]

Генератор документации может иметь оркестратор верхнего уровня, делегирующий команде анализа, команде документации и команде валидации, у каждой свои специализированные воркеры.

Проблема: расходы на токены взрываются. Трёхуровневая иерархия с 5 агентами на уровень сжигает 50K+ токенов только на координацию. Оправдано только когда плоские паттерны действительно не справляются со сложностью.

Как агенты на самом деле общаются

Паттерны описывают структуру. Стратегии коммуникации описывают, как движется информация.

Общее состояние

Все агенты читают из общего объекта состояния и пишут в него. Изменения видны всем.

interface SharedState {
  task: string;
  results: Map<string, any>;
  currentStep: string;
}

// Агент A пишет
state.results.set('analysis', analysisResult);

// Агент B читает
const analysis = state.results.get('analysis');

Начинайте с этого. Просто реализовать, легко отлаживать (просто смотрите на состояние), не нужна инфраструктура для сообщений. Состояния гонки могут укусить, если агенты пишут одновременно, и состояние растёт без ограничений, если не чистить. Но большинство агентных систем должны использовать общее состояние, пока не столкнутся с конкретными проблемами, которые оно не решает.

Передача сообщений

Агенты отправляют сообщения через шину событий. Никакого прямого разделения состояния.

eventBus.publish('analysis.complete', {
  ticker: 'AAPL',
  analysis: result
});

eventBus.subscribe('analysis.complete', async (event) => {
  await portfolioAgent.process(event.analysis);
});

Слабая связанность между агентами, естественно для асинхронной работы, легко добавлять новых агентов. Сложнее отлаживать, потому что трассируете поток сообщений. Используйте, когда агенты действительно независимы и не должны знать друг о друге.

Механизм передачи управления

Один агент явно передаёт управление другому с контекстом.

class Agent {
  async handoff(targetAgent: Agent, context: Context) {
    const handoffContext = {
      previousAgent: this.name,
      taskContext: context,
      timestamp: Date.now()
    };
    return await targetAgent.execute(handoffContext);
  }
}

Понятный поток управления, легко проверять, но сильная связанность и по умолчанию последовательное выполнение. Используйте, когда задачи должны выполняться в определённом порядке.

Архитектура памяти

Одиночные агенты используют контекстные окна и внешнюю память. Мультиагентные системы добавляют ещё одну проблему: координировать состояние без его дублирования или создания конфликтов.

Память на основе сессий даёт каждому взаимодействию агента изолированную сессию, которая сливается обратно в общую память по завершении. Распространено в супервизорных паттернах, где воркеры работают независимо.

Оконная память хранит скользящее окно последних обменов между всеми агентами, сжимая или отбрасывая самые старые записи. Работает для долгих разговоров, где нельзя хранить всё, но контекст важен.

Эпизодическую память (хранение истории взаимодействий между конкретными парами агентов) я недостаточно тестировал в продакшене, чтобы сказать, стоит ли она сложности.

Реалии продакшена

Лабораторные демки масштабируются иначе, чем продакшен.

Экономика токенов

Мультиагентные системы сжигают токены быстро. Четыре координирующихся агента легко могут увеличить расходы в 10 раз по сравнению с одиночным агентом.

Типичная раскладка супервизорной системы:

Декомпозиция супервизора: ~1K токенов
4 агента-воркера по 3K каждый: 12K токенов
Синтез супервизора: ~2K токенов
Итого: ~15K токенов

Сравните с одиночным агентом на той же задаче: может быть 4K токенов. Вы платите за координацию.

Кэшируйте инструкции супервизора где возможно. Сжимайте вывод воркеров (структурированные данные, а не прозу). Всегда параллелизируйте независимую работу.

Задержки

Каждый вызов LLM добавляет 2–5 секунд. Последовательная обработка убивает пользовательский опыт.

1 агент: 3 секунды
4 агента последовательно: 12 секунд
4 агента параллельно: 3–4 секунды

Всегда параллелизируйте независимую работу.

Распространение ошибок

Один агент, вернувший мусор, может сломать агентов ниже по цепочке. Циклические зависимости создают дедлоки. Параллельные агенты, долбящие один API с ограничением частоты, исчерпывают ресурсы.

Защита: таймауты на каждом уровне, автоматические выключатели после N сбоев, деградация с частью агентов, изолированное состояние, чтобы сбои воркеров не повреждали общее состояние.

Мониторинг

Нельзя отлаживать то, чего не видишь. Отслеживайте успешность по агентам, накладные расходы на координацию, потребление токенов по агентам и паттерны взаимодействия.

class ObservableAgent {
  async execute(task: Task): Result {
    const span = tracer.startSpan('agent.execute', {
      agentId: this.id,
      taskType: task.type
    });
    
    try {
      const result = await this.process(task);
      span.setStatus({ code: SpanStatusCode.OK });
      return result;
    } catch (error) {
      span.setStatus({ 
        code: SpanStatusCode.ERROR,
        message: error.message 
      });
      throw error;
    } finally {
      span.end();
    }
  }
}

Устранение неполадок

Симптом: Агенты выдают противоречивые результаты Решение: Проверьте, не читают ли агенты устаревшее состояние. Добавьте метки времени к обновлениям состояния. Рассмотрите последовательное выполнение для взаимозависимых агентов.

Симптом: Расходы на токены неожиданно взлетают Решение: Логируйте использование токенов по агентам и задачам. Обычно один агент слишком многословен в своих рассуждениях. Ограничьте формат вывода.

Симптом: Супервизор становится узким местом под нагрузкой Решение: Группируйте похожие задачи для одной декомпозиции. Кэшируйте решения по маршрутизации. Рассмотрите паттерн роя, если задачи действительно независимы.

Симптом: Циклические вызовы агентов Решение: Добавьте лимиты глубины вызовов. Логируйте цепочки вызовов агентов. Обычно это признак неправильной декомпозиции задачи.

Выбор паттерна

Супервизор: Задачи чётко декомпозируются, нужна прозрачность, 3–8 специализированных агентов, качество важнее скорости.

Рой: Нужны несколько перспектив, нет чёткой декомпозиции, критична отзывчивость в реальном времени. (На самом деле, подумайте ещё раз, нужны ли вам вообще несколько агентов.)

Иерархия: Управляете 10+ агентами, несколько уровней абстракции, расходы на токены приемлемы.

Один агент: Задача достаточно простая, хватает одной области, минимизация расходов важна, пока не уверены.

Что дальше

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

В репозитории motia-examples есть примеры, которые стоит изучить: шахматная арена (конкурирующие агенты), финансовый агент (паттерн супервизора) и планировщик путешествий (координация через общее состояние).

Советы

Параллельное выполнение экономит больше времени, чем любая оптимизация. Четыре агента по 3 секунды каждый, работающие параллельно, всегда быстрее одного агента за 10 секунд.

Структурированный вывод от воркеров снижает стоимость синтеза. Не заставляйте воркеров возвращать прозу, которую супервизор должен парсить. Возвращайте JSON, который супервизор может объединить.

Начните с общего состояния, переходите на передачу сообщений только когда столкнётесь с конкретными проблемами, которые общее состояние не решает.

Логируйте всё первую неделю. Количество токенов, задержки, частоту ошибок по агентам. Быстро найдёте узкое место.

ЧаВо

Сколько агентов, прежде чем понадобится иерархический паттерн? Обычно около 10 воркеров. Ниже плоский супервизор справляется с координацией. Выше координаторы среднего уровня начинают окупаться.

Можно смешивать паттерны в одной системе? Да. Супервизор может координировать воркеров, которые внутри используют коммуникацию роя. Просто помните о добавляемой сложности.

Какая минимальная мультиагентная система? Два агента с общим состоянием. Один делает поиск, другой синтезирует. Всё. Докажите ценность, прежде чем добавлять сложность.

Как корректно обрабатывать сбои агентов? Таймауты на каждый вызов агента, запасные ответы из кэшированных результатов и режим деградации, работающий с частью агентов. Проектируйте под частичные отказы с первого дня.

Ресурсы

репозиторий motia-examples: продакшен-реализации мультиагентных систем
OpenAI Multi-Agent Cookbook: паттерны и примеры кода
Документация LangGraph: фреймворк для построения графов агентов