4 июня 2026 г.
Твои агенты без состояния. Поэтому они умирают.
На твоём ноуте агент проходит путь от начала до конца за один заход, и проблемы ты не видишь. Прод — это длинный многошаговый процесс на инфраструктуре, которая перезапускается, ловит таймауты и падает на полпути, — а агент держал весь свой прогресс в памяти. «Agentic reckoning» 2026-го — это открытие, что сбой не в модели, а в рантайме. Починка старая и скучная: durable execution. Вот честная версия.
На твоём ноуте агент проходит от начала до конца за один заход, и проблемы ты не видишь. Думает, зовёт пару инструментов, завершается, готово. Выглядит надёжно.
Прод — другой зверь. Там агент — длинный многошаговый процесс на инфраструктуре, которая перезапускает деплои, убивает контейнеры, жрущие слишком много памяти, и рвёт соединения по таймауту — рутинно, как факт жизни. А типичный агент держит весь свой прогресс в одном месте: в памяти. Так что в тот миг, когда процесс моргнул, пятьдесят шагов дорогой работы испаряются, и агент начинает с нуля. Сделай так на сценарии, который идёт часами, — и он может не закончиться вовсе.
Расплата: дело в рантайме, а не в модели
У этого осознания теперь есть имя. VentureBeat назвал это «agentic reckoning», и тезис точен: предприятия обнаруживают, что точка отказа — не рассуждение модели, а рантайм. Агенты, склеенные из «Python-скриптов, цепочек LangChain, ad hoc оркестрации», не переживают прод не потому, что они не умные, а потому, что они без состояния — у них нет долговечной памяти о том, что они уже сделали. Одно описание операционной реальности предельно прямое: перезапуски контейнеров стирают контекст, а у долгоиграющих агентов (дольше четырёх часов) системы без персистентности состояния несут на 90% более высокий риск тотального отказа задачи из-за таймаута или сбоя инфраструктуры.
Вот что упускается в каждом споре «достаточно ли умна модель». Твой агент умирает не потому, что не может рассуждать. Он умирает, потому что это скрипт, прикидывающийся системой, на инфраструктуре, которой плевать, насколько он умён.
А теперь это ещё и денежный костёр
Раньше отсутствие состояния стоило тебе только времени. В 2026-м оно стоит сверху ещё и токенового счёта. Когда 100-шаговый агент падает на шаге 47 и стартует с шага 1, ты теряешь не только время — ты заново платишь за все токены, которые шаги с 1-го по 47-й уже сожгли, а потом жжёшь их снова. Долгоиграющий агент без состояния — это проблема надёжности и проблема контроля затрат в одном пальто. Дорогая часть работы — ровно та, что ты постоянно выбрасываешь и переделываешь.
Починке снова сорок лет
Лекарство — не модель поумнее и не промпт похитрее. Это durable execution (долговечное исполнение), и это та же идея, что десятилетиями крутит банковские пакетные задания и пайплайны заказов: сохраняй каждый шаг по мере выполнения, а когда процесс падает — возобновляйся с места остановки, а не с начала.
Temporal, самый известный движок для этого, описывает модель чисто: он записывает каждый шаг воркфлоу как неизменяемую историю событий, так что если процесс падает на шаге 47 из 100, он переигрывает лог и возобновляется с шага 48 — а не с шага 1. Агент получает память о собственном прогрессе, переживающую падения, перезапуски и передеплои. Это не новинка; это checkpointing, саги и идемпотентность — сантехника любой серьёзной долгоиграющей задачи. Как сказал один инженер, агентные воркфлоу просто заново открывают durable execution. Рынок согласен, что это несущая конструкция: Temporal поднял раунд на $300M при оценке $5B в начале 2026, а LangGraph и Vercel Workflows наперегонки добавляют те же гарантии.
Честный подвох
Durable execution необходим, а не волшебен, и есть тонкость, которую надо уважать, иначе она тебя укусит. Replay работает так: он заново прогоняет твой воркфлоу и переиспользует записанный в журнал результат каждого уже сделанного шага. Но вызов LLM недетерминирован — запусти его дважды и получишь два разных ответа. Так что нельзя просто дать replay перезапустить его. Каждый вызов модели (и каждый вызов инструмента с побочным эффектом) надо обернуть как записанную «activity», чей результат журналируется на первом прогоне и никогда не исполняется заново на replay. Ошибись с этой границей — и твоё «восстановление» тихо сделает работу — и выставит тебе счёт — дважды. Это настоящая инженерия, а не библиотека, присыпанная сверху.
Суть
Агент в проде — это длинный распределённый процесс. Я уже доказывал, что мульти-агентная система — это распределённая система и падает как она; здесь та же правда на уровень ниже. Относись к агенту как к долговечному, возобновляемому процессу, которым он должен быть, — сохранённое состояние, идемпотентные шаги, восстановление, которое ты реально протестировал, — или прими, что каждый перезапуск контейнера отправляет его в ноль.
Твой агент падает не потому, что недостаточно умён. Он падает потому, что у него нет памяти о том, что он уже сделал, а инфраструктура, на которой он живёт, будет снова и снова выдёргивать у него ковёр из-под ног. Дай ему долговечное состояние — или смотри, как он умирает на шаге 47, снова и снова, каждый раз платя полную цену.
Комментарии
Пока нет комментариев
Войдите, чтобы участвовать в разговоре.
Будьте первым, кто оставит мысль.