Введение: зачем нужен AI-агент для WordPress и Elementor
Ручная сборка страниц в WordPress с Elementor отнимает у контент-менеджеров и разработчиков часы. Перенести структуру из Figma, расставить виджеты, проверить адаптив, прогнать тесты - это рутина, которая тормозит публикацию. AI-агент, заточенный под эту задачу, берёт рутину на себя: получает задачу через Telegram, обращается к MCP-инструментам и CLI, применяет изменения сначала в бета-окружении, а после проверки - в проде.
Ключевой вывод из нашего кейса: промпта недостаточно. Надёжный агент для production - это инженерная архитектура с очередью задач, атомарными командами CLI и автоматическими валидаторами. Ниже разберём, как именно построена эта система и почему каждая деталь важна, когда с агентом работают реальные пользователи.
Почему промпта недостаточно: ограничения LLM в управлении состоянием
LLM генерирует текст, но не умеет надёжно управлять состоянием внешней системы. Модель не «помнит», что уже создала страницу, не гарантирует идемпотентность и не обрабатывает конфликты параллельных запросов. Когда агент действует напрямую через промпт и API, каждый вызов - это новая попытка интерпретировать задачу, и результаты недетерминированы.
В нашем проекте мы прошли через все классические грабли: потеря контекста при длинных цепочках действий, «галлюцинации» в структуре виджетов Elementor, неспособность атомарно откатить неудачное изменение. Решение - вынести состояние из агента и дать ему инструменты, которые гарантируют консистентность.
Потеря задач и дубликаты: реальные баги промпт-агентов
Первый инцидент случился на этапе прототипа. Агент получил задачу «создать лендинг по макету X», начал выполнение, но на пятом шаге потерял контекст и создал страницу заново. Результат - три дубликата в админке WordPress, которые контент-менеджер чистил вручную.
Второй кейс: два редактора одновременно отправили задачи на изменение одного и того же блока. Агент обработал запросы параллельно, применил оба набора правок без блокировок и сломал вёрстку. Откатить изменения можно было только через бекап базы данных.
Третий инцидент - пропуск шага. Агент доложил «страница готова», но валидатор показал, что секция с отзывами отсутствует. LLM «решила», что уже добавила этот блок, хотя реального вызова API не произошло. Эти баги не лечатся доработкой промпта - нужна архитектура, которая исключает неоднозначность.
Архитектура агента: очередь задач, CLI и управление окружениями
Ядро системы - связка из трёх компонентов: Telegram-бот принимает запрос, ставит задачу в очередь, CLI-инструменты атомарно применяют изменения к WordPress/Elementor API. Между LLM и состоянием сайта всегда стоит прослойка, которая гарантирует идемпотентность, логирование и возможность отката.
Очередь задач: как мы победили потерю запросов и дубликаты
Каждая задача - это структурированный объект с уникальным идемпотентным ключом, типом операции, полным набором параметров и статусом выполнения. Очередь на базе Redis (в прототипе) или RabbitMQ (в production-версии) гарантирует доставку и исключает двойную обработку.
Формат задачи выглядит так:
{
"idempotency_key": "page-landing-x-2026-07-25-v1",
"type": "create_page",
"payload": {
"title": "Лендинг продукта",
"template": "figma_config_v2.json",
"environment": "beta"
},
"status": "pending",
"retries": 0,
"max_retries": 3
}
При получении задача блокируется (статус processing), и другой воркер не возьмёт её в работу. После успешного выполнения статус меняется на completed. При ошибке - failed, и после backoff-задержки система пробует снова. Если три попытки провалены, задача уходит в dead-letter-очередь для ручного разбора.
Идемпотентный ключ решает проблему дубликатов: повторная отправка задачи с тем же ключом возвращает текущий статус, а не создаёт новую операцию. Контент-менеджер может нажать «отправить» дважды - система обработает запрос один раз.
CLI для всех операций с состоянием: почему это must-have
CLI инкапсулирует всю сложность взаимодействия с WordPress и Elementor: аутентификацию, валидацию входных параметров, обработку ошибок API, логирование каждого изменения. LLM не вызывает REST API напрямую - она формирует команду CLI, а та уже выполняет атомарную операцию.
Примеры команд:
wp-agent create-page --title "Лендинг" --template config.json --env beta- создаёт страницу с заданным конфигом виджетовwp-agent update-widget --page-id 42 --widget-id 7 --props '{"title": "Новый заголовок"}'- точечно меняет свойства виджета Elementorwp-agent rollback --page-id 42 --to-version 3- откатывает страницу к предыдущему состоянию из лога измененийwp-agent validate --page-id 42 --against figma_config.json- запускает валидаторы для проверки результата
Каждая команда пишет запись в лог: что сделано, с какими параметрами, какой был ответ API. Это даёт полный аудит-трейл и возможность отката без бекапов базы данных. Когда агент ошибается, мы не гадаем «что пошло не так» - мы смотрим лог и видим конкретный шаг.
Выбор CLI как основного интерфейса даёт ещё одно преимущество: команды можно тестировать изолированно, без LLM. Разработчик запускает wp-agent create-page ... в терминале и сразу видит результат. Это ускоряет отладку и делает поведение агента предсказуемым.
Управление окружениями: бета-тестирование перед прод-деплоем
Агент никогда не применяет изменения напрямую к живому сайту. Все операции сначала выполняются в бета-окружении - полной копии продакшена. После применения запускаются автоматические валидаторы: проверка структуры JSON-конфига Elementor, сравнение с макетом Figma, скриншотные тесты вёрстки, поиск битых ссылок.
Если валидаторы проходят успешно, задача получает статус ready_for_review. Контент-менеджер видит результат в бета-среде и одним кликом одобряет перенос в прод. При обнаружении расхождений задача автоматически возвращается агенту на доработку с конкретным списком проблем - без участия человека.
Этот процесс - и есть quality gate. Он работает как автоматический контролёр, который не верит словам агента и проверяет факты.
Quality gate: почему нельзя доверять словам агента
LLM склонна выдавать желаемое за действительное. Агент может доложить «страница готова», хотя часть виджетов не применилась или вёрстка разъехалась. Единственный способ обеспечить качество - автоматические проверки, которые сравнивают результат с эталоном.
Мы используем три типа валидаторов:
- Синтаксические - проверяют JSON-схему конфига Elementor: все ли обязательные поля заполнены, корректны ли типы данных, нет ли битых ссылок на несуществующие виджеты.
- Семантические - сравнивают структуру страницы с макетом Figma: совпадает ли количество секций, правильный ли порядок блоков, соответствуют ли размеры и отступы.
- Функциональные - делают скриншоты бета-версии страницы и сравнивают pixel-by-pixel с референсными изображениями. Отклонение больше порога - задача возвращается на доработку.
На практике это выглядит так: агент завершает задачу, quality gate запускает валидаторы, находит расхождение в отступах между секциями и возвращает задачу с комментарием «отступ между hero и features: ожидалось 80px, фактически 120px». Агент получает этот фидбек и исправляет конкретный параметр. Цикл повторяется, пока все проверки не пройдут.
Python-компилятор для Figma: от дизайна к коду Elementor
Дизайнеры работают в Figma, а контент попадает в Elementor. Python-компилятор связывает эти два мира: он парсит макет Figma через API, извлекает структуру секций, размеры, шрифты, цвета и генерирует JSON-конфиг, понятный CLI-инструментам агента.
Процесс выглядит так:
- Дизайнер обновляет макет в Figma и ставит тег
ready-for-dev - Компилятор по вебхуку забирает макет и генерирует конфиг
figma_config_v3.json - Конфиг попадает в репозиторий, и агент получает команду «обнови страницу по новому макету»
- Агент применяет изменения через CLI в бета-окружении
Компилятор не даёт 100% точности - сложные анимации и кастомный CSS он не воспроизводит. Но для типовых лендингов и статейных страниц покрытие составляет около 90%: структура, отступы, типографика и цвета переносятся автоматически. Оставшиеся 10% - ручная доводка, которую агент уже не делает.
Практические уроки: что мы вынесли из построения агента
Главный инсайт: промпт - это клей, а не ядро. LLM хороша для понимания задачи и генерации плана действий, но исполнение должно быть детерминированным. Состояние живёт вне агента, в очереди задач и логах CLI. Идемпотентность и очереди - обязательные условия для production, без них дубликаты и потери неизбежны.
Второй урок: quality gate должен быть автоматическим и недоверчивым. Агент ошибается систематически, и только формальные проверки ловят эти ошибки до того, как их увидит пользователь. Ручное ревью результатов не масштабируется - при потоке из десятка задач в день человек становится бутылочным горлышком.
Третий урок: CLI как абстракция над API окупается с первого бага. Логирование каждой операции даёт возможность отката и аудита, а изолированное тестирование команд ускоряет разработку. Прямые вызовы API из промпта - это технический долг, который придётся выплачивать при первом инциденте.
Подход, описанный в этом кейсе, перекликается с более общими принципами архитектуры агентных CMS, где контроль над состоянием и конвейеры обработки становятся стандартом. Для тех, кто строит агентов с нуля, будет полезен разбор архитектуры самописного AI-агента с практическим кодом на Python.
Когда не стоит строить такого агента: ограничения и риски
Архитектура с очередью задач, CLI и валидаторами оправдана при потоке от пяти задач в день и сложной структуре страниц. Для сайта-визитки с тремя страницами, которые обновляются раз в месяц, затраты на инфраструктуру превысят выгоду.
Другие ограничения:
- Нужна команда, готовая поддерживать Python-компилятор для Figma и обновлять его под изменения API
- Сложные анимации и кастомный CSS остаются за человеком - агент их не воспроизводит
- При изменении структуры виджетов Elementor придётся обновлять JSON-схемы валидаторов
Если объём задач мал, а структура страниц простая, возможно, достаточно связки «шаблон + ручная доводка». Агент даёт выигрыш на масштабе, а не на единичных операциях. Опыт других команд подтверждает: агенты часто находят неожиданное применение, но для этого нужна инфраструктура, готовая к экспериментам.
Заключение: AI-агент как новый стандарт работы с CMS
Система, которую мы построили, - это не магия, а инженерная дисциплина. Очередь задач гарантирует доставку и идемпотентность. CLI инкапсулирует сложность API и даёт аудит-трейл. Бета-окружение и quality gate защищают прод от ошибок. Python-компилятор для Figma сокращает разрыв между дизайном и вёрсткой.
Результат: контент-менеджер отправляет задачу в Telegram и через несколько минут получает готовую страницу в бета-среде. Останется проверить и нажать «опубликовать». Рутина ушла агенту, человеку остался контроль.
Надёжный AI-агент для CMS - это достижимая цель. Ключ к ней - не в более clever промптах, а в архитектурных решениях, которые делают поведение системы предсказуемым. Начните с CLI для одной операции, добавьте очередь задач, подключите валидатор - и вы увидите, как прототип превращается в инструмент, которому можно доверять.