Case study: Shopping agent

Pointa: opakované nákupy nejsou těžké, jen berou pozornost. Cíl nebyl “autopilot”, ale paměť + správný timing + potvrzení, než se objednávka skutečně odešle.

Kontext

  • Telegram je UI: zpráva → návrh → potvrzení
  • Rohlík nemá stabilní API pro tohle → automatizace přes Playwright (a férově přiznaná křehkost)
  • historie nákupů se učí z účtenek / objednávek, ne z ručního zadávání

Design rozhodnutí (a proč)

  • Učení z historie: u každé položky držím last_bought, frequency_days, times_bought
  • Ověřená frekvence: automatický návrh bere jen položky, které už byly koupené víckrát (méně falešných nákupů)
  • Alias vrstva: když se názvy na webu mírně liší, bot se zeptá na klíčové slovo místo toho, aby hádal
  • Human‑in‑the‑loop: bez “potvrzuji” se objednávka neodešle

Největší pasti

  • UI na webu se mění → řešení: raději fail a viditelná chyba než tichá chyba v košíku
  • duplicity v historii → řešení: processed_order_ids (idempotence)
  • neznámé produkty → řešení: dialog v Telegramu (0 = přeskočit, 00 = přeskočit vše)

Důkazy / provozní signály

  • logika příkazů: /uctenky, nakup, potvrzuji
  • persistovaná session (cookies) lokálně, aby se bot nemusel pokaždé přihlašovat

Co bych udělal dál

  • rychlý “dry‑run” výpis: co by se přidalo do košíku a proč (audit)
  • lepší detekce UI změn + fallback screenshot do logu pro rychlý debug
Projekt Zpět na Case studies