Почему пилоты AI-агентов застревают и не доходят до продакшена

Осенью 2025 года разговор про AI-агентов сместился с восторга на счёт. Внутренние пилоты, которые год назад показывали инвесторам и совету директоров, чаще всего живут в статусе «эксперимента» и не переходят в постоянную эксплуатацию. Причина не в том, что модели слабые — GPT-, Claude- и Gemini-класса модели уже умеют вызывать инструменты и держать длинные цепочки шагов. Проблема в разрыве между красивой демонстрацией на трёх заготовленных кейсах и живым процессом, где вход мусорный, шагов сотни, а ошибка стоит денег.

Что вообще считают «агентом» и почему это важно для разбора

Под агентом* здесь понимается система на базе языковой модели, которая не просто отвечает текстом, а планирует шаги, вызывает внешние инструменты (API, поиск, базы, действия в интерфейсе) и сама решает, когда задача выполнена. От чат-бота её отличает автономность: между запросом и результатом может быть десяток вызовов, которых человек не видит.

Именно эта автономность и создаёт основную боль масштабирования. Чат-бот, который ошибся, выдал неверный ответ — пользователь его перечитал и отбросил. Агент, который ошибся, мог оформить возврат, отправить письмо клиенту или изменить запись в системе. Цена ошибки перестаёт быть текстовой.

Где именно ломается путь от пилота к масштабу

Провалы редко выглядят как громкий сбой. Чаще это тихое «давайте пока оставим на ручном режиме». Типовые точки обрыва повторяются от компании к компании.

1. Демо собирали на удобных данных

Пилот показывают на аккуратных запросах: понятный вопрос, чистый документ, один язык. В проде на вход прилетают опечатки, вложенные PDF со сканами, смешанные формулировки и запросы, которых в тестах не было. Точность, которая на демо выглядела как «почти всегда правильно», на реальном потоке падает — и падает незаметно, пока кто-то не посчитает.

2. Накопление ошибки на длинных цепочках

Если один шаг агента выполняется верно в 95% случаев, то цепочка из десяти таких шагов доходит до конца без ошибки примерно в 60% случаев (0.95 в десятой степени). Двадцать шагов — уже около 36%. Математика простая и беспощадная: чем автономнее агент, тем длиннее цепочка и тем сильнее множатся мелкие погрешности. Демо на трёх шагах этого не показывает.

3. Нет владельца процесса и метрики успеха

Пилот часто запускает команда инноваций или подрядчик. Когда доходит до эксплуатации, выясняется, что нет ответственного отдела, нет SLA, нет метрики «сколько задач агент закрыл сам, не позвав человека». Без цифры разговор о масштабировании превращается в спор вкусов.

4. Стоимость на потоке пугает больше, чем на пилоте

На пилоте гоняют сотню запросов, и счёт за токены не замечают. На потоке в десятки тысяч обращений длинные цепочки с большим контекстным окном** и повторными вызовами инструментов дают счёт, который меняет экономику процесса. Иногда оказывается, что человек дешевле.

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

Пилот против продакшена: что меняется

Что помогает довести агента до масштаба

Универсального рецепта нет, но паттерны у команд, которым это удалось, повторяются.

1. Сузить задачу. Агент, который делает одно узкое действие хорошо, доезжает до прода чаще, чем «универсальный ассистент по всему».
2. Оставить человека в контуре на дорогих шагах. Решения с ценой ошибки в деньгах отдавать на подтверждение оператору, а не автономному агенту.
3. Мерить на реальном потоке с первого дня. Логировать каждый шаг, считать долю автономных завершений и стоимость запроса, а не только «получилось / не получилось».
4. Подключить проверенные данные через RAG. Извлечение из корпоративной базы*** снижает выдумывание фактов, но не отменяет проверку.
5. Заложить откаты и эскалацию. Заранее определить, что делает система, когда агент не уверен или упёрся в ошибку.
6. Назвать владельца до старта пилота. Если некому будет эксплуатировать результат, пилот и останется пилотом.

Кому это пригодится, а кому пока нет

Стоит внедрять сейчас:

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

Пока рано автономно:

• Процессы, где ошибка стоит денег или репутации без возможности отката — финансовые операции, юридически значимые действия.
• Задачи с очень длинными цепочками и без чёткой метрики «сделано верно».
• Ситуации, где входные данные принципиально непредсказуемы, а проверить результат дорого.

* Агент — система на базе языковой модели, которая планирует шаги и сама вызывает инструменты (API, поиск, действия в интерфейсе), а не только отвечает текстом.

** Контекстное окно — объём текста в токенах, который модель обрабатывает за один вызов. Чем длиннее история и документы в запросе, тем больше окно и выше стоимость.

*** RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные фрагменты из внешней базы знаний, а не полагается только на выученное при обучении.