Клубок ИИ-агентов. Чему кейс Uber учит бизнес - Entaxy

Агент для продаж, помощник поддержки, агент для закупок — каждый из них понемногу облегчает рутинные задачи. Но стоит подключить их к одним корпоративным системам, как возникают вопросы: кто отвечает за подключения, какие данные кому доступны и где искать причину сбоя?

Uber описали именно такую историю. Команды самостоятельно создавали MCP-интеграции, инфраструктура дублировалась, инструменты было трудно найти и повторно использовать. Ответом стал MCP Gateway — единый шлюз между агентами и внутренними сервисами. На 1 октября 2026 года платформа объединяла более 800 MCP-серверов и 5000 инструментов.

Чтобы агенты могли работать с бизнес-системами, Uber понадобился управляемый интеграционный слой. Давайте разберемся как его можно построить на российском стеке, не разрабатывая заново инфраструктуру для каждого ИИ-помощника.

Что на самом деле построила Uber?

MCP, или Model Context Protocol, задаёт общий способ предоставлять ИИ-приложениям инструменты и данные. Но единый протокол не избавил Uber от разрозненных реализаций: каталог инструментов и обработку вызовов пришлось вынести в общую платформу.

В её архитектуре разделены две задачи. Реестр хранит описания MCP-серверов и инструментов, сведения об ответственности и доступности. Шлюз обрабатывает запросы: переводит MCP-вызовы в обращения к существующим сервисам по HTTP, gRPC или TChannel и возвращает результат агенту. Переписывать сами прикладные системы для этого не требуется.

Особенно показателен порядок публикации. Uber автоматически обнаруживает сервисы и формирует описания инструментов, но первоначально они отключены. Доступ открывает команда-владелец после проверки. Найти техническую возможность вызвать API — ещё не значит разрешить агенту ею пользоваться.

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

Почему MCP недостаточно

Представим, что три команды подключают своих агентов к учётной системе. Одна реализует преобразование данных, вторая — собственную обработку ошибок, третья — отдельное хранение реквизитов доступа. Даже если снаружи все три решения говорят на MCP, внутри остаются три интеграции, которые нужно сопровождать независимо.

Изменение интерфейса учётной системы приходится учитывать в каждой реализации. А при инциденте сначала нужно выяснить, через какую связку прошёл запрос.

Поэтому задача шире, чем «поднять MCP-сервер». Нужен слой, который отделяет агентские приложения от особенностей корпоративных систем: преобразует сообщения, направляет запросы, обрабатывает сбои и позволяет проследить выполнение. Именно здесь полезна интеграционная платформа.

Построение общей среды интеграции

Для работы с MCP в Энтакси предусмотрена генерация протокольной инфраструктуры. Платформа формирует транспортную обвязку, обработку JSON-RPC, ветки маршрутизации для инструментов, ресурсов и шаблонов запросов. Используются механизмы безопасности платформы, включая JAAS и OAuth. При этом бизнес-логику инструмента и его связь с конкретной системой по-прежнему нужно проектировать и реализовывать.

Вместо того чтобы каждый агент самостоятельно разбирался с интерфейсами учётной системы, команда создаёт интеграционный маршрут и предоставляет нужную функцию через MCP. Другие агенты могут использовать её без повторной разработки подключения.

Например, агенту не обязательно знать, каким запросом получить остатки из складской системы и как сопоставить её коды товаров с кодами CRM. Эти правила можно реализовать в маршруте Энтакси. Агенту предоставляется инструмент с определёнными параметрами и ожидаемым результатом.

Энтакси при этом не следует считать готовой копией MCP Gateway Uber. Автоматическое обнаружение серверов, общий каталог инструментов и согласование публикации, представляют отдельные требования к решению. Платформа даёт интеграционную основу и генерацию MCP-сервисов; весь комплекс управления агентами нужно проектировать с учётом задач компании.

Один заказ, несколько систем

Рассмотрим практический пример: российский дистрибьютор хочет поручить агенту подготовку предложения клиенту. Данные о клиенте находятся в CRM, цены и договорные условия — в 1С, остатки — в складской системе.

При прямых подключениях агенту пришлось бы работать с несколькими интерфейсами и согласовывать их ответы. В архитектуре на Энтакси можно спроектировать более узкий инструмент — «Подготовить данные для предложения».

