Отрасль спорит о качестве моделей, а агенты падают на исполнении
Отраслевая дискуссия вокруг ИИ-агентов сосредоточена на качестве рассуждений: какая модель лучше планирует, где меньше галлюцинаций, чей reasoning глубже.
Практика промышленных внедрений смещает фокус в другую сторону.
Значительная часть отказов агентных систем в продакшене приходится не на модель, а на исполнение.
Чат-бот отвечает на вопрос, агент выполняет работу
Разница между чат-ботом и корпоративным агентом кажется небольшой, но она переписывает архитектуру целиком.
Схема «запрос пользователя, API агента, вызов LLM, ответ» закрывает вопросы-ответы, суммаризацию, поиск и базовый tool calling. Реальный сценарий выглядит иначе:
▪️ агент поддержки анализирует логи,
▪️ ищет по базе знаний,
▪️ поднимает похожие исторические инциденты,
▪️ проверяет политику эскалации,
▪️ ждет review инженера
▪️ и только потом формирует рекомендацию.
Такой процесс занимает минуты, часы или дни. Это уже не диалог, а долгоживущий бизнес-процесс с ИИ внутри.
Неудобные инженерные вопросы
В этот момент архитектуре начинают задавать неудобные инженерные вопросы:
📍что произойдет, если пользователь закроет вкладку,
📍истечет таймаут запроса,
📍один из смежных сервисов окажется недоступен,
📍вызов модели зашедулен под throttling,
📍апрув от человека придет через шесть часов,
📍процесс перезапустится на середине выполнения.
Ответ «обработаем в коде агента» означает, что архитектура уже в состоянии долга.
Типичные сценарии отказа
1️⃣ состояние workflow хранилось только в памяти;
2️⃣ сессия фронтенда исчезла;
3️⃣ бэкенд-запрос превысил таймаут;
4️⃣ транзиентная ошибка внешнего API перезапустила процесс с нуля
5️⃣ шаг человеческого согласования жил вне workflow;
6️⃣ механизма возобновления с последнего завершенного шага не существовало;
7️⃣ повторная попытка неидемпотентной операции создала дублирующую работу.
Во всех этих случаях модель отработала корректно. Отказал рантайм.
Проблемы не новые, новые — те, кто строит
Стоит отметить, что ни один из перечисленных режимов отказа не является новым. Durable-execution рантаймы решили задачу persist-and-resume годы назад, чекпоинтинг старше их, а ключи идемпотентности лежат в фундаменте платежной индустрии.
Изменился не набор проблем, а состав тех, кто строит системы.
Команды, которые сегодня выкатывают агентов, в массе своей не застали эпоху workflow-движков, поэтому дисциплина осваивается заново.
Сдвиг в проектировании
Практический сдвиг в проектировании формулируется одной фразой: приложением является workflow, модель является одной активностью внутри него.
Из этого следует конкретный список требований, который не имеет отношения к промпт-инжинирингу:
• устойчивое состояние
• явные политики retry
• трекинг прогресса
• correlation ID
• чекпоинты человеческого согласования
• обработка частичных отказов
• возобновление по внешним событиям
• аудируемость
• версионирование workflow
Деструктивный тест
Проверить, работает ли это, архитектурной диаграммой невозможно. Единственный надежный тест — деструктивный:
▪️ убить процесс в произвольной точке, желательно неудобной.
▪️ обнулить все состояние в памяти и в контексте,
▪️ поднять систему и посмотреть на поведение.
Если возобновленный процесс заново выводит план — отсутствует читаемое агентом устойчивое состояние. Если переделывает завершенные шаги — недостаточна гранулярность чекпоинтинга. Если повторно выполняет побочный эффект — отсутствуют ключи идемпотентности.
Вывод
Следующий этап корпоративного ИИ определится не размером модели и не качеством промптов, а архитектурой исполнения.
#tech_inside
Отраслевая дискуссия вокруг ИИ-агентов сосредоточена на качестве рассуждений: какая модель лучше планирует, где меньше галлюцинаций, чей reasoning глубже.
Практика промышленных внедрений смещает фокус в другую сторону.
Значительная часть отказов агентных систем в продакшене приходится не на модель, а на исполнение.
Чат-бот отвечает на вопрос, агент выполняет работу
Разница между чат-ботом и корпоративным агентом кажется небольшой, но она переписывает архитектуру целиком.
Схема «запрос пользователя, API агента, вызов LLM, ответ» закрывает вопросы-ответы, суммаризацию, поиск и базовый tool calling. Реальный сценарий выглядит иначе:
▪️ агент поддержки анализирует логи,
▪️ ищет по базе знаний,
▪️ поднимает похожие исторические инциденты,
▪️ проверяет политику эскалации,
▪️ ждет review инженера
▪️ и только потом формирует рекомендацию.
Такой процесс занимает минуты, часы или дни. Это уже не диалог, а долгоживущий бизнес-процесс с ИИ внутри.
Неудобные инженерные вопросы
В этот момент архитектуре начинают задавать неудобные инженерные вопросы:
📍что произойдет, если пользователь закроет вкладку,
📍истечет таймаут запроса,
📍один из смежных сервисов окажется недоступен,
📍вызов модели зашедулен под throttling,
📍апрув от человека придет через шесть часов,
📍процесс перезапустится на середине выполнения.
Ответ «обработаем в коде агента» означает, что архитектура уже в состоянии долга.
Типичные сценарии отказа
1️⃣ состояние workflow хранилось только в памяти;
2️⃣ сессия фронтенда исчезла;
3️⃣ бэкенд-запрос превысил таймаут;
4️⃣ транзиентная ошибка внешнего API перезапустила процесс с нуля
5️⃣ шаг человеческого согласования жил вне workflow;
6️⃣ механизма возобновления с последнего завершенного шага не существовало;
7️⃣ повторная попытка неидемпотентной операции создала дублирующую работу.
Во всех этих случаях модель отработала корректно. Отказал рантайм.
Проблемы не новые, новые — те, кто строит
Стоит отметить, что ни один из перечисленных режимов отказа не является новым. Durable-execution рантаймы решили задачу persist-and-resume годы назад, чекпоинтинг старше их, а ключи идемпотентности лежат в фундаменте платежной индустрии.
Изменился не набор проблем, а состав тех, кто строит системы.
Команды, которые сегодня выкатывают агентов, в массе своей не застали эпоху workflow-движков, поэтому дисциплина осваивается заново.
Сдвиг в проектировании
Практический сдвиг в проектировании формулируется одной фразой: приложением является workflow, модель является одной активностью внутри него.
Из этого следует конкретный список требований, который не имеет отношения к промпт-инжинирингу:
• устойчивое состояние
• явные политики retry
• трекинг прогресса
• correlation ID
• чекпоинты человеческого согласования
• обработка частичных отказов
• возобновление по внешним событиям
• аудируемость
• версионирование workflow
Деструктивный тест
Проверить, работает ли это, архитектурной диаграммой невозможно. Единственный надежный тест — деструктивный:
▪️ убить процесс в произвольной точке, желательно неудобной.
▪️ обнулить все состояние в памяти и в контексте,
▪️ поднять систему и посмотреть на поведение.
Если возобновленный процесс заново выводит план — отсутствует читаемое агентом устойчивое состояние. Если переделывает завершенные шаги — недостаточна гранулярность чекпоинтинга. Если повторно выполняет побочный эффект — отсутствуют ключи идемпотентности.
Вывод
Следующий этап корпоративного ИИ определится не размером модели и не качеством промптов, а архитектурой исполнения.
#tech_inside