Почему большинство ИИ-агентов не доживают до продакшена — или долго там не задерживаются (2026)

Этот диалог или похожий за последние пару был в жизни каждого разработчика, который участвует в планировании задач продукта. За последний год понимание того, как может выглядеть конечный результат внедрения ИИ в рабочие задачи продукта, у большинства «хотящих ИИ» специалистов улучшилось, но всё ещё недостаточно.

В головах многих «хотящих ИИ» специалистов успешная интеграция — это, как правило, магическая кнопка или чат, в котором живёт бот вроде Джарвиса из фильмов про Железного Человека, у более продвинутых это n8n-like воркфлоу, умно вкрученный в процессы продукта. К сожалению, очень часто на этом планирование успешной интеграции заканчивается.

С другой стороны мы всё ещё разрабатываемый «классические» (без ИИ) программные продукты и фичи. И в разработке этих продуктов основные принципы планирования успешной интеграции никуда не делись, всё ещё команды расписывают сложнейшие технчиские задания, user-stories и прочие документы, регламентирующие работу продукта или фичи.

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

Первым делом нужно избавиться от этого представления. Изучите, как работают LLM, расскажите своим коллегам и «хотящим ИИ» специалистам, как работают LLM и крупные продукты, на них построенные, — пускай LLM станут для вас более детермированными. После такого погружения любому захочется составить полное техническое задание, где описано успешное внедрение, и ограничить бесконечную силу этой волшебной коробки.

А именно:

• программирование
• переписка
• работа с большими объёмами текста
• поиск
• преобразование между форматами
• генерация черновиков и рекомендаций
• исполнение длинных и однотипных процессов

Обратите внимание, что «принятия решений» среди этих задач нет. Принятие решение должно быть детермированным и предсказуемым, ИИ тут лучше не использовать автономно.

Как мы выяснили в предыдущем пункте, ИИ-агенты должны иметь ограниченный набор фич (от 1 до 3), в этой связи для сложных процессов нужно объединять несколько агентов вместе. Лидеры индустрии и блогеры продвигают такую заманчивую вещь, как оркестрацию ИИ-агентов. Имеется ввиду, что совместно через правильно настроенную оркестрацию ваши ИИ-агенты будут работать автономно и давать результат.

Оркестрация — действительно перспективная штука, но если вы используете ИИ-агентов как вспомогательный инструмент в вашем бизнесе, а не главный продукт, по статусу на июнь 2026 года не стоит бежать вперёд паровоза и пытаться использовать этот инструмент любой ценой. Экспериментировать для развития навыков специалистов и культуры команды — отлично, интеграция в бизнес-процессы любой ценой — в июне 2026 года плохо. ИИ-агент и люди в качестве оркестраторов — это сейчас самый оптимальный уровень автономности. Когда крупные корпорации или специализированные команды доработают свои решения, ваша команда возьмёт уже готовые решения и принципы, чтобы адаптировать под себя.

Сегодня ИИ-агенты должны иметь ограниченную автономность, их работа должна строиться на запросах пользователей агенту или на понятных триггерах: работа по расписанию, создание заказа в системе и т. д.

Если оркестрацию можно организовать через человека или уже отработанные принципы, то вот передача контекста — это задача напорядок сложнее. Передача контекста в ИИ-агента означает качественную передачу данных, требуемых LLM (или другой нейронной сети) для качественного ответа. Здесь во всей красе проявляются проблемы нейроннок, как чёрных ящиков. Если не передавать в используемую вами нейронку достаточно контекста, её ответы не будут полезными.

Технически проблем нет. Крупные вендоры предоставляют достаточный набор инструментов для передачи контекста: fine-tuning, RAG, правила написания промптов. Проблема смысловая. Какие именно данные передавать или использовать в каждом конкретном кейсе? Как их агрегировать? Как распределять веса?

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

Команде разработки нужно тесно сотрудничать в этом вопросе с людьми, кто на данный момент имеет контекст, который планируется передать в нейронку. Этих специалистов нужно погрузить в принципы работы доступных инструментов: fine-tuning, RAG и т. д., и совместными усилиями разработать план, какие данные из контекста должны передаваться или использоваться в вашем будущем агенте.

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

Тестированием в этой статье называется авто-тестирование, то есть создание инфраструктуры автоматической проверки всей функциональности продукта с помощью заранее написанных сценариев и проверок.

Очень много программных продуктов сегодня не тестируют, не смотря на то, что детермированные системы тестировать легче тестировать, чем ИИ-агентов. Этот общий вайб отсутствия тестов приводит к тому, что тестирование ИИ-агентов ещё более редкий кейс из-за сложности.

Если мы учтём всё вышесказанное, а именно ограниченный набор фич, описание значительного числа кейсов использования и ограничений, главной технической проблемой в тестировании становятся:

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

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

Тем не менее я бы рассмотрел для любой команды использование реальной продакшн модели в тестировании. Просто запуск этих тестов должен происходить ни в каждом PRе или коммите, а реже, например, без деплоем на продакшн. Проверить хотя бы раз каждый важный кейс использования с реальной моделью выйдет дешевле, чем потери после неправильных ответов на продакшне.

Проверка результатов — это вторая составляющая сложности тестирования агентов. Даже если вы используете мокинг на одном из этапов, писать тесты, в которых происходит просто посимвольное сравнение текста глупо. Тест должен проверить смысл ответа. Для проверки ответов существует два базовых подхода:

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

Такой матчер возвращает коэффициент совпадения, разработчик выбирает порог совпадения для конкретного теста. Совпадение выше порога — тест считается успешным.

Самый дешёвый и бесплатный с точки зрения использования LLM вариант — векторизированное сравнение. Вариант, который я использую в своих пет-проектах, векторизуем каждое слово в `result` и каждое слово в ожидаемом тексте. Сравниваем каждое слово с каждым, находим медианный коэффициент для каждого слова, а потом медианный коэффициент между словами. Сравнием медианный коэффициент с порогом. У этого подхода есть масса недостатков, начиная от принципов расчёта общего коэффициента для всей фразы (медианный не всегда подходит, надо ещё количество слов сравнивать), заканчивая подбором верного порога для каждого теста. Но как я написал выше, это бесплатный вариант, так что над ним надо попотеть как следует.

Так же сложен, как и тестирование. Если сбор данных с пользователей, мониторинг используемых ресурсов LLM и другие стандартные технические задачи мониторинга очевидны. В этом плане ИИ-агент мало чем отличается от «классического» продукта, то как ответить на Главный Вопрос Жизни, Вселенной и Всего Такого: «разумно ли ведёт себя агент?». А на этот вопрос ответить нужно, и далеко не факт, что он будет 42.

Как быть? Придумывать новые метрики? Сложные семантические оценки и анализ? Да, можно, но это всё безумно дорого, и если вы дочитали до этого момента, значит скорее всего, вы работаете над продуктом, который не имеет ресурсов на разработку такого в 2026 году. Позже возможно появятся общие принципы мониторинга и ответа на Вопрос.

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

Давайте использовать методы, успешно протестированные на людях! ИИ-агент чаще всего выполняет работу, которую до него выполнял человек. А для работы людей в разных индустриях и на разных должностях давным-давно придумали KPI. У программистов свои KPI, в колл-центрах свои KPI, на швейных фабриках — свои. Да, люди не любят KPI, но мнение машин по поводу KPI мы пока не знаем. Так что в 2026 году можете смело брать готовые практики KPI для людей, и адаптировать их для работы вашего ИИ-агента. Эта задача не является технически сложной, так как в вашем продукте уже разработанные KPI — полдела сделано. А если KPI нет, создавать их или нет — это вопрос не к этой статье.

Это типы задач, которые обязательно должны быть в вашем роадмапе при разработке ИИ-агента в 2026 году. Приходите в 2027 году, скорее всего материал этой статьи изменится где-то на 20-25%