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