ИИ-агент
Если обычный ассистент просто отвечает на сообщение, агент — это система, которая решает задачу. Между запросом пользователя и финальным ответом он может сделать несколько шагов и обратиться к разным инструментам.
Из чего состоит агент
- LLM-«мозг» — модель, которая выбирает следующий шаг.
- Набор инструментов — функции, которые агент может вызывать: поиск, базы данных, API, выполнение кода.
- Память — что было сделано в этой задаче и в предыдущих сессиях.
- Планировщик — иногда отдельный модуль, иногда тот же LLM в специальном режиме.
Типичные сценарии
- Аналитика: «собери данные из CRM, посчитай конверсию по сегментам и пришли отчёт».
- Поддержка: «открой тикет в Jira, добавь скриншот, ответь клиенту».
- Программирование: «исправь эту ошибку, проверь тестами, открой пулл-реквест».
- Кросс-системная автоматизация: запросы из почты в CRM, оттуда в платежи и обратно.
Где пока сложно
- Длинные многошаговые задачи — модели часто теряют контекст или зацикливаются.
- Обеспечение безопасности: агент с доступом к реальным системам — серьёзная зона риска.
- Оценка качества и отладка — поведение агента сильно зависит от случайности и формулировок.
Когда применять и когда нет
Применять
- Задача требует нескольких шагов и вызова разных систем
- Хочется снять с человека рутину, в которой 80% решений однотипны
- Есть понятные правила и метрика «получилось/не получилось»
Не применять
- Цена ошибки очень высока и нет права на нестабильное поведение
- Задачу проще решить детерминированным пайплайном без LLM
- Не настроены права доступа и безопасность к системам, в которые агент будет ходить
Примеры применения
Команда поддержки запускает агента, который при поступлении нового тикета сам ищет похожие закрытые тикеты, читает связанную документацию, формирует черновик ответа и прикладывает ссылку на нужный раздел. Окончательный ответ всё ещё отправляет человек — но он экономит 5–10 минут на каждый тикет и реже допускает ошибки.
Часто задаваемые вопросы
Чат-бот отвечает на сообщение и обычно не выходит за пределы диалога. Агент решает задачу: он может задавать уточняющие вопросы, обращаться к базе данных, вызывать внешние API, повторять шаги, пока не получит результат. На уровне архитектуры это разница между «один запрос — один ответ» и «многошаговый процесс с инструментами».
Можно, но это требует отдельной работы: ограниченные права доступа, отдельные сервисные учётки, аудит каждого действия, обязательные подтверждения для критичных операций. Безопасность агентов — отдельная инженерная задача, и пускать модель сразу в продакшн без этих ограничений — плохая идея.