Enterprise AI-агенты выходят в продакшн - и компании в лоб сталкиваются с проблемой надёжности. LLM может быть сколь угодно умной, но если агент падает, теряет состояние или сжигает токены на повторные запуски, бизнесу от этого не легче. Многие команды обнаруживают: успех агента в продакшне определяется вовсе не производительностью модели.
Долгие AI-воркфлоу должны переживать сбои, сохранять состояние, восстанавливаться после ошибок, управлять затратами на инференс и координироваться между API, инструментами и корпоративными системами. И как показывает практика, с этим справляются далеко не все.
После первой волны, ориентированной на быстрый запуск, компаниям приходится возвращаться к первым реализациям и перепроектировать архитектуру агентов с нуля - с упором на оркестрацию, наблюдаемость, управление и восстановление. Об этом рассказала Прити Сомал, старший вице-президент по инженерии в Temporal Technologies, на мероприятии AI Impact Series в Нью-Йорке.
«К нам приходит много клиентов, которые строят версию 2.0 того же самого агента, - говорит Сомал. - Им нужно было двигаться очень быстро, но они не позаботились о "сантехнике". Всё летит в тартарары - и они возвращаются к перестройке уже на надёжном фундаменте.»
- Прити Сомал, старший VP Engineering, Temporal Technologies
Для компании Temporal, чья инфраструктура появилась ещё до нынешней волны агентного AI, этот сдвиг отражает более широкое осознание: продакшн-AI требует долговечного исполнения, управления состоянием, видимости воркфлоу и механизмов восстановления при сбоях моделей или нижестоящих систем.
Агентный AI обострил знакомые инженерные проблемы
«Эти паттерны не новы, - говорит Сомал. - AI просто их усиливает.»
- Прити Сомал
Агентные системы добавляют сложности, потому что они часто включают долгие многошаговые процессы, раскиданные по множеству сервисов, моделей, API и инструментов. Один воркфлоу может вызывать несколько языковых моделей, обращаться к Retrieval-Augmented Generation (RAG) системам, триггерить внешние приложения и управлять состоянием часами или даже днями. Инженерные вопросы - говорит Сомал - часто всплывают только после развёртывания.
«Люди пишут агентов, но не думают о том, что будет, если агент упадёт, - объясняет она. - Мне придётся запускать весь поток агента заново?»
- Прити Сомал
Для компаний, работающих в условиях ограниченного бюджета, ответ имеет значение. Перезапуск воркфлоу после ошибок может умножить расходы на инференс, увеличить задержки и создать плохой пользовательский опыт.
Сомал сравнила текущий момент с ранним периодом корпоративного облака, когда компании мигрировали нагрузки, не задумываясь, что нужно перепроектировать архитектуру, чтобы эти нагрузки выдержали долгосрочную эксплуатацию.
«Эта спешка внедрять AI в мире, где вы даже не модернизировали своё приложение, напоминает мне тот самый lift-and-shift, что был в облаке, - сказала она. - Все поняли: мы тратим больше денег на облако, а ценности не получили.»
- Прити Сомал
Почему долгие агенты требуют новой архитектуры
Корпоративные воркфлоу всё чаще включают агентов, работающих в длинных временных окнах - иногда многие часы - и взаимодействующих с инструментами и системами. Проблемы надёжности накапливаются, когда воркфлоу сохраняются во времени, и это затрагивает состояние (state) и память (memory) - два понятия, которые в AI-обсуждениях часто путают.
Состояние касается исполнения воркфлоу: где агент находится в процессе, какие действия уже выполнены и откуда нужно восстанавливаться после сбоя. Память или контекст - это информация, которую агент переносит между взаимодействиями или задачами.
«Состояние агента - это то, на каком шаге он находится и какие действия выполнены, и если что-то крашится, откуда вы хотите восстановиться, - объяснила Сомал. - А контекст и память - это другая история.»
- Прити Сомал
Это различие становится критически важным, когда компании переходят от простых чат-взаимодействий к длительным бизнес-процессам. Сомал привела пример из здравоохранения - клиент Abridge, где воркфлоу обрабатывают визиты к врачу через несколько стадий: обработка аудио, суммаризация, вызов моделей и генерация пост-визитного отчёта.
«В этом потоке не одна часть, - говорит Сомал. - Запись видео, нарезка, суммаризация, вызов LLM, генерация итогового отчёта - всё это оркестрируется.»
- Прити Сомал
Вывод для бизнеса: успешные агенты всё сильнее зависят от систем, способных переживать сбои, координировать сервисы и поддерживать непрерывность во времени.
Детерминированный позвоночник (Deterministic Spine)
Полезный фреймворк для проектирования enterprise AI - это детерминированный позвоночник, как его называет Сомал. Именно так они в Temporal видят свою роль.
«Это путь, по которому вы хотите идти, - объясняет она. - Он вызывает "мозг", но если мозг не отвечает, он вызывает его снова. Если мозг ответил, но следующий шаг упадёт - система подхватит с места ошибки.»
- Прити Сомал
В этой схеме языковая модель выступает как вероятностная система с переменными выходами, а оркестрационное ПО обеспечивает надёжность исполнения вокруг неё. И эта концепция важна, потому что enterprise-системы всё чаще требуют консистентности, даже когда модели остаются недетерминированными. Закупочный воркфлоу, медицинская сводка, эскалация в поддержку или комплаенс-процесс не могут просто бесшумно рухнуть из-за того, что вызов модели не прошёл по таймауту или внешняя зависимость упала.
«Что вас в первую очередь волнует - это возможность восстановиться и не платить токен-налог, если что-то пошло не так,» - говорит Сомал.
- Прити Сомал
Надёжность, видимость и экономика токенов
По мере того как руководители оценивают ROI от AI, видимость затрат становится растущей проблемой. Долгоиграющие агенты часто делают множественные вызовы моделей в сложных воркфлоу, что создаёт непрозрачные паттерны расходов. Сомал описала одно из операционных преимуществ оркестрации - видимость того, где накапливаются затраты. Поскольку воркфлоу наблюдаемы шаг за шагом, команды могут видеть, где именно потребляются токены в процессе работы агента.
«У вас есть видимость всего потока в едином окне, - говорит она. - Теперь вы можете видеть, на что уходят токены в агенте, который делает несколько шагов и вызывает несколько разных систем.»
- Прити Сомал
Восстановление воркфлоу также влияет на эффективность затрат. Без долговечной оркестрации сбой на позднем этапе может заставить организацию перезапустить весь процесс с самого начала, включая все предыдущие вызовы моделей. Сомал сказала: системы, спроектированные вокруг восстановления, могут возобновлять исполнение с точки прерывания.
«Вы подхватываете с того места, где произошёл сбой, - сказала она. - Мы экономим вам стоимость запуска агента с первого шага заново.»
- Прити Сомал
Предприятиям нужно строить «асфальтированные дороги» и привлекать партнёров
Вопросы управления - ещё один emerging-паттерн по мере того, как агентный AI захватывает корпоративный мир. Вместо того чтобы внедрять готовые fully-managed агентские системы оптом, компании всё чаще хотят стандартизированные внутренние фреймворки, которые обеспечивают защитные барьеры, сохраняя гибкость. И реализовывать такие важные функции, как контроль управления, политики выбора моделей, системы идентификации, управление затратами и наблюдаемость.
«Предприятия смотрят на строительство таких "асфальтированных дорог", - говорит Сомал. - Взять что-то готовое с полки, скорее всего, не сработает, потому что есть все эти дополнительные требования.»
- Прити Сомал
По мере того как организации пересматривают развёртывания первого поколения, эти вызовы всё меньше выглядят как проблема модели и всё больше - как проблема системной инженерии. И Temporal находится в хорошей позиции, чтобы помочь предприятиям сделать этот следующий шаг, отчасти потому, что для многих организаций Temporal уже существовал как часть более широких программ модернизации до того, как AI стал стратегическим приоритетом.
«Temporal уже внутри enterprise, - говорит Сомал. - Взять это и расширить на AI и агентские платформы - это кажется очень естественным.»
- Прити Сомал
🔑 Ключевой вывод
Проблема AI-агентов в enterprise - не в том, насколько умна модель. Модели уже достаточно умны. Проблема в надёжности: как сделать так, чтобы агент не падал, не терял контекст и не сжигал бюджет на повторные запуски. Первая волна агентов была про скорость. Вторая волна - про фундамент. Компании, которые не перестроят архитектуру сейчас, будут платить за это токенами позже.