Jak AI-agenty przekształcają komercyjne API: case integracji z Dodo Pizza bez otwartego interfejsu
AI-agenty przestały być tylko konceptem — już wykonywane są przez nie transakcyjne czynności w produkcji: dodawanie produktów do koszyka, sprawdzanie salda bonusowego, potwierdzanie płatności i składanie zamówień. Kluczowym wyzwaniem technicznym jest współpraca z usługami, które nie oferują publicznych API. Case integracji z Dodo Pizza pokazuje, jak developer stworzył pełnowartościowy skill agenta nad zamkniętym RESTful-interfejsem, obejdzie WAF i ochronę antybotową za pomocą headless przeglądarki, jednocześnie zachowując ścisłą prywatność danych i respektując warunki użytkowania.
Architektura agenta: od CLI do kontekstowego skilla
System został zbudowany jako rozszerzalny skill dla frameworków agenckich (Claude Code, Kimiclaw, Openclaw), kompatybilny z każdym interfejsem obsługującym zewnętrzne narzędzia. W przeciwieństwie do asystentów głosowych, które ograniczają się do pytań informacyjnych, ten agent wykonuje stateful operacje: zarządzanie koszykiem, wybór punktu odbioru osobistego, dwuetapową autoryzację poprzez zapisane ciasteczka oraz potwierdzenie płatności przed spisaniem środków.
Krytycznie ważna jest zasada podziału odpowiedzialności:
- Interfejs agenta — czysty natural language interface: „zamów pizzę z kabanosami i lemoniadą”, „pokaż historię ostatnich trzech zamówień”;
- Logika wykonawcza — skrypt Node.js (
dodo.mjs), uruchamiany na podstawie triggera z agentowego runnera; - Wzajemne połączenia sieciowe — wyłącznie przez headless Chromium (Puppeteer), imitujące zachowanie realnego użytkownika.
Agent nie parsuje HTML — wykonuje fetch()-zapytania do wewnętrznego API strony z kontekstu załadowanej strony po przejściu wszystkich klientowskich sprawdzianów. Dla serwera to zwykły ruch użytkownika: taki sam User-Agent, te same ciasteczka, to samo navigator.webdriver === false, ten sam porządek ładowania zasobów.
Inżynieria odwrotna zamkniętego API i walka z detekcją
Dokumentację na ponad 30 endpunktów uzyskano metodą snifowania ruchu sieciowego za pomocą Chrome DevTools Protocol. Skrypt przechwytuje wszystkie fetch-i XHR-zapytania zawierające /api/ podczas pełnego scenariusza użytkownika — od przeglądania menu do finalizacji zamówienia. Dzięki temu powstała pełna mapa endpunktów: GET /api/v5/menu, POST /api/v5/cart/add, PUT /api/v5/order/confirm, GET /api/v5/profile/bonuses i inne.
Główne techniczne przeszkody i ich rozwiązania:
- Detekcja Webdrivera: ServicePipe sprawdza
navigator.webdriver. Rozwiązanie — jedna linia w opcjach uruchomienia Puppeteer:--disable-blink-features=AutomationControlled, plus ręczna zmiana właściwości w runtime. - JS-challenge: strona wyświetla captcha-trening tuż po
page.goto(). Agent czeka na pojawienie się napisu „dostawa” w<title>— wskaźnika pomyślnego załadowania SPA. - reCAPTCHA v3 przy logowaniu: programowe rozwiązanie brak. Autoryzacja odbywa się raz ręcznie na maszynie z GUI, ciasteczka zapisywane są w pliku i przekazywane na serwer. Czas życia — 30 dni, automatyczna rotacja nie została zrealizowana.
- Fingerprinting Canvas/WebGL: póki co nie aktywowany, ale architektura zakłada przyszłą integrację z
puppeteer-extra-plugin-stealth.
Wszystkie te działania zapewniają stabilną pracę przez 4 miesiące bez awarii i blokad.
Od skilla do ekonomii agentowej: bezpieczna autoryzacja i orkestracja międzyserwisowa
Obecnie agent działa w trybie „jeden użytkownik — jeden account — jeden serwis”. Jednak skalowalna model wymaga standaryzowanej identyfikacji agentowej. Proponuje się wykorzystanie operatorów telekomunikacyjnych jako identity provider: MTS ID, Sber ID czy Tinkoff ID już weryfikują tożsamość za pomocą paszportu i SIM. Schemat podobny do OAuth-owego tokenu agenta:
- Użytkownik raz autoryzuje się przez operatora;
- Operator wydaje JWT z wyraźnymi scope'ami:
orders:dodo:read,orders:dodo:write,limit:2000rub/day; - Dodo sprawdza podpis tokena i waliduje scope przed wykonaniem operacji;
- Odrzucenie dostępu — natychmiastowe przez mobilną aplikację operatora.
To eliminuje potrzebę przechowywania ciasteczek i ręcznej autoryzacji, dając biznesowi kontrolę nad uprawnieniami i analizę.
Jeszcze bardziej perspektywiczny jest model master-agenta. Koordynuje on kilka skillów równolegle:
Master Agent:
├── Dodo Skill → Pikantne kabanosy 25 cm — 369₽ (odbiór osobisty 15 min)
├── Magnit Skill → Dobry Cola 1.5l — 89₽ (dostawa 30 min)
└── Wniosek: „Zabierz pizzę z Dodo, zamów colę z Magnitu.
Oszczędność 66₽, objętość coli 3 razy większa. Ok?”Taki agent korzysta z protokołu A2A (Agent-to-Agent): każdy serwis publikuje maszyno-czytelne opisy swoich możliwości (np. w formacie OpenAPI 3.1 z rozszerzeniem x-agent-capabilities). Agenci odkrywają się nawzajem dynamicznie, bez ręcznej integracji.
Co jest ważne
- Agenty już działają w produkcji: autor zamówienia używa ich jako głównego sposobu składania zamówień od grudnia 2025 roku — to nie PoC, a gotowe rozwiązanie.
- Zamknięte API można legalnie wykorzystywać przez headless przeglądarkę, jeśli imituje się zachowanie realnego użytkownika i nie narusza się ToS (automatyzacja własnych działań w własnym akunecie).
- Biznes traci kontrolę i analizę, ignorując ruch agentowy: obecne integracje są niemożliwe do odróżnienia od scraperów w metrykach.
- Wydzielony agent-ready API — nie opcja, a przewaga konkurencyjna: obniża CAC do zera, eliminuje prowizję marketplaców i otwiera kanał dla personalizowanych promocji.
- Personalizacja powinna żyć po stronie klienta: agent zna historię zamówień, budżet i preferencje — biznesowi wystarczy udostępnić czyste, dokumentowane API.
Realizacja — 380 linijek JavaScript, jedna zależność (puppeteer-core), instalacja jedną komendą. Kod nie jest publikowany w open source ze względów etycznych: obchód ochrony antybotowej konkretnego serwisu wymaga uzgodnienia z właścicielem API. Cel artykułu — nie instrukcja do obchodzenia, a zaproszenie do dialogu o standardyzacji interfejsów agentowych.
— Editorial Team
Brak komentarzy.