Несколько агентов вместо одного нужны тогда, когда внутри процесса реально существуют разные роли: разные источники данных, разные права доступа или разные ответственные в компании. Во всех остальных случаях деление добавляет задержку, счёт и точки отказа, не давая взамен ничего, кроме красивой схемы в презентации подрядчика.
Слово «мультиагентная система» в коммерческих предложениях обычно означает одно из двух. Либо в сервисе живут несколько разных инструкций, которые по очереди подставляются в один и тот же вызов модели, — это не несколько агентов, а один агент с набором режимов. Либо это действительно отдельные компоненты со своими правами и своими источниками — и тогда у них есть цена, которую надо увидеть в смете.
Ниже — шесть признаков, по которым решение принимается за десять минут, расчёт цены деления на потоке 4 000 обращений в месяц и разбор двух вещей, которые в схеме из нескольких агентов забывают заложить чаще всего: маршрутизации и сквозного журнала.
Что на самом деле стоит за словом «несколько агентов»
Агент — это связка из модели, базы знаний, набора инструментов и правил; состав мы разбирали в статье про то, из чего состоит ИИ-агент. Два агента — это две такие связки, у каждой свой набор инструментов и свои права. Если инструменты и права одни и те же, а различается только текст инструкции, перед вами один агент, и делить в нём нечего.
Компонент, который решает, какому агенту передать задачу, и собирает итоговый ответ из того, что вернули исполнители. Может быть реализован правилами (по каналу, теме, типу документа, правам пользователя) или ещё одним вызовом модели. Что спросить у подрядчика: «по какому признаку оркестратор выбирает исполнителя и что попадает в журнал при каждом выборе».
Простая проверка на входе: попросите нарисовать схему и подписать на каждой стрелке, что именно передаётся и какие права нужны получателю. Если на всех стрелках оказывается один и тот же набор данных и одни и те же права, схема нарисована для презентации.
Три признака, при которых деление оправдано
| Признак | Как выглядит в жизни | Что было бы без деления |
|---|---|---|
| Разные источники данных | Один агент работает с базой знаний поддержки, второй — с остатками и ценами в учётной системе | Один поиск по смешанной базе даёт ответы про товар из регламента отпусков |
| Разные права доступа | Агент для клиентов читает только публичные данные, внутренний — видит себестоимость и договоры | Либо клиентский агент получает лишние права, либо внутренний теряет нужные |
| Разные владельцы процесса | За тексты для клиентов отвечает руководитель поддержки, за складские действия — начальник склада | Изменение правил одним владельцем ломает работу другого без предупреждения |
Второй признак — самый весомый и единственный, который нельзя обойти настройкой. Права выдаются учётной записи, а не абзацу в инструкции: если клиентскому контуру и внутреннему нужен разный доступ к учётной системе, это две технические учётные записи и, значит, два агента. Это же требование обычно возникает и в омниканальных контурах, где обращения из разных каналов приходят в одну ленту, — состав такой сборки мы вынесли на страницу омниканального ассистента.
Карта связей. Слева узел «Обращение», от него стрелка к узлу «Оркестратор (правила: канал, тема, права)». От оркестратора три стрелки к узлам «Агент поддержки — база знаний, только чтение», «Агент по заказам — учётная система, чтение и запись в пределах лимитов», «Внутренний агент — договоры и себестоимость, доступ только сотрудникам». Внизу сквозная линия «журнал: один идентификатор обращения через все шаги». На каждой стрелке подписано, что передаётся. Чертёжный стиль, подписи по-русски.
Три признака, при которых это усложнение
- Одна база знаний на всех. Если и «агент по тарифам», и «агент по доставке» ищут в одном и том же наборе документов, вы платите за три вызова модели там, где хватало одного поиска с фильтром по разделу.
- Один процесс и один ответственный. Разделение по темам внутри одного отдела не даёт ничего: тот же человек правит те же тексты, но теперь в трёх местах, и рано или поздно они разъезжаются.
- Деление ради «специализации промптов». Аргумент «узкая инструкция работает точнее» справедлив, но решается он не отдельными сервисами, а подстановкой нужного блока правил в один вызов. Точность та же, задержка и счёт — прежние.
«Что сломается, если завтра свести всё в одного агента?» Внятный ответ звучит так: «клиентский контур получит доступ к себестоимости» или «складские действия окажутся под правилами, которые пишет поддержка». Ответ «станет менее гибко» или «модель будет хуже понимать контекст» означает, что деление сделано без причины и его можно убрать вместе с его стоимостью.
Цена деления в рублях и секундах
Переменная часть одного текстового обращения в нашей модельной экономике — 3,2 ₽: вызов модели 2,2 ₽, векторный поиск 0,7 ₽, запись в журнал 0,3 ₽. Полный разбор удельной стоимости со всеми постоянными расходами лежит в материале про стоимость одного обращения; здесь нас интересует только та часть, которая умножается на число шагов.
Задержка растёт быстрее счёта, и это чаще становится причиной провала. Одиночный агент отвечает примерно за 2,5 секунды вместе с поиском. Три последовательных вызова плюс переходы между ними дают около 7,5 секунды. В переписке с клиентом это разница между «отвечает» и «завис»: часть людей за это время успевает написать второе сообщение, и диалог рассыпается. Если деление всё-таки нужно, лечится это не сокращением шагов, а честным индикатором «печатает» и параллельным, а не последовательным вызовом там, где шаги не зависят друг от друга.
Парная диаграмма из двух блоков. Левый блок «Стоимость обращения»: столбцы 3,2 ₽ (один агент) и 8,9 ₽ (три роли), подпись «+22 800 ₽/мес на потоке 4 000». Правый блок «Задержка ответа»: столбцы 2,5 с и 7,5 с. Под обоими блоками общая подпись: «регресс-набор с 40 до 110 примеров». Оси подписаны, все надписи по-русски.
Две вещи, которые забывают заложить: маршрутизация и журнал
В сметах подробно расписаны сами агенты и почти никогда — то, что их связывает. А ломается проект именно здесь: на выборе исполнителя и на разборе случая, когда выбор оказался неверным.
Соблазн понятен: пусть модель сама решает, кому передать задачу. На практике это худший из возможных вариантов оркестратора. Выбор модели невоспроизводим — на одном и том же обращении она может выбрать разных исполнителей; он необъясним — в журнале остаётся результат, но не причина; и он платный — это лишний вызов на каждом обращении.
- 1По каналу и типу отправителя. Клиент из чата — клиентский агент, сотрудник из внутреннего интерфейса — внутренний. Это одно условие и ноль вызовов модели.
- 2По правам пользователя. Если у обратившегося нет доступа к себестоимости, к агенту с этим доступом задача не уходит вообще — независимо от формулировки вопроса.
- 3По ключевым признакам темы. Номер заказа в тексте, вложенный документ, название раздела — детерминированные признаки, которые закрывают большую часть маршрутизации.
- 4Остаток — одной моделью, но с обязательным запасным путём. Всё, что не разобралось правилами, уходит на классификацию моделью; при низкой уверенности — к человеку, а не к случайному агенту. Сама идея разделения потока на детерминированный слой и модель разобрана подробнее в статье про гибридную архитектуру.
Вторая позиция — журнал, и это момент, ради которого стоит читать эту статью до подписания сметы. Клиент получил неверный ответ. В схеме из одного агента разбор занимает минуты: есть запрос, найденный источник, ответ. В схеме из трёх ролей нужно понять, кто из троих ошибся, и это возможно только при одном условии: у обращения есть сквозной идентификатор, который проставляется на входе и попадает в каждую запись журнала на каждом шаге.
Если каждый компонент пишет свой журнал со своей нумерацией, восстановление цепочки одного обращения делается сопоставлением меток времени вручную. На потоке в несколько тысяч обращений в месяц это часы работы вместо минут — и именно поэтому такой разбор перестают делать через месяц после запуска. Строку «сквозной идентификатор обращения во всех журналах» имеет смысл вносить в техническое задание отдельным пунктом, а не надеяться, что она подразумевается.
Один номер, который присваивается обращению на входе и попадает в каждую запись журнала на каждом шаге: у маршрутизатора, у исполнителя, у сборщика ответа. Позволяет собрать всю цепочку одним запросом вместо ручного сопоставления по времени. Что спросить у подрядчика: «покажите журнал одного случайного обращения за прошлую неделю целиком — от входа до отправленного ответа».
Схема-лента из четырёх записей журнала, идущих слева направо: «14:02 маршрутизатор — выбран агент по заказам, причина: номер заказа в тексте», «14:02 агент по заказам — найден заказ, статус получен», «14:03 сборщик — ответ собран, источник указан», «14:03 отправлено клиенту». Через все четыре записи проходит горизонтальная линия с подписью «идентификатор обращения A-4192». Сбоку пометка «разбор одного случая — 3 минуты». Чертёжный стиль, подписи по-русски.
Когда деление точно не нужно
Список ситуаций, в которых схему из нескольких агентов стоит свернуть в одну ещё на этапе обсуждения, короткий и почти всегда узнаваемый.
- Поток меньше 1 000 обращений в месяц. Разовые 140 000 ₽ на оркестратор и сквозной журнал здесь не вернутся ничем: экономии от специализации на таком объёме просто нет.
- Все данные лежат в одной системе и доступны одному кругу людей. Тогда различаются только формулировки, а это настройка, а не архитектура.
- Ответ нужен быстро. Живой чат с клиентом плохо переносит семь с половиной секунд; если деление неизбежно, шаги придётся распараллелить, и это ещё одна статья работ.
- Некому разбирать сигналы. Три агента — это три места, где что-то может пойти не так. Если человека, который на это смотрит, в компании нет, лишние компоненты просто накопят необнаруженных ошибок.
Разумный порядок такой: сначала один агент с одной базой знаний и одним набором прав, три месяца эксплуатации и журнал. По журналу становится видно, где обращения действительно требуют другого источника или других прав, — и вот тогда деление делается по факту, на одну роль за раз, а не сразу на пять. Правильные вопросы к перечню интеграций, которые понадобятся каждой роли, мы собрали на странице интеграций.
Каждый дополнительный агент — это не новая возможность, а новая передача. Считать надо передачи, а не роли.
