AvioBook, разработчик ПО для авиакомпаний в составе Thales Group, собрала мультиагентную систему Connected Analytics на Amazon Bedrock AgentCore. Система отвечает на вопросы авиаменеджеров и диспетчеров операционного центра управления (OCC) на естественном языке, опираясь на операционные данные платформы AvioBook Connect.
Коротко о главном. Два ролевых агента: один работает с историческими данными и проверяет корректность кодов задержек, второй обрабатывает живые запросы и оценивает каскадные эффекты нарушений в расписании. Доступ к данным вынесен в MCP-инструменты в AgentCore Gateway, запросы уходят в Amazon Athena и S3 через Glue Data Catalog, а привязка пользователя к конкретной авиакомпании идёт через JWT и Cognito. Заявленный экономический ориентир: сокращение времени разворота борта на 2-4 минуты, что для перевозчика с 200 рейсами в день даёт около 495 тыс. долларов в месяц. Всё описанное - proof-of-concept, а не боевая эксплуатация.
Что такое Amazon Bedrock AgentCore и почему AvioBook выбрала его
Amazon Bedrock AgentCore - платформа AWS для сборки, запуска и оркестрации AI-агентов. Она закрывает то, что обычно приходится писать самому: управление сессиями, изоляцию среды исполнения, подключение внешних инструментов, единый шлюз к данным и контроль доступа. Модель можно взять из Bedrock или подключить другую, а логику агента описать в коде или конфигурации.
Чем AgentCore отличается от простого вызова LLM через API
Вызов LLM через API - это один запрос и один ответ. Модель получает текст и возвращает текст. Она не помнит предыдущий шаг, не имеет доступа к базе данных и не может сама сходить за цифрами.
AgentCore добавляет четыре слоя:
- Состояние сессии. Многошаговый диалог с сохранением контекста между вызовами.
- Маршрутизация между агентами. Платформа решает, какой агент берёт конкретный запрос.
- Gateway для инструментов. Внешние действия подключаются по протоколу MCP.
- Контроль доступа. Identity пользователя распространяется на все вызовы инструментов.
Разница простая: LLM-API отвечает на вопрос, агент решает задачу. Первый не знает, откуда взять данные о задержках конкретного рейса, второй достаёт их через инструмент и подкрепляет ответ ссылкой на источник.
Задача AvioBook: от ручных отчётов к вопросам на естественном языке
Диспетчер OCC работает с расписанием, оборотами бортов, задержками, экипажами. Данные лежат в разных системах, а ответ на вопрос «сколько раз за прошлый месяц технические задержки превышали 30 минут» обычно требует выгрузки, сводной таблицы и ручной проверки кодов причин.
AvioBook Connect собирает операционные данные авиакомпаний. Connected Analytics должна была превратить их в ответы на естественном языке: вопрос, ответ с доказательствами, решение принимает человек.
Выбор AgentCore объясняется стеком. Данные уже жили в Amazon S3, аутентификация работала на Cognito, метаданные лежали в Glue Data Catalog, запросы шли через Athena. Платформа давала MCP-совместимый Gateway и управляемую оркестрацию, поэтому команде не пришлось строить маршрутизацию агентов и управление сессиями с нуля.
Архитектура Connected Analytics: два агента, две роли
Connected Analytics состоит из двух ролевых агентов. Каждый получает свой набор MCP-инструментов, свои системные промпты и свой контекст.
Агент исторических данных: проверка кодов задержек и паттерны
Первый агент работает с накопленными данными AvioBook Connect. Его основная функция - проверять корректность кодов задержек по классификации IATA и отвечать на вопросы по историческим срезам. Пример запроса: сколько раз за последний месяц задержки по техническим причинам превышали 30 минут и какие борта чаще всего попадали в такие ситуации.
Агент не читает таблицы напрямую. Он формирует SQL-запрос, отправляет его через инструмент в Amazon Athena, та выполняет запрос по данным в S3, используя метаданные из Glue Data Catalog. Ответ приходит в виде строк и агрегатов, а модель пересказывает их на естественном языке.
Отдельный слой работы - валидация кодов. Если диспетчер указал код, не соответствующий описанию, агент это замечает и показывает расхождение. На исторических данных такие ошибки видны как аномалии: одно и то же событие кодируется по-разному у разных смен.
Оперативный агент: живые запросы и каскадные эффекты
Второй агент обрабатывает запросы по текущему дню. Главная функция - оценка каскадных эффектов. Борт задержался на 40 минут: какие следующие сегменты затронуты, где экипаж выйдет за пределы рабочего времени, какой рейс придётся переназначить.
Такие вопросы требуют других инструментов. Нужны не агрегаты за месяц, а конкретные рейсы, назначения бортов и ограничения по времени работы экипажей. Логика здесь ближе к планированию, чем к отчётности.
Почему не один универсальный агент
Соблазн сделать одного агента с десятью инструментами понятен. На практике качество выбора инструмента падает с ростом их числа: модель путает похожие описания, смешивает контексты и вызывает лишние действия. Отладка превращается в охоту за призраками, потому что непонятно, где ошибка: в промпте, в описании инструмента или в маршрутизации.
Разделение по ролям снижает нагрузку на модель и упрощает оценку качества: каждый агент тестируется отдельно на своём наборе запросов. Координация нескольких агентов подробно разбирается в материале про архитектуру коллективного разума, где провалы мультиагентных систем связываются с отсутствием семантического слоя для координации, а не со слабостью моделей.
MCP инструменты для доступа к данным: как это работает в AgentCore Gateway
MCP (Model Context Protocol) - открытый протокол, который описывает, как модель вызывает внешние инструменты. Инструмент задаётся именем, описанием и схемой входных параметров. Модель видит этот список и решает, что вызвать.
Цепочка данных: от вопроса пользователя до ответа через Athena и S3
Путь запроса выглядит так:
- Пользователь задаёт вопрос в интерфейсе Connected Analytics.
- Агент определяет, какой MCP-инструмент подходит, и извлекает параметры: период, авиакомпанию, фильтр по типам задержек.
- AgentCore Gateway маршрутизирует вызов к нужному инструменту.
- Инструмент собирает SQL-запрос и отправляет его в Amazon Athena.
- Athena выполняет запрос по данным в Amazon S3, опираясь на схему из Glue Data Catalog.
- Результат возвращается агенту, тот формирует ответ на естественном языке и прикладывает данные, на которых основан вывод.
Ключевая деталь: агент никогда не обращается к хранилищу сам. Он видит только результат инструмента. Это ограничивает пространство действий модели и делает поведение предсказуемым.
Почему MCP-инструменты вынесены в Gateway, а не встроены в агента
- Единая точка контроля доступа. Права и фильтры меняются в инструменте, без пересборки и повторного деплоя агента.
- Переиспользование. Оба агента обращаются к одним и тем же базовым инструментам, отличаются только специализированные.
- Независимое тестирование. Инструмент проверяется отдельно: подставили параметры, посмотрели SQL и результат.
- Совместимость. MCP-инструменты работают и с другими MCP-клиентами, а не только с этим агентом.
На практике самодокументируемые инструменты с внятными описаниями заметно сокращают объём контекста, который уходит в модель. Разбор реального MCP-сервера с архитектурой, авторизацией и снижением контекста на 74% есть в кейсе MCP для агентной коммерции.
Безопасность и мультитенантность: JWT, Cognito и привязка к авиакомпании
AvioBook Connect обслуживает несколько авиакомпаний одновременно. Данные одного перевозчика не должны попадать к другому, и это обязательное требование, а не пожелание.
Как JWT и Cognito обеспечивают изоляцию данных между авиакомпаниями
Схема простая и предсказуемая:
- Пользователь проходит аутентификацию в Amazon Cognito.
- Cognito выдаёт JWT, в claims которого лежит идентификатор авиакомпании.
- Токен уходит вместе с запросом к MCP-инструменту.
- Инструмент проверяет подпись токена и сам добавляет в SQL условие вида
WHERE airline_id = ..., подставляя значение из claims.
Важный момент: агент не передаёт идентификатор авиакомпании как параметр. Значит, модель не может его подменить или выдумать. Фильтр формируется на стороне инструмента из проверенного токена. Даже если агент сформулирует запрос на данные другого перевозчика, инструмент вернёт только разрешённый срез.
Такой контур не закрывает все риски агентов. Отдельно остаются защита от prompt injection, разделение контуров и контроль вызовов инструментов. Чек-лист по этим темам собран в разборе про теневую сторону ИИ-агентов, где пилоты разбиваются о грязные данные и отсутствие архитектуры безопасности.
Ответственность и доказательства: почему решения остаются за человеком
Система отвечает с доказательствами. На вопрос «почему рейс задержался» агент не ограничивается формулировкой «из-за погоды», а показывает конкретные записи: код задержки, время, борт, источник данных. Диспетчер видит основание и может его проверить.
Решение принимает человек. В авиации цена ошибки измеряется безопасностью и деньгами, поэтому право менять расписание агенту никто не отдаёт. Connected Analytics готовит ответ и подсказывает варианты, окончательный выбор за специалистом OCC.
У подхода есть побочная выгода: аудит становится тривиальным. Для каждого ответа можно восстановить цепочку: какой инструмент вызвали, какой SQL ушёл в Athena, какие строки вернулись.
Экономические ориентиры: 2-4 минуты разворота и 495 тыс. долларов в месяц
AvioBook заявляет ориентир: аналитика на естественном языке помогает сократить время разворота воздушного судна на 2-4 минуты. Для перевозчика с 200 рейсами в день это даёт до 495 тыс. долларов экономии в месяц.
Как считаются эти цифры и что они не учитывают
Расчёт опирается на стоимость минуты простоя борта для типового перевозчика. Арифметика прозрачная: минуты умножаются на число рейсов и стоимость минуты.
Что остаётся за скобками:
- Стоимость разработки, хостинга и поддержки системы.
- Время персонала на обучение работе с агентом.
- Ошибки агента и их последствия, например неверная подсказка, которая привела к лишнему перемещению борта.
- Методика измерения самих 2-4 минут. Неясно, получены они на proof-of-concept или в реальной эксплуатации.
Воспринимайте 495 тыс. долларов как порядок величины, а не как гарантированный результат. Логика при этом рабочая: минута простоя стоит денег, а быстрый доступ к аналитике позволяет раньше замечать причину задержки.
Ограничения proof-of-concept и что дальше
Материал описывает proof-of-concept. Система протестирована на ограниченном наборе данных, не проверена на пиковых нагрузках реальной эксплуатации и не встроена во все бизнес-процессы AvioBook. Выводы о качестве ответов получены в контролируемых условиях.
Проактивный алертинг аномалий: следующий шаг AvioBook
Сегодня система отвечает на запросы. Следующий шаг - сама инициирует уведомления: замечает, что код задержки указан некорректно, или что каскадный эффект превысит допустимый порог, и пишет диспетчеру до того, как он сам догадается спросить.
Технически это делается на той же инфраструктуре: те же агенты, те же MCP-инструменты, плюс триггеры и фоновые проверки. На момент публикации эти планы не реализованы.
Что можно забрать из этого кейса для своего проекта
Три паттерна переносятся за пределы авиации и AWS.
- Разделение агентов по ролям. Каждый агент получает свою персону, свой набор инструментов и свои промпты. Это упрощает отладку и оценку качества.
- Вынос доступа к данным в MCP-инструменты. Инструмент отвечает за SQL и фильтры, агент за формулировки. Права меняются без пересборки агента.
- Ответы с доказательствами и решение за человеком. Агент показывает, на каких данных основан вывод, и не подменяет специалиста.
Когда стоит смотреть в сторону Amazon Bedrock AgentCore
AgentCore уместен, если вы уже живёте в AWS с Athena, S3 и Cognito, вам нужна управляемая оркестрация агентов и вы готовы описывать инструменты по MCP. Тогда интеграция даёт наименьшее трение.
Если вы вне AWS или строите полностью локальный контур, разумнее смотреть на другие варианты: LangGraph, CrewAI и собственные реализации. Пошаговый разбор того, как собрать агента без платформы, с оркестрацией, памятью, обработкой ошибок и сравнением latency и стоимости, есть в материале строим AI-агента с нуля.
Какие вопросы задать перед стартом похожего проекта
- Какие данные нужны и где они лежат?
- Кто пользователи и какие у них роли?
- Как изолируются данные между тенантами?
- Какие инструменты получат агенты и можно ли вынести их в MCP?
- Как проверяется корректность ответов?
- Что происходит, когда агент ошибается?
- Как измеряется эффект и по какой методике?
Если на первые три вопроса нет внятного ответа, начинать с агентов бессмысленно. Сначала данные и доступ, потом модель.