После drag-and-drop: как AI-агенты и MCP меняют CMS и конструкторы сайтов

Слово «агент» в сейчас году встречается в описаниях почти любой CMS или конструктора сайтов – от Webflow до uCoz. Однако появление рядом с кнопкой «Редактировать» новой кнопки «Спросить AI» еще не означает, что архитектура платформы действительно изменилась.

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

Ниже – попытка разобрать происходящее с точки зрения архитектуры, а не, порой, “пустозвонных” пресс-релизов сервисов.

I. Что может скрываться за словом «агент»?

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

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

II. При чем здесь MCP

Model Context Protocol – открытый стандарт, представленный Anthropic в конце ноября 2024 года. Он решает вполне реальную инженерную задачу: сокращает количество уникальных интеграций между моделями, приложениями и источниками данных.

Без общего протокола каждое соединение модели с отдельной системой приходится проектировать заново. Например, если есть N AI-приложений и M источников данных, количество потенциальных интеграций быстро превращается в N×M.

MCP задает общий способ, с помощью которого AI-приложение через MCP-клиент подключается к серверу. Сервер, в свою очередь, публикует доступные инструменты, ресурсы и промпты вместе с формальным описанием их параметров.

Здесь важно сделать некоторые уточнения.

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

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

И третье: MCP не является универсальной заменой REST или GraphQL. Обычный API, как правило, вызывает программа с заранее заданной логикой. MCP рассчитан на клиента, который может получить список инструментов во время работы, изучить их описание и решить, какой инструмент вызвать и в какой последовательности.

III. Архитектура: кто теперь обращается к CMS

Исторически у CMS было два основных типа клиентов: человек, работающий через интерфейс, и приложение, которое обращается к API по заранее запрограммированному сценарию.

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

Показателен подход Webflow: действия агента подчиняются тем же ролям и разрешениям, которые действуют для обычных участников workspace. Иными словами, CMS не получает отдельную «AI-версию». В существующей модели доступа появляется новый тип клиента.

IV. Почему платформы внедряют агентные функции в разном порядке

Сравнивать платформы только по дате запуска агентных функций не очень полезно. Гораздо важнее понять, почему одним системам такой переход дался проще, чем другим.

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

Следом появились решения у визуальных конструкторов с серверной логикой – например, Webflow и Framer. Здесь задача сложнее: элемент на холсте не равен полю в CMS. Платформам пришлось отдельно разрабатывать ветвление изменений, журналы действий и более детальные механизмы доступа к элементам проекта.

Затем агентные функции начали появляться в крупных enterprise-платформах управления customer experience, таких как Adobe Experience Manager. Цена ошибки в этих системах особенно высока: затрагиваются бренд, юридические требования и большие объемы опубликованного контента. Поэтому вместо одного универсального агента там создаются отдельные агенты для конкретных ролей и сценариев.

Нишевые, а также некоторые отечественные конструкторы (тот же uCoz), пришли к агентным функциям позже, но это объясняется не только скоростью разработки. Архитектура таких платформ устроена иначе.

В uCoz нет развитой модели типов контента, характерной для headless CMS: сайт в значительной степени состоит из шаблонов и файлов. Поэтому вместо разрешений на уровне отдельного поля MCP-сервер uCoz использует более грубые, но универсальные механизмы контроля: автоматический бэкап перед сохранением, проверку HTML-кода перед записью, быстрый откат к предыдущей версии и явное подтверждение изменений в диалоге с агентом.

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

V. Что агент может делать с сайтом

На практике агентный доступ к сайту не сводится к генерации текстов или отдельных блоков. Получив доступ к CMS, шаблонам, аналитике и инструментам публикации, агент может работать сразу с несколькими уровнями проекта: менять контент, перестраивать модель данных, собирать страницы, редактировать код и готовить изменения к выходу в production. Чем шире доступный контекст и набор инструментов, тем выше потенциальная польза, и тем серьёзнее последствия ошибки. Поэтому возможности агента имеет смысл рассматривать вместе с рисками, которые возникают в каждой области.

VI. Шкала агентности веб-платформ

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

Уровень 5 пока скорее обозначает направление развития, чем распространенную практику. Это, скажем так, прогноз, задел на будущее.

VII. Агент как источник новых классов инцидентов

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

Избыточные права

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

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

Массовые правки и частичное выполнение

Способность изменить тысячи документов по одной команде – одновременно главное преимущество и один из основных рисков агентных систем.

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

Работа не с тем проектом или окружением

В workspace с несколькими сайтами, а также при наличии staging- и production-окружений агент может применить операцию не к той среде.

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

Prompt injection через содержимое CMS

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

Один из описанных сценариев использовал вредоносный GitHub issue для перехвата агента, подключенного к MCP-серверу GitHub, и вывода данных из приватных репозиториев.

Утечка токенов и других данных

Пример из реальности: пакет postmark-mcp в npm. Начиная с версии 1.0.16, опубликованной в середине сентября 2025 года, он незаметно отправлял копии писем на сторонний адрес с помощью скрытого BCC-правила. Примерно через десять дней пакет обнаружили и удалили из npm.

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

Подключение небезопасных пакетов и инструментов

MCP-сервер – это исполняемый код. В зависимости от конфигурации он может получить доступ к файловой системе, токенам и внешним API.

Помимо случая с postmark-mcp, была зафиксирована уязвимость CVE-2025-6514 с оценкой CVSS 9.6 в распространенном пакете mcp-remote. Вредоносный сервер мог добиться выполнения произвольных команд через специально сформированный URL, возвращенный во время OAuth-авторизации.

Уязвимость обнаружила команда JFrog Security Research. Информация о ней была опубликована 9 июля 2025 года, исправление вышло в версии 0.1.16.

Неконтролируемые расходы

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

По данным TechCrunch, Uber потратил годовой бюджет на AI-инструменты для разработки за первые четыре месяца 2026 года. В отраслевых публикациях встречаются и более резкие примеры – вплоть до десятков тысяч долларов за несколько дней работы зациклившегося агента. Однако такие оценки не всегда подтверждены независимо, поэтому их следует приводить с обязательным указанием источника.

Сложность аудита

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

VIII. Почему обычного Undo недостаточно

Undo предполагает одного участника, который выполняет действия последовательно и в известном порядке.

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

Поэтому агентные платформы все чаще используют подходы, знакомые по Git и CI/CD:

Отдельные элементы этой цепочки уже реализованы в разных продуктах.

Тот же Webflow поддерживает ветвление изменений перед публикацией и ведет журнал действий агента. Sanity использует промежуточное состояние staged changes, которое можно целиком просмотреть и скорректировать до применения. uCoz создает автоматический бэкап перед сохранением, проверяет HTML-код шаблона и позволяет быстро вернуться к предыдущей версии.

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

IX. Как изменится труд разработчика

Речь идет не столько о замене разработчиков, сколько о смещении фокуса их работы.

Вместо создания каждой страницы вручную специалисту все чаще приходится решать следующие задачи:

• проектировать компоненты и схемы данных так, чтобы агент мог безопасно их комбинировать;

• описывать инструменты, поскольку формулировки, параметры и ограничения становятся частью интерфейсного контракта;

• настраивать разрешения на уровне отдельных операций, а не только пользовательских ролей;

• определять, какие действия агент может выполнять самостоятельно, а какие всегда требуют подтверждения;

• тестировать не только конечный код, но и весь агентный процесс;

• выбирать точку, в которой публикация обязательно проходит человеческое ревью;

• обеспечивать наблюдаемость и аудит действий, выполненных агентом;

• задавать бюджеты на вызовы моделей и инструменты аварийной остановки при зацикливании;

• проектировать воспроизводимый откат к известному состоянию вместо расчета на обычный Undo.

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

Вместо выводов

Следующий этап развития CMS связан не с очередным улучшением генерации текста. Речь идет о переходе к системам, которыми одновременно управляют люди, обычные приложения и AI-агенты.

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

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

Список использованных источников

• Anthropic – анонс Model Context Protocol: https://www.anthropic.com/news/model-context-protocol

• Спецификация MCP: https://modelcontextprotocol.io/specification/2025-11-25

• WordPress Developer Blog – MCP Adapter: https://developer.wordpress.org/news/2026/02/from-abilities-to-ai-agents-introducing-the-wordpress-mcp-adapter/

• GitHub – WordPress/mcp-adapter: https://github.com/wordpress/mcp-adapter

• Webflow Developer Documentation – MCP Server: https://developers.webflow.com/mcp/reference/overview

• Webflow – changelog MCP 2.0: https://developers.webflow.com/home/changelog/2026/7/21

• Sanity – страница Content Agent: https://www.sanity.io/content-agent

• Sanity – анонс Content Operating System: https://www.prnewswire.com/news-releases/sanity-launches-the-ai-content-operating-system-for-the-ai-era-302704294.html

• uCoz – MCP uCoz: https://www.ucoz.ru/ai/mcp

• uCoz – техническая документация подключения MCP: https://api.ucoz.net/mcp.html

• Adobe Newsroom – анонс Adobe CX Enterprise: https://news.adobe.com/news/2026/04/adobe-redefines-custome-experience

• Adobe Newsroom – анонс агентов AEM: https://news.adobe.com/news/2026/04/adobe-introduces-brand-visibility-solution

• Adobe Experience League – документация по агентам AEM: https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/ai-in-aem/agents/overview

• TechCrunch – о бюджете Uber на AI-инструменты: https://techcrunch.com/2026/06/02/uber-caps-employee-ai-spending-after-blowing-through-budget-in-four-months/

• Snyk – разбор инцидента с postmark-mcp: https://snyk.io/blog/malicious-mcp-server-on-npm-postmark-mcp-harvests-emails/

• The Hacker News – об отравленных описаниях MCP-инструментов: https://thehackernews.com/2026/06/microsoft-warns-poisoned-mcp-tool.html

• TechCrunch – о росте расходов токенов на AI-агентов: https://techcrunch.com/2026/06/05/the-token-bill-comes-due-inside-the-industry-scramble-to-manage-ais-runaway-costs/

• arXiv – риски AI-агентов с доступом к инструментам: https://arxiv.org/pdf/2605.09721

• arXiv – безопасность агентных систем и prompt injection: https://arxiv.org/pdf/2606.28791