Слова «искусственный интеллект» и «приложение, которое вас понимает» звучали в презентациях много раз. Но одно дело — предложить визионерскую идею, и совсем другое — заставить её работать в реальном, высоконагруженном приложении. Долгое время нас ограничивал сам уровень развития технологий. Попытки построить по-настоящему живой и гибкий диалог на базе классических инструментов упирались в то, что системе не хватало возможности выходить за рамки жёстко прописанных скриптов и сценариев.
Но в 2025 году ситуация изменилась. Взрывной рост LLM и смещение общего фокуса в индустрии в сторону AI-технологий дали понять: теперь возможно всё. Мы решили вернуться к идее персонализированного городского ассистента, но уже с новым инструментарием.
Зачем это нужно? Можно объяснить на простом примере. Допустим, вы забыли ключи от дома у друга, а завтра уезжаете в командировку. Что нужно сделать? Открыть Доставку, выбрать тип отправки, указать адрес, найти контакт, сформировать заказ. Потом вспомнить, что в аэропорту не будет времени перекусить — открыть Лавку, собрать снеки. Проверить, сколько жидкости можно брать в ручную кладь. Заказать такси. Найти, где поужинать по прилёту. Пять сервисов. Десятки шагов. И всё это — ради одной цели: спокойно уехать в поездку.
Приложением Яндекс Go ежемесячно пользуются 58 миллионов человек для решения своих повседневных задач. Мы стремились создать продукт, который закрывает все потребности в одном месте — бесшовно, без необходимости скачивать лишние приложения. Но, глядя на такие многоходовые сценарии, мы спросили себя: можем ли мы пойти еще дальше? Можно ли решать задачи еще быстрее и удобнее, никуда не нажимая и не переходя по вкладкам? Теперь мы объединяем городские сервисы в Яндекс Go совершенно по-новому с помощью Алисы AI.
Меня зовут Сергей Грошев, я бэкенд-разработчик в SuperApp Core, и эту статью мы написали вместе с моим коллегой Сергеем Нанаевым — руководителем службы разработки SuperApp. Здесь мы будем говорить не о маркетинге, а о самой технологии. Мы расскажем, как встраивали SDK Алисы, почему готовые UI-решения нам не подошли, как работает наш оркестратор Solaris и зачем нам пришлось написать собственный инструмент для создания агентов — YaDK.
Архитектура: как всё устроено внутри
Когда мы только начинали работу в этом направлении, перед нами стояли две глобальные инженерные задачи.
- Во-первых, нужно было интегрировать Алису AI в Go.
- Во-вторых, создать большую, полноценную мультиагентную схему.
Нам предстояло научить разные сервисы не просто существовать рядом в одном приложении, а взаимодействовать друг с другом в рамках одного чата.
Чтобы понять масштаб, давайте посмотрим на итоговую схему движения пользовательского запроса. Это настоящая распределённая система, где каждый компонент решает строго свою задачу.
Алиса сначала интерпретирует запрос и определяет, какая часть её умений должна быть задействована для ответа. По сути, она выбирает сценарий обработки: будет ли запрос обработан внутри базового AI-стека или же для его выполнения потребуется подключение сервисов Яндекс Go.
Допустим, мы отправляем в этот чат сообщение. Что происходит дальше?
Если в чат поступает запрос вроде «Какая сегодня погода?» или «До скольки работает метро», Алиса понимает, что это информационный сценарий. Такой запрос полностью обрабатывается внутри базового AI-стека: Алиса формирует ответ самостоятельно и возвращает его пользователю.
Но если запрос звучит как «Хочу борщ» или «Закажи такси до дома», Алиса распознаёт сценарий, связанный с Городскими сервисами Яндекса. В этом случае она выбирает ветку умений, отвечающую за взаимодействие с Go, и передаёт управление в Solaris.
Solaris — это оркестратор и сердце мультиагентской системы агентов Яндекс Go, которая сама является частью более широкой архитектуры Алисы AI. Именно он принимает решение, какие сервисы должны быть задействованы для выполнения запроса. Например, запрос про борщ может означать как покупку ингредиентов в Лавке, так и поиск ресторана через Еду. Алиса передаёт общее намерение, а Solaris решает, каких агентов нужно вызвать и как выстроить дальнейший сценарий.
Таким образом, мы разделили ответственность следующим образом: SDK чата отвечает за транспорт и пользовательский интерфейс, Алиса — за интерпретацию запроса и выбор ветки умений, а сложная логика взаимодействия между сервисами вынесена на уровень оркестрации.
Зачем понадобился отдельный оркестратор
Итак, давайте чуть подробнее взглянем на Solaris. Это не просто прокси-сервер, перекладывающий JSON-ы из одного кармана в другой, а полноценный оркестратор, как мы уже сказали, который выполняет две критически важные функции в нашей мультиагентной схеме.
Первая функция — резолвинг агентов.
Запрос пользователя часто бывает нечётким или комплексным. Когда вы пишете «Хочу борщ», для системы это неоднозначная команда. Solaris анализирует контекст и решает, кого именно нужно разбудить для выполнения задачи. В кейсе с борщом мы понимаем, что потребность может быть закрыта по-разному, поэтому оркестратор вызывает агентов под собой параллельно: агента Лавки, чтобы предложить ингредиенты, и агента Еды, чтобы предложить ресторан.
Но как заставить этих агентов понимать друг друга и отвечать в едином формате?
Здесь мы сделали ставку на новый open source протокол A2A (Agent2Agent). Это открытый стандарт, созданный специально для того, чтобы LLM-агенты могли бесшовно общаться между собой. В отличие от классического подхода, где агентов часто приходится оборачивать в жёсткие интерфейсы инструментов, A2A позволяет сохранить их автономность.
Протокол предоставляет общий язык для взаимодействия: агенты могут обменяться списком своих возможностей и затем перейти к обмену сообщениями. Для Solaris это означает колоссальное упрощение архитектуры: нам не важно, на каком фреймворке написан агент Лавки или Еды. Если он поддерживает A2A, он автоматически становится частью экосистемы, может сообщать о своих навыках и принимать задачи в стандартизированном потоке.
Это принципиальный момент: теперь пользователь может не выбирать сервис вручную. Мы агрегируем возможности разных вертикалей под один запрос.
Вторая функция — преобразование и мердж ответов.
Получив данные через A2A-каналы, оркестратор должен собрать их, валидировать и склеить в единую, связную выдачу для фронтенда. Пользователь при этом не должен видеть швы между микросервисами — он должен получить единый ответ, где гармонично соседствуют карточки продуктов и список ресторанов.
Но наша цель не только в том, чтобы просто сложить два ответа вместе. В планах развития Solaris заложен более сложный осознанный мердж с дополнением. Это логика, позволяющая строить кросс-сценарии.
Например: вы бронируете столик в ресторане через агента Еды. Solaris, видя успешное бронирование, понимает контекст: пользователю нужно будет добраться до этого места к определённому времени. В этот момент оркестратор сам, без дополнительного запроса, инициирует вызов агента Такси и добавляет в финальный ответ кнопку вызова машины или расчёт стоимости поездки.
Такая логика делает систему по-настоящему мультиагентной. Мы уходим от последовательного переключения между приложениями к модели, где один интент порождает цепочку действий в разных доменах, невидимую для пользователя, но управляемую единым мозгом.
Frontend: единая библиотека для всех вертикалей
Интегрировав SDK и получив рабочий чат, мы довольно быстро осознали, что теперь придётся дорабатывать всю логику взаимодействия пользователя с системой. Потому что одно дело — текстовый диалог с болталкой, и совсем другое — этот же самый диалог, в котором присутствуют сложные транзакционные сценарии: где нужно выбирать опции доставки, скроллить списки товаров или редактировать корзину.
Сначала мы посмотрели на готовые решения. Казалось логичным переиспользовать существующие UI-компоненты, которые уже есть в экосистеме Яндекса. Но попытка натянуть их на специфику чат-интерфейса мультиагентной системы ни к чему хорошему не привела. Это было, цитируя наши внутренние обсуждения, «очень больно и дорого». Потому что адаптировать существующие компоненты под новую логику асинхронного взаимодействия с AI было гораздо трудозатратнее, чем написать с нуля.
Так родилась библиотека новых UI-компонентов, которую мы сразу спроектировали как shared-ресурс.
Мы создали унифицированный набор визуальных элементов, который расшарили на все вертикали. Теперь любой сервис, подключающийся к этой схеме не рисует интерфейс сам. Разработчики этих команд берут готовые компоненты из нашей библиотеки и дорабатывают их под свои нужды.
Таким образом мы решили сразу две задачи:
- Скорость разработки. Командам не нужно думать над тем, как должна выглядеть карточка товара в чате или кнопка подтверждения заказа — они просто переиспользуют код.
- UX-консистентность. Для пользователя переключение между сценариями происходит бесшовно. Карточка салата из Лавки и карточка бургера из Еды строятся на одних и тех же принципах, сохраняя визуальное единство внутри диалога с ассистентом.
Backend: четыре принципа архитектуры YaDK
На старте работы над мультиагентной схемой мы, как и многие, сначала посмотрели по сторонам. Пытались базироваться на готовых рыночных решениях для построения агентов. Но быстро уперлись в реальность: наш пайплайн на них либо не воспроизводился вовсе, либо воспроизводился с огромным трудом и множеством костылей. Интегрировать внешние фреймворки в специфическую инфраструктуру Яндекса — не такая уж тривиальная задача.
Тогда мы пришли к логичному выводу: нужен свой инструмент. Он должен быть, во-первых, предельно простым в освоении, а во-вторых — максимально нативным для нашей среды. Сказано — сделано! Так появилась библиотека YaDK (Yandex Agent Development Kit).
В архитектуру YaDK мы заложили четыре фундаментальных принципа, которые позволяют писать агентов быстро и предсказуемо:
- Абстракция от LLM. Мы убеждены, что бэкенд-разработчик продуктовой команды не должен разбираться в том, как именно работает нейросеть под капотом. Вся агентская работа в библиотеке сведена к взаимодействию с примитивными интерфейсами. Это сущности, с которыми уже умеют работать все наши бэкендеры, что резко снижает порог входа.
- Строгая типизация и контракты. Мы на берегу согласовали все протоколы общения и маршрутизацию. Это значит, что когда разработчик пишет агента на YaDK, мы по умолчанию уже знаем, в каком формате он получит запрос и, что важнее, как он вернёт ответ.
- Маршрутизация через конфигурацию. Чтобы добавить нового агента в общее дерево стека, не нужно писать код связывания. Требуется просто добавить адрес агента в конфигурационный файл. Система сама подхватит его и включит в общий контур маршрутизации.
- Reliability и Observability из коробки. Так как мы амбициозно целимся в большое количество запросов, то совершенно точно не могли позволить себе никаких чёрных ящиков. В библиотеку сразу заложены инструменты надёжности и наблюдаемости (метрики, логирование, трейсинг), чтобы мы могли оценивать качество и стабильность работы каждого агента.
Главная цель YaDK — ускорение разработки. Мы хотели, чтобы любой наш коллега или любая другая команда могли написать агента быстро, просто и не изобретая велосипед. И это сработало!
Сценарии использования и планы на будущее
Что конкретно умеет получившаяся система на текущем этапе? Мы не строили абстрактного собеседника, с которым можно поболтать за жизнь — мы фокусировались на прикладных сценариях, где текстовый или голосовой ввод быстрее и удобнее прокликивания множества экранов.
Прямо сейчас Алиса AI в Go закрывает несколько ключевых доменов:
- Логистика: формирование заказов в Такси и Доставке.
- E-grocery и Foodtech: поиск ресторанов, подбор готовых блюд и сборка корзины продуктов в Лавке для конкретного рецепта.
- Информационные запросы: благодаря базовому функционалу Алиса AI умеет ходить в интернет. Она может найти нормы провоза багажа, порекомендовать хорошую постановку в театре или просто рассказать о погоде.
Куда мы движемся дальше?
Главный вектор развития — полная транзакционность внутри чата. Мы хотим, чтобы пользователь мог завершать сценарии, вообще не покидая интерфейс диалога.
Ещё одна амбициозная инженерная задача на следующий год — работа с памятью и персонализацией. У Алисы есть технология «Моя память», и мы планируем внедрить аналогичный механизм для агентов Яндекс Go. Более того, мы хотим объединить эти контексты. Часть знаний о пользователе есть у Алисы (общие предпочтения), часть — у Городских сервисов (история заказов, любимые рестораны).
Технически объединение этих баз знаний позволит создать действительно умный контекст. Если пользователь однажды напишет, что он вегетарианец или не ест лук, система запомнит это. При следующем запросе «хочу ужин» оркестратор, зная этот контекст, автоматически отфильтрует выдачу агентов Еды и Лавки, исключив неподходящие варианты.
Заключение
Сейчас, оглядываясь на проделанную работу, мы понимаем: нам по-настоящему удалось реализовать одну из первых в Яндексе мультиагентную схему. Само собой, это был не проект одной изолированной группы, а масштабная инженерная коллаборация между командой Алисы и вертикалями Go.
Ещё год назад идея о том, что суперапп будет понимать сложный контекст и вести осмысленный транзакционный диалог, казалась если уж не невозможной, то как минимум крайне сложной. Сегодня у нас есть работающая архитектура: встроенный SDK, оркестратор Solaris, библиотека YaDK и агенты, которые уже живут в продакшене.
Для нас как для разработчиков это полноценный сдвиг парадигмы: мы всё больше уходим от чисто детерминированных кнопочных интерфейсов к вероятностным AI-интерфейсам. Это, с одной стороны, создаёт ряд новых вызовов и сложностей, но взамен позволяет скрыть огромную часть взаимодействия десятков микросервисов за одной простой строкой ввода в чате.
