Оркестр агентов: Архитектура, память и экономика мультиагентных систем

Попытка натянуть академическую теорию 2000-х на современный оркестр LLM - это как пытаться заправить Теслу углем. Сегодняшний стандарт - это Schema Registry, семантический JSON и строгая валидация на выходе, а не многостраничные спецификации взаимодействий.

Рисунок. Архитектурная схема «Монолит против Оркестра»

Но есть нюанс: микросервисы - это не про «больше - значит лучше».

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

В мире ИИ то же самое. Multi-Agent System - это мощный паттерн, но он не бесплатен. Каждый новый агент добавляет:

- точку отказа (агент упал - часть пайплайна встала)

- накладные расходы на контекст (передача состояния между агентами)

- риск «бесконечного уточнения» (агенты переспрашивают друг друга)

Поэтому прежде чем строить рой агентов, ответьте на вопрос: «А можно ли решить задачу проще?»

Именно здесь Anthropic сформулировал лестницу сложности - практический инструмент, который помогает не превратить ваш ИИ-проект в распределённый кошмар на пустом месте.

1.3.5. Лестница сложности: когда вам действительно нужен оркестр

Не бросайтесь строить рой агентов только потому, что это модно. Anthropic сформулировал лестницу, которая экономит месяцы работы и сотни тысяч долларов на API.

Уровень 1: Промпт (Prompt)

Что это: Один запрос - один ответ. Без памяти, без инструментов, без циклов.

Когда использовать: Задача решается за один вызов LLM. Перевод текста, саммаризация, генерация письма по шаблону.

Живой пример: "Переведи этот договор на русский" - промпт, GPT-4o, готово. Не нужен агент. Не нужен оркестр. Не нужен Event Sourcing. Просто промпт.

Цена ошибки: Низкая. Если перевод кривой - перечитаете сами.

Уровень 2: Скилл (Skill)

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

Когда использовать: Вы ловите себя на том, что копируете один и тот же промпт из заметок. "Ага, вот этот промпт для анализа договоров - использую его каждую неделю." Значит, пора завернуть его в функцию с параметрами.

Живой пример: Анализ договора на риски. Вы делаете это каждую неделю. Вместо того чтобы каждый раз вставлять промпт на 500 слов, вы создаёте функцию analyze_contract(text, risk_types) с фиксированным промптом внутри. Это скилл.

Цена ошибки: Средняя. Если скилл сломался - вы заметите на втором-третьем использовании.

Уровень 3: Воркфлоу (Workflow)

Что это: Несколько зависимых шагов, где выход одного - вход другого. Нужна надёжность, потому что ошибка на шаге 2 ломает шаг 3.

Когда использовать: Задача требует последовательности действий с проверками. "Сначала извлеки данные, потом проверь их, потом сгенерируй отчёт."

Живой пример: Обработка заявки на возврат. Агент 1 извлекает номер заказа из письма. Агент 2 проверяет в базе, что заказ существует. Агент 3 рассчитывает сумму возврата. Агент 4 отправляет письмо клиенту. Если Агент 2 ошибся и сказал "заказа нет" - Агент 3 не должен считать сумму. Нужна валидация между шагами.

Цена ошибки: Высокая. Если воркфлоу сломался на шаге 3 - клиент получил неверную сумму возврата. Приходится откатывать всю цепочку.

Здесь появляется Event Sourcing (Глава 2.3) - чтобы откатывать состояние.

Уровень 4: Мульти-агент (Multi-Agent)

Что это: Шаги требуют полной изоляции друг от друга. Разные контексты, разные роли, разные модели. Агенты не знают о существовании друг друга - они общаются через шину данных.

Когда использовать: Задача настолько сложная, что один агент не может держать всё в голове без Context Pollution (Глава 1.1). Или когда разные части задачи требуют противоположных ролей (продавец vs юрист).

