Автоматизация ВКонтакте с ИИ: 9 задач и результаты моих тестов

Автоматизация ВКонтакте с ИИ может брать на себя сбор материалов, проверку входящих, работу с журналом и подготовку контента. Но между «агент нажал кнопку» и «продвижение принесло клиентов» остаётся большая разница. В своём тесте я увидел её сразу.

25 августа 2026 года я собрал девять задач для работы во ВКонтакте. В тестах получилось отправить 3 заявки в друзья и один комментарий; несколько запусков закончились с техническими проблемами. Доказанного роста подписчиков и продаж этот день не показал.

На старте было около 300 подписчиков, один-два лайка под публикацией и почти нулевая живая активность. Я хотел проверить, можно ли перенести регулярную работу с площадкой в управляемый процесс: отдельные инструкции, расписание, единый реестр и контроль результатов.

Ниже - разбор того эксперимента: что делали девять задач, где они ломались и что пришлось изменить. Названия кнопок, доступность действий и лимиты описывают тест 25 августа 2026 года. Это не актуальная инструкция по интерфейсу VK и не подтверждение, что выбранная механика подходит любому аккаунту.

Сначала важная граница: я не собирал машину для спама

Фраза «автоматизация продвижения» легко вызывает неправильную картинку. Будто агент получает аккаунт, начинает добавлять сотни людей, писать в личку и оставлять под публикациями одинаковое «Отличный пост!».

Такой сценарий мне не нужен.

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

Моя задача была другой: перенести в автоматизацию полезную часть старого SMM-марафона.

• находить людей, которые уже соприкоснулись с моим сообществом;
• постепенно добавлять подходящих в друзья;
• замечать публикации и истории друзей;
• читать обычную ленту и включаться только там, где есть что сказать;
• находить профессиональные сообщества;
• не терять ответы людей;
• вести единую память о действиях;
• каждый вечер проверять, не начала ли система делать глупости.

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

Для меня это и есть граница между ИИ-сотрудником и бездумным автокликером.

Как устроена автоматизация: инструкции, агент и общий журнал

Вся система состоит из пяти слоёв.

Obsidian с редактируемыми регламентами
                |
                v
cron по расписанию -> ИИ-агент -> браузер -> интерфейс VK
                |                         |
                v                         v
       Google-реестр <- фактические действия и результаты
                |
                v
      ежедневный контроль качества и дашборд

В моём тесте техническим исполнителем стал OpenClaw. Но регламенты специально написаны не под одну модель или одного агента.

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

Obsidian хранит должностные инструкции

Для каждой задачи создан отдельный Markdown-файл. В нём лежат:

• цель;
• источники данных;
• алгоритм;
• дневные лимиты;
• условия пропуска;
• стоп-сигналы;
• формат записи результата;
• ограничение времени;
• правила текста и тона.

Главное решение: сам cron не хранит копию алгоритма.

В cron есть только расписание и короткая команда: открой конкретный файл, перечитай его полностью и выполни актуальную версию. Если файл недоступен, ничего не делай.

Это кажется мелочью, но именно она делает систему управляемой. Мне не нужно искать старый промпт внутри планировщика, останавливать задачу и пересобирать её после каждой правки. Я меняю один регламент в Obsidian, Syncthing доставляет его на сервер, и следующий запуск работает уже по новым правилам.

Google Sheets хранит операционную память

Мы начали с большой таблицы, а потом почти вдвое упростили её. Чем больше колонок, тем больше времени агент тратит на чтение, сопоставление и заполнение полей, которые никто потом не использует.

В финальной версии осталось восемь рабочих вкладок:

1. Дашборд - текущие показатели и ежедневные итоги.
2. Люди - профиль, источник, статус и следующее действие.
3. Действия - что фактически сделано, где, когда и каким запуском.
4. Сообщества - найденные группы, оценка и статус вступления.
5. Темы - реальные вопросы аудитории и гипотезы контента.
6. Запуски - начало, конец, статус, результат и ошибка каждой задачи.
7. Стоп-лист - люди и источники, с которыми нельзя взаимодействовать.
8. Настройки - лимиты, режим паузы, поисковые темы и технические параметры.

Числовой VK ID мы сделали необязательным. Нормализованной ссылки на профиль достаточно.

Это решение появилось не из теории. За него мы заплатили первым падением системы.

Первый тест занял больше получаса и уронил память

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

Агент начал искать числовой VK ID каждого человека. У части профилей вместо id123456 была короткая ссылка с именем. Старые способы получить ID не сработали. Агент стал открывать каждый профиль, искать ссылки на друзей и стену, снимать большие DOM-снапшоты, пробовать разные команды и перепроверять результат.

Три человека заняли больше тридцати минут.

OpenClaw съел около 2 ГБ оперативной памяти. Gateway получил OOM, перезапустился и восстановил ту же зависшую задачу. До таблицы агент сначала вообще не дошёл.

Это был идеальный урок.

Нам не нужен идеальный профиль человека. Для продвижения достаточно имени и стабильной ссылки. Числовой ID полезен, только если он уже виден. Нельзя открывать отдельную страницу ради поля, которое не влияет на следующее действие.

Мы переписали регламент:

• читать карточки прямо в списке подписчиков;
• не открывать личные профили;
• не снимать полный DOM;
• не искать числовой ID любой ценой;
• сначала прочитать все существующие ссылки из таблицы;
• записывать новых людей одной пакетной операцией;
• жёстко останавливаться через 10 минут.

Следующий тест собрал пять новых людей примерно за четыре минуты без открытия профилей и без перезапуска gateway. Потом задача записала десять кандидатов за один проход.

Но и здесь появилась следующая проблема.

Девять задач ИИ-SMM-отдела в эксперименте

Мы разделили процесс на отдельные роли. У каждой свой график и своя зона ответственности.

На момент описанного теста некоторые задачи ещё находились на испытательном сроке. Это важно. Наличие cron ещё не доказывает, что он приносит продвижение.

Почему очередь кандидатов больше дневного лимита заявок

Сначала мы собирали десять кандидатов и хотели отправлять десять заявок в друзья.

На практике это не работает. У части людей нет кнопки Добавить в друзья. Доступна только подписка. Кто-то уже друг. Кто-то закрыт. Кто-то попал в список раньше.

В первом тесте отправки заявок агент открыл семь профилей:

• три заявки отправил;
• одного человека распознал как уже существующего друга;
• троих пропустил, потому что у них была только кнопка подписки.

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

Это два разных показателя:

• сколько людей мы нашли;
• сколько допустимых действий смогли выполнить.

Смешивать их нельзя.

Почему три заявки заняли 17 минут: агент не узнал кнопку

После нажатия Добавить в друзья VK показал не ожидаемое Заявка отправлена, а Вы подписаны.

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

Три заявки заняли 17 минут вместо десяти.

Для интерфейса в нашем тесте мы зафиксировали такой переход:

Добавить в друзья -> Вы подписаны = заявка отправлена

После однозначной смены состояния не нужно повторять проверку на каждом профиле. Нельзя нажимать второй раз, если результат неясен. Сомнение записывается в журнал, а задача идёт дальше или останавливается.

Так рождается настоящая должностная инструкция ИИ-сотрудника. Не из красивой схемы, а из конкретных мест, где он ошибся.

Автоматизация друзей столкнулась с реальностью: друг был один

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

У него не было свежих публикаций. Последний содержательный пост был от 9 мая. Агент правильно не стал писать комментарий под старой записью только ради выполнения плана.

Но полностью игнорировать старую безопасную публикацию тоже не обязательно. Мы разделили правила:

• комментарий только под свежей записью не старше 14 дней;
• лайк можно поставить под последней подходящей публикацией не старше 90 дней;
• если нет безопасного повода, выполнить ноль действий.

Это маленькая деталь, но она защищает от очень странного поведения. Представьте человека, который внезапно приходит к вам под пост трёхмесячной давности и оставляет длинный аналитический комментарий. Технически действие выполнено. Социально оно выглядит ненормально.

С историями всё оказалось ещё честнее: доступных историй было ноль

В блоке историй агент увидел собственный профиль, человека со статусом Заявка отправлена и алгоритмическую подборку VK.

Подтверждённого друга среди них не было.

Результат теста:

• просмотрено историй друзей - 0;
• реакций - 0;
• ответов - 0;
• ошибок - 0.

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

Поиск сообществ показал, насколько буквальным бывает ИИ

Первая тема поиска была онлайн-эксперты.

VK выдал маникюр, барбершопы, астрологию, макраме, рисование и онлайн-опросы. Слово онлайн встречается в огромном количестве описаний, которые не имеют отношения к нашей аудитории.

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

Мы изменили сам принцип поиска.

Нельзя искать только буквальное название аудитории. Нужно искать профессиональную среду, в которой она живёт:

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

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

При этом потребительские доски объявлений и страницы отдельных салонов не подходят. Нам нужны места профессионального общения самих специалистов.

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

Реальная лента дала один комментарий из восьми публикаций

Задача комментариев в общей ленте была самой спорной.

Изначально мы хотели просматривать 20 публикаций и оставлять до пяти содержательных комментариев. Первый контрольный запуск показал реальную воронку.

Агент просмотрел восемь записей:

• развлекательный пост о кино;
• продажу курса;
• юмористическую запись;
• политико-криминальную новость;
• промо телевизионного шоу;
• локальную рекламу аренды;
• спортивный рекламный материал;
• пост Wylsacom о Vision Pro.

Подходящим оказался один пост из восьми. Агент поставил лайк и написал один комментарий. Вся сессия заняла 5 минут 43 секунды.

В этой небольшой выборке подошёл один пост из восьми - 12,5 процента. Такой тест не даёт надёжной нормы для всей ленты. Мы взяли гипотезу для следующей проверки: просматривать до 30-40 записей и допускать меньше комментариев, если подходящих поводов нет.

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

После проверки в регламент добавили:

• прокручивать и дозагружать ленту порциями;
• просматривать до 40 разных публикаций;
• не останавливаться после первой видимой порции;
• не писать ради выполнения нижнего лимита;
• использовать 1-2 простых предложения;
• не ставить длинное тире, только короткий дефис;
• иногда добавлять один уместный смайлик;
• не рекламировать продукт, сообщество или личные сообщения;
• не повторять структуру предыдущих комментариев.

Первый комментарий был содержательным, но получился слишком аналитическим. Формально всё хорошо, а по тону чувствовалась нейросеть. После этого в регламент появился отдельный запрет на шаблоны вроде важнее не X, а Y, ключевой момент здесь и другие конструкции, которые превращают обычную реплику в заключение консультанта.

Входящие диалоги: отвечать можно, притворяться Ильёй нельзя

Отдельная задача два раза в день проверяет:

• ответы на наши комментарии;
• комментарии под публикациями ShvedkovPRO;
• новые личные сообщения.

Она не пишет первой. Лайк, подписка, принятие заявки и просмотр истории не считаются разрешением начать личный разговор.

На простой публичный вопрос агент может ответить по контексту. На вопрос о продукте он читает нужный раздел базы знаний. В первом личном ответе он обязан честно представиться: Привет! Я ИИ-помощник Ильи.

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

Мы отдельно оставили список разрешённых материалов пустым. Пока конкретный файл и ссылка не согласованы, агент не имеет права обещать или отправлять PDF, презентацию или чек-лист.

Во время пустого теста входящих событий не было. Но агент зачем-то попытался открыть локальную базу OpenClaw через sqlite3, которого на сервере не оказалось. На результат это не повлияло, зато показало ещё один источник лишней самодеятельности.

В регламент добавили прямой запрет:

• не читать внутреннюю базу OpenClaw;
• не использовать sqlite3;
• считать Google-реестр единственным источником дедупликации;
• указывать в отчёте любую ошибку инструмента, даже если задача продолжилась.

Темы и коллаборации оставили как сомнительный эксперимент

Не каждая автоматизация обязана сразу стать постоянной.

Раз в неделю агент анализирует реальные вопросы и обсуждения за последние 14 дней. Он может добавить до пяти тем контента и максимум двух авторов, с которыми теоретически возможен совместный материал.

Но тема попадает в таблицу только в двух случаях:

• человек задал прямой содержательный вопрос;
• одна проблема независимо проявилась минимум в двух событиях.

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

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

Это тоже важная часть управления ИИ-командой. Сотрудник не становится полезным только потому, что у него есть расписание.

В 22:00 отдельный агент проверяет всех остальных

Последняя задача дня не открывает VK. Она читает только Google-реестр.

Она проверяет:

• все ли действия имеют run_id;
• существуют ли запуски, на которые ссылаются действия;
• нет ли повторных комментариев и заявок;
• не превышены ли дневные лимиты;
• уложились ли задачи в своё время;
• не записан ли SUCCESS после превышения лимита;
• не было ли капчи, предупреждения, жалобы или несовпадения аккаунта;
• не повторяется ли одна и та же техническая проблема.

На дашборде появился постоянный журнал:

Одна дата занимает одну строку. Повторный запуск обновляет её, а не создаёт дубль. При последующем разборе можно открыть дашборд и увидеть не десятки сообщений в Telegram, а последовательность ежедневных выводов.

Глобальная пауза включается не при любой ошибке Python. Она нужна при реальном риске:

• капча;
• предупреждение или ограничение VK;
• жалоба человека;
• несовпадение аккаунта;
• неясный результат внешнего действия;
• повторно отправленное сообщение, заявка или комментарий;
• превышение дневного лимита внешних действий;
• два негативных события за семь дней.

Один неудачный флаг CLI или предупреждение о будущей версии библиотеки попадает в отчёт, но не останавливает весь отдел.

Результаты теста: что действительно сработало

К концу настройки в реестре было 18 людей.

Фактические тесты дали:

• 10 новых кандидатов за один оптимизированный сбор;
• 3 отправленные заявки в друзья;
• 1 подтверждённого друга;
• 1 содержательный комментарий и лайк в общей ленте;
• 0 доступных историй подтверждённых друзей;
• 0 подходящих вступлений в сообщества после первых шумных поисков;
• 0 новых входящих событий;
• 4 проблемных запуска в истории тестов, включая превышения времени и старую ошибку авторизации.

Это не результат продвижения. Это результат настройки производственной линии.

На момент описанного теста у меня не было доказательства, что система даст подписчиков, диалоги или заявки на услуги. В этой статье не приведены последующие замеры. Число действий агента нельзя выдавать за результат продвижения.

Зато уже есть другое:

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

Семь правил, которые я заберу в следующие автоматизации

1. Сначала read-only, потом кнопки

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

Поэтому сбор кандидатов и отправка заявок стали разными задачами.

2. Не собирайте данные, которые не влияют на решение

Числовой VK ID стоил нам получаса и падения памяти. Ссылка на профиль решала ту же операционную задачу.

Каждая колонка таблицы должна отвечать на вопрос: какое следующее действие меняется из-за этого значения?

3. Интерфейс нужно учить на конкретных состояниях

Добавить в друзья -> Вы подписаны оказался важнее длинного универсального промпта.

ИИ-агенту полезны не абстрактные советы «проверь результат», а конкретные признаки успешного перехода.

4. Лимит времени важнее плана действий

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

Без этого один непонятный элемент интерфейса способен удерживать браузер до OOM.

5. Ноль действий должен быть нормальным результатом

Нет истории друга, нет свежего поста, нет подходящего сообщества, нет входящего сообщения - ничего не делаем.

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

6. Один источник истины лучше трёх копий промпта

Алгоритм хранится в Obsidian. Состояние и факты - в Google Sheets. Cron знает только путь к регламенту.

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

7. Отдельный контролёр нужен раньше, чем кажется

Дашборд не должен появляться после сотни действий. Он нужен в тот момент, когда в системе появляется вторая автономная кнопка.

Потому что вопрос уже не только «сработало ли». Нужно видеть, не повторилось ли действие, не вышли ли мы за лимит и не скрыла ли задача ошибку под статусом SUCCESS.

Как начать автоматизацию ВКонтакте с одной задачи

Да, но я бы не начинал с девяти задач за день.

Минимальная версия выглядит так:

1. Создайте одну таблицу с людьми, действиями, запусками, стоп-листом и настройками.
2. Выберите один безопасный read-only источник кандидатов.
3. Научите агента проверять дубли до открытия браузера.
4. Ограничьте тест тремя объектами и десятью минутами.
5. Запишите точные состояния интерфейса после первого прогона.
6. Только потом разрешите одно внешнее действие.
7. Добавьте дневной лимит и аварийную паузу.
8. Все фактические действия записывайте сразу после подтверждения.
9. Разделите сбор, действие и аналитику на разные задачи.
10. После согласованного периода проверки отключите или пересмотрите задачи, которые не дают полезного результата.

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

Как проверить, есть ли у автоматизации маркетинговый смысл

После технического теста нужно наблюдать за результатами на площадке. Для этой системы я выделил такие показатели:

• сколько заявок в друзья принято;
• на какие комментарии ответили;
• сколько появилось содержательных диалогов;
• были ли обращения по продукту и из какого источника;
• сколько времени уходит на контроль и исправления;
• какие действия выглядят неестественно и требуют остановки.

Заявка в друзья, сообщение, заявка на услугу и покупка - разные события. Их нужно учитывать отдельно. Эта статья показывает настройку и первые тесты. Дальнейшие результаты нельзя достроить из количества лайков.

Что взять из кейса для своего проекта

Начните с одной задачи, в которой удобно проверять результат: собрать вопросы под вашими публикациями, подготовить черновики ответов или свести показатели в таблицу. У внешних действий отдельно проверяйте актуальные правила площадки, доступный способ работы и уместность для своего аккаунта. Лимиты моего эксперимента не являются разрешёнными лимитами VK.

Для работы с контентом пригодятся пример контент-плана из своих материалов и разбор задач ИИ-SMM-менеджера. Если вы внедряете систему в компании, используйте план первого проекта от выбора процесса до приёмки.