[phpBB Debug] PHP Warning: in file [ROOT]/ext/sniper/mobiledevice/core/functions.php on line 846: Undefined variable $status
[phpBB Debug] PHP Warning: in file [ROOT]/ext/sniper/mobiledevice/core/functions.php on line 846: Undefined variable $status
[phpBB Debug] PHP Warning: in file [ROOT]/ext/sniper/mobiledevice/core/functions.php on line 846: Undefined variable $status
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4218: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3103)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4218: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3103)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4218: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3103)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4218: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3103)
Форум с Михаилом Молчановым • Крах «цифрового энтузиазма»: Почему AI-агенты на предприятиях переживают эпоху «жесткой перестройки»
Страница 1 из 1

Крах «цифрового энтузиазма»: Почему AI-агенты на предприятиях переживают эпоху «жесткой перестройки»

Добавлено: 31 май 2026, 10:49
Михаил Молчанов

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

Когда генеративные нейросети хлынули в корпоративный сектор, главным требованием была скорость. Каждая компания стремилась первой внедрить «умного» агента, который пишет код, отвечает в поддержке или анализирует документы. Но переход от демонстрации возможностей к реальной, 24/7/365 эксплуатации обернулся болезненным откровением: производительности языковых моделей недостаточно.

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

«Всё рушится, и они возвращаются к фундаменту»

Ситуацию описывает Прети Сомал, старший вице-президент по инжинирингу в Temporal Technologies (компании, специализирующейся на оркестровке распределенных приложений). По ее словам, текущий тренд — это массовая перестройка.

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

Паттерны проблем не новы — распределенные системы сталкивались с этим десятилетиями. Но AI многократно их усилил. Агентный процесс теперь может длиться часами, проходя через цепочку: вызов LLM → поиск в базе знаний → обращение к API склада → отправка письма клиенту. Что произойдет, если на третьем шаге API не ответит? В старых «игрушечных» демо-ботах процесс просто падал. В реальном бизнесе это срыв поставки, потеря заказа или неотправленный отчет врача.

Главный вопрос, который сейчас решают инженеры: «Если агент упадет, придется ли мне запускать весь процесс заново с нуля?»

Состояние vs. Контекст: Архитектурная пропасть

В погоне за красивыми демонстрациями компании смешивали два принципиально разных понятия: состояние процесса и память агента.

  • Состояние (State) — это детерминированный трек процесса: какие действия уже выполнены, на каком шаге мы остановились, куда идти после перезапуска.
  • Память (Memory) — это вероятностное содержимое, которое генерирует и переносит модель: темы диалога, предпочтения пользователя, контекст предыдущих решений.

Проблемы начинаются, когда процесс работает долго. Пример из здравоохранения, который приводит VentureBeat: обработка визита врача. Это аудиозапись → расшифровка → вызов LLM для суммаризации → генерация рецепта → проверка страховой. Весь цикл может занимать часы. Если на этапе страховой произойдет тайм-аут, а система не сохранила состояние расшифровки и суммаризации, врачу или агенту придется начинать все заново. Это коллапс эффективности.

Детерминированный позвоночник для вероятностного мозга

Спасательным кругом для корпоративных ИТ-отделов становится концепция «детерминированного позвоночника» (Deterministic Spine).

Архитектурно это выглядит так:
У нас есть жесткая, предсказуемая оркестрация (позвоночник), которая знает последовательность шагов. Она вызывает «мозг» (языковую модель) как внешнюю, вероятностную функцию. Если мозг «завис», выдал ошибку или тайм-аут, позвоночник не падает. Он просто повторяет вызов, ждет, или инициирует восстановление с последней контрольной точки.

В этой модели корпоративные системы (закупки, эскалации, медотчеты) не могут молча упасть из-за каприза LLM. Оркестратор гарантирует выполнение бизнес-логики, даже если «мозг» временно отключился.

Это критически важно, потому что бизнес-процессы не прощают тишины. Если агент для поддержки клиента замолчал на час из-за сбоя модели, это репутационные потери. Если автоматическая закупка упала посередине транзакции — финансовые потери.

Видимость токенов и экономика выживания

Помимо надежности, «Перестройка» решает еще две насущные проблемы:

  1. Видимость расходов. Долгоживущие агенты тратят миллионы токенов на многократные вызовы. Без оркестрации не понятно, где именно «сгорали» деньги: на бесконечном переписывании одного промпта или на реальной работе. Детерминированный позвоночник дает пошаговую аналитику затрат.
  2. Экономия на восстановлении. Перезапуск всего процесса с нуля из-за ошибки на 15-м шаге — роскошь. Сохранение состояния позволяет возобновить работу с места сбоя, сохраняя все уже оплаченные вызовы LLM и результаты промежуточных API.

Предприятия строят «вымощенные пути»

Интересно, что рынок отходит от идеи купить «готовую агентную платформу коробкой». Крупные компании не хотят попадать в зависимость от одного вендора агентского фреймворка.

Вместо этого они строят внутренние «вымощенные пути» (Paved Paths) — стандартизированные фреймворки с жесткими ограничениями: контроль управления (governance), политики выбора моделей, унифицированная система идентификации и, конечно, встроенная наблюдаемость.

По данным VentureBeat, платформы вроде Temporal уже стали частью стандартной программы модернизации в крупных корпорациях. Теперь этот же проверенный механизм оркестровки инфраструктуры просто накладывают на AI-агентов. Это естественная эволюция: сначала мы научились управлять микросервисами, теперь учимся управлять вероятностными агентами с той же степенью жесткости.

Вывод: Демо закончилось. Началась инженерия.

Эйфория первых внедрений AI прошла. 2024-2025 годы станут временем «жесткой перестройки» корпоративных агентов.

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

Надежность больше не опция. Это единственное условие эксплуатации.