Живой пример: Департамент бизнес-аналитики. Агент-аналитик копается в данных (100 тысяч токенов SQL-запросов). Агент-юрист проверяет соответствие договору (50 тысяч токенов юридических текстов). Агент-писатель формулирует отчёт для директора (чистый контекст, только факты). Если скормить всё одному агенту - он утонет в контексте и начнёт галлюцинировать.

Цена ошибки: Критическая. Если агент-юрист пропустил пункт о неустойке - компания теряет миллионы. Нужен HITL (Глава 4.5), Circuit Breaker (Глава 3.4), полный Audit Trail (Глава 6.2).

Проблема: дорого или неработоспособно

На уровнях 3–4 у вас ровно два пути - и оба ведут в тупик:

1. GPT-4o/Claude Opus - надёжно, но невыносимо дорого. Воркфлоу из 10 шагов сжигает $5–10 за заявку. При 1000 заявок в день это $5000–10000 только на API. И вы платите эту цену вечно.

2. Дешёвые модели (Qwen2-7B, Llama-3-8B) - цена копеечная, но план из 10 шагов выполняется в 3–5% случаев. Они путают последовательность, игнорируют валидацию и проваливают критические проверки.

Классический выбор: либо бедные, но мёртвые, либо живые, но без денег.

Evoflux - это третий путь.

Как это связано с Evoflux

Evoflux - это эволюционный поиск во время инференса: агент генерирует план, пытается выполнить, получает обратную связь от инструментов и эволюционно правит план. Это не файн-тюнинг (который требует сотен примеров и ломается при изменении каталога инструментов). Это адаптация на лету. Для мультиагентной системы это значит: меньше падений, меньше перезапусков, меньше сожжённого бюджета.

Лестница говорит "когда", Evoflux говорит "как сделать дёшево на уровнях 3-4".

На уровнях 1-2 (промпт, скилл) вам не нужен Evoflux - задачи простые, дешёвые модели справляются.

На уровнях 3-4 (воркфлоу, мульти-агент) вы хотите использовать дешёвые модели (Qwen2-7B, Llama-3-8B), но они ломаются на сложных планах из 10+ шагов.

Классический подход: "Бери GPT-4o".

Evoflux говорит: "Подожди. Пусть дешёвая модель попробует, сломается, и эволюционно починит план на лету."

Результат: выполнимость растёт с 3% до 24%, а цена остаётся на уровне дешёвой модели.

Вывод: Evoflux это техника, которая делает уровни 3-4 экономически доступными. Без неё воркфлоу и мульти-агент системы разоряют бюджет на тяжёлых моделях. С ней - вы можете использовать дешёвые модели там, где раньше нужен был GPT-4o.

Микросервисы и оркестр агентов строятся на одном принципе: «разделяй и властвуй». Но как именно собрать из кусочков работающую систему? Введём главное понятие этой главы - оркестрацию.

1.4. Что такое Оркестрация?

Оркестрация в ИИ - это не просто «запуск нескольких агентов подряд». Это управление потоком данных, состоянием и ответственностью.

Метафора: симфонический оркестр

Дирижёр (Orchestrator) - не играет ни на одном инструменте. Его задача - видеть партитуру целиком и указывать, кто вступает сейчас.

Скрипки (Specialists) - виртуозны в своём узком деле, но не знают, что делают трубы.

Партитура (Workflow/State) - жёсткий или гибкий план.

Роли в ИИ-оркестре

Router (Маршрутизатор) - принимает запрос и решает, какой агент (или последовательность агентов) должен его обработать.

Agents (Исполнители) - выполняют узкую задачу. Их промпты короткие и сфокусированные.

Bus (Шина данных) - место, где агенты оставляют результаты.

Важно: они передают не просто текст, а структурированные данные.

Например, JSON (JavaScript Object Notation - текстовый формат, похожий на словарь с ключами и значениями, понятный любому языку программирования).

Supervisor (Координатор) - проверяет результат перед выдачей пользователю. Может отправить задачу на доработку.

