Два бота нашли друг друга в группе и начали продавать виллы друг другу

Вечер 11 апреля начался с того, что я обнаружил: 17 моих AI-агентов не работали. Не упали, не выдали ошибку — просто тихо стояли с надписью «работаю», хотя на самом деле давно закончили и ждали чего-то, чего никогда не придёт.

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

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

Проблема 1: 17 агентов с синдромом «я ещё работаю»

Открываю систему управления агентами. У 11 из 17 статус «in_progress» — работают. Смотрю на задачи: все закрыты, результаты есть, комментарии оставлены. Агенты сделали свою работу, но не переключили себя в статус «done».

Это классическая ситуация для систем с долгими задачами: агент начинает задачу, выполняет её, отчитывается о результате — и застревает. Ждёт подтверждения, дополнительной команды, чего угодно. Внешне выглядит как «работает». На деле — завис.

Представь сотрудника, который сделал отчёт, положил его на стол и сидит с умным видом. Спрашиваешь: «Ты занят?» — «Да, работаю». — «Что делаешь?» — «Работаю». Он искренне считает, что ещё в процессе, хотя отчёт давно готов.

Решение: написал скрипт-«доктора». Каждые 5 минут он проверяет каждого агента: если статус «in_progress», но задача завершена и результат есть — принудительно переводит в «done» и освобождает для новых задач. Не изящно, но работает. Через минуту после деплоя все 17 ожили и начали разгребать накопившиеся задачи.

Проблема 2: 230 уведомлений в день

Агенты ожили — и начали активно об этом сообщать. Открываю Telegram: 230 сообщений за день. «Stories Sync запущен». «Авто-перезапуск: Sales Bots». «Heartbeat OK». «Задача принята». «Задача выполнена». «Задача отменена». Каждые несколько минут — что-то новое.

Это как офис, где каждый сотрудник вслух комментирует каждое своё действие: «Открыл почту. Прочитал письмо. Ответил на письмо. Закрыл вкладку. Взял кофе. Открыл новую вкладку.» Работа ведётся, но шум делает невозможным сосредоточиться на чём-то важном.

Проблема глубже, чем просто «много сообщений». Когда всё одинаково громко — важное теряется в потоке. Реальный алерт «сервис упал» тонет в море «heartbeat OK», «задача принята», «модуль запущен».

Решение: фильтр по принципу «мне нужны только результаты и блокеры». Технические статусы, подтверждения запуска, промежуточные состояния — всё это агенты теперь пишут в свои внутренние логи, но не в мой Telegram. В чат попадает только: готовый результат работы, блокер требующий моего решения, аномалия требующая внимания.

230 сообщений превратились в 5. Те же самые агенты делают ту же самую работу — просто перестали комментировать каждый шаг.

Проблема 3: бесконечный диалог двух продавцов

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

Первый бот: «Ищете виллу на Бали? Могу предложить отличные варианты!»

Второй бот: «Да! Расскажите подробнее, очень интересно.»

Первый: «Конечно! У нас есть виллы в Чангу, Семиньяке, Убуде — от 150 до 800 долларов за ночь. Какой район вас интересует?»

Второй: «Чангу! А есть что-нибудь с бассейном?»

Первый: «Отличный выбор! Да, есть несколько вариантов...»

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

Решение простое, но требовало явной реализации: каждый бот теперь знает список всех Telegram ID компании — своих аккаунтов, других продающих ботов, служебных аккаунтов. При получении сообщения первым делом проверяет: отправитель в списке «своих»? Если да — игнорирует. Реагирует только на внешние сообщения.

Для этого в базе данных завёл таблицу company_accounts с ID всех аккаунтов, которые принадлежат нам. Все боты читают эту таблицу при старте и добавляют её в свой «игнор-лист». Когда добавляем новый аккаунт — одна SQL-запись, и все боты автоматически обновляются.

Проблема 4: один лид — шесть уведомлений менеджеру

Менеджер по бронированиям — живой человек, работает в определённые часы. Когда появлялся горячий лид, система добросовестно ей сообщала. И сообщала. И ещё раз. И напоминала. И ещё раз напоминала.

Александра, свяжись с клиентом! (через 30 минут) Александра, срочно! (через час) АЛЕКСАНДРА, КЛИЕНТ ЖДЁТ! (через два часа)

Три-шесть уведомлений об одном и том же лиде. Плюс ночные пуши — система не знала, что Александра работает до 8 вечера по Бали, а в 3 часа ночи писать ей не стоит.

Это одна из тех ситуаций, которые кажутся хорошей идеей (не потерять лид!), но на практике создают дисфункцию. Менеджер начинает игнорировать уведомления, потому что 90% из них — повторы того, о чём уже знает. В итоге именно то важное уведомление, которое было бы новым, тоже пропускается.

Два изменения:

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

Казалось бы очевидные вещи. Но без явной реализации «очевидное» не работает — система делает то, что запрограммировано, а не то, что кажется само собой разумеющимся.

Между делом: демо-сайт и КП за час

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

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

Сайт с нуля — около часа. Не потому что я быстро верстаю, а потому что у меня есть готовая база компонентов и ИИ-помощник, который переводит описание в код. Я описываю структуру страницы, он генерирует HTML и CSS, я правлю под конкретику клиента. КП на основе шаблона — ещё 15 минут.

Это и есть то, о чём я писал про сдвиг к роли наладчика: когда у тебя есть правильно настроенные инструменты, «сделать сайт» превращается из проекта на неделю в задачу на час. Оставшееся время идёт на другие задачи — как в этом случае, на починку армии агентов.

Стандартизация: 17 агентов на единой модели

Пока разбирался с конкретными багами, обнаружил системную проблему: у разных агентов были разные конфигурации базовой модели. Один работал на более мощной (и дорогой) версии, другой — на стандартной. Некоторые имели разные лимиты контекста. Конфигурация складывалась исторически: когда-то добавил агента с одними настройками, потом другого — с другими, и со временем всё расползлось.

Это не только вопрос расходов (хотя и он тоже — об этом отдельно). Это вопрос предсказуемости. Когда агенты работают на разных конфигурациях, ты не всегда понимаешь, почему один справляется с задачей, а другой — нет. Может быть дело в промпте, а может — в лимите контекста или версии модели.

Стандартизировал всех 17 на одну конфигурацию. Это заняло около получаса — обход по каждому агенту, проверка настроек, выравнивание. Попутно нашёл и удалил 18 задач, которые числились в очереди, но были уже нерелевантными — артефакты экспериментов недельной и двухнедельной давности.

Что этот вечер говорит про автоматизацию

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

Есть расхожее заблуждение про автоматизацию: «настроил один раз — работает само». Реальность другая: ты настраиваешь, система работает, но окружающий мир меняется. Группы в Telegram появляются и исчезают. Аккаунты блокируются и заменяются. Нагрузка растёт — алгоритмы, которые работали при 10 объектах, ломаются при 50. Боты эволюционируют и начинают вести себя неожиданными способами (например, продавать виллы друг другу).

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

Неожиданные уроки армии ботов

За несколько месяцев управления системой из 17 агентов я замечаю закономерность: самые полезные уроки приходят из самых нелепых ситуаций.

Бот, продающий виллы другому боту — это смешно. Но этот случай заставил меня явно задуматься: а что вообще знает каждый агент о том, кто другие агенты? Оказалось — ничего. У каждого бота была логика «реагировать на сообщения», но не было понятия «наши аккаунты». Это пробел в архитектуре, который проявился только когда два агента оказались в одном чате.

230 уведомлений в день — раздражает. Но этот случай показал, что у меня не было явной политики «что должно попадать ко мне». Агенты генерировали всё, что казалось им важным. Без фильтра «важно для меня» и «важно для логов» — это одно и то же.

Агент, застрявший в статусе «работаю» — это потеря производительности. Но этот случай показал, что система управления агентами не имела механизма самопроверки: «я сказал, что работаю — я действительно работаю?»

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

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

Итог вечера

К ночи система работала лучше, чем утром. Не идеально — идеальная система — это утопия. Но предсказуемо и с меньшим количеством слепых пятен.

17 агентов перестали зависать. 225 лишних уведомлений исчезли. Два бота перестали продавать виллы друг другу. Менеджер перестала получать ночные дубли. Все модели стандартизированы. 185 гигабайт видео уехали в облако и ноутбук задышал.

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

Один человек с ноутбуком на Бали. Без офиса, без команды разработчиков. 16 вилл, 17 ботов и вечер, который начался с «ничего не работает», а закончился «работает лучше, чем вчера».