Представим обычную задачу: хочется куда-нибудь уехать на выходные. Есть бюджет, свободная суббота и воскресенье, желание оказаться у воды и условие вернуться домой до полуночи.
В привычном интерфейсе сначала приходится решить, куда ехать. Потом отдельно проверить билеты, посмотреть отели, сравнить время в пути и цены, вернуться к первому варианту, потому что второй оказался слишком дорогим, и заново собрать поездку.
Привет! Меня зовут Арут Агабабян, я CTO Туту и один из организаторов нашего ИИ-хакатона. В Туту я отвечаю за технологическое развитие компании и много работаю с тем, как новые технологии можно превращать в реальные пользовательские сценарии. В этой статье расскажу, зачем мы открыли сервисы Туту для ИИ-агентов через MCP, что получилось у участников хакатона и какие выводы мы сделали про будущее агентных решений в travel-tech.
Для ИИ-агента естественнее другой сценарий: человек описывает ограничения обычным языком, а система сама раскладывает задачу на несколько действий и обращается к нужным сервисам.
Путешествие редко состоит из одной операции: нужно совместить транспорт, даты, жилье, бюджет и иногда несколько пассажиров. Поэтому в начале лета мы открыли сервисы Туту для ИИ-агентов через Model Context Protocol (MCP), а в августе дали эту инфраструктуру участникам всероссийского хакатона.
Рассказываем, зачем вообще тревел-сервису MCP, что на нем начали собирать разработчики и какие ограничения у агентного подхода уже видны.
ИИ постепенно становится еще одним интерфейсом к travel-tech
До недавнего времени генеративный ИИ в путешествиях в основном использовали как консультанта. У модели можно было спросить, куда поехать на три дня, что посмотреть в Казани или в каком районе Стамбула искать отель.
Проблема начиналась на следующем шаге. Модель знает, что из Москвы в Петербург ходят поезда, но ее собственных знаний недостаточно, чтобы надежно ответить, какие места доступны вечером 18 сентября и сколько они стоят прямо сейчас. Для этого нужен доступ к реальным данным сервиса.
Параллельно меняется и сам путь пользователя к покупке. В июне Forbes Technology Council описывал эту трансформацию через две технологии: GEO — Generative Engine Optimization, оптимизацию присутствия в ответах генеративных систем, — и MCP — Model Context Protocol, протокол подключения моделей к внешним данным и инструментам. В приведенном Forbes исследовании 64% маркетологов назвали снижение использования традиционного поиска одним из главных ожидаемых последствий распространения AI-поиска.
Для travel-tech эти два механизма решают разные задачи.
GEO влияет на этап, когда пользователь спрашивает: «Куда мне поехать и что выбрать?» Здесь важны контент, отзывы, рейтинги, упоминания и другие данные, на основании которых модель формирует ответ.
MCP нужен дальше, когда от общего совета требуется перейти к конкретному действию: проверить расписание, найти доступный номер, сравнить варианты и подготовить пользователя к оформлению.
То есть между запросом «хочу на выходные к морю» и покупкой постепенно появляется новый программный слой.
Что MCP меняет на практике
Model Context Protocol — открытый протокол для взаимодействия языковых моделей с внешними инструментами и источниками данных.
Если сильно упростить архитектуру, получается такая цепочка:
Например, пользователь может попросить найти поезд Москва — Петербург. Агент понимает направление и дату, вызывает доступный через MCP инструмент поиска и получает актуальные варианты. После этого модель уже может работать с результатом: сравнить отправления, объяснить различия и помочь выбрать подходящий.
Сейчас через Tutu MCP агентам доступны пять основных направлений: самолеты, поезда, автобусы, электрички и отели. Для размещения можно использовать в том числе оценки и отзывы.
При этом мы сознательно оставили границу перед чувствительными действиями. Агент может провести пользователя через поиск и подготовить переход к заказу, но данные пассажира, окончательная проверка и оплата остаются на сайте Туту.
Для текущего этапа развития агентных интерфейсов human-in-the-loop — участие человека в критической точке сценария — выглядит вполне практичным компромиссом. Цена ошибки при рекомендации отеля и цена ошибки при оплате билета различаются.
Зачем после запуска MCP понадобился хакатон
Сделать API или MCP-сервер — только половина задачи. Вторая половина начинается с вопроса: что сторонние разработчики вообще будут строить, если дать им доступ к тревел-инструментам?
Внутри продукта мы неизбежно смотрим на путешествие через существующие сценарии. Есть выдача билетов, карточка отеля, заказ, личный кабинет. Внешняя команда гораздо меньше ограничена историей этих интерфейсов.
Поэтому с 19 по 21 августа мы провели всероссийский ИИ-хакатон. Задача была довольно широкой: разработать проект на основе Tutu MCP, который решает реальную проблему путешественника.
На участие пришла 301 заявка. На хакатон прошли 150 человек — 71 команда. До сдачи проектов дошли 42 команды, девять решений вышли в финал.
Мы специально оценивали не только факт использования ИИ. В критериях были понимание задачи, глубина функционала, UX/UI, документация, архитектура, качество кода, технологическая новизна и стабильность работы. Добавить LLM к форме поиска сравнительно легко. Нам было интереснее посмотреть, появляется ли за этим новый пользовательский сценарий.
Поисковая форма оказалась далеко не единственной точкой входа
Самое интересное в результатах хакатона — даже не отдельные проекты, а повторяющиеся модели поведения.
Часть команд начинала планирование поездки с повода. Человек знает, что ему нужно попасть на мероприятие или собрать людей из разных городов к определенной дате. Город, транспорт и жилье становятся уже результатом расчета.
Другие команды экспериментировали с discovery-сценариями, где человек вообще не начинает с формы «откуда — куда». Начальной информацией могут быть впечатление, изображение или очень свободное описание желаемой поездки. Дальше агент постепенно переводит это намерение в параметры, с которыми уже могут работать реальные тревел-сервисы.
Еще один класс задач связан с групповым планированием. Обычная выдача хорошо устроена для одного покупателя. Если несколько людей едут из разных городов, нужно учитывать несколько расписаний, общий дедлайн, бюджет и компромиссы между участниками.
Наконец, оказалось полезно строить поиск вокруг жесткого ограничения. Например: «У меня 20 тысяч рублей, три дня и нужно вернуться в Москву к понедельнику утром». Здесь задача начинается не с выбора конкретного направления, а с вычисления множества реально достижимых вариантов.
Все четыре подхода объединяет одна вещь: пользовательское намерение оказывается сложнее набора полей в традиционной форме поиска. И именно здесь языковая модель полезна как слой, который переводит свободный человеческий запрос в последовательность формализованных действий.
В агентной модели важен источник правды
Генеративная модель может хорошо понять фразу «хочу недорого уехать куда-нибудь, где тепло». Но цена билета, свободный номер и расписание поезда — это факты, которые нельзя получать из вероятностного ответа модели. Поэтому важно разделять две функции системы.
LLM хорошо работает с намерением, контекстом и выбором следующего действия. Продуктовый backend отвечает за фактические данные и выполнение операции.
Для пользователя эти слои могут выглядеть как один разговор. Внутри системы между ними должна оставаться четкая граница.
Это особенно заметно на travel-tech-продукте, где данные быстро меняются. Даже качественный ответ, построенный на вчерашней цене или уже недоступном месте, бесполезен.
MCP здесь интересен не потому, что делает модель «умнее». Он дает ей стандартизированный способ обращаться к инструментам, способным ответить на вопрос сейчас.
Чем больше агент умеет делать, тем важнее безопасность
У агентной архитектуры есть обратная сторона. Как только модель получает инструменты, последствия ошибки становятся серьезнее.
Обычная языковая модель может сгенерировать неправильную фразу. Агент с доступом к инструментам потенциально способен вызвать неправильную функцию, передать лишние параметры или отреагировать на вредоносную инструкцию в данных, которые получил извне.
На хакатоне мы дважды зафиксировали попытки атак через инъекции. Сам факт хорошо показывает, почему безопасность MCP-сервера нельзя рассматривать как приложение к основной функциональности.
Prompt injection — инъекция инструкций в контекст модели — остается одной из проблем агентных систем. Например, вредоносная инструкция может находиться в тексте, который модель получила из внешнего источника, и попытаться заставить агента изменить исходную задачу или вызвать другой инструмент.
Поэтому по мере расширения возможностей агента приходится думать уже не только о качестве промпта. Нужны контроль доступных действий, проверка параметров, разделение read- и write-операций, ограничения прав, журналирование вызовов и подтверждение человеком критичных действий.
Это одна из причин, почему в текущем сценарии Туту финальная покупка остается за пользователем.
MCP пока не означает, что пользователи завтра перестанут открывать сайты
Здесь легко перескочить от эксперимента к выводу, что привычный поиск скоро исчезнет. Мы бы с этим не спешили.
Сам факт появления MCP-сервера не создает пользовательский трафик: клиент должен поддерживать протокол, а сервер нужно подключить. Полностью автономных тревел-агентов, которые без участия человека проходят весь путь от идеи до покупки, рынок пока тоже не получил.
Но инфраструктурная часть развивается быстро. Сейчас Tutu MCP уже можно подключать к нескольким совместимым клиентам и использовать как инструмент внутри агентного сценария.
Поэтому для нас MCP пока скорее новый канал взаимодействия с продуктом, чем замена сайту или приложению.
Что мы вынесли из эксперимента
После запуска MCP и хакатона наше представление об агентном travel-tech стало немного конкретнее.
Первое наблюдение связано с интерфейсом. Когда человек может сформулировать конечную цель обычным языком, точкой входа в продукт необязательно остается поисковая форма. Для некоторых задач удобнее сначала понять намерение и ограничения, а форму параметров собрать уже внутри системы.
Второе — агент особенно полезен в задачах, где нужно связать несколько действий. Отдельный поиск авиабилета решается существующими интерфейсами достаточно хорошо. Задача «найди, куда мы втроем можем улететь из разных городов, чтобы встретиться на выходных и уложиться в общий бюджет» уже заметно сложнее.
Третье — качественная агентная система требует надежного инструментального слоя. Без актуальных данных языковая модель остается консультантом. Доступ к продуктовым инструментам превращает ее в интерфейс к сервису.
Четвертое — полезность агента растет вместе с риском. Чем ближе система подходит к реальным действиям и деньгам, тем важнее контроль инструментов, безопасность и понятные точки подтверждения пользователем.
И наконец, MCP сам по себе не решает продуктовую задачу. На хакатоне лучше всего выглядели идеи, где сначала была понятная проблема путешественника, а уже затем появлялись ИИ и инструменты для ее решения.
А что получили участники
Мы хотели, чтобы хакатон был полезен не только Туту.
Для участников это была возможность за несколько дней проверить собственную идею на реальном travel-tech-контексте, поработать с Tutu MCP и получить обратную связь от людей, которые каждый день делают продукты для путешествий.
Можно было прийти с гипотезой, собрать ее в работающий прототип и сразу увидеть, где идея действительно решает пользовательскую задачу, а где пока существует только на уровне красивой концепции.
Авторы лучших проектов получили призы, технику, мерч и сертификаты Туту на путешествия. Партнером хакатона стала Huawei, которая предоставила технику для призового фонда.
Но, пожалуй, самая интересная часть для нас начинается после финального питчинга. Девять проектов вошли в число лучших, три заняли призовые места, а некоторые идеи мы сейчас изучаем вместе с продуктовыми командами. Подробности пока не раскрываем: сначала хотим разобраться, какие из решений можно развивать дальше и в каком формате это делать вместе с авторами.
Поэтому участие в наших хакатонах — это не только три дня разработки и возможность забрать приз.
Это способ:
— получить доступ к реальной технологической инфраструктуре travel-tech-компании;
— проверить свою гипотезу на прикладной задаче;
— показать решение инженерам и продуктовым командам Туту;
— получить обратную связь от экспертов;
— и, если идея действительно сильная, продолжить разговор уже после окончания соревнования.
Ну и путешествия, конечно. Мы все-таки Туту :)
Планируем продолжать такие форматы. Поэтому если вам интересны ИИ, агентные системы и travel-tech, следите за нашими следующими хакатонами.
Что дальше
Мы пока не знаем, станет ли диалог с ИИ таким же привычным способом покупать путешествия, каким когда-то стал сайт или мобильное приложение.
Но уже видно, что агентная модель создает еще один способ взаимодействия с travel-tech. Пользователь формулирует намерение, модель помогает его разобрать, а специализированные сервисы предоставляют актуальные данные и выполняют конкретные операции.
Для компаний это означает появление нового технического вопроса: насколько продукт готов к ситуации, когда его интерфейсом становится чужой ИИ-агент?
Мы начали отвечать на него с MCP. Хакатон показал, что поверх такого слоя можно строить сценарии, которые сложно было бы придумать, если исходить только из привычной поисковой выдачи.
Теперь интереснее всего проверить, какие из них выдержат столкновение с реальными пользователями.
Автор: Arutyun92