1. Агент передаёт идентификатор клиента и список товаров, а маршрут проверяет обязательные параметры.

2. Настроенные подключения получают сведения из CRM, 1С и складской системы; маршрут сопоставляет идентификаторы и приводит данные к единому формату.

3. Правила обработки исключают из ответа поля, не нужные для предложения. Агент получает согласованный набор цен, условий и остатков.

4. Если один из источников недоступен, маршрут возвращает предусмотренный статус ошибки или неполных данных. В интерфейсе агента такой результат нельзя выдавать за подтверждённое предложение.

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

Когда такой инструмент понадобится помощнику продаж и агенту поддержки, у них появится общая реализация доступа к данным. Если интерфейс складской системы изменится, можно будет обновить подключение и сохранить внешний контракт инструмента — при условии, что его смысл и формат ответа не меняются.

Доступ и ответственность важнее промпта

В Uber шлюз проверяет права на уровне инструментов и скрывает чувствительные данные в ответах. Эти ограничения встроены в инфраструктуру, а не оставлены на усмотрение модели.

При проектировании решения на Энтакси стоит придерживаться того же принципа. Разрешение получить остатки не должно автоматически давать право менять заказ. Просьба в системном промпте «не изменять документы» не заменяет ограничения доступа. Для операций записи нужны отдельные инструменты, проверки и, где это требуется, подтверждение сотрудника.

Энтакси предоставляет механизмы авторизации сервисов, хранения ключей и секретов, а также аудит-логирование. Но конкретные права агента, проверку полномочий инициатора и правила передачи его контекста нужно настроить в общей архитектуре. Поддержка OAuth сама по себе не решает задачу делегирования полномочий через цепочку агентов.

Для разбора сбоев в Энтакси предусмотрены журналы транзакций и процессов: идентификатор запроса позволяет связать записи разных этапов маршрута. Чтобы по ним можно было восстановить действия ИИ-сценария, на этапе проектирования нужно определить, как фиксируются инициатор, агент и операция. При этом чувствительные данные не должны попадать в журналы без необходимости.

Локальное развёртывание Энтакси и возможность работы без доступа к внешним ресурсам полезны для российских организаций с изолированными сегментами сети. Но размещение шины внутри компании не делает локальной внешнюю языковую модель: разрешённый состав передаваемых ей данных нужно определять отдельно. Соответствие требованиям защиты информации зависит от всей системы, а не только от выбора платформы.

Не загружайте агенту весь каталог

На масштабе Uber возникла ещё одна проблема: описания тысяч инструментов перегружали контекст модели. Компания применила поэтапный поиск инструментов, сокращение ответов до нужных полей и работу через командную строку с сохранением результатов в файлы.

Агенту нужен не весь ИТ-ландшафт, а набор возможностей для конкретной задачи. У помощника закупок и агента поддержки могут быть разные инструменты, даже если они используют одну интеграционную платформу.

Средства преобразования данных Энтакси позволяют реализовать подготовку компактного ответа в маршруте. Например, вернуть по заказу статус и ожидаемую дату отгрузки, а не полную карточку со служебными полями. Это не тождественно механизму Response Projection Uber, но решает близкую задачу на уровне конкретной интеграции: не передавать модели лишнее.

С чего начинать прямо сейчас?

Не стоит ждать появления пяти тысяч инструментов. Выберите процесс, в котором несколько агентов обращаются к одним данным. Проверьте, есть ли у подключений общая реализация, владелец, ограничения доступа и понятная диагностика.

Для пилота полезнее оценивать не количество подключённых агентов, а управляемость сценария: сколько времени занимает публикация нового инструмента, можно ли использовать его повторно, как быстро находится причина сбоя и удаётся ли изменить подключение без переделки всех потребителей. Отдельно стоит проверить поведение при недоступности источника и повторном запросе на запись, т.к. гарантированная доставка сообщения не равна защите от создания дубликатов документов.

Энтакси нужна здесь не для того, чтобы решать за агентов, кому какую задачу поручить. Её роль — организовать их взаимодействие с корпоративными системами: дать общую интеграционную основу, стандартизировать MCP-сервисы и сократить число независимо сопровождаемых подключений. Если несколько команд уже строят собственные мосты к одной и той же 1С, обсуждать эту основу пора сейчас, пока клубок ещё можно распутать.