Разработка ИИ-агентов и мультиагентных систем: когда нужен один агент, а когда несколько

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

Четыре причины добавить агента

• Разные права. Агент, который читает входящие, не должен иметь права записи в учёт. Разделение ролей — это разделение учётных записей, и проверить его проще, чем «аккуратную инструкцию» одному агенту.
• Разные модели. Разбор документа может делать небольшая быстрая модель, а рассуждение по сложному случаю — более крупная. Тогда это два шага с разными моделями, и удобно, когда у каждого свой агент и своя оценка качества.
• Независимая проверка. Проверяющий с другой инструкцией и без права записи замечает то, что автор не видит. Он не гарантирует безошибочность, но ловит класс ошибок, который иначе доходит до клиента.
• Параллельная работа. Если задача раскладывается на независимые части (например, три документа читаются одновременно), агенты ускоряют работу, а результаты собирает один координатор.

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

Ошибки накапливаются по цепочке

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

Расход и задержка

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

Отладка

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

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

Когда берём библиотеку

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

Когда берём собственную обвязку

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

В любом варианте работу с моделью прячем за собственным интерфейсом. Тогда смена модели или библиотеки не потребует переписывать бизнес-логику. Облачный сервис трассировки производителя библиотеки для данных ограниченного доступа чаще не подходит по требованиям заказчика, поэтому трассы пишем в ваш журнал. Подробнее о выборе между частной моделью и внешним интерфейсом — в статье «Своя LLM или ChatGPT API».

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

Если работа в основном решается правилами, а модель нужна для разбора неструктурированного входа, выбирайте гибрид: код исполняет, модель размечает. Критерии собраны в статье «RPA или ИИ-агент». Для продаж есть отдельная страница: ИИ-агент для автоматизации продаж.