Jing Li
22 сентября 2026 г. | Время чтения: 8 мин.
Время чтения: 8 минут
В корпоративном ПО происходит сдвиг, о котором, как мне кажется, говорят недостаточно.
На протяжении тридцати лет мы создавали наши системы для одного типа пользователей: человека, кликающего по экрану. Но сегодня самые быстрорастущие пользователи ваших систем — вовсе не люди. Это ИИ-агенты.
Теперь мы создаем решения для людей и агентов одновременно, и большинство корпоративных архитектур просто не готовы к обоим вариантам.
Как мы к этому пришли
Прежде чем перейти к тому, что должно измениться, давайте обсудим, как мы к этому пришли.
Монолит: Интерфейс и бэкенд были объединены в единое целое. Если вы меняли пользовательский интерфейс, вы рисковали сломать лежащие в его основе данные и логику. Все было жестко связано.
Микросервисы: Команды разделили бэкенд на независимые части, чтобы двигаться быстрее. Но интерфейс остался привязан к конкретным каналам: веб-приложение напрямую подключалось к определенным эндпоинтам. Это был прогресс, но не свобода.
Headless: Вы полностью отделяете уровень представления от бэкенда. Создаете функционал один раз, предоставляете его где угодно — например, в веб, на мобильных устройствах, на партнерском портале, в POS-системе. «Головой» может быть что угодно.
От UX к DX и AgentX
Самым интересным мне кажется даже не сама архитектура. Это история о том, кто находился у этой «головы».
UX (Пользовательский опыт)
Архитектура headless в первую очередь решила задачу для конечного пользователя. Вы могли доставлять один и тот же каталог продуктов через сайт, мобильное приложение и киоск в магазине, и все они обращались к одному бэкенду. Быстрый, согласованный, не зависящий от канала интерфейса опыт.
DX (Опыт разработчиков)
По мере развития API архитектура headless расширила возможности инженерных команд. Разработчики смогли собирать корпоративные возможности, как блоки Lego, — создавая новые интеграции и внутренние инструменты из стандартизированных интерфейсов, не затрагивая бэкенд.
AgentX (Опыт агентов)
Но правила игры снова изменились.
ИИ-агенты не кликают по экранам. Через открытые протоколы, такие как MCP, они читают, пишут и рассуждают с использованием ваших систем напрямую, полностью обходя интерфейсы, на которые полагаются люди. Они представляют собой совершенно новый класс безголовых (headless) потребителей. И именно под них должна строиться современная headless-архитектура.
Две сложные проблемы
Предоставление доступа к вашему бэкенду автономным агентам дается не бесплатно. Это создает две проблемы, с которыми большинство архитектур не рассчитаны справляться.
1. Структурированный доступ
Агенту нельзя просто выдать сырой дамп базы данных. Чтобы принимать интеллектуальные решения, ему нужен контекст — что делает API, что ему требуется, что он возвращает — до того, как он сделает какой-либо вызов. Стандартные REST-эндпоинты были созданы для человеческих разработчиков, которые сначала читают документацию. Агентам нужны самоописываемые, семантически богатые метаданные, обернутые вокруг сервисов. Исходные API никогда для этого не создавались.
2. Управление и контроль (Governance)
Когда человек нажимает кнопку, вопросы идентификации и контроля доступа вполне понятны. Но когда агент быстро объединяет в цепочку десять вызовов API между вашей CRM и ERP, пока вы пьете кофе, кто это контролирует? Как вы:
- Обеспечиваете детальный контроль идентификации и доступа для автономных задач?
- Предотвращаете непредвиденные расходы на API из-за бесконечных циклов?
- Поддерживаете четкий журнал аудита каждой системы, к которой прикасался агент?
Три возможности для архитектуры, готовой к агентам
Для этого требуются три вещи.
1. Активы, готовые для агентов — имеющиеся у вас API должны быть адаптированы для агентов и предоставляться через открытый стандарт, такой как MCP, чтобы агент мог обнаружить, что они делают и как безопасно их использовать, без необходимости перестраивать что-либо с нуля.
2. Единый хаб обнаружения — центральный реестр как для команд, так и для агентов. Каталог всего существующего в вашем предприятии с возможностью поиска: что это делает, как это вызвать и, что крайне важно, к чему на самом деле разрешен доступ конкретному агенту.
3. Управляемый доступ везде — эти возможности должны работать там, где происходит работа. Это может быть внутри ИИ-ассистента вроде Claude, рабочего пространства для совместной работы вроде Slack или Teams, или в вашем собственном пользовательском приложении. Один набор активов. Один набор элементов управления. Согласованность на каждой поверхности.
Создание для того, что будет дальше
Объедините эти три пункта, и вы сделаете гораздо больше, чем просто отделите интерфейс от бэкенда. Вы создали архитектуру, которая является доступной, обнаруживаемой и управляемой — готовую ко всему, что появится у «головы» дальше.
От пользователей к разработчикам. А теперь и к агентам.
Именно для этого создана MuleSoft: превращение имеющихся у вас API в активы, готовые к работе с агентами, предоставление вашим командам и агентам единого хаба для их обнаружения и обеспечение доступности этих возможностей везде, где работает ваш бизнес.
Чтобы узнать больше о подготовке вашей архитектуры к эпохе ИИ, посетите mulesoft.com.