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












