Реальные бизнес-кейсы Temporal в MAS

В MAS главная проблема — это непредсказуемость времени и хаос. Агенты могут  ждать ответа LLM минутами , вызовы API падают по таймауту, а длинные цепочки рассуждений (Reasoning Loops) легко ломаются из-за сетевых сбоев.

Бизнес-ценность - необходим там, где сбой на середине пути стоит бизнесу денег, репутации или ломает пользовательский опыт.

1. Платежные цепочки

Кейс: Покупка сложной подписки или оплата корзины. Как это работает: Нужно списать деньги, обновить баланс в одной БД, выписать инвойс в другой системе и выдать доступ. Если на этапе инвойса сеть упала — Temporal гарантирует, что цепочка дойдет до конца после восстановления. А если произошла критическая ошибка, движок автоматически вернет деньги на карту.

Используемые конструкции SDK: - @WorkflowMethod (или workflow.Register) — для объявления основной функции заказа. - Workflow.newActivityStub — для инициализации Activities (списание денег, создание инвойса, выдача прав). - RetryOptions — настраивается для Activity инвойса. Задается экспоненциальный бэкофф, чтобы Temporal бесконечно или долго пытался достучаться до упавшей инвойс-системы, не ломая весь процесс заказа. - Saga — для реализации паттерна консистентности Saga. При успешном выполнении Activity списания денег в объект Саги регистрируется компенсирующее действие (Activity возврата средств). Если последующие шаги падают с неисправимой ошибкой, SDK автоматически выполняет все зарегистрированные компенсации в обратном порядке.

2. Тяжелый фоновый процессинг Кейс: Рендеринг видео, генерация огромных отчетов, миграция данных.

Как это работает: Тяжелая задача (Activity) выполняется на воркере и шлет серверу Heartbeat (пульс). Если сервер с видеокартой отказывает в обслуживание (выключение питания, сбой гипервизора, Kernel Panic или реальный выход железа из строя, высокий таймаут очереди воркера), Temporal заметит пропажу пульса, поднимет задачу на другом сервере и продолжит с точки сбоя.

Используемые конструкции SDK: - Activity.RecordHeartbeat(ctx, progress) — вызывается внутри длинного цикла обработки данных. Воркер сообщает серверу Temporal: «Я обработал уже 45%». - ActivityOptions.withHeartbeatTimeout — таймаут, настраиваемый в Workflow. Если воркер отключился или завис и перестал присылать heartbeat-пульс в течение этого времени, сервер Temporal мгновенно считает Activity упавшим. -Activity.getExecutionContext().getHeartbeatDetails — вызывается в самом начале Activity при перезапуске. Новый воркер, подхвативший упавшую задачу, считывает сохраненный ранее progress  продолжает не с нуля, а с 45-го процента.