Недавно переносил у нас рабочую Windows-ВМ с Hyper-V на Proxmox.

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

Сам процесс я автоматизировал через AI-агента и уже на первой попытке всплыл хороший пример того, почему такие задачи нельзя сводить к последовательному выполнению команд. Агент создал ВМ на Proxmox, запустил ее, получил от qm status состояние running и посчитал перенос завершенным, хотя сама Windows в этот момент вообще не загрузилась.

Дальше таких моментов всплыло еще больше.

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

Когда в работе появляется несколько независимых задач, возникает очевидная идея - "почему бы не поручить их разным AI-агентам одновременно, вместо того чтобы ждать, пока один агент закончит все по очереди?"

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

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

Привет! Меня зовут Рома, я фуллстак разработчик в компании Efsol. Когда я начал делать агентов под разные задачи внутри компании, я довольно быстро понял что задача не сводится просто к хорошему промпту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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