Взгляд практика на агентский уровень MuleSoft: Model Context Protocol и Agent Fabric поверх управляемого Anypoint Exchange, превращающие ИИ-ассистентов и автономных агентов из угадывающих систем в регулируемых участников.
Задайте корпоративному ИИ-ассистенту простой вопрос: какое API отслеживает заказ, кто его владелец и как получить доступ? Без опоры на проверенные данные ассистент все равно ответит. Он прочитает любые страницы вики, попавшие в контекст, смешает их с паттернами из обучающей выборки и выдаст что-то уверенное, правдоподобное и зачастую неверное. Автономный агент повышает ставки еще сильнее: он не просто дезинформирует разработчика, он действует, формируя вызовы к конечным точкам, которые понимает лишь наполовину, с учетными данными, которых у него быть не должно.
Модный диагноз заключается в том, что модели должны стать лучше. Опыт работы «в полях» подсказывает, что реальная преграда проще и ближе к дому: большинство предприятий не могут ответить на базовые вопросы о своем собственном ИТ-ландшафте в машиночитаемом виде. Какие API существуют, что говорится в их контрактах, кто их владельцы, как предоставляется доступ. Обнаружение всегда было болезненным для людей, и люди компенсируют это знаниями коллег и вопросами в кулуарах. Агенты не могут так поступать. Агент ровно настолько хорош, насколько хороша его карта ИТ-ландшафтя, а у большинства компаний ее нет.
Это проблема, которую решает агентский уровень MuleSoft, и именно поэтому Anypoint Exchange имеет в эпоху агентов гораздо большее значение, чем когда-либо имел в качестве каталога для просмотра. Exchange — это управляемая система записей, ориентированная на API. Поместите Model Context Protocol перед ней, и каждый ассистент, второй пилот (copilot) и автономный агент унаследуют одну и ту же обоснованную карту. Добавьте Agent Fabric, и сами агенты присоединятся к реестру. Причем ИИ не только потребляет результат: как показывает разработка в основе этой статьи, ИИ ускоряет создание самого уровня, сокращая четверть работы по интеграции до считанных дней.
Рисунок 1. Два будущего для одного и того же вопроса. Агент без карты отвечает по устаревшим источникам и импровизирует с доступом. На агентском уровне вопрос попадает на конечную точку MCP поверх управляемого каталога Exchange: ответ является записью, а каждое действие остается в рамках политик.
Проблема, переосмысленная для эпохи агентов
Проблема поиска существовала задолго до появления ИИ. Инженеры всегда тратили вторую половину дня на поиски API, владельцев и документации. Изменился профиль затрат. Человек, не сумевший найти нужное API, теряет время; необоснованный агент теряет доверие компании:
- Ассистент отвечает на вопросы об интеграции по устаревшим страницам вики и звучит при этом уверенно.
- Агент обнаруживает конечные точки путем сканирования, не имея представления о жизненном цикле, устаревании или версиях контрактов.
- У агента нет регулируемого способа запросить доступ, поэтому пилотные проекты либо буксуют на уровне «только чтение», либо обходят политики стороной.
- Каждая команда агентов строит собственную закрытую опись ИТ-ландшафта, и эти описи расходятся.
Все это не проблема моделей. Это проблема систем учета, и это единственная проблема, которую интеграционная платформа уже решила сама для себя. Exchange содержит управляемые контракты, версии, владельцев и рабочие процессы доступа, и все это доступно через API. Эпоха агентов добавляет срочность: причину выставить эту машиночитаемую правду перед каждым ИИ-интерфейсом, который использует компания.
Агент хороши ровно настолько, насколько хороша карта ИТ-ландшафта. Агентский уровень — это и есть такая карта, управляемая и автоматически поддерживаемая в актуальном состоянии.
Агентский уровень: MCP поверх проверенных данных
MuleSoft теперь поставляет поддержку Model Context Protocol по всей платформе. Сервер MuleSoft MCP Server предоставляет возможности Anypoint любому клиенту, поддерживающему MCP, а коннектор MCP Connector позволяет командам превращать приложения Mule в серверы MCP, благодаря чему существующие интеграции становятся инструментами, которые может вызывать агент. Разместите конечную точку MCP поверх управляемого каталога, и обнаружение станет интерактивным для всех ИИ-интерфейсов одновременно: второго пилота в IDE разработчика, чат-ассистента бизнес-пользователя, автономного агента внутри рабочего процесса.
Разница между этим и предоставлением агенту возможности просматривать вики — это разница между свидетелем и слухом. Когда каталог отвечает через MCP, ответ представляет собой управляемую запись: опубликованный контракт, зарегистрированный владелец, заявленный жизненный цикл и глубокая ссылка на управляемый рабочий процесс для всего, что связано с транзакциями. Запрос доступа перестает быть импровизацией агента с учетными данными и становится тем же самым стандартным процессом контрактов API Manager, который используют люди, выполняемым в рамках политик.
Рисунок 2. Агентский уровень в работе. Ассистенты и агенты задают вопросы на обычном языке через конечную точку MCP поверх каталога. Ответы содержат управляемую запись, а любые действия проходят через те же контракты и рабочие процессы доступа, которые используют люди.
Agent Fabric: агенты присоединяются к каталогу
Вектор развития MuleSoft усиливает эту ценность. Agent Fabric, плоскость управления платформы для ИИ-агентв, серверов MCP и API, рассматривает агентов как полноправных участников каталога. Реестр агентов (Agent Registry) обнаруживает и регистрирует агентов, серверы MCP и активы LLM в Anypoint Exchange, включая агенты, созданные на внешних платформах. Брокер агентов (Agent Broker) маршрутизирует запросы между ними. Визуализатор агентов (Agent Visualizer) отображает, кто и что вызывает. А политики управления распространяются на межсетевой трафик агентов, трафик MCP и LLM точно так же, как политики API регулируют API-трафик сегодня.
Если сделать шаг назад, этот паттерн уже знаком интеграционным архитекторам: управляемый реестр, политики в точке взаимодействия и наблюдаемость (observability) трафика. Тот же Exchange, который является системой учета для API-ландшафта, становится системой учета для рабочей силы агентов, действующих на этом ландшафте. Один каталог служит основой для агентов; этот же каталог регистрирует их.
Что поддерживает актуальность карты: извлечение, отправка, привязка
Обоснованный уровень агентов надежен ровно настолько, насколько надежен лежащий в его основе каталог, поэтому три простых интеграционных паттерна составляют всю эту историю. Извлечение (Pull): запланированный поставщик сущностей только для чтения вызывает API Exchange Experience и проецирует каждый актив в любой портал разработчиков, используемый в компании, причем Backstage.io является распространенным выбором, причем каждая запись содержит отслеживаемые аннотации, ссылающиеся на ее актив в Exchange, без единой строки написанного вручную YAML. Рабочая реализация синхронизируется каждые пятнадцать минут в соответствии с целевым показателем актуальности, а сигналы об отклонениях (drift alarms) оповещают платформенную команду при сбое синхронизации.
Рисунок 3. Паттерн 1: извлечение (pull). Запланированный поставщик сущностей вызывает API Exchange Experience (шаг 1) и обновляет сущности портала с отслеживаемыми аннотациями (шаг 2); транзакционные действия ссылаются обратно на Exchange и API Manager (шаг 3). Карта остается актуальной без необходимости поддерживать ее вручную.
Отправка (Push): ландшафт, который никогда не работал на Mule, поступает через CI. CLI каталога API (API Catalog CLI) публикует спецификации OAS и AsyncAPI в Exchange во время сборки, поэтому служба Java или поток Kafka получают управляемый контракт, семантическую версию и именованного владельца, а та же синхронизация извлечения переносит их повсюду, делая неотличимыми от API Mule. Это универсальное управление API (Universal API Management), выполняющее тихую и важную работу для эпохи агентов: карта агента охватывает весь ландшафт, а не только уголок интеграционной платформы.
Рисунок 4. Шаблон 2: push. CI запускает API Catalog CLI во время сборки (шаги 1 и 2), публикуя спецификации, не относящиеся к Mule, в Exchange, где регулируются контракты, версии и политики; та же синхронизация по принципу pull переносит их на каждый «вход» (шаг 3). Карта агента охватывает всю инфраструктуру.
Ссылка: каждое транзакционное действие ведет по глубокой ссылке в систему, которой оно принадлежит, как для людей, так и для агентов. Контракты и доступ находятся в MuleSoft; обнаружение, владение и документация — на портале; синхронизация односторонняя, поэтому нет риска рассинхронизации и нет необходимости спорить о том, какой источник является основным. Один источник истины для каждого факта — это именно то, что делает карту безопасной для передачи автономному субъекту.
ИИ ускоряет саму сборку
В этой архитектуре есть вторая история, связанная с ИИ, и она меняет экономику запуска. Рабочая сборка, лежащая в основе этой статьи — поставщик сущностей Exchange, интеграция с порталом, поиск, визуализированные контракты, страница с показателями и конечная точка MCP — была собрана за дни, а не недели, при этом агент кодирования на базе ИИ занимался созданием каркаса, а команда руководила архитектурой и тестами. Эта сборка визуализирует пять форматов спецификаций бок о бок: OAS, AsyncAPI, GraphQL, gRPC и даже EDI, за единой строкой поиска, с набором тестов из более чем двухсот элементов. Интеграционный интерфейс, который предоставляет Exchange, сделал такую скорость возможной; агент кодирования на базе ИИ сделал это дешевым.
ИИ также ускоряет наполнение каталога. Краулер предлагает записи для спецификаций, которые он находит в репозиториях, ИИ предлагает теги возможностей и вероятных владельцев, а люди подтверждают это одним кликом; все, что остается невостребованным, попадает в отчет о «слепых зонах», который незаметно превращает неизвестные риски в список задач. Этот цикл стоит сформулировать прямо: ИИ — это не просто причина для создания агентного уровня. Это то, как этот уровень создается достаточно быстро, чтобы иметь значение.
Что это дает
Начинайте с результатов работы агентов. Каждая поверхность ИИ в организации отвечает на вопросы об инфраструктуре на основе одной регулируемой записи, а не собственных догадок. Агенты действуют в рамках тех же контрактов, политик и рабочих процессов доступа, что и люди, и в этом заключается разница между пилотным проектом агента, который блокирует служба безопасности, и тем, который она одобряет. Карта охватывает как Mule, так и не-Mule системы и остается актуальной по определению. А с помощью Agent Fabric уровень расширяется от обеспечения работы агентов до их регистрации и управления ими в том же Exchange, который управляет вызываемыми ими API.
Люди не остаются в стороне; они получают портал, который всегда хотели, в качестве побочного эффекта. Тот же регулируемый каталог питает портал Backstage для платформенной инженерии, Anypoint API Experience Hub для разработчиков со стороны партнеров и обеспечивает единый поиск по всей инфраструктуре с указанием владельца и визуализированным контрактом для каждой записи. То, чего организация избегает, столь же конкретно: YAML, поддерживаемый вручную, второй рабочий процесс доступа, каталог, который устаревает, и программа ИИ, основанная на вики-страницах.
Как это вписывается в дорожную карту
Последовательность короткая, потому что ИИ делает ее короткой. Сначала настройте поставщика pull-синхронизации; с агентом кодирования на базе ИИ для создания каркаса первая регулируемая карта с возможностью поиска появится через несколько дней. Настройте глубокие ссылки, чтобы каждое действие оставалось авторизованным. Добавьте API Catalog CLI в шаблоны CI, чтобы инфраструктура, не относящаяся к Mule, поступала через тот же регулируемый путь. Затем откройте конечную точку MCP для помощников и агентов, которые все равно появятся, и позвольте Agent Fabric зарегистрировать их в том же Exchange, что и API, которые они вызывают. Сначала карта; агенты уже близко.
В предыдущей статье этой серии, «Omni Gateway Beyond the Front Door», утверждалось, что шлюз должен находиться в центре сети приложений, а не только на публичном периметре. Эра агентов подтверждает ту же мысль на уровень выше, и делает это безотлагательно. Exchange всегда был единственным местом для публикации, обнаружения и повторного использования активов. В агентном предприятии это прочтение становится острее: одна регулируемая карта перед всем, что вы запускаете, для каждого человека и каждого агента. Именно для этого и нужен агентный уровень.
Эта публикация отражает полевой опыт интеграции Anypoint Exchange с внутренним порталом разработчика на базе Backstage.io и конечной точкой обнаружения MCP в масштабах предприятия. Упомянутые названия продуктов и возможности, включая Exchange Experience API, API Catalog CLI, Anypoint API Experience Hub, MuleSoft MCP Server and Connector и Agent Fabric (Agent Registry, Agent Broker, Agent Visualizer и политики управления агентами), быстро развиваются и варьируются в зависимости от выпуска и региона; уточняйте текущие детали у команды по работе с клиентами MuleSoft и в документации по продукту.
Ссылка: Tariq Yaqub, “Omni Gateway Beyond the Front Door,” MuleSoft Blog, August 2026, https://blogs.mulesoft.com/news/omni-gateway-beyond-the-front-door/.
