Если вспомнить, что мы проходили в архитектуре за последние десятилетия, вырисовывается любопытная картина. Сначала были монолиты и мэйнфреймы, затем — двух- и трехзвенные архитектуры. Не так давно все активно занимались распиливанием монолита на микросервисы, массово внедряли CQRS. Казалось, нащупан стабильный путь развития. Но что дальше? Как раз об этом сегодняшняя публикация. Мы подготовили ее на основе доклада на True Tech Day от Олега Ивлева — директора по развитию технологий, и Марина Путниковича — руководителя центра практик «Архитектура» в МТС Web Services. Надеемся, получилось интересно!

Традиционные архитектурные паттерны и их адаптация

После распиливания монолитов на микросервисы появились LLM, агенты — а у них другие требования и парадигма проектирования систем. Теперь приходится переосмысливать: что именно мы строим, как мы это делаем и какие риски при этом принимаем? В каком направлении все развивается?

Стандартные паттерны вроде микросервисной архитектуры по-прежнему с нами, но на фоне новых задач важно понимать, что мы можем адаптировать под изменившиеся условия. Если смотреть на реальность, становится ясно: миграции с монолита на микросервисы не всегда оказывались успешными. Во многих компаниях результат этих переходов нельзя назвать удачным и экономически оправданным. Мы ожидали гибкости и масштабируемости, а на практике получили те же монолиты, только разбитые на миллионы контейнеров.

В условиях появления новых технологий, таких как AI, вероятно, именно SOA окажется архитектурой, которая больше всего подходит для агентов. В микросервисах все жестко: кто, с кем и когда общается. Но агенту это не нужно. У него есть цель — и ему не требуется строгое соблюдение протокола. Поэтому такие паттерны, как SOA, немного укрупненные микросервисы и FaaS, могут быть теми подходами, которые дадут нам возможность использовать AI в бизнесе.

При этом нельзя сказать, что происходит глобальная смена парадигмы. Мы, скорее, пытаемся адаптироваться к революции, которая началась с языковых моделей в 2022 году. Старая архитектура продолжает жить, как это было всегда. Кто-то до сих пор делает проекты на PHP за 15 минут. Останется и SOA, и микросервисная архитектура.

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

Что приходит на смену микросервисам

Переход к Al-ready-архитектуре — это не отказ от микросервисов, а их эволюция. Они не становятся устаревшими, но им нужно адаптироваться. Речь идет о переходе к более крупным сервисам, в которых четко определено, что именно они делают. Это особенно важно в системах, где действуют агенты с ограниченным контекстом: управлять множеством агентов в сложной архитектуре практически невозможно, если сервисы не описаны как автономные единицы, предлагающие понятную услугу.

Главная задача — не следовать инструкции шаг за шагом, а решать все в условиях динамичной среды. Поэтому архитектура должна быть спроектирована с учетом того, какие действия сервис может выполнить для агента и в конечном счете для пользователя. Контекст меняется: раньше проектирование шло от CJM (Customer Journey Map) и сценариев работы с интерфейсом. Сейчас пользователь исчезает из прямого взаимодействия: он просто говорит, например, «закажи огурцы», и задача уходит агенту. Архитектура должна быть ориентирована на то, как агент будет достигать цели, а не на то, как человек станет нажимать кнопки.

Был такой вопрос: насколько крупным или мелким должен быть микросервис? Раньше шутили, что он обязан «помещаться в голову» разработчику. Сейчас это выражение можно переформулировать: сервису нужно помещаться в контекст агента, чтобы тот мог с ним работать и достигать цели.

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

Что такое Agentic-Ready-архитектура и чем она отличается от микросервисной

Если посмотреть на ландшафт с точки зрения Agentic-Ready-подхода, становится очевидно: меняется не только архитектура, но и сам взгляд на систему. Сейчас термин Agentic Ready активно используется в статьях, обсуждениях, документации. Но, возможно, корректнее было бы говорить о Agentic Ready Service Architecture, потому что в этой парадигме агенты опираются именно на сервисы.

В отличие от классической микросервисной архитектуры, в системе появляются новые компоненты, о которых раньше не приходилось задумываться. Это и knowledge graph, с ним агент сможет работать, и guardrails — ограничители, задающие рамки принятия решений. Нам нужно явно описывать, что делает каждый сервис, чтобы агент мог интерпретировать его функциональность и использовать для достижения цели. Агент не будет строго следовать зафиксированной инструкции — он станет ориентироваться на контекст, оценивать состояние системы, подстраиваться под изменения и выбирать наилучшую стратегию действий.

Так как агент по сути становится ключевым участником системы, мы начинаем проектировать архитектуру, исходя из его потребностей. Это меняет подход к данным: необходимо использовать векторные базы, правильно формировать фрагменты знаний (chunks) и связывать их в knowledge graph. Коммуникация тоже трансформируется: привычные синхронные API постепенно уступают место intent-ориентированным интерфейсам, где важна не форма вызова, а смысл задачи.

Появляются новые протоколы, новые модели взаимодействия, такие как MCP (Modular Capabilities Protocol), а также концепции вроде OODA (Observe, Orient, Decide, Act), которые описывают поведение агента в переменной среде. Изменения касаются не только технологий, но и культуры разработки: майндсет меняется, а вместе с ним и принципы проектирования. Если раньше проблемы микросервисов сводились к вопросам инфраструктуры вроде «поднимать ли отдельную базу под каждый сервис», то теперь ключевой вопрос — как дать агенту инструменты для выполнения задачи, не полагаясь на строго заданные сценарии.

Кроме того, возникают новые требования к документации. Агенту нужно понимать, какой API и как применять. Поэтому уже недостаточно просто описать структуру запроса и ответа в service registry. Необходимо добавить примеры использования, возможные варианты ответов, чтобы агент был в состоянии адаптировать вызов под текущий контекст.

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

Как проектировать новую архитектуру

Если смотреть еще шире, можно задать более радикальный вопрос: а что, если все действительно будет построено только на агентах? Такая идея уже обсуждается — в частности, Microsoft предполагает, что будущее не за классическим софтом, а за «интернетом агентов». В этом подходе исчезает привычный слой бизнес-приложений (bizapps), и все, что раньше реализовывалось кодом и логикой, теперь делается через агентов.

Сложно представить такой мир буквально, потому что любое приложение сегодня — это не только код, но и большая аналитическая работа, принятые архитектурные решения, логика, структура API. Это огромный пласт знаний, который трудно передать агенту напрямую, даже если у нас идеальные базы и системы reasoning-as-a-capability. Поэтому, скорее всего, агент будет выполнять роль оркестратора: отслеживать события, понимать контекст и действовать в соответствии с изменениями среды.

Это повлияет не только на API, но и на сами события: они будут нести больше контекста, больше информации для принятия решений. Фокус архитектуры сместится в сторону создания среды, в которой агент сможет безопасно и эффективно работать. Особенно это важно для отраслей с высокой регуляцией, таких как финтех или медтех, где любое автономное решение несет потенциальный риск. Здесь задача архитекторов будет не только в проектировании систем, но и в управлении рисками, связанными с поведением агентов.

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

Тем не менее старая архитектура никуда не исчезнет мгновенно. Скорее, произойдет интеграция: детерминированные системы просто станут «умнее». Они будут советовать, предлагать варианты, но это будут вероятностные ответы, а не гарантированная логика. Поэтому и старая архитектура, и архитектура агентов будут сосуществовать.

В такой модели фокус смещается: не на домен и не на разбиение системы, а непосредственно на сервис и его поведение. Все остальное — работа агента. А наша задача — наблюдать, как он справляется (или нет).