В каждой дорожной карте продукта есть пункт «AI Agent». Это слово звучит как прогресс. Оно сигнализирует руководству, что ваша команда строит будущее, а не просто поддерживает настоящее. Но вот неудобная правда, которую не покажут большинство демо-видео: агент — это самый дорогой и наименее предсказуемый способ выполнить задачу. Для большинства бизнес-задач это совершенно неподходящий инструмент. Лучшие инженеры — это не те, кто спешит его создать. Это те, кто знает, когда стоит остановиться.
Ловушка классификации
Понаблюдайте за тем, как команда планирует своего первого агента, и вы обычно увидите следующее. Приходит письмо в службу поддержки. Большая языковая модель читает тему и текст, решает, является ли это вопросом по оплате или техническим багом, и отправляет его в соответствующую очередь. Команда называет это агентом. Это не так.
То, что они создали — это детерминированный поток с одним вызовом модели внутри. Шаги фиксированы: принять письмо, вызвать модель, направить в очередь. Здесь нет цикла, нет использования инструментов, нет момента, когда система останавливается, чтобы пересмотреть свой план из-за неудачи первой попытки. Она не просматривает базу знаний, не пишет код и не проверяет статус заказа в процессе работы. Она принимает одно решение и идет дальше. Обертывание этого единственного вызова в микросервис не делает его агентом.
Реальная цена ошибки — принятия потока за агента — заключается не только в дополнительной инфраструктуре. Это недетерминированность, которую вы навлекаете без какой-либо выгоды. Одно и то же письмо может быть направлено по-разному утром во вторник и днем в среду, потому что температура (temperature) не равна нулю или промпт «дрейфует». Вы платите «агентскую» цену за задержки, стоимость токенов и накладные расходы на оценку, в то время как поток с одним шагом классификации решает проблему быстрее и дешевле.
Спускайтесь по лестнице
У большинства проблем есть более простые «родственники», которые решают их не хуже. Представьте это в виде лестницы и начинайте с нижней ступени.
Исправьте процесс. Иногда работа существует только потому, что две системы не согласованы. Запись клиента в вашей CRM не синхронизируется с платформой тикетов, поэтому каждое утро человеку приходится вручную устранять этот разрыв. Не автоматизируйте этот разрыв с помощью агента. Устраните его. Если бы конвейер данных (data pipeline) работал исправно, работа бы исчезла.
Используйте запрос. Если ответ — это простой поиск или агрегация, относитесь к этому именно так. «Сколько возвратов мы обработали в прошлый вторник?» не требует рассуждений. Ему нужен SQL. Агент, переводящий естественный язык в SQL, звучит элегантно, пока вы не поймете, что затраты на поддержку превышают написание трех документированных запросов, которые ваша команда запускает с дашборда.
Создайте детерминированный поток. Когда правила фиксированы, а результат повторяем, используйте явную логику. Если сумма заказа превышает порог, передайте задачу в финансовый отдел. Если пользователь не проявлял активности тридцать дней, отправьте письмо для повторного вовлечения. Код справляется с этим с нулевой вариативностью и полной наблюдаемостью. Его можно протестировать юнит-тестами. Вы не можете протестировать юнит-тестами «вайб».
Используйте поток с одним вызовом модели. Здесь место классификации, тегирования тональности или извлечения данных. Модель принимает одно решение внутри жесткого скрипта. Вы загружаете документ, извлекаете номер счета и записываете его в базу данных. Остальные шаги жестко закодированы. Модель не выбирает, что делать дальше; она только маркирует то, что видит. Это мощный паттерн, но это все еще поток.
Создавайте агента в последнюю очередь. Оставьте этот шаг для задач, где следующее действие действительно зависит от того, что модель обнаружит в процессе выполнения. Если системе нужно прочитать письмо, понять, что необходимо проверить статус отгрузки через API логистики, обнаружить, что отгрузка задерживается, и затем составить персонализированный ответ на основе этих свежих данных — вот тогда вы вступаете на территорию агентов. Путь нельзя проложить заранее, потому что модель сама решает, что делать после каждого нового факта.
Тест у маркерной доски
Есть быстрый способ разрешить спор на совещании. Попросите команду нарисовать ветви принятия решений на маркерной доске.
Если вы можете проложить каждый путь до запуска модели, стройте поток. Рисуйте ромбы, пишите операторы if, и дело сделано. Предсказуемость — это преимущество, а не ограничение.
Если сама модель должна решать, каким будет следующий шаг, если она выбирает инструмент, устанавливает параметры и возвращается назад, чтобы переосмыслить план, — тогда вам нужен агент. Эта динамическая маршрутизация и есть разделительная линия. Не переходите её случайно только потому, что вам захотелось использовать новый API.
Скрытый налог
В демо-роликах агенты выглядят бесшовными. В продакшене же проявляются четыре «налога», которые быстро накапливаются.
Недетерминированность. Тот же