Несколько агентов вместо одного оправданы, когда задача распадается на части с разными инструментами и разными правами, а не когда она просто большая. Разделение ради «специализации» без такой границы почти всегда ухудшает результат: растут стоимость, задержка и сложность отладки, а качество не меняется. Начинать нужно с одного агента и делить его, только упёршись в конкретное ограничение.
Что даёт разделение
Разные права. Агент, читающий документы, и агент, меняющий данные в CRM, могут иметь разный доступ. Это единственная причина, работающая безусловно: она конструктивно ограничивает ущерб.
Меньше инструментов на каждого. При десятках инструментов качество выбора падает — модель путает похожие. Разделение возвращает каждому агенту обозримый набор.
Разные модели под разную цену. Простую классификацию делает дешёвая модель, сложное рассуждение — дорогая. На большом потоке экономия заметна.
Независимая замена частей. Один агент можно переписать, не трогая остальных, — если между ними определён контракт.
Чем платить
Стоимость растёт. Каждая передача между агентами — это новый запрос с новым контекстом. Задача, решаемая одним агентом за пять обращений, у трёх агентов легко превращается в пятнадцать.
Задержка растёт. Агенты обычно работают последовательно, и время складывается.
Отладка усложняется непропорционально. Найти, на каком шаге одного агента произошла ошибка, — задача решаемая. Найти, какой из трёх агентов неверно понял результат предыдущего, — заметно сложнее.
Появляется потеря контекста на стыках. Второй агент видит не всё, что видел первый, а только переданное. Половина ошибок мультиагентных систем — здесь.
Основные схемы
Конвейер
Агенты идут последовательно: разбор → проверка → действие. Каждый делает свою часть и передаёт результат дальше.
Подходит, когда этапы действительно разные по инструментам. Просто устроен, предсказуем по стоимости. Слабое место — ошибка на раннем этапе распространяется дальше и обнаруживается в конце.
Диспетчер и исполнители
Главный агент определяет тип задачи и передаёт профильному исполнителю. Исполнители друг о друге не знают.
Подходит для потока разнородных задач: обращения по продажам, по поддержке, по документам. Диспетчер должен быть простым — его задача классификация, а не рассуждение; часто для него достаточно дешёвой модели.
Исполнитель и проверяющий
Один агент делает работу, второй проверяет результат по критериям и возвращает на доработку.
Оправдано там, где цена ошибки высока, а проверка формализуема. Стоимость примерно удваивается, поэтому применяется точечно — например, к юридически значимым текстам, а не ко всем ответам подряд.
| Схема | Когда подходит | Основной риск |
|---|---|---|
| Конвейер | этапы с разными инструментами | ранняя ошибка идёт до конца |
| Диспетчер | поток разнородных задач | ошибка классификации уводит всю задачу |
| Проверяющий | высокая цена ошибки | двойная стоимость |
Когда одного агента достаточно
Признаки того, что делить рано:
- инструментов меньше десятка и они не путаются;
- все шаги требуют одних и тех же прав;
- задача укладывается в разумное число шагов;
- нет требований к разной стоимости на разных этапах.
Практическое правило: сначала довести до работы одного агента, потом делить по обнаруженной границе. Разделение, спроектированное заранее «на вырост», обычно проходит не по тем швам — реальные границы видны только после эксплуатации.
Что ломается на практике
- Потеря контекста на передаче. Второй агент не знает деталей, которые первый счёл неважными. Лечится явным контрактом: что именно передаётся, в каком формате, что обязательно.
- Взаимное зацикливание. Исполнитель и проверяющий гоняют задачу по кругу. Нужен жёсткий лимит итераций — см. «Зацикливание ИИ-агента».
- Размытая ответственность. При ошибке непонятно, какой агент виноват. Помогает журналирование входа и выхода каждого агента.
- Диспетчер слишком умный. Если он начинает рассуждать, а не классифицировать, система теряет предсказуемость и дорожает.
- Разделение по ролям вместо инструментов. «Агент-аналитик», «агент-редактор», «агент-критик» звучат осмысленно, но если у них одни и те же инструменты и права, это один агент, разбитый на три запроса, — дороже без выигрыша.
Последний пункт — самая частая ошибка. Граница должна проходить по инструментам и правам, а не по названиям профессий.
Как считать стоимость
Стоимость мультиагентной системы — не сумма стоимостей агентов. Добавляется контекст, который передаётся между ними, и повторные обращения при доработках.
Практический ориентир: прежде чем делить, оцените, во сколько обращений превратится одна задача. Если одноагентная схема укладывается в пять, а трёхагентная — в пятнадцать, разделение должно давать втрое больше пользы, а не просто «выглядеть архитектурнее». Методика расчёта — в статье «Стоимость эксплуатации ИИ-агента».
Разбор: одна задача в двух схемах
Задача: обработать обращение клиента — определить тип, найти данные в CRM, подготовить ответ.
Схема А. Один агент, пять инструментов.
```
шаг 1 классифицировать обращение → тип: вопрос по заказу
шаг 2 найти клиента → найден
шаг 3 найти заказ → найден
шаг 4 найти ответ в базе знаний → найден
шаг 5 сформулировать ответ → готово
итого: 5 обращений
```
Контекст растёт от шага к шагу, но история одна и передаётся целиком.
Схема Б. Три агента: диспетчер, поисковик данных, составитель ответа.
```
диспетчер: шаг 1 классифицировать → тип: вопрос по заказу
(передаёт задачу дальше)
поисковик: шаг 2 прочитать постановку → понял задачу
шаг 3 найти клиента → найден
шаг 4 найти заказ → найден
(передаёт результат дальше)
составитель: шаг 5 прочитать переданное → понял контекст
шаг 6 найти ответ в базе → найден
шаг 7 сформулировать → готово
итого: 7 обращений
```
Обращений стало больше на два — это шаги, где новый агент разбирается в том, что передал предыдущий. Плюс каждая передача несёт свой контекст: инструкцию нового агента, описания его инструментов, переданные данные.
Что мы получили за эту наценку. В данном случае — ничего. У всех трёх агентов одни и те же права (чтение CRM и базы знаний), одна и та же цена ошибки. Деление прошло по ролям, а не по полномочиям, — это и есть самая частая ошибка.
Когда та же схема оправдана. Если составитель ответа получает право отправлять письмо клиенту, картина меняется: у него появляется полномочие, которого нет у остальных. Тогда разделение ограничивает ущерб конструктивно — поисковик при любой ошибке ничего не отправит, потому что физически не может.
Проверочный вопрос перед делением: отличаются ли у частей права доступа. Если нет — вы получите ту же работу дороже.
Частые вопросы
Когда нужна мультиагентная система?
Когда задача распадается на части с разными инструментами и разными правами доступа. Например, чтение документов и изменение данных в учётной системе — это разные полномочия, и разделение конструктивно ограничивает ущерб. Если у всех частей одни инструменты и права, разделение только удорожает решение.
Сколько агентов оптимально?
Столько, сколько реальных границ по правам и инструментам, — обычно два-три. Большее число почти всегда означает, что деление прошло по ролям, а не по полномочиям. Начинать следует с одного и делить по обнаруженной в эксплуатации границе, а не по заранее нарисованной схеме.
Мультиагентная система работает лучше одного агента?
Не по умолчанию. Она лучше там, где нужны разные права или разные модели по цене; в остальных случаях качество то же, а стоимость, задержка и сложность отладки выше. Улучшение даёт схема с проверяющим агентом, но она примерно удваивает стоимость и применяется точечно.
Почему агенты теряют контекст при передаче?
Второй агент видит только то, что передал первый, а не всю историю. Если контракт передачи не определён явно, первый агент отбрасывает детали, которые счёл неважными, а второму они оказываются нужны. Лечится строгим форматом передачи: какие поля обязательны и что означает каждое.
Как отлаживать мультиагентную систему?
Журналировать вход и выход каждого агента отдельно, включая выбранные инструменты и их результаты. Без этого при ошибке невозможно понять, какой агент неверно понял предыдущего. Полезно уметь запускать каждого агента изолированно на сохранённом входе — тогда ошибку можно воспроизвести без всей цепочки.
Что дальше
Как агенты вызывают инструменты — «Function calling», как их стандартизовать между решениями — «MCP». Что передаётся между шагами и как это хранится — «Память ИИ-агента». Как ограничить последствия ошибок — «Ограничение действий».
Проектирование архитектуры под конкретный процесс — часть работ по разработке и внедрению ИИ-агента.