Мультиагентные системы: цифровой отдел вместо одного бота

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

Универсальный бот «обо всём» ломается на первом же нестандартном запросе: у него один набор инструкций на все случаи. Мультиагентная система устроена как команда — у каждого агента своя узкая зона ответственности и свой набор инструментов.

Чем это отличается от обычного чат-бота

Как выглядит связка на практике

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

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

Где человек остаётся в контуре

Мы намеренно оставляем точки согласования там, где ошибка стоит дорого: отправка денег, обязательства перед клиентом, изменение данных в учётной системе. Агент готовит решение, человек подтверждает одним действием. Это сохраняет скорость и снимает главный страх — «а если оно сделает что-то не то».

Сроки и стоимость

Мультиагентная система — от 800 000 ₽, срок 2-3 месяца, поэтапно. Начинаем всегда с аудита за 50 000 ₽: на нём становится понятно, нужна ли связка вообще или задача закрывается одним агентом за 200 000 ₽. Бывает и так, и мы об этом скажем.

Паттерны оркестрации в мультиагентных системах: как агенты делят работу

Оркестрация — это правило, по которому агенты делят работу: кто берёт задачу первым, что передаёт дальше, кто проверяет и когда процесс завершён. В мультиагентных системах для бизнеса схема важнее выбора модели или фреймворка. Мы берём самую простую схему, которая закрывает процесс, и усложняем только по названной причине. Основы разобраны в статье что такое мультиагентная система, контекст шире — в материале про agentic AI.

Код или модель в роли оркестратора. Если процесс рисуется блок-схемой, оркестратором служит обычный код: он предсказуем, дёшев и тестируется как любая программа. Оркестратор на модели нужен там, где путь зависит от содержания входа; он может перепланировать шаги на нестандартном случае, как сказано в таблице выше. Свободу мы ограничиваем: выбор только из разрешённых шагов и лимит числа шагов на задачу.

Схемы сочетаются: диспетчер на входе, конвейер внутри, проверяющий в конце, человек на критичном шаге. Иерархию из нескольких уровней мы закладываем редко: контекст теряется на каждом уровне, цена растёт, отладка усложняется. «Рой» агентов, которые сами договариваются о порядке, в рабочие процессы не закладываем: на момент подготовки материала это скорее эксперимент. Собирать связку можно на фреймворке или на своём коде, критерии — в статье про фреймворки для AI-агентов.

Роли агентов и разделение прав

Роль описывается одной фразой: «достаёт из письма номер заказа и срок поставки». Если у двух ролей одинаковые права и контекст и они просто идут друг за другом, это скорее два шага одного агента, чем два агента. Отдельного агента оправдывают различия в доступе к данным, в праве что-то менять, в независимости проверки, в модели или в изолированном контексте.

Права задаём учётными записями и набором инструментов, а не текстом инструкции: просьбу «не делай этого» модель способна нарушить, а закрытый доступ обойти нельзя. Агент, который читает чужие письма, может встретить в них текст, оформленный как команду. Разделение прав ограничивает ущерб, но угрозу не снимает, см. статью про безопасность AI-агентов. Критичное действие (деньги, обязательство, запись в учётную систему) выполняет обычная интеграция после подтверждения человека, см. человек в контуре.

Общее состояние и память между агентами

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

• Поля вместо пересказа: номер заказа, дата, причина, ссылка на фрагмент. Формат полей проверяет код, поэтому потери видны в журнале.
• У каждого поля один владелец. Если писать в поле могут двое, итог зависит от порядка их работы, а не от смысла.
• Каждому агенту только нужное: общий контекст «на всякий случай» удорожает каждое обращение к модели и открывает агенту лишние данные.

Память, которая живёт дольше одной задачи, — отдельный вопрос: кому разрешено в неё писать, иначе ошибка одного агента станет «знанием» для всех остальных. Варианты разобраны в статье про память AI-агента.

Как проверять качество связки, а не только отдельных агентов

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

1. Каждый агент на примерах своей роли. Проверяющему отдельно дают черновики с заведомой ошибкой: если он их пропускает, пользы от него нет.
2. Стыки. Что будет при пустом поле, неожиданном формате или отметке «не уверен». У каждой ситуации должен быть описанный исход.
3. Сквозной набор реальных задач от входа до результата. Критерий «правильно» согласуется до запуска и записывается в техническое задание.
4. Трудные и вредные входы: пустое обращение, противоречивые данные, недоступная система, чужая инструкция внутри текста.
5. Повторный прогон после любой правки инструкции или смены модели.

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

