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

Запрос был такой - сделать короткий анонс из готовой статьи в блоге для размещения в соц.сети, подготовить рерайты для площадок, прикрепить картинку, поставить UTM-метки и опубликовать все по каналам. 

Т.к. задача рутинная, сразу возникла идея отдать ее агенту.
То есть, на входе статья в блоге, а на выходе Google Doc с короткими анонсами, рерайтами для Дзена и Spark, а далее публикация в Telegram и отложенные посты для остальных социальных сетей.

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

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

В этой статье хочу рассказать как я разрабатывал агента, который принимает запросы из телеги и создает страницы на WordPress + Elementor, не путает проекты, не трогает прод и не собирает каждый раз дизайн рандомно.

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

Но по факту все, конечно же, оказалось сложнее.

Чтобы это начало работать нормально, пришлось сделать отдельный навык - очередь задач, SQLite, CLI-проверки, правила для телеги, валидаторы, перенос бета в прод и отдельный компилятор на Python.

Так что расскажу все по порядку, возможно, кому то пригодится.

Тут будет по сути хронология работы с агентом, так что идем от начала до сегодняшнего дня.

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

А потом смотришь внимательнее и понимаешь, что основная дыра вообще не там. Токены уходят не на полезную работу, а на служебную движуху вокруг нее. Cron-задачи, проверки, диагностика, статусные запросы, огромные списки инструментов “на всякий случай” - все это тихо ест бюджет каждый день. Агент еще ничего толком не сделал, а счетчик уже крутится. Примерно как если бы мастер пришел поменять розетку, но сначала выгрузил из газели весь строительный рынок, два перфоратора и почему-то бетономешалку.

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

В общем, базовая история с аудитом страниц — мы каждый месяц отправляли подрядчику несколько страниц на проверку. Отбирали несколько максимально разных. Если находились проблемы на одной, мы также правили и на однотипных. В месяц так проверяли 4–6 страниц. И тут, из очевидных минусов — оплата подрядчика и ожидание.

Учитывая, что по сути нужно проверять однотипные вещи, вроде title, description, H1 и, например, ошибки в консоли, то я подумал, почему бы не попробовать отдать это агенту. Да, в деталях все не так просто, но общая процедура каждый раз плюс‑минус одинаковая, а значит можно настроить сценарий. 

Так появилась идея научить нашего AI‑ассистента делать аудит новых страниц самостоятельно. Не в стиле «посмотри сайт и скажи, что думаешь», а по нормальной процедуре, с фиксированным результатом. На выходе я хотел получать гугл‑таблицу с чек‑листом и PDF со скриншотами проблемных мест.

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