Три дня на задачу, которая на бумаге выглядела просто: сделай так, чтобы агент сам заходил на сайты конкурентов, собирал цены и сообщал об изменениях. Без ручного труда, без Excel-таблиц, без "а можешь обновить?" в чате. Казалось, справлюсь за вечер.
Не справился. Но разобрался — и теперь это работает. Вот что я понял по пути.
Почему парсер — это не агент
Первая ошибка была предсказуемой: я пошёл гуглить "парсинг цен Python" и через час уже писал BeautifulSoup-скрипт. Формально он работал — заходил на страницу, вытаскивал нужный div, выводил цену.
Но это не агент. Это скрипт с жёстко зашитой логикой. Стоило конкуренту поменять вёрстку — и скрипт молча ломался. Добавить новый сайт — садись, переписывай селекторы. Каждый раз вручную, каждый раз заново.
Агент устроен иначе. Он не ищет конкретный CSS-класс — он понимает, что ему нужна цена товара, и сам разбирается, как её найти. Меняется структура страницы — адаптируется. Появляется новый сайт — достаточно добавить URL в список.
Разница примерно такая же, как между калькулятором и человеком, который умеет считать.
Что внутри: LLM + инструменты + память
Когда я наконец перестал бороться с селекторами и начал думать про агента нормально, структура сложилась сама.
Основа — языковая модель. Я использовал GPT-4o, но подойдёт любая с поддержкой tool calling. Она принимает решения: что сейчас делать, как интерпретировать то, что пришло, нужно ли копать глубже.
Вокруг неё три инструмента.
Загрузчик страниц. Простой requests я пробовал — многие сайты блокируют без браузерного окружения. Перешёл на Playwright: он запускает настоящий браузер и рендерит JavaScript. Это важно, потому что цены часто подгружаются динамически.
Экстрактор цен. LLM получает HTML страницы — точнее, очищенный текст, полный HTML слишком большой — и вытаскивает цену, название товара, дату. Иногда агент сам решает, что нашёл не то, и повторяет запрос с другими параметрами.
База данных. Простая SQLite с четырьмя полями: товар, источник, цена, время. Агент пишет туда каждый результат и сравнивает с предыдущим. Если цена изменилась больше чем на 5% — помечает как интересное.
Оркестрацию я сделал через LangChain, хотя честно говоря думаю, что можно было обойтись без него. Логика несложная, и фреймворк местами добавлял путаницы, а не убирал.
Где я потратил час на ерунду
Расскажу про тупик — чтобы не было ощущения, что всё шло гладко.
Примерно в середине работы я решил: пусть агент сам находит нужную страницу. Заходит на сайт, ищет товар через поиск, переходит по результатам. Автономный поиск, звучит красиво.
Это была плохая идея. Агент начинал блуждать. Страница категории, потом страница фильтров, потом куда-то ещё — и через три шага GPT-4o уже не очень понимал, зачем вообще сюда пришёл. Контекст разбухал, результат был непредсказуемым.
Я откатился к простому решению: URL каждого товара задаю явно. Агент не ищет — загружает конкретную страницу и вытаскивает цену. Скучнее, но работает стабильно.
Дело в том, что полная автономия агента для мониторинга цен — это не достоинство, а помеха. Здесь важна точность, а не инициатива.
Как выглядит реальный запуск
Раз в день через простой cron запускается скрипт. Он передаёт агенту список из 20 пар "товар — URL". Агент проходит по каждой, собирает цены, записывает в базу, сравнивает с вчерашними.
Результат приходит в Telegram-бот: короткий список того, где цена изменилась. Что-то вроде: "Конкурент A: дрель Bosch — было 8 900, стало 7 400. Снижение 17%."
На всё уходит около 12 минут. Без моего участия.
Иногда агент ошибается — неправильно интерпретирует цену со скидкой или путает основной товар с похожим. Примерно в 3–5% случаев. Я не пытаюсь довести это до нуля: слишком дорого по времени. Раз в неделю смотрю на аномальные записи и при необходимости правлю промпт.
Что дальше и где потолок
Думаю сейчас про две вещи.
Первая — исторические тренды. Пока я вижу только "вчера/сегодня". Хочу добавить простую визуализацию, чтобы видеть, как цена менялась за месяц. Это уже не про агента — просто аналитика поверх базы.
Вторая — масштаб. На 20 позициях всё работает хорошо. Что будет на 200 — не знаю. Скорее всего, замедлится и вырастут расходы на API. Придётся или кешировать запросы к LLM там, где страница не изменилась, или переключаться на более дешёвую модель для рутинных случаев.
На практике главный вывод оказался не технический. Я начинал с желания сделать "умного" агента, который всё решает сам. Закончил на простом и предсказуемом пайплайне, где LLM занимается только тем, в чём правда помогает — извлечением смысла из неструктурированного HTML. Остальное — обычный код.
И это, как ни странно, работает лучше.