Сколько стоит сложность: токены, задержка и поддержка каждого агента

• Токены. Каждый агент получает свои инструкцию и контекст, поэтому обращений к модели больше, чем у одного агента. Расход снижают так: каждому только нужное, модель попроще на простых шагах, фильтр кодом до обращения к модели, кэширование повторяющихся частей запроса, если поставщик его даёт (проверяйте условия). Расчёт — в статье про обращения к модели.
• Задержка. Шаги конвейера складываются, параллельные ветки ждут самую медленную. Для заявки это обычно не важно, для живого разговора заметно.
• Поддержка. У каждого агента свои инструкция, тесты и версия. Изменилось правило — правим несколько инструкций; обновилась модель у поставщика — прогоняем набор заново, см. сопровождение агента.
• Время людей. Если решений на подтверждение больше, чем человек успевает смотреть, узким местом становится очередь.

Бюджет, как сказано выше: мультиагентная система — от 800 000 ₽, срок 2-3 месяца. Обращения к модели и, при установке в контуре, оборудование идут отдельной строкой и зависят от потока; считаем их на аудите по вашим объёмам.

Типичные сбои мультиагентной системы: циклы, накопление ошибок, конфликт действий — и защита

В связке ошибка рождается в одном месте, а проявляется в другом. Сбои, которые мы закладываем заранее:

• Цикл. Проверяющий возвращает черновик, исполнитель правит, и так по кругу, а счёт за модель растёт. Защита: лимит шагов и возвратов, таймаут, предел расхода; при превышении задача уходит человеку с историей.
• Накопление ошибок. Неточность раннего шага доезжает до конца, и каждый следующий агент достраивает ответ на ней. Защита: между шагами код проверяет формат и простые условия (номер существует, суммы сходятся), у вывода есть ссылка на источник, а отметка «не уверен» останавливает цепочку (самооценка модели ненадёжна, поэтому она лишь дополняет проверки кодом).
• Конфликт действий. Два агента меняют одну запись, или один пообещал клиенту одно, а другой записал другое. Защита: у каждой записи один владелец, изменения в учётных системах идут через одну интеграцию, повторный запуск шага не создаёт дубль, обязательство подтверждает человек.
• Недоступная система. Не ответила 1С, поставщик модели вернул ошибку. Защита: таймауты, ограниченное число повторов, состояние «задача ждёт» и ручной режим.

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

Пример архитектуры сквозного процесса

Это иллюстрация, а не описание проекта заказчика: «претензия клиента по заказу — от обращения до решения». Реальная схема зависит от ваших систем и цены ошибки.

1. Диспетчер на коде по каналу и теме определяет, что это претензия; неясное уходит человеку. Разборщик без прав на запись достаёт поля: номер заказа, суть, просьбу клиента, цитату-источник.
2. Исследователь, только чтение: история заказа из учётной системы и пункты условий возврата из базы знаний со ссылкой на источник. Письма целиком и контактов клиента не видит.
3. Исполнитель готовит черновик ответа и предложение: замена, возврат или отказ с обоснованием. Это предложение, а не действие.
4. Проверяющий и код. Код сверяет номер заказа, суммы и даты с учётной системой; проверяющий на модели смотрит, отвечает ли черновик на просьбу клиента и нет ли в нём обязательств, которых нет в условиях.
5. Менеджер видит поля, источники, черновик и отметки о расхождениях и подтверждает, правит или отклоняет. После этого обычная интеграция отправляет ответ и создаёт задачу в учётной системе.

Управляемой схему делают карточка со сквозным номером, лимиты шагов и расходов, журнал с версиями инструкций, выход «не уверен» на любом шаге и тестовый набор из реальных претензий. Маршрут задан кодом, поэтому оркестратора на модели нет. И оговорка: если претензий немного и менеджер всё равно читает каждую, такая цепочка избыточна: хватит одного агента с тремя инструментами.

Когда мультиагентная система не нужна

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

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

Критерии с разбором на примере — в статье один агент или несколько: когда нужна мультиагентная система; нужна ли автоматизация вообще — в материале когда AI-агент не нужен. Порядок такой: экспресс-аудит — 50 000 ₽, 5-7 рабочих дней, сумма засчитывается в проект; он показывает, сколько агентов нужно процессу. Если хватит одного, начинаем с пилота на одном процессе — от 200 000 ₽, 3-4 недели (разработка AI-агентов), а второго добавляем, когда причина названа и подтверждена замером. Ответ «хватит одного» — тоже результат аудита.