Представим, что вы попросили ИИ-агента убрать старое название компании с сайта. Он нашёл 80 упоминаний, исправил их и сообщил, что задача выполнена. Но среди этих упоминаний оказались архивные новости и юридические документы, в которых название менять было нельзя.
Для CMS всё прошло штатно: авторизованный пользователь отправил корректные запросы, данные обновились, ошибок нет. А теперь кому-то предстоит искать и исправлять результаты слишком усердной работы агента.
Когда агент получает возможность самостоятельно менять сайт, на первый план выходят механизмы проверки изменений и восстановления после ошибок. Причём решение зависит от того, как организована работа с контентом. Если агент — единственный редактор, подходит одна схема. Если контент параллельно меняют люди и несколько агентов, нужна другая.
Один редактор: агент собирает и публикует сайт
На собственных проектах я использую схему, в которой для повседневного редактирования не нужно заходить в админку. Я ставлю задачи агенту Hermes: изменить текст, обновить информацию, добавить материал, исправить ссылки, переделать страницу.
Агент работает с проектом локально, вносит изменения, выполняет сборку и доставляет её на production-сервер. Затем веб-сервер переключает активный инстанс на новую версию. Несколько предыдущих релизов при этом сохраняются. Пока переключения не произошло, посетители видят старую версию сайта.
Откат устроен в два слоя, потому что код и контент хранятся по-разному.
Код и вёрстка выходят релизами: предыдущая версия лежит рядом, и вернуться к ней можно примерно за полминуты. Текущий и предыдущий релизы сохраняются обязательно, более ранние тоже остаются на сервере.
Контент живёт в базе данных, а не в Git, поэтому переключение релиза само по себе его не восстанавливает. Для данных предусмотрена отдельная защита: перед любой записью агент обязан сделать снапшот базы, а по ночам выполняется резервное копирование с сохранением копии вне сервера.
Как это работает на практике, показал недавний случай. Агент добавлял в статью кликабельные ссылки на источники, но неправильно сформировал их в формате редактора. В результате на опубликованной странице внутри ссылки появилась надпись unknown node.
Ошибку обнаружила обязательная проверка живой страницы после публикации, прямо в той же сессии. Откат не понадобился — хватило точечной правки. Но если бы исправить проблему не удалось, у меня оставался снапшот базы, сделанный перед изменениями.
В этой схеме агент — единственный редактор. Ни я, ни другие люди параллельно не меняем контент через админку. Если нужно обновить описание услуги, поправить внутренние ссылки и разместить статью, я формулирую задачу, а агент выполняет весь цикл.
Не приходится отдельно публиковать каждую страницу, согласовывать правки нескольких участников и разбираться, кто успел изменить документ во время работы агента. Задача выполняется последовательно, а изменения кода и контента сопровождаются своими механизмами восстановления.
Конечно, остаются технические ограничения. Например, миграция базы может сделать старую версию приложения несовместимой с новыми данными. Поэтому наличие предыдущей сборки ещё не гарантирует, что откат пройдёт без проблем.
Но пока редактор один и задачи идут последовательно, сложная система согласования параллельных изменений не нужна. Для небольшого корпоративного сайта, блога или проекта, где контентом управляют через одного агента, это вполне рабочая модель.
Когда редакторов несколько, откат усложняется
Теперь другая ситуация. Представим корпоративный портал, где новости публикует редактор, вакансии обновляет HR, описания услуг ведут специалисты отделов. Параллельно ИИ-агент исправляет устаревшую информацию на десятках страниц.
Просто вернуть сайт к прежнему состоянию уже нельзя. За время работы агента сотрудники могли внести собственные правки, и полный откат уничтожит их вместе с ошибками.
Проблема может возникнуть даже в пределах одной страницы. Агент поменял заголовок, через несколько минут сотрудник обновил телефон, а позже выяснилось, что заголовок неверный. Если восстановить прежний снимок страницы целиком, телефон тоже пропадёт.
Нужно отменить именно действие агента и сохранить то, что сделали после него. А если правки затронули одно поле, система должна заметить конфликт и предложить человеку его разрешить.
Здесь полезно посмотреть на опыт команды Tracy — агента, который редактирует сайты на Joomla и WordPress по запросам на обычном языке.
Один из разработчиков Tracy рассказал на Reddit, что сильнее всего повлияло на доверие пользователей. По его наблюдениям, решающую роль сыграло не то, насколько умно выглядят рассуждения модели, а вполне конкретные механизмы:
- Агент не трогает живой сайт. Импортируется копия, и он работает на ней.
- Все записи проходят через один серверный механизм. Изменения попадают в журнал, обходных путей у агента нет.
- Каждый ход становится чекпоинтом. Его можно просмотреть, сравнить с предыдущим состоянием, когда доступен diff, и отменить отдельно от остальных.
- Есть именованные релизы. Можно вернуться к конкретной версии, например к той, которую утвердил заказчик.
- Агент изучает устройство сайта перед работой. Он получает представление о теме оформления, структуре и контенте, а не действует по предположениям о типовой конфигурации.
Команда сознательно отказалась от подтверждений перед каждой правкой. Агент действует в изолированной среде, человек смотрит результат после. По наблюдениям разработчиков, простой откат оказался полезнее постоянных запросов на подтверждение, которые со временем перестают внимательно читать.
Главная идея здесь: вместо контроля каждого шага можно построить среду, где агент работает самостоятельно, а результаты его действий остаются видимыми и по возможности обратимыми.
Почему одного отката недостаточно
Есть три разных слоя защиты, которые дополняют друг друга. Резервная копия нужна для восстановления после серьёзного сбоя. История изменений позволяет отменить конкретную ошибку, не теряя остальную работу. Ограничения полномочий нужны, чтобы агент вообще не мог выполнить недопустимую операцию.
При этом даже хорошая система версий не решает все проблемы.
Первый вопрос — последствия за пределами CMS. Если публикация успела отправить уведомление, вызвать webhook, обновить внешний каталог или получить рекламный трафик по новому URL, возврат старого текста этого не отменит.
Важно различать предотвращение ошибки и восстановление после неё. Например, если агенту запрещено удалять определённые данные, ограничение должно действовать независимо от того, каким способом он пытается выполнить операцию. Недостаточно заблокировать одну команду, если к тому же результату можно прийти другим путём.
Второй вопрос — зависимости между изменениями. Допустим, агент создал новый шаблон и несколько страниц на его основе. Если отменить только создание шаблона, страницы могут перестать работать. Перед откатом система должна учитывать, какие более поздние изменения зависят от отменяемого действия.
Третий вопрос — гранулярность отката. Чекпоинт на каждый ход ценен тем, что позволяет отменить конкретную ошибку, не теряя полезные результаты других действий. Полный снимок сайта технически проще, но возвращение к нему может стереть изменения, которые хотелось сохранить.
Причём сам по себе чекпоинт ещё не гарантирует такого поведения. Важно, что именно он хранит: состояние документа целиком, изменения отдельных полей или набор операций. От этого зависит, насколько безопасно можно отменять старые действия после новых правок.
Поэтому возможность отката полезна, но не делает любое действие агента безопасным.
Ветки контента
Есть ещё одна задача, особенно актуальная для сайтов с несколькими редакторами.
Допустим, компания готовит ребрендинг. Нужно обновить главную страницу, описания услуг, изображения, меню и несколько посадочных страниц. Работа занимает неделю, а редакторы всё это время продолжают публиковать новости и обновлять текущую информацию.
Обычные черновики позволяют готовить отдельные документы. Но хотелось бы собрать все изменения ребрендинга в одну независимую рабочую область, проверить их вместе и опубликовать согласованным набором.
В разработке программ для этого давно используют ветки Git. Похожую идею начинают переносить и на контент.
Один из примеров — Content Branching в Payload CMS 4. Вместо одной последовательности редакций предполагается возможность готовить независимые наборы связанных изменений.
На мой взгляд, направление перспективное. Подробнее об идее и возможных сценариях можно прочитать в разборе «Content Branching в Payload CMS 4» на payloadcms.ru.
Для ИИ-агентов такой механизм был бы особенно полезен. Агент мог бы готовить группу связанных материалов в собственной ветке, пока редакция продолжает работать с основным сайтом. При этом главным вопросом остаётся корректное объединение изменений, особенно если агент и человек редактировали одни и те же документы.
А нужна ли агенту CMS вообще?
Если агент самостоятельно редактирует сайт, возникает закономерный вопрос: зачем ему CMS?
Для небольшого сайта, где контент хранится в файлах проекта, отдельная CMS действительно может оказаться лишней. Агент способен изменять Markdown, JSON и компоненты страниц напрямую. Git хранит историю, сборка формирует новую версию, а система развёртывания доставляет её на сервер.
Но CMS — это не только административная панель. Это модели данных, связи между документами, API, управление медиафайлами, локализация, права доступа и история версий. Всё это остаётся полезным, даже если визуальным редактором никто не пользуется.
На моих проектах Payload CMS продолжает выполнять эти задачи, хотя повседневные изменения контента проходят через агента, а не через админку.
А в среде с несколькими редакторами структурированное хранилище и механизмы совместной работы становятся ещё важнее.
Поэтому для простого сайта ответом может стать отказ от CMS в пользу файлов и релизов. Для сложного проекта — CMS с программным доступом, ревизиями и изолированными рабочими областями.
Вопрос уже не столько в том, нужна ли административная панель, сколько в том, какие функции управления контентом останутся востребованными, когда основным пользователем системы станет ИИ-агент.
С чего начать
Автономность стоит выдавать конкретным видам действий, а не агенту целиком. Исправление опечаток, обновление внутренних ссылок и подготовка черновиков несут один уровень риска. Удаление материалов, изменение цен, юридических текстов, схемы базы данных и публикация во внешних системах — совсем другой.
Я бы начинал с обратимых и легко проверяемых задач: исправления битых внутренних ссылок, обновления заранее определённых контактов, метаданных, подготовки новостей, поиска устаревших упоминаний и создания страниц по готовому шаблону.
Для первых экспериментов результат лучше сохранять как черновик или в изолированной рабочей среде. Когда станет ясно, что агент выполняет определённый тип задач стабильно, часть операций можно публиковать автоматически.
Систему полезно проверять на неудобных сценариях. Попросить агента изменить элемент, который встречается в десятках мест. Дать ему поменять заголовок, затем вручную исправить телефон на той же странице и попробовать откатить только действие агента. Отменить раннюю правку, от которой уже зависят более поздние. Проверить, что действительно восстановилось после отката. Заблокировать операцию и посмотреть, не сможет ли агент выполнить её другим способом.
При этом для сайта с единственным агентом-редактором достаточно начать с проверки сборки, живых страниц, сохранности данных и процедуры восстановления. Для команды с параллельным редактированием понадобятся дополнительные проверки конфликтов и зависимостей.
Раньше человек сам открывал страницу, менял текст, проверял и публиковал. Теперь он может ставить задачу, а агент — выполнять весь цикл. Для одного редактора это превращается в последовательность релизов, для команды — в систему контролируемых изменений, где люди и агенты работают параллельно.
Современные ИИ-модели уже достаточно умны, чтобы самостоятельно редактировать сайты. Теперь главное — организовать работу с контентом и публикацию так, чтобы ошибки агента можно было вовремя обнаружить, а их последствия — ограничить и исправить.
