Один агент на всё или рой узких: что дешевле в проде

Когда вы даёте одному агенту доступ к 40 инструментам, точность выбора нужного действия падает — это заметно на бенчмарках вроде ToolBench и в жалобах команд, которые строят агентов на GPT-4o или Claude. Модель начинает вызывать не тот инструмент, теряет контекст задачи и разбухает по токенам, потому что описания всех тулов лежат в системном промпте одновременно. Отсюда два лагеря: одни делают одного generalist-агента с гигантским набором функций, другие — рой узких single-skill агентов, каждый из которых умеет ровно одно. Разница между подходами — это не вкусовщина, а деньги на инференс, задержки и то, сколько вам придётся чинить по ночам.

Что стоит за терминами

Single-skill агент — это ЛЛМ-обвязка^*, заточенная под одну задачу: классификация обращения, поиск по базе знаний, генерация SQL, вызов одного внешнего API. У него узкий системный промпт, короткий список инструментов (часто один-два) и предсказуемый формат вывода.

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

^* ЛЛМ-обвязка (LLM wrapper) — код вокруг вызова модели: сборка промпта, парсинг ответа, вызов инструментов, ретраи. Сам агент — это модель плюс эта логика, а не отдельная «сущность».

Каждый лишний инструмент в промпте generalist-агента — это не бесплатная опция, а минус к точности выбора и плюс к счёту за токены на каждом запросе.

Где generalist ломается

Проблема не в том, что модель «глупая». Проблема в том, что выбор из одного действия среди сорока — это задача классификации, и вероятность ошибки растёт с числом кандидатов. К этому добавляется три эффекта.

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

Где ломается рой экспертов

Обратная крайность не бесплатна. Как только вы разбиваете систему на десять узких агентов, вам нужен оркестратор — маршрутизатор, который решает, кому передать запрос. Это ещё один вызов модели (или классификатор), ещё одна точка отказа и ещё один источник задержки.

• Латентность складывается. Маршрутизатор → эксперт → иногда второй эксперт — это три последовательных вызова вместо одного. На пользовательских сценариях каждая лишняя секунда заметна.
• Передача контекста. Между агентами надо аккуратно прокидывать состояние. Потеряли часть — эксперт получает обрезанную задачу и уверенно выдаёт неверный ответ.
• Операционные издержки. Десять промптов, десять наборов тестов, десять версий, которые надо катить и мониторить раздельно.

Сравнение по ключевым параметрам

Как выбрать под свою задачу

Ориентир простой: считайте число инструментов и разнородность доменов, а не следуйте моде на «мультиагентность».

1. До 5-7 инструментов одного домена — берите generalist. Дробить нечего, оркестратор добавит только задержку и точки отказа.
2. Инструменты из разных доменов (поддержка + аналитика + рассылки) — разбивайте по доменам, даже если внутри домена агент остаётся универсальным.
3. Есть класс запросов с высокой ценой ошибки (платежи, юридические ответы) — выносите его в отдельного узкого агента с жёстким промптом и своими тестами.
4. Замерьте базовую точность на реальных логах до рефакторинга. Если generalist уже даёт 90%+ на вашем трафике — разбивка может не окупить рост латентности.

Гибрид как норма

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

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

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