ИИ-агент

Зачем это знать

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

Что такое ИИ-агент простыми словами

Вы просите заказать обед на двенадцать человек к часу дня, бюджет — шесть тысяч рублей. Справочная служба пришлёт список ресторанов с телефонами. Помощник откроет сайт доставки, сравнит меню, оформит заказ, оплатит картой компании и пришлёт вам номер заказа.

Чат-бот работает как справочная. ИИ-агент — как помощник.

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

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

Как это работает

1. Цель формулируют словами. «Обед на двенадцать человек, доставка к 13:00, до 6 000 ₽». Задан результат и границы, а порядок шагов агент придумывает сам.
2. Агент делает первый шаг. Открывает сайт доставки — это вызов инструмента. Инструментом называют любую функцию, которую агенту разрешили: поиск в интернете, чтение почты, запрос в вашу базу, отправка формы.
3. Смотрит на результат и решает, что дальше. Ресторан не везёт к часу — агент возвращается к списку и берёт следующий. Круг «действие → результат → следующее действие» повторяется, пока задача не закрыта.
4. Останавливается. Цель достигнута, либо кончился отведённый лимит шагов, либо чего-то не хватает — тогда агент передаёт задачу человеку.
5. Отчитывается: номер заказа, сумма, перечень того, что сделано.

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

Пример из практики

Сервисная компания принимала заявки на ремонт по электронной почте: около 1 200 писем в месяц. Разбор одного письма занимал 5–7 минут — замер по 80 письмам за две недели. Диспетчер читал текст, определял объект, заводил заявку в учётной системе, назначал мастера.

Агента запустили в режиме черновика: он готовил заявку, а создавал её диспетчер нажатием кнопки. За первые две недели из 430 черновиков 27 оказались неверными, чаще всего агент путал филиалы с похожими адресами. Ему выдали справочник филиалов, и доля ошибок опустилась до 4 на 500 заявок. После этого заведение заявок отдали агенту полностью, а назначение мастера оставили диспетчеру.

Проверка одной заявки занимает около минуты вместо шести. На объёме 1 200 писем это примерно 100 часов диспетчерского времени в месяц — расчётом, по замерам до и после.

Что это даёт бизнесу

• Задача закрывается целиком. Обычная автоматизация справляется, пока шаги одинаковые. Агент разбирает и нестандартные случаи: письмо от нового поставщика, непривычную формулировку, пропущенное поле. Часть таких случаев он всё равно вернёт человеку, и это штатный режим.
• Экономию можно посчитать заранее. Формула простая: сколько минут занимает операция сейчас, сколько минут останется на проверку, умножить на объём за месяц. Если разница меньше стоимости работы сотрудника за то же время, проект окупается — это и есть порог, с которого стоит считать.
• Риском управляют настройками. Право на необратимое действие выдают отдельно и по одному. Пока агент работает в черновике, его ошибка стоит минуты чужого времени на исправление.
• Видно, где именно ломается процесс. Журнал шагов показывает, на каком месте агент застревает. Обычно это места, где спотыкались и люди, просто раньше этого никто не считал.

Когда без этого можно обойтись

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

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

И там, где ошибку не откатить — платежи, отправка клиентам, юридически значимые документы, — агента оставляют в режиме черновика надолго. Выигрыш в скорости там меньше, чем цена одного неверно ушедшего документа.

Что важно проверить

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

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

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