Пример работы оркестратора

Пользователь пишет: «Найди в моей переписке все упоминания слова договор и отправь юристу краткое резюме».

Router видит слово «найди» (поиск) и «отправь юристу» (доставка) - решает, что сначала нужен Поисковый Агент, потом Агент-Составитель резюме.

Agents выполняют: первый ищет письма (возвращает JSON со списком), второй пишет резюме.

Bus - временное хранилище, где первый агент оставляет найденные письма.

Supervisor перед отправкой проверяет: «А есть ли там что-то конфиденциальное?» - если да, то не отправляет, а просит пользователя подтвердить.

Оркестратор не знает, как именно искать письма или писать резюме. Он только знает порядок шагов и правила перехода.

1.5. Паттерны оркестрации

Паттерн (от англ. pattern - образец) - это проверенная схема взаимодействия между агентами. Не изобретайте велосипед: в 90% задач работает один из трёх шаблонов, описанных ниже.

Паттерн А: Последовательная цепочка (Sequential Chain)

Схема: User Query -> Agent A (Извлечение) -> Agent B (Анализ) -> Agent C (Отчёт) -> User

Когда использовать

линейные процессы (ETL - извлечение, преобразование, загрузка; перевод текста и последующее форматирование).

Плюсы: просто отлаживать.

Минусы: нет возможности вернуться назад. Если Agent B ошибётся, Agent C сделает красивый отчёт на основе лжи.

Реальный пример

Взять Excel-файл с продажами (Агент А - извлечь данные), найти аномалии (Агент Б - статистический анализ), отправить отчёт в Telegram (Агент В - отправитель). Если Агент Б ошибётся и назовёт нормальные продажи аномалией, Агент В отправит ложную тревогу - и никто не вернётся назад.

Паттерн Б: Звезда с Центром (Supervisor / Hub-and-Spoke)

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

Когда использовать

сложные творческие или аналитические задачи, где нужен цикл обратной связи (написал проверил исправил).

Плюсы: гибкость. Supervisor может менять план на лету.

Минусы: Supervisor становится «узким горлышком». Он должен быть очень умной (и дорогой) моделью.

Пример

написать ответ на сложную жалобу клиента. Supervisor вызывает:

· агента «Эмпатия» (сгенерировать извинение),

· потом агента «Компенсация» (рассчитать скидку),

· потом агента «Юрист» (проверить, не нарушает ли это оферту).

Если юрист говорит «нарушает», Supervisor может отменить компенсацию и вызвать агента «Стандартный ответ».

Паттерн В: Рой (Swarm / Decentralized)

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

Когда использовать

Системы реального времени, мониторинг, трейдинг.

Плюсы: масштабируемость.

Минусы: хаос. Очень сложно отлаживать. Непонятно, кто виноват, если система приняла странное решение.

Паттерн Г: Агентские торги (Bidding)

Жесткий роутинг (Router -> Агент А) хорош, но не всегда экономичен. Что, если Агент А сейчас перегружен, а Агент Б свободен и стоит в два раза дешевле?

Как это работает

Оркестратор не назначает задачу, а «бросает клич» в шину данных. Специализированные агенты делают «ставку» (bid), указывая два параметра:

· Свою цену за выполнение (в токенах или условных единицах).

· Свой Confidence Score (уверенность в успехе, от 0 до 1).

Оркестратор выступает в роли аукциониста: он выбирает не обязательно «самого умного» агента, а того, кто предлагает лучший баланс цены и уверенности для этой конкретной задачи.

Когда использовать

Высоконагруженные системы, где критически важна оптимизация Cost Per Task.

Плюсы: Динамическая балансировка нагрузки и реальная экономия бюджета.

Минусы: Требует сложной логики оркестратора и задержку на «торги» (доли секунды).

Приведем теперь итоговую схему - инструмент для принятия решений

Рисунок. Выбор паттерна оркестрации

Используйте эту схему как чек-лист при проектировании: ответьте на три вопроса (линейность, взаимозависимость, критичность реального времени) - и получите готовый паттерн.

Задача линейная (ETL, перевод)? -> Sequential Chain

Нужен контроль и ветвление? -> Supervisor

Асинхронные события, высокая параллельность? -> Swarm

Важное предупреждение

Рой хорош для систем мониторинга - тысячи датчиков шлют события, каждый агент сам решает, реагировать или нет. Но представьте, что в чате поддержки 50 агентов начинают отвечать клиенту одновременно, перебивая друг друга, - и никто не может объяснить, почему клиенту начислили три скидки. Для 90% бизнес-задач начинайте с Supervisor или цепочки.

Паттерн выбран, агенты запущены. Но есть один нюанс, который убивает 80% оркестров на старте. Агенты не умеют читать мысли друг друга. И если они общаются текстом - жди беды.

1.6. Главная проблемаоркестрации: Шина данных (The Data Bus)

Самая частая ошибка новичков - попытка передать данные между агентами через обычный текст.

Плохой пример

Агент А пишет: «Ну, продажи выросли примерно на 10%, вроде бы неплохо, но в феврале был провал.»

Агент Б читает это и думает:

10% - это мало или много?

Какой именно февраль?

«Провал» - это на сколько процентов?

Агент Б галлюцинирует (придумывает несуществующие факты), пытаясь угадать контекст.

Хороший пример (Структурированная шина): Agent A возвращает JSON:

json

{

"metric": "sales_growth",

"value": 0.10,

"period": "2024-Q1",

"anomalies": [

{"month": "February", "deviation": -0.15, "reason": "holiday_shortage"}

],

"confidence": 0.95

}

Agent B получает этот JSON. Он точно знает значения. Он не гадает.

Правило номер 1 оркестрации

Агенты общаются на языке структур (JSON, XML, Pydantic-модели), а люди общаются с системой на языке текста.

JSON - это уже хорошо, но этого мало. В реальном проекте агенты пересылают гигабайты логов, истории диалогов, промежуточные выкладки. Контекст снова загрязняется. Нужна шина, которая умнее, чем просто «возьми и передай всё».

1.7. Умная шина: Передача тольконеобходимого (Selective Context Loading)

В наивной архитектуре агенты пересылают друг другу полные истории диалогов. Это дорого и шумно.

Решение: Шина как источник истины (Single Source of Truth)

Вместо передачи значений, мы передаем ссылки или запросы на данные.

Агент-Производитель

Сохраняет результат в Шину (Kafka Topic / Redis Key).

В Шину летит не только payload (сами данные), но и metadata (данные о данных: кто, когда, краткое содержание):

json

{

"message_id": "msg_555",

"payload_summary": {

"has_transaction_details": true,

"risk_level": "high"

},

"data_pointer": "kafka_topic_finance_results/partition_1/offset_999"

}

Агент-Потребитель

Получает сообщение. Смотрит на payload_summary.

Если ему нужно только risk_level, он берет его из заголовка. Токенов потрачено: ~10.

Если нужен полный анализ, он использует data_pointer, чтобы подтянуть полный payload из Шины только в этот момент.

Реализация на практике (пример для Kafka + Redis)

1. Агент-производитель пишет payload в Redis (TTL = 24 часа).

2. В Kafka отправляет только:

{

"topic": "task_results",

"key": "session_123",

"data_pointer": "redis://cache/task_555",

"payload_summary": {"risk_level": "high"}

}

3. Агент-потребитель:

- Если нужен только risk_level берёт из заголовка Kafka (0 токенов).

- Если нужны детали делает GET redis://cache/task_555.

Схематично

[Агент А] -> сохраняет полные данные -> Redis (хранилище)[Агент А] -> отправляет короткий указатель -> Kafka -> [Агент Б][Агент Б] -> если нужно детали -> GET Redis

Рисунок. Умная шина данных (техническая реализация)

Давайте соберём все компоненты вместе и проследим путь одного запроса от пользователя до финального ответа.

Рисунок. Сквозной жизненный цикл запроса в мультиагентной системе ИИ

Преимущества

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

Агент загружает в свой контекст только релевантные фрагменты.

Чистота контекста

Нет шума от предыдущих шагов.

Асинхронность

Агент-потребитель может начать работу, как только появятся критические данные.

Соберём всё, что мы узнали о монолите, оркестрации и шине данных, в короткий список выводов. А затем посмотрим, куда ведёт эта дорога - к проблемам памяти и состояния.

Резюме главы 1

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

Оркестрация - это разделение труда. Переход от монолита к микросервисам.

Есть три главных паттерна: Цепочка (для простых процессов), Supervisor (для сложных задач), Рой (для асинхронных событий). Начните с Supervisor.

Общайтесь структурами, а не текстом. Шина данных должна передавать JSON/объекты.

Используйте умную шину. Передавайте метаданные и указатели, а не весь контент сразу. Это экономит бюджет и повышает точность.

Но разделить задачи между агентами - полдела. Главная боль начинается, когда агентам нужно:

· Помнить, о чём говорили 10 шагов назад.

· Передать эстафету другому агенту без потери смысла.

· Не запутаться в 50 разных историях диалогов.

Именно этим - памяти и состоянию экосистемы - посвящена следующая глава.

ГЛАВА 2. ПАМЯТЬ ЭКОСИСТЕМЫ: ОТ KVCACHE ДО КОРПОРАТИВНОЙ ДОЛГОСРОЧНОЙ ПАМЯТИ

«Агент без памяти - это человек с амнезией. Он знает, как говорить, но забывает, что сказал минуту назад.»

В Книге 2 мы говорили о краткосрочной и долгосрочной памяти одного агента. В Книге 3 мы говорим о памяти системы.

2.1. Иерархия памяти враспределенной системе

Когда у вас 10 агентов работают над одной задачей, память перестаёт быть локальной проблемой одного агента. Она становится инфраструктурной - как дороги, водопровод и электричество для города.

У каждого типа памяти своя скорость, своя цена и свой срок годности. Мы выделяем четыре уровня. У каждого - свой SLA (Service Level Agreement - договорённость о том, как быстро и надёжно данные будут доставлены) и своя стоимость.

Рисунок. 4 уровня памяти в распределенной системе

Уровень 1: Горячая память (KV Cache & Session Store)

Почему «горячая», а не просто «оперативная»?

В классических серверах RAM - это общий пул быстрой памяти. В нашей иерархии «горячая память» - это два специализированных подвида:- KV Cache (в VRAM GPU), который хранит внутренние представления текущего диалога и привязан к конкретному инстансу модели.- Session Store (например, Redis) - общая оперативная память для текущих сессий агентов.Их объединяет скорость (наносекунды - микросекунды) и недолговечность (данные исчезают при перезапуске). Этим они отличаются от «тёплой» памяти (PostgreSQL, дни-недели) и «холодной» (S3, годы).

Где живёт: VRAM (видеопамять GPU - та самая, где модель держит текущий диалог), Redis (быстрое хранилище «ключ-значение» в оперативной памяти сервера). Оба этих хранилища мы называем «горячей» памятью, потому что они обеспечивают максимальную скорость доступа, но их содержимое не переживает перезапуск агента или сервиса.

Время жизни: миллисекунды - часы.

Что хранит: текущий диалог, промежуточные вычисления (например, «на втором шаге я получил сумму 1500 рублей»), активные инструменты (какие функции сейчас доступны агенту).

Цена доступа: почти нулевая - если данные уже в кэше (временном буфере), модель читает их мгновенно.

Риск: теряется при рестарте инстанса (если сервер перезагрузили - всё, горячая память пуста).

Инженерный совет (человеческим языком):

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