ИИ-агенты в компании: что работает, а что пока хайп

Слово «агент» за последние пару лет растянули до неузнаваемости. Им называют и чат-бота с одной кнопкой, и систему, которая сама планирует работу на неделю. Чтобы говорить предметно, договоримся о смысле: агент — это языковая модель, которая не просто отвечает текстом, а вызывает инструменты. Ищет в базе, читает тикет, запрашивает метрики, создаёт задачу — и по результату решает, что делать дальше.

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

Общее правило: чем уже задача, тем лучше результат

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

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

Сценарий 1. Разбор входящих заявок

Что делает. Читает новое обращение в поддержку или сервис-деск, определяет категорию и срочность, вытаскивает ключевые данные (номер договора, модель оборудования, адрес), проверяет, нет ли похожих открытых заявок, и назначает на нужную группу. Иногда — предлагает черновик ответа.

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

Что важно:

• начинать с режима подсказки — агент предлагает категорию, человек подтверждает одним кликом. Через пару недель видно, где он ошибается, и можно переводить часть категорий в автоматический режим;
• держать понятный список категорий. Если люди сами путаются, к какой группе относится заявка, модель тоже будет путаться;
• не давать агенту закрывать заявки и отправлять ответы клиенту без проверки, пока не накоплена статистика.

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

Сценарий 2. Помощник по базе знаний

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

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

Что важно:

• обязательно показывать источник каждого ответа;
• учитывать права доступа к документам на уровне поиска;
• назначить владельца базы знаний — человека, который отвечает за актуальность документов. Без него качество деградирует за несколько месяцев;
• собирать вопросы, на которые помощник ответить не смог. Это лучший список того, чего не хватает в документации.

Сценарий 3. Мониторинг с объяснением инцидентов

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

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

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

Что важно:

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

Сценарий 4. Аналитика по учётной системе

Что делает. Позволяет задавать вопросы к данным обычным языком: «какая выручка по региону за прошлый квартал», «какие клиенты не платили больше двух месяцев». Агент переводит вопрос в запрос к базе или отчёту, выполняет его и объясняет результат.

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

• схема данных сложная, а названия таблиц и полей не говорят ничего человеку со стороны;
• одно и то же понятие считается по-разному в разных отделах — что такое «выручка», с НДС или без, по отгрузке или по оплате;
• запрос выдал число, которое выглядит правдоподобно, но посчитано неверно, и никто этого не заметил.

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

Что важно:

• давать агенту не всю базу, а подготовленные витрины или представления с понятными названиями и описанием каждого поля;
• зафиксировать определения ключевых метрик и включить их в инструкции агента;
• показывать пользователю сам запрос или логику расчёта, а не только итоговую цифру;
• доступ к данным — только на чтение и только в пределах прав пользователя.

Где пока хайп

Несколько типов обещаний, к которым стоит относиться осторожно:

• «Цифровой сотрудник, который заменит отдел». Агенты хорошо снимают рутинные операции, но не заменяют людей, которые понимают контекст, договариваются и несут ответственность.
• «Агент сам разберётся, какие инструменты нужны». Чем больше инструментов, тем чаще модель выбирает не тот. Десяток хорошо описанных инструментов лучше сотни.
• «Полностью автономная работа без контроля». Для действий с последствиями — деньги, клиенты, продуктив — человек в контуре пока обязателен.
• «Внедрим за неделю». Прототип — да. Рабочую систему с логированием, правами доступа, тестами и поддержкой — нет.

Как запускать

Схема, которая работает почти для любого сценария:

1. Выберите процесс с большим объёмом однотипных операций и понятным результатом.
2. Опишите, что сейчас делает человек, по шагам.
3. Запустите агента в режиме подсказки: он предлагает, человек решает.
4. Логируйте каждое действие и каждое решение агента.
5. Через несколько недель посмотрите статистику ошибок и переведите в автоматический режим только то, где агент стабильно точен.

Медленно, зато результат держится, а не рассыпается после первого месяца.