Как Яндекс собрал платформу AI‑агентов для Алисы поверх Temporal и зачем вообще понадобился свой сервер — VogueTech

Что нового

Яндекс перестал запускать агентский режим Алисы на «тонкой обёртке» над OpenAI Agents SDK и построил отдельную платформу Agent Transport System (ATS). Это центральный сервер, который управляет агентами, инструментами и моделями через собственный gRPC‑протокол и опирается на Temporal для отказоустойчивости.

Ключевые изменения по сравнению с нулевой версией:

Долгоживущие агенты с восстановлением состояния
- Агент «Исследовать» в Алисе AI работает до 20 минут.
- За одну сессию он успевает обойти десятки сайтов, запустить несколько моделей и вызвать множество инструментов на разных хостах.
- Если в середине цепочки что‑то падает — релиз, сеть, проблемы с инфраструктурой — ATS восстанавливает выполнение с последнего консистентного состояния, а не запускает всё заново.
Распределённое выполнение по умолчанию
- Один агент может жить на одном сервисе, другой — на другом, инструменты — на третьем.
- ATS координирует все вызовы, не требуя, чтобы «всё крутилось в одном процессе», как у базового OpenAI Agents SDK.
Тонкий SDK для разработчиков агентов
- Агентский код реализует протокол и бизнес‑логику.
- Хранение состояния, ретраи, мониторинг, доступы и квоты уезжают в ATS.
- Time‑to‑first‑run для нового сервиса снижается: не нужно каждому агентскому сервису поднимать свою БД и инфраструктуру отказоустойчивости.
Слой поверх Temporal, а не привязка агентов к Temporal SDK
- ATS использует Temporal как движок надёжного исполнения workflow и activity.
- Агентский код не зависит напрямую от Temporal SDK и может быть написан на языках без официальной поддержки Temporal (в частности, на C++).

Числовых бенчмарков по скорости, стоимости токенов или нагрузке команда не приводит. Основной «измеримый» эффект — возможность удерживать сложные агентские сценарии до 20 минут без потери прогресса и без повторного сжигания LLM‑токенов при сбоях.

Как это работает

От наивного SDK к платформе

Первая версия агентского режима в Алисе выглядела просто: Яндекс взял OpenAI Agents SDK и написал над ним тонкую обёртку. Всё работало в духе «идеальной лабораторной установки»: агенты и инструменты — в одном процессе, состояние выполнения — в памяти.

Проблемы такого подхода:

Локальное состояние. Процесс упал — вся история выполнения потеряна. Агент стартует с нуля, даже если до этого два часа гонял тяжёлые запросы к LLM.
Хрупкая цепочка сервисов. Если у вас цепочка вида Агент1 → Агент2 → Агент3 → Агент4, и Агент2 лежит из‑за релиза или сетевого сбоя, вы теряете всё, что ниже по дереву: результаты, промежуточные данные, прогресс.
Инфраструктурный зоопарк. Можно было «залатать» проблему: добавить БД, ретраи, мониторинг, алерты, квоты для каждого сервиса. Но тогда каждый агентский сервис превращается в мини‑платформу, а запуск нового агента занимает недели: доступы, база, конфигурации.

Команда сформулировала требования:

централизованное хранение и восстановление состояния;
распределённое выполнение как норма, а не исключение;
минимальный объём инфраструктурного кода в самих агентах.

Отсюда родилась идея ATS — отдельного сервера, который говорит с агентами и инструментами по gRPC и берёт на себя всё «тяжёлое» вокруг надёжности.

Temporal как «двигатель надёжности»

Под ATS лежит Temporal — фреймворк для построения систем, которые не теряют состояние даже при падении воркеров, сетевых проблемах и рестартах.

Temporal оперирует двумя сущностями:

Workflow — объект с состоянием, который описывает последовательность шагов. Код workflow должен быть детерминированным и без сайд‑эффектов. Нельзя ходить в сеть, открывать файлы, использовать случайные числа без фиксации исходного значения.
Activity — функции с сайд‑эффектами (сеть, БД, вызовы моделей, инструменты). Workflow вызывает activity, когда нужно сделать «что‑то недетерминированное».

Как Temporal держит всё в порядке:

История выполнения (event history)
Temporal сохраняет каждое решение workflow и результаты завершённых activity в хранилище. Это подробный лог: какие activity вызывали, с какими аргументами, что вернулось.
Восстановление через replay
Если воркер с кодом workflow падает, Temporal поднимает новый воркер, «проигрывает» историю и приводит workflow в то же состояние, в котором он был до сбоя. Уже завершённые activity не запускаются повторно — их результаты берутся из истории.
Повтор activity и идемпотентность
Activity выполняются по схеме at‑least‑once. Если воркер не успел записать completion в историю, Temporal может запустить activity повторно. Поэтому любой сайд‑эффект (запись в БД, запрос к внешнему API) должен быть идемпотентным или иметь дедупликацию.

Для ATS это означает: если что‑то упало, workflow агента восстанавливается до последнего консистентного шага, а activity (вызовы инструментов, моделей, внешних сервисов) аккуратно ретраятся по заданной политике.

Почему Яндекс не пишет агентов напрямую на Temporal

У Temporal есть интеграция с OpenAI Agents SDK. Теоретически можно было бы описывать агентов как workflow прямо в Temporal. Команда Алисы на это не пошла по нескольким причинам:

Жёсткая привязка к Temporal SDK
Если агентский код напрямую использует Temporal, миграция на другой движок будет болезненной.
Языки разработки
В Яндексе много кода на C++. У Temporal нет официального C++ SDK. Привязывать архитектуру к доступности SDK по языкам — плохая идея.
Модель взаимодействия с пользователем
Temporal отлично подходит для стейт‑машин и сложных графов выполнения: запустили workflow, он прошёл фазы и выдал финальный ответ.
Алисе нужно другое: отдавать пользователю промежуточные ответы по мере выполнения, а не только финальный результат.

Поэтому Яндекс построил свой сервер ATS поверх Temporal. Temporal отвечает за надёжное выполнение внутренних workflow, а ATS реализует протокол общения с агентами, маршрутизацию вызовов, работу с несколькими сервисами и выдачу частичных ответов пользователю.

Что это значит для вас

Если вы продуктовый менеджер или архитектор

Долгие сценарии без страха падений
Агент «Исследовать» — пример сложного сценария: десятки сайтов, вызовы моделей, инструменты, до 20 минут работы.
С ATS такие сценарии можно планировать осознанно: если один из сервисов упадёт, вы не потеряете два часа запросов к LLM и не сожжёте бюджет на токены в холостую.
Масштабирование без дублирования инфраструктуры
Вам не нужно заставлять каждую команду поднимать свою БД, писать ретраи и мониторинг для агентского кода.
Команды пишут агентов как «чистый» код, ATS берёт на себя распределённое выполнение и устойчивость.
Подготовка к многосервисной архитектуре агентов
Если вы строите ассистента, который должен общаться с десятками внутренних сервисов, подход Яндекса показывает, что центральная платформа агентов полезнее, чем десятки самостоятельных мини‑агентов.

Если вы бэкенд‑разработчик

Меньше инфраструктурного кода в сервисе
Внутри агентского сервиса вы реализуете протокол, бизнес‑логику и, при необходимости, инструменты.
Логика ретраев, хранение истории, восстановление состояния и оркестрация по сервисам живут в ATS и Temporal.
Понимание, как писать код с учётом at‑least‑once
Любой вызов, который Temporal видит как activity, может выполниться повторно.
Если вы сейчас проектируете свой агентный фреймворк, придётся сразу закладывать идемпотентность или дедупликацию.
Чёткое разделение: детерминированный workflow и сайд‑эффекты
Подход Temporal дисциплинирует архитектуру. Часть кода должна быть чистой и детерминированной, часть — содержать сайд‑эффекты и работать как activity.
Это упрощает отладку и делает поведение системы предсказуемым.

Когда такой подход вам поможет

Использовать идеи ATS и Temporal стоит, если:

у вас есть ассистент или агент, который выполняет цепочки действий дольше нескольких секунд — от минут до десятков минут;
сценарий включает несколько внешних сервисов и инструментов, которые могут падать или временно быть недоступны;
повтор выполнения «с нуля» слишком дорог — по времени, по деньгам (LLM‑токены), по нагрузке на внешние API.

Когда можно обойтись без этого

Если ваш агент:

живёт внутри одного процесса,
делает один‑два коротких запроса,
и вы спокойно переносите повторный запуск целиком,

то городить Temporal и отдельный сервер не обязательно. Встроенных возможностей OpenAI Agents SDK или аналогов будет достаточно.

Доступность и ограничения

Речь идёт о внутренней платформе Яндекса для Алисы AI. Публичного доступа к ATS нет, это не внешний продукт.
Если вы разрабатываете свои агенты, вы можете использовать Temporal напрямую или строить аналогичный слой поверх него.

Для работы с Temporal в России может понадобиться VPN в зависимости от того, где вы разворачиваете инфраструктуру и какие облака используете. ATS как продукт Яндекса доступен только внутри экосистемы Яндекса.

Место на рынке

Яндекс решает задачу, с которой уже столкнулись крупные игроки, строящие сложных ассистентов:

OpenAI развивает OpenAI Agents SDK и интеграцию с Temporal, но по умолчанию предлагает модель, где многое живёт в одном процессе и без жёсткой платформенной прослойки.
Многие компании пишут собственные оркестраторы поверх workflow‑движков (Temporal, Cadence, Argo Workflows) или строят свои DSL для описания цепочек действий.

Яндекс выбрал связку «Temporal как движок + собственный сервер ATS как оркестратор агентов». Это даёт:

независимость агентского кода от конкретного workflow‑движка (нет прямой завязки на Temporal SDK);
возможность использовать языки без официальной поддержки Temporal, включая C++;
архитектуру, заточенную под ассистента, который должен отдавать пользователю промежуточные ответы, а не только финальный результат workflow.

Конкретных сравнений по скорости выполнения, стоимости или SLA с другими платформами (например, встроенными агентами у OpenAI или решениями на базе Cadence) команда не приводит. Фокус — на архитектуре и надёжности долгоживущих сценариев.

Если вы строите свою платформу агентов, опыт Яндекса показывает, что одного лишь SDK от поставщика LLM часто мало. Нужен отдельный слой, который умеет жить в распределённом мире, переживать падения сервисов и беречь ваши токены и время разработчиков.