Система ИИ-агентов: когда нужен не один

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

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

Здесь — вторая половина. Когда несколько агентов дают выигрыш, когда добавляют только стоимость, и по каким признакам это решается до разработки, а не после.

Что называют системой агентов

Начнём с определения, потому что термин используют широко и по-разному.

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

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

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

Как работа проходит через систему агентов

Запрособращение клиента или событие

Координаторразбирает и маршрутизирует

Агент-специалистсвоя роль и свои инструменты

Проверкаправила, лимиты, человек

Действиеответ, запись, документ

Один агент против нескольких

Сравнение по тем свойствам, которые видно в эксплуатации, а не в презентации.

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

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

Признаки, что одного агента не хватает

Четыре сигнала, по которым решение принимается честно, а не по моде.

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

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

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

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

Если ни один из четырёх признаков не про вас — вам нужен один агент. Это не упрощение ради экономии, а честный инженерный выбор: система, собранная без нужды, работает хуже.

Три схемы, которые встречаются в работе

Способов соединить агентов много, но в бизнес-задачах живут в основном три.

Конвейер. Шаги идут по прописанному маршруту: разобрать → проверить → оформить → уведомить. Каждый агент делает своё и передаёт дальше. Самая предсказуемая схема, легче всех отлаживается, покрывает большинство задач документооборота и обработки заявок.

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

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

Жёсткий маршрутРабочий выбор для бизнеса

• Порядок шагов задан заранее
• Стоимость запроса предсказуема
• Понятно, на каком шаге сбой
• Легко показать аудитору и клиенту
• Ограничен тем, что предусмотрели

Свободная оркестрацияДорого и трудно отлаживается

• Координатор сам решает порядок
• Стоимость запроса плавает
• Сбой воспроизводится не всегда
• Справляется с непредусмотренным
• Требует жёстких лимитов на шаги

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

Что стоит денег в системе агентов

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

Токены на каждый шаг. Один запрос пользователя в системе из четырёх агентов превращается в четыре и больше обращений к модели, и каждое тянет за собой контекст. У российских моделей цена посильная — младшая модель GigaChat стоит 65 ₽ за миллион токенов, старшая 650 ₽, — но множитель на число шагов надо закладывать честно.

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

Наблюдаемость. В системе из нескольких агентов ответ на вопрос «почему клиенту сказали такую цену» невозможен без логов каждого шага. Логи, их хранение и интерфейс для разбора — часть проекта, а не приятное дополнение.

Обработка отказов. Модель может не ответить, сервис — не отдать данные. В одном агенте это одна ветка обработки; в системе из пяти — пять, и каждая должна вести не в тишину, а к понятному действию.

Задержка. Четыре шага по несколько секунд превращаются в ощутимую паузу. Для фонового процесса это неважно, для живого диалога с клиентом критично — и часто именно задержка, а не деньги, ставит крест на красивой схеме.

Три системы, которые встречаются чаще других

Абстрактные схемы плохо помогают решать. Вот три конфигурации из практики — с указанием, чем оправдано деление на агентов.

Обработка входящих обращений. Первый агент определяет тему и срочность, второй ищет ответ в базе знаний компании, третий формулирует ответ клиенту, человек подтверждает спорное. Деление оправдано разными правами: агент-классификатор не имеет доступа к отправке, агент-поиск не умеет писать клиенту. Обычно вырастает из одного агента поддержки, когда обращения становятся разнородными.

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

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

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

Память: чем система отличается от набора запросов

Тема, которую в схемах рисуют одним квадратиком «Память», а в работе она определяет половину качества.

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

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

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

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

База знаний компании. Регламенты, прайсы, описания услуг. Это не память, а справочник: агент обращается к нему по необходимости, а не таскает целиком в контексте. Механику такого поиска разбирает статья про то, что такое RAG — она же объясняет, почему «загрузить все документы в модель» работает хуже, чем кажется.

Долгая память о клиенте. Что покупал, на что жаловался, о чём договорились в прошлый раз. Живёт не в модели, а в вашей CRM, и агент просто читает её как источник данных.

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

Чем такие системы собирают

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

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

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

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

Как понять, что система работает

Метрика «агенты запущены» ничего не говорит. Мерить стоит то, что связано с деньгами и временем.

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

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

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

Время прохождения. От поступления до результата. Автоматизация, которая отвечает за минуту вместо трёх часов, ценна даже при той же точности.

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

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

Право действия — главный вопрос безопасности

У агента в отличие от чат-бота есть возможность что-то сделать, и это меняет разговор о рисках. Ошибка бота — неправильный ответ. Ошибка агента — отправленное письмо, изменённый заказ, проведённый возврат.

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

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

Необратимое — через человека. Деньги, договоры, отмены, письма клиентам от лица компании. Агент готовит, человек подтверждает одним нажатием. Это не недоверие к технологии, а нормальная практика разделения ответственности.

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

Разделение прав по ролям. Агент, который читает, и агент, который меняет, — разные агенты с разными ключами доступа. Тогда ошибка в разборе запроса физически не может испортить данные.

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

Как проектировать: порядок, который работает

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

От процесса к системе, а не наоборот

1. 1
   Разложить процессшаги, данные, решения, участники — на бумаге
2. 2
   Найти узкое местогде уходит больше всего времени людей
3. 3
   Один агент под негоузкая задача, понятная инструкция
4. 4
   Месяц работыгде ошибается, чего не хватает
5. 5
   Второй агент — если упёрлисьпо признакам, а не по плану

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

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

Один агент. Под этот шаг, с ограниченными правами и понятной инструкцией. Запустить, посмотреть на реальном потоке.

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

Второй — по признакам. Из тех четырёх, что перечислены выше. Если ни один не сработал, второй агент не нужен, и это хороший исход.

Когда система агентов не нужна вообще

Отдельный список, потому что он экономит больше денег, чем любые советы по проектированию.

Решения принимаются по правилам. Если «если сумма больше N — на согласование, иначе провести», это не задача для модели. Обычная автоматизация справится дешевле, быстрее и без непредсказуемости. Это же относится к большинству задач вокруг автоматизации без нейросетей.

Данных нет в системах. Агенту нужно откуда-то брать факты. Если остатки, цены и статусы живут в головах и переписках, начинать надо с учёта, а не с ИИ.

Поток маленький. Десяток обращений в день человек обработает лучше и дешевле. Автоматизация окупается на объёме и на однообразии.

Цена ошибки очень высока, а проверить некому. Медицина, право, финансы в чувствительной части. Там ИИ работает помощником специалиста, а не автономной системой, и разница принципиальная.

Как система ведёт себя, когда что-то идёт не так

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

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

Агент ответил не в том формате. Следующий шаг ждёт структурированные данные, а получил свободный текст. Классическая поломка стыка, которая на демонстрации не видна, а на потоке случается регулярно. Лечится проверкой формата на каждом переходе.

Данные не пришли. Внешняя система не отдала остатки или расписание. Правильное поведение — сказать «не могу проверить наличие, уточню и вернусь», а не придумать ответ. Модель, оставленная без данных и без запрета, склонна заполнять пустоту правдоподобным вымыслом.

Цепочка зациклилась. Координатор гоняет задачу между агентами по кругу. Без лимита на число шагов это тратит деньги ровно до тех пор, пока кто-то не заметит. Лимит должен стоять всегда, даже в жёстком маршруте.

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

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

Сколько людей нужно, чтобы это поддерживать

Вопрос, который не задают при запуске и который определяет судьбу проекта через полгода.

Система агентов — не разовая поставка. У неё есть содержание, и оно складывается из четырёх занятий.

Чтение логов. Кто-то регулярно смотрит, где система ошиблась и что передала людям. Без этого качество тихо деградирует, а узнаёте вы об этом от клиента.

Правка инструкций. Меняются условия, услуги, правила — меняются и инструкции агентов. Работа не программиста, а того, кто знает предмет.

Обновление базы знаний. Документы, из которых система берёт факты, устаревают. Пересмотр раз в квартал — минимум для живого бизнеса.

Контроль расходов. Счёт за обращения к модели растёт вместе с потоком. Раз в месяц стоит смотреть, не изменилась ли стоимость одной задачи.

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

Что спросить у подрядчика

Если систему агентов вам предлагают, пять вопросов быстро показывают глубину проработки.

«Почему здесь несколько агентов, а не один?» Хороший ответ ссылается на конкретные признаки в вашем процессе. Плохой — на современность подхода.

«Сколько обращений к модели на один запрос пользователя?» Из этого числа считается месячный счёт. Если ответа нет, экономика проекта неизвестна.

«Какие действия агент может совершить сам?» Должен быть перечень, а не «работает с CRM».

«Что происходит, когда шаг падает?» Ответ должен описывать поведение, а не «такого не будет».

«Как я увижу, почему было принято такое решение?» Если логов по шагам нет, разбираться с претензией клиента будет не с чем.

Правильно устроенная система агентов — это не про число квадратиков на схеме, а про то, что каждый следующий агент добавлен по конкретной причине и его можно убрать, объяснив, что при этом сломается. Если такое объяснение есть по каждому — систему проектировали, а не рисовали.

Как это выглядит на конкретных задачах и во что обходится, разобрано на странице про разработку и внедрение ИИ-агентов.