Крах «цифрового энтузиазма»: Почему AI-агенты на предприятиях переживают эпоху «жесткой перестройки»
Первая волна внедрения корпоративных AI-агентов захлебнулась в хаосе. Компании, ослепленные мощью больших языковых моделей, забыли о базовых принципах надежности. Теперь наступает эра жесткой инженерной перестройки: от простых чат-ботов к отказоустойчивым, долгоживущим системам, которые не рушатся при первом же тайм-ауте.
Когда генеративные нейросети хлынули в корпоративный сектор, главным требованием была скорость. Каждая компания стремилась первой внедрить «умного» агента, который пишет код, отвечает в поддержке или анализирует документы. Но переход от демонстрации возможностей к реальной, 24/7/365 эксплуатации обернулся болезненным откровением: производительности языковых моделей недостаточно.
Оказывается, AI-агент, работающий в реальном бизнес-процессе, должен не просто генерировать красивый текст. Он обязан выдерживать сбои серверов, помнить о своем состоянии после перезагрузки, элегантно восстанавливаться после ошибок API, считать каждую потраченную копейку на токены и синхронизироваться с десятками корпоративных систем. Первая волна это проигнорировала. И теперь проекты горят.
«Всё рушится, и они возвращаются к фундаменту»
Ситуацию описывает Прети Сомал, старший вице-президент по инжинирингу в Temporal Technologies (компании, специализирующейся на оркестровке распределенных приложений). По ее словам, текущий тренд — это массовая перестройка.
«К нам приходит много клиентов, которые строят вторую версию того же агента, — говорит Сомал. — Им нужно было двигаться очень быстро, но они не позаботились об инфраструктуре. Всё рушится и горит, и они возвращаются к созданию надёжного фундамента».
Паттерны проблем не новы — распределенные системы сталкивались с этим десятилетиями. Но AI многократно их усилил. Агентный процесс теперь может длиться часами, проходя через цепочку: вызов LLM → поиск в базе знаний → обращение к API склада → отправка письма клиенту. Что произойдет, если на третьем шаге API не ответит? В старых «игрушечных» демо-ботах процесс просто падал. В реальном бизнесе это срыв поставки, потеря заказа или неотправленный отчет врача.
Главный вопрос, который сейчас решают инженеры: «Если агент упадет, придется ли мне запускать весь процесс заново с нуля?»
Состояние vs. Контекст: Архитектурная пропасть
В погоне за красивыми демонстрациями компании смешивали два принципиально разных понятия: состояние процесса и память агента.
- Состояние (State) — это детерминированный трек процесса: какие действия уже выполнены, на каком шаге мы остановились, куда идти после перезапуска.
- Память (Memory) — это вероятностное содержимое, которое генерирует и переносит модель: темы диалога, предпочтения пользователя, контекст предыдущих решений.
Проблемы начинаются, когда процесс работает долго. Пример из здравоохранения, который приводит VentureBeat: обработка визита врача. Это аудиозапись → расшифровка → вызов LLM для суммаризации → генерация рецепта → проверка страховой. Весь цикл может занимать часы. Если на этапе страховой произойдет тайм-аут, а система не сохранила состояние расшифровки и суммаризации, врачу или агенту придется начинать все заново. Это коллапс эффективности.
Детерминированный позвоночник для вероятностного мозга
Спасательным кругом для корпоративных ИТ-отделов становится концепция «детерминированного позвоночника» (Deterministic Spine).
Архитектурно это выглядит так:
У нас есть жесткая, предсказуемая оркестрация (позвоночник), которая знает последовательность шагов. Она вызывает «мозг» (языковую модель) как внешнюю, вероятностную функцию. Если мозг «завис», выдал ошибку или тайм-аут, позвоночник не падает. Он просто повторяет вызов, ждет, или инициирует восстановление с последней контрольной точки.
В этой модели корпоративные системы (закупки, эскалации, медотчеты) не могут молча упасть из-за каприза LLM. Оркестратор гарантирует выполнение бизнес-логики, даже если «мозг» временно отключился.
Это критически важно, потому что бизнес-процессы не прощают тишины. Если агент для поддержки клиента замолчал на час из-за сбоя модели, это репутационные потери. Если автоматическая закупка упала посередине транзакции — финансовые потери.
Видимость токенов и экономика выживания
Помимо надежности, «Перестройка» решает еще две насущные проблемы:
- Видимость расходов. Долгоживущие агенты тратят миллионы токенов на многократные вызовы. Без оркестрации не понятно, где именно «сгорали» деньги: на бесконечном переписывании одного промпта или на реальной работе. Детерминированный позвоночник дает пошаговую аналитику затрат.
- Экономия на восстановлении. Перезапуск всего процесса с нуля из-за ошибки на 15-м шаге — роскошь. Сохранение состояния позволяет возобновить работу с места сбоя, сохраняя все уже оплаченные вызовы LLM и результаты промежуточных API.
Предприятия строят «вымощенные пути»
Интересно, что рынок отходит от идеи купить «готовую агентную платформу коробкой». Крупные компании не хотят попадать в зависимость от одного вендора агентского фреймворка.
Вместо этого они строят внутренние «вымощенные пути» (Paved Paths) — стандартизированные фреймворки с жесткими ограничениями: контроль управления (governance), политики выбора моделей, унифицированная система идентификации и, конечно, встроенная наблюдаемость.
По данным VentureBeat, платформы вроде Temporal уже стали частью стандартной программы модернизации в крупных корпорациях. Теперь этот же проверенный механизм оркестровки инфраструктуры просто накладывают на AI-агентов. Это естественная эволюция: сначала мы научились управлять микросервисами, теперь учимся управлять вероятностными агентами с той же степенью жесткости.
Вывод: Демо закончилось. Началась инженерия.
Эйфория первых внедрений AI прошла. 2024-2025 годы станут временем «жесткой перестройки» корпоративных агентов.
Компании, которые выживут в этой гонке, те, кто прямо сейчас переписывают архитектуру, отделяя состояние от контекста, создавая детерминированный позвоночник и встраивая механизмы наблюдаемости. Остальные продолжат тушить пожары в «горящих» процессах, где ИИ обещал рай, но принес хаос непредсказуемости.
Надежность больше не опция. Это единственное условие эксплуатации.