Не каждой автоматизации нужен ИИ-агент

Короткий ответ. Агента берите там, где вы не можете описать шаги заранее. Где можете, берите обычный процесс. Большинство бизнес-задач как раз такие, и агент в них покупает вам непредсказуемость за большие деньги.

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

Разница принципиальная, потому что это разные виды софта. Процесс на одинаковом входе всегда делает одно и то же. Агент решает, что делать, а значит, на том же входе завтра он может пойти другим путём. В этом весь смысл агента, и в этом же вся его цена.

Когда лучше обычный процесс?

Всегда, когда шаги можно записать.

Если человек в компании способен описать процесс нумерованным списком с условиями, то этот список и есть техзадание. Закодировать его быстрее, чем написать промпт. Он выполняется за миллисекунды, а не за секунды, стоит ноль за запуск, а когда ломается, вы получаете трассировку с номером строки.

Таких задач больше, чем принято думать. Направить заявку по источнику и сумме. Выставить счёт, когда сделка закрылась. Напомнить про документ, который не пришёл за три дня. Свести две системы, которые разошлись в карточке клиента. Предупредить, что лицензия истекает через месяц. Шаги везде известны заранее, и ни одна из этих задач не станет лучше оттого, что выбор сделает модель.

Проверьте так. Отдайте процесс толковому новичку вместе с чек-листом на одну страницу. Будет ли он делать это правильно каждый раз? Значит, это обычный процесс.

По каким трём признакам видно, что агент лишний?

Результат должен лечь в готовую форму. Счёт, запись в календаре, поле в CRM, строка в реестре. Когда ответ обязан попасть в схему, вы просите модель сделать то, что шаблон уже делает, только теперь она может ошибиться.

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

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

Сколько на самом деле стоит агент?

Не токены. Токены – самая дешёвая часть.

Настоящая цена в том, что систему больше нельзя понять, прочитав её. Что сделает процесс, написано в коде. Что сделает агент, зависит сразу от промпта, версии модели, набора инструментов и того, что именно пришло на вход в тот день. Когда он выкинет что-то неожиданное, вы будете воспроизводить сбой отдельным проектом.

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

И есть человеческая цена. Кто-то должен смотреть, что агент сделал. Если проверка занимает столько же, сколько сама задача, автоматизация не убрала работу, а переложила её.

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

Всё это не аргумент против агентов. Это аргумент за то, чтобы использовать их там, где они окупаются.

Где агент действительно окупается?

Там, где шаги правда нельзя перечислить заранее.

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

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

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

Как решить до начала разработки?

Три вопроса о процессе, именно в таком порядке.

Можно ли записать шаги? Если да, запишите и дальше не читайте. Ничего ниже к вам не относится.

Какой единственный шаг вы не можете описать? Обычно он именно один, и обычно это задача чтения или классификации. Этот шаг и есть ваш агент. Всё слева и справа от него – обычный процесс.

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

Системы, которые живут в проде, скучные почти везде и умные ровно в одном месте. Те, что переписывают через полгода, были умными везде.