Слово «агент» стало модным настолько, что им называют любой чат-бот с парой кнопок. Разница между ними при этом принципиальная и лежит не в интеллекте, а в правах: бот отвечает, агент действует. Разберем, что агент реально умеет в корпоративных системах, где проходят границы и что обязательно предусмотреть до того, как давать ему доступ на запись.
Отвечать и действовать — разные задачи
Чат-бот получает вопрос и возвращает ответ. Цикл замкнут: он ничего не меняет, и худшее, что может случиться, — неверный ответ. Агент планирует последовательность шагов, вызывает функции ваших систем, оценивает результат и решает, что делать дальше. Он создает записи, меняет статусы, запускает процессы.
Отсюда главное следствие: цена ошибки другая. Неверный ответ бота человек может перепроверить. Неверное действие агента придется отменять — а иногда его уже нельзя отменить.
Что агент делает хорошо
Переносит данные между системами
Взять данные из письма, найти контрагента в CRM, создать заявку, приложить документ, уведомить ответственного. Рутина, которая сейчас занимает часы у людей и не требует суждения.
Выполняет регламентные последовательности
Процессы вида «если условие, то шаги А, Б, В, иначе Г» — с проверками и ветвлениями. Агент отличается от обычной автоматизации тем, что справляется с нечеткими входами: письмо, написанное в свободной форме, для скрипта непреодолимо, для агента — обычный вход.
Собирает информацию из нескольких источников
«Подготовь сводку по клиенту» — история сделок из CRM, задолженность из учетной системы, открытые обращения из поддержки. Каждый источник по отдельности доступен и человеку, но сведение занимает время.
Обрабатывает входящий поток
Классификация обращений, определение срочности, маршрутизация, черновик ответа для типовых случаев. Разгружает первую линию, оставляя ей то, что требует решения.
Где границы
- Решения с существенными последствиями. Согласование крупной суммы, отказ клиенту, увольнение — здесь агент готовит, человек решает. Не только из-за рисков, но и потому, что за такие решения кто-то должен отвечать персонально.
- Действия, которые нельзя отменить. Отправка письма контрагенту, платеж, публикация. Все необратимое — только с подтверждением.
- Процессы без четких правил. Если два ваших специалиста поступают в одной ситуации по-разному, агент не сможет вывести правило из воздуха. Сначала регламент, потом автоматизация.
- Задачи, где нужен доступ к тому, чего нет в системах. Агент не знает того, что живет в головах и переписке в мессенджерах.
Полезное правило при проектировании: агент получает право на запись только там, где действие обратимо или подтверждается человеком. Все остальное он готовит, но не выполняет. Это ограничение снимает большую часть возражений службы безопасности и почти не уменьшает пользу.
Что обязательно предусмотреть
Права по минимуму
Агенту выдается отдельная учетная запись с правами ровно на то, что ему нужно, и ни на шаг больше. Не «как у администратора, чтобы работало», а перечень конкретных операций. Это тот случай, когда удобство на старте оборачивается разбирательством потом.
Журнал всех действий
Что сделал, когда, по какому запросу, на основании каких данных. Без журнала невозможно разобрать ни одну спорную ситуацию, а они будут. Это первое, что спросит служба безопасности, и правильно спросит.
Подтверждение на критичных шагах
Человек в контуре не на каждом действии — иначе теряется смысл, — а на тех, где ошибка дорога. Список таких шагов составляется вместе с владельцем процесса до разработки.
Поведение при отказе смежной системы
CRM недоступна, API вернул ошибку, документ не сохранился. Агент должен остановиться и сообщить, а не продолжать выполнение с половиной данных. Незавершенная последовательность хуже невыполненной.
Ограничение на объем
Лимит на число операций в единицу времени. Агент, ушедший в цикл, способен создать тысячу заявок быстрее, чем кто-то это заметит. Ограничитель стоит копейки и однажды окупается целиком.
Порядок внедрения
- Выберите один процесс с четким регламентом и понятной ценой ошибки. Не самый заметный, а самый описанный.
- Начните с режима «только чтение»: агент готовит действие и показывает его человеку, но не выполняет. Так вы увидите качество решений без риска.
- Дайте права на запись на обратимых операциях — создание черновика, назначение ответственного, смена внутреннего статуса.
- Расширяйте права на необратимые действия, только когда накопится статистика, и с подтверждением человеком.
- Отслеживайте долю действий, которые человек исправил. Ее рост — сигнал, что процесс изменился и агента надо перенастраивать.
Реалистичные ожидания
Агент не заменяет сотрудника целиком — он забирает механическую часть его работы. Это меняет структуру рабочего дня, а не численность: человек перестает переносить данные и начинает разбирать то, что требует решения.
И еще одно: агент не спасает сломанный процесс. Если регламент противоречив, а данные в системах неполные, автоматизация ускорит воспроизведение этих проблем. Разумная последовательность — сначала навести порядок в процессе, потом автоматизировать, а не наоборот.
Как агент устроен внутри
Понимание конструкции помогает оценить, где границы возможного, и не покупать магию.
У агента есть три части. Первая — набор доступных ему операций: прочитать сделку из CRM, создать заявку, отправить уведомление. Это обычные вызовы ваших систем, описанные так, чтобы модель могла определить, что каждый из них делает и какие параметры нужны.
Вторая — цикл принятия решений: модель получает задачу, выбирает следующий шаг, вызывает операцию, видит результат и решает, что делать дальше. Именно этот цикл отличает агента от бота: он не отвечает одним ходом, а работает до достижения цели или до остановки.
Третья — ограничители: что нельзя делать, сколько шагов максимум, что требует подтверждения, когда остановиться и позвать человека. Эта часть в демонстрациях обычно отсутствует, и именно она определяет, можно ли выпускать агента в рабочую систему.
Практический вывод: качество агента определяется не столько моделью, сколько тем, насколько аккуратно описаны доступные операции и ограничители. Расплывчатое описание операции приводит к тому, что модель вызывает ее не вовремя и не с теми параметрами, — и это не проблема модели.
С каких процессов обычно начинают
Есть несколько типовых сценариев, которые хорошо ложатся на агента и при этом безопасны на старте.
- Обработка входящей почты: разобрать письмо, определить тип, найти контрагента, создать или обновить запись, уведомить ответственного. Массово, механически, обратимо.
- Подготовка сводки перед встречей или звонком: собрать данные о клиенте из нескольких систем в один документ. Только чтение — риска почти нет. Близкая задача — отчет по вопросу на русском: модель пишет запрос, а цифры считает база.
- Первичная обработка заявок: классификация, проверка полноты данных, запрос недостающего, маршрутизация. Разгружает первую линию.
- Регламентная сверка: сопоставить документы между системами, найти расхождения, сформировать список для разбора. Агент готовит, человек решает.
- Оформление типовых внутренних заявок: справка, отпуск, доступ. Ограниченный набор действий с понятным маршрутом согласования.
Общих черт у этих сценариев три: много механической работы, четкий регламент и обратимость. Начинать с процесса, где нет регламента, бессмысленно — сначала регламент, потом автоматизация.
Сколько это стоит и когда окупается
Основные затраты в агентских проектах — не модель, а описание операций и интеграции. Каждая система, к которой агент обращается, требует настройки доступа, описания операций и обработки отказов.
Отсюда практическое следствие для оценки: считать надо по числу систем и операций, а не по числу сценариев. Агент, работающий с одной системой в пяти сценариях, дешевле агента, который делает одно действие, но в четырех системах.
Окупаемость считается как в любом проекте автоматизации: сколько времени сейчас уходит на эту работу, какую долю агент забирает, что остается людям и сколько стоит владение. Разница с обычной автоматизацией в том, что агент справляется с нечеткими входами — и потому берет те случаи, которые скрипт не осилил бы. Именно эта доля и есть источник выгоды.
Что проверить перед запуском
- Список операций с правами: что именно агент может делать в каждой системе и почему ему это нужно.
- Перечень действий, требующих подтверждения человеком, согласованный с владельцем процесса.
- Поведение при отказе смежной системы: останавливается и сообщает, а не продолжает с половиной данных.
- Лимит операций в единицу времени и механизм экстренной остановки.
- Журнал действий с возможностью восстановить, что и почему было сделано.
- Процедура разбора: кто смотрит на действия, которые человек исправил, и с какой периодичностью.
Последний пункт часто пропускают, а он дает больше всего. Доля действий, которые пришлось исправлять, — главная метрика качества агента. Ее рост означает, что процесс изменился или агент столкнулся с новым классом ситуаций, и разбираться надо сразу, а не когда накопятся жалобы.
Чем агент отличается от обычной автоматизации
Резонный вопрос: многое из описанного делается скриптами и настройками бизнес-процессов без всякого ИИ. Разберем, где проходит граница, потому что от этого зависит, нужен ли вам агент вообще.
Обычная автоматизация работает, когда вход структурирован и правила известны заранее. Пришел документ определенного формата — выполнить последовательность действий. Такие процессы автоматизируются надежнее и дешевле без ИИ, и предлагать сюда агента — значит усложнять решенную задачу.
Агент нужен там, где вход нечеткий. Письмо, написанное человеком в свободной форме. Обращение, которое может относиться к пяти разным процессам. Документ, форма которого заранее неизвестна. Здесь скрипт требует перечислить все варианты, а их невозможно перечислить, — и именно это ограничение агент снимает.
Практическое следствие для проектирования: разумное решение обычно гибридное. Агент разбирает нечеткий вход и определяет, что это за случай, а дальше управление передается обычному процессу с жесткими правилами. Так вы получаете гибкость там, где она нужна, и предсказуемость там, где она важнее.
Обратная проверка тоже полезна: если для вашей задачи легко написать полный перечень правил, агент не нужен. Правила будут дешевле, быстрее и надежнее, а главное — их поведение полностью предсказуемо, что для корпоративных систем часто ценнее гибкости.
Как тестировать агента
Проверка агента сложнее проверки бота: результат — не текст, а последовательность действий, и вариантов ее развития много. Нужен свой подход.
Основа — тестовый контур, полная копия систем, где агент может действовать без последствий. Это обязательное требование, а не пожелание: отлаживать агента, имеющего право на запись, в рабочей системе нельзя. Развертывание такого контура иногда оказывается самой долгой частью подготовки, и начинать его надо заранее.
Дальше собирается набор сценариев с известным правильным исходом: вот такое письмо должно привести вот к такой последовательности действий. Проверяется не только конечный результат, но и путь: агент, пришедший к верному итогу через десять лишних вызовов, работает, но дорого и медленно.
Отдельно тестируются отказы. Что произойдет, если система недоступна, если данных нет, если пришел вход, не соответствующий ни одному сценарию, если задача в принципе невыполнима? Правильное поведение во всех этих случаях — остановиться и сообщить. Агент, который в непонятной ситуации продолжает действовать, опаснее агента, который ошибается предсказуемо.
Коротко
- Бот отвечает, агент действует — отсюда принципиально разная цена ошибки.
- Хорошо работает на переносе данных, регламентных последовательностях, сборе информации и обработке входящего потока.
- Границы: существенные решения, необратимые действия, процессы без четких правил.
- Обязательны минимальные права, журнал действий, подтверждение на критичных шагах, корректный отказ и лимит на объем операций.
- Начинать надо с режима «только чтение» и обратимых операций, расширяя права по накопленной статистике.