Как дать ИИ-агенту доступ к сайту и ничего не сломать

У клиента есть ИИ-агент, который пишет статьи, ведёт справочник и правит поля для поиска. Клиент хочет, чтобы агент делал это прямо на сайте, без разработчика посередине. Дальше обычно предлагают два варианта, и оба плохие.

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

Есть третий. Рассказываем, как он устроен, на проекте, где агент ведёт контент интернет-магазина с восемью сотнями товаров, обменом с 1С и живыми заказами.

Узкий вход вместо широкого доступа

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

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

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

Сначала проверка, потом запись

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

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

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

Ничего не теряется

Перед каждой правкой снимается копия страницы целиком. Есть история правок и откат, причём откат тоже можно отменить.

Отдельно — массовые операции. Перед правкой, которая затрагивает раздел, агент снимает снимок этого раздела, и снимок сразу подаётся обратно, если нужно вернуть всё как было. Без этого массовая правка — самая опасная операция из возможных: одна неверная замена проходит по тысяче страниц за секунду.

Ответы в формате, который дёшево читает модель

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

Списки отдаём таблицей с табуляцией, а не JSON: модель разбирает такое дешевле и ошибается реже. Ошибку отдаём фразой с подсказкой, что исправить, а не кодом: «код рубрики уже у статьи», «адрес /blog/… занят». Агент по такой фразе чинит сам, по коду — идёт гадать.

Правила знают ловушки конкретного сайта

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

• Ссылки проверяются запросом к сайту. Не регулярным выражением, а настоящим обращением: открывается адрес или нет.
• Адрес, который открывается, но ведёт не туда, получает отдельное предупреждение. На этом проекте так нашлась кнопка «Зарегистрироваться», которая вела на страницу входа. Формально ссылка рабочая, по смыслу — нет.
• Справочник не даст записать одно написание двум разным сущностям. Иначе автоматическая перелинковка начнёт вести на случайную из них.
• Канонический адрес ставится только на страницу, которая открывается без переадресации. Иначе поисковик получает указание на адрес, который сам же и перенаправляет.
• У товаров меняются только поля для поиска. Описания и цены перезаписывает обмен с 1С: всё, что агент напишет в эти поля, исчезнет при следующей выгрузке, а он об этом не узнает.

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

Где решает человек

Новые страницы приходят черновиками. На сайт их выпускает владелица — одним переключателем, но осознанно.

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

Как проверять перед запуском

Шлюз, который умеет записывать, надо проверять не выборочно. Мы выгрузили через него все страницы сайта и прогнали обратно: 3568 товаров вместе со снятыми с продажи, 366 статей, 136 карточек справочника, 110 акций. Расхождений быть не должно ни одного — выгрузка и обратная запись обязаны давать исходный текст символ в символ.

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

Что получается в работе

Первая неделя после открытия новых команд выглядела так. За ночь агент сверил справочник автоссылок и поправил шестнадцать карточек, разобрал конфликт двух написаний одного ингредиента, исправил заголовок, который нашла проверка, подготовил девять статей-гидов, обновил девять старых материалов по циклу «выгрузить — поправить — проверить — записать» и перед массовой правкой снял снимок раздела.

Цифры за первые недели: 75 новых страниц, 438 обновлений, всего через шлюз прошли 316 разных страниц — подробности этого проекта в отдельном кейсе. Больше трети команд приходится на время после десяти вечера — агент работает тогда, когда работает владелица, и разработчик для этого не нужен.

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

Одиннадцать дней: что видно по результату

Объём работы сам по себе ничего не доказывает — его обещают все. Интереснее посмотреть, что из этого объёма вышло наружу, в чужой кабинет вебмастера.

За одиннадцать дней, с конца октября по десятое ноября, через шлюз прошло вот что.

• Справочник ингредиентов вырос с 71 карточки до 137. Все они прошли аудит по двенадцати параметрам: заголовок, первый заголовок страницы, разметка, блок вопросов и ответов, подбор товаров.
• Перелинковка по разделу: проверены 364 статьи и 133 карточки, обновлены 212 страниц, добавлено 560 внутренних ссылок. Все 159 уникальных адресов, на которые они ведут, отвечают кодом 200 — ни одной битой.
• Девять статей по двум брендам, темы отобраны по частотности запросов.
• Двадцать шесть описаний для поиска переписаны по данным поисковой консоли и проверены на сайте — все двадцать шесть на месте.

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

Что из этого получилось в поиске за те же одиннадцать дней: страниц в индексе Google стало 1147 вместо 1071, показов — от 1200 до 1400 в день вместо восьмисот с небольшим. Для одиннадцати дней это быстро, и объяснение простое: правки шли сразу разделами — справочник целиком, перелинковка по всем статьям.

Отдельно стоит история про robots.txt. Среди новых команд есть проверка страницы глазами поиска, и через день после открытия агент нашёл ею давнюю ошибку: в файле была отдельная группа для Googlebot, неполная, а запреты лежали в общей группе — и на Googlebot не действовали вовсе. Робот месяцами ходил по постраничной навигации, адресам с параметрами оплаты и служебным каталогам. Такую ошибку сайт носит годами: файл выглядит заполненным, проверка синтаксиса молчит.

Последнее наблюдение — про данные. Пока у агента есть выгрузка поисковой консоли и частотности запросов, он правит то, что влияет на выдачу: описания страниц с высокими показами и нулевыми кликами, темы под живой спрос. Без таких выгрузок остаётся объём ради объёма.

Что проверить, прежде чем пускать агента на свой сайт

1. Что перезаписывается автоматически. Обмен с 1С, импорт прайсов, синхронизация с маркетплейсом. Всё, что они перезаписывают, агенту трогать бессмысленно.
2. Где наследуются свойства. В Битриксе свойство раздела спускается на страницы, у которых нет своего. Правка в одном месте может молча изменить сотни страниц.
3. Что происходит с адресами. Если на сайте есть переадресации, агент должен знать о них: иначе он проставит канонические адреса на страницы, которые перенаправляют.
4. Есть ли резервное копирование и как быстро оно разворачивается. Откат внутри шлюза закрывает контент, но не базу целиком.
5. Кто выпускает страницы на сайт. Ответ «никто, они выходят сами» означает, что первая же неудачная формулировка окажется в поиске.

Коротко

• Агенту не нужен доступ в админку — ему нужен список операций и предсказуемые ответы.
• У любой записи должен быть режим проверки: агент исправляет свои ошибки сам, если ему показать их до записи.
• Копия перед правкой, история, откат и снимок раздела перед массовой операцией — это не роскошь, а условие, при котором доступ вообще можно открывать.
• Правила под ловушки конкретного сайта важнее общих ограничений.
• Человек остаётся на выпуске страниц, а не на каждой правке.

Если у вас есть агент и живой сайт, которому нельзя ломаться, — посмотрите, как мы это делаем, или напишите нам: разберём, какие операции агенту нужны и где у вашего сайта опасные места.