Захожу в понедельник в админку — и вижу, что один из конкурентов за выходные уронил цену на главный товар на 12%. Кто-то из команды заметил бы это через два дня, когда продажи уже просели. Я решил сделать так, чтобы такие вещи не зависели от человеческого внимания.
Этот пост — разбор того, как я строил AI-агента для мониторинга цен. Без продающих обещаний, просто пошагово — что сработало, куда я врезался и что бы переделал.
Зачем нужен агент, а не простой парсер
Первое, что приходит в голову — написать скрипт, который раз в час ходит на сайты конкурентов и сохраняет цены. Я так и сделал, и это работало ровно до первой капчи, первого AJAX-сайта и первого изменения вёрстки. Парсер ломается от любого чиха.
AI-агент умеет адаптироваться. Если структура страницы изменилась — он не падает, а пытается понять, где теперь цена. Если сайт поднял капчу — замечает это и переключается на другой источник. Это не магия, а набор эвристик, обёрнутых в логику принятия решений.
Архитектура: из чего состоит агент
Система состоит из четырёх слоёв.
Слой сбора данных. Сюда входят парсеры для конкретных сайтов, API-коннекторы (если конкурент даёт публичное API), и агрегаторы вроде Ozon или Wildberries, где можно получить данные без героических усилий. Для каждого источника — свой адаптер. Если конкурент закрыл сайт — адаптер помечается как сломанный, и агент переходит к следующему.
Слой обработки. Здесь LLM принимает на вход сырой HTML или скриншот и вытаскивает нужные поля: название товара, цену, наличие, скидку. Для этого не нужна мощная модель. Иногда это llama 3, иногда что-то из линейки Gemini Lite — зависит от задачи.
Слой анализа. Тут всё самое интересное. Агент сравнивает текущие цены с историей, выявляет аномалии, формирует алерты. Одно дело — цена упала на 50 рублей, совсем другое — на 20% за сутки. Агент сам решает, что считать значимым изменением.
Слой уведомлений. Отправка в Telegram, на почту, в Slack — как удобнее. У меня приоритет такой: резкое изменение — сразу в Telegram, накопленная сводка — раз в день на почту.
Первая проблема, в которую я упёрся
Сайты конкурентов не хотят, чтобы их парсили. Донатед, Cloudflare, капча на каждый чих, динамическая загрузка контента. Я потратил три дня на то, чтобы заставить агента стабильно собирать данные с одного конкретного сайта — и это был site:a, у которого ещё и вёрстка регулярно менялась.
Потом до меня дошло: не надо парсить все сайты одинаково. Для каких-то конкурентов данные приходят через RSS, для других — через SerpAPI или парсинг через прокси. Часть данных беру с маркетплейсов, где всё уже структурировано. Там есть API для партнёров, и данные лежат в нормальном JSON.
Не бейся в одну стену. Собери данные из разных каналов и агрегируй.
Как я научил агента не слать ложные алерты
Первую неделю агент слал по 40 уведомлений в день. Я перестал смотреть Telegram от этого канала вообще. Бесполезный шум.
Я ввёл пороги. Не "цена изменилась" — а "цена изменилась более чем на 5% и держится так больше 6 часов". Добавил дедупликацию: если на одном товаре цену прыгали туда-сюда три раза за час — это один алерт, а не три. Ввёл понятие "тренда": агент смотрит не на одно изменение, а на паттерн. Цена падает три дня подряд — значит это не баг, а стратегическое решение конкурента.
Отдельная история — сезонность. Агент должен знать, что в чёрную пятницу цены падают у всех, и не слать алерт "конкурент демпингует". Для этого я загрузил историю цен за два года и настроил пороги относительно медианы, а не абсолютного значения.
Инструменты, которые я использую
Не буду советовать определённый стек — расскажу, что работает у меня, а ты адаптируй под себя.
LangGraph — для оркестрации. Граф состояний нагляден, а мониторинг цен хорошо ложится на конечный автомат: собрать данные → обработать → проанализировать → отправить → повторить.
PostgreSQL с TimescaleDB — для хранения. Мне нужна история цен, чтобы строить графики и считать тренды. TimescaleDB умеет в time-series и нормально дружит с SQL-запросами вроде "покажи среднюю цену за последний месяц по этому SKU".
LLM — комбинация. На этапе извлечения данных из страниц — мелкие модели или open-source решения, чтобы не платить за каждый вызов. На этапе анализа и формирования выводов — что-то посильнее, потому что там нужна интерпретация, а не просто распознавание цифр.
Сколько это стоит и стоит ли оно того
Посчитал. Агент обрабатывает около 200 товаров на 8 конкурентов, запуск раз в три часа. Около 600 вызовов API в сутки. Обходится это примерно в $15–20 в месяц — в основном на API маркетплейсов и LLM. Сервер — минимальный VPS за $5.
За три месяца я поймал семь значимых изменений цен, которые повлияли на мои продажи. Два раза оперативно отреагировал и скорректировал цены. По моим прикидкам, это сэкономило несколько сотен тысяч рублей — не в виде точного подсчёта, но порядок цифр правильный.
Что я бы сделал иначе
Начал бы с хранилища раньше. Первые две недели я писал в JSON-файлы, и это было больно — нельзя нормально построить графики и нельзя нормально искать по истории. Пришлось всё переделывать.
Не стал бы парсить все сайты вручную. Я потратил много времени на парсеры, которые живут неделю и ломаются от любого редизайна. Сейчас я бы сразу смотрел в сторону готовых решений для мониторинга и API-источников — и парсил только то, что нельзя получить иначе.
И главное — не строил бы агента как большую монолитную систему. Сначала простой скрипт, который просто собирает цены в таблицу. Потом алерты. Потом аналитика. Постепенно. AI-слой добавляется последним, когда база уже работает и ты понимаешь данные.
Мониторинг цен — это не rocket science. Это инженерная задача среднего уровня, где AI помогает закрыть неудобные места: парсинг страниц с кривой вёрсткой, интерпретация неоднозначных ситуаций, приоритизация алертов. Если ты уже работаешь с данными и у тебя есть список конкурентов — начни с ручного сбора, посмотри на данные, пойми паттерны. Агент добавишь потом.
