Узкий агент против универсального: почему я всегда выбираю первое

Распространённое заблуждение

Когда люди впервые знакомятся с AI-агентами, им нравится идея одного умного помощника который делает всё. Отвечает клиентам, продаёт, ведёт календарь, создаёт задачи, пишет отчёты.

Это красиво выглядит в презентациях. В продакшене это работает плохо.

Почему универсальные агенты ломаются

Контекстное окно. У LLM ограниченный объём информации который он может обработать за раз. Если ты пытаешься дать ему инструкции по 20 разным задачам, набор правил по продажам, по поддержке, по календарю, по CRM, по отчётам, это просто не помещается или помещается плохо. Модель теряется в инструкциях.

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

Отладка. Когда что-то сломалось, непонятно в какой задаче. Все сценарии переплетены в один промпт, ты правишь одно и ломаешь другое.

Метрики. Как померить универсального агента? Он и продаёт и поддерживает. Одна метрика их не покрывает, а отдельные метрики сложно связать с единым промптом.

Что значит "узкий агент"

Агент который делает одну вещь и делает её хорошо. Пример: агент который только отвечает на вопросы по продуктам. Только квалифицирует лидов. Только обрабатывает возвраты.

У него маленький промпт с фокусированными инструкциями. Своя база знаний для своей задачи. Свои метрики. Свои логи.

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

Почему это работает лучше

Каждый узкий агент можно отладить независимо. Я могу переработать сценарий продаж не трогая поддержку. Могу обновить базу знаний поддержки не задевая CRM-интеграцию.

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

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

Команда клиента понимает структуру. "Это агент А, он отвечает за FAQ. Это агент Б, он записывает на приём". Просто объяснить, просто контролировать.

Практический пример

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

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

Диспетчер на входе спрашивает "по какой теме вопрос" и направляет. Если диспетчер не уверен, спрашивает клиента уточняющий вопрос.

Качество ответов выросло на четверть по внутренней оценке. Время на обновление сценариев упало в три раза. Клиент доволен.

Исключения из правила

Бывают задачи где универсальность важна. Например, бот-секретарь одного руководителя который работает только на него. Там объём невелик, задач мало, всё хорошо умещается в одном промпте. Тут дробить избыточно.

Но в 90% клиентских проектов где есть реальный поток обращений, узкие агенты выигрывают.

Что делать тебе

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

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

Хочешь разобрать твою архитектуру и решить где стоит дробить, пиши в t.me/kulmashev.