Jak Funkcjonuje Agent IA Konwersacyjny Wewnątrz

Jak działa Agent IA Konwersacyjny wewnątrz (Archiwizacja OpenClaw)

Jak działa agent IA konwersacyjny w praktyce, turniej po turnieju? Ten post otwiera czarną skrzynkę OpenClaw: od momentu, gdy wiadomość klienta dociera na WhatsApp do tekstu, który agent pisze z powrotem. Będzie to techniczne. Warto sięgnąć, jeśli zdecydujesz się na architekturę produktu, kupisz rozwiązanie i chcesz ocenić podstawę, lub jeśli lubisz wiedzieć, co dzieje się za tą konwersacją.

TL;DR: każdy turniej przechodzi przez 6 etapów — ingest, rozwiązuje kontekst, wybiera umiejętności, decyduje o następnej akcji, wykonuje z ograniczeniami, przechowuje pamięć. Cały cykl obraca się w <sekundach na brzegu Cloudflare, bez stałego serwera.

---

Dlaczego architektura jest ważna

Agent konwersacyjny, który wygląda na działający w demo, ale łamie się w produkcji, zwykle ma jedno z tych 4 problemów:

1. Wysoka opóźnienie — klient czeka 8 sekund na odpowiedź, konwersacja umiera.
2. Nieskrępowana fantazja — agent tworzy cenę, godziny, politykę.
3. Zagubiony kontekst — klient wraca po 2 dniach i agent "zapomina" wszystko.
4. Nieskrępowany koszt — każda długa konwersacja wypełnia prompt i płacisz fortunę w tokenach.

4 to wybory architektury, a nie ograniczenia modelu. OpenClaw został zbudowany, aby uniknąć 4 — i drogą do zrozumienia jest patrzenie na cykl turnieju.

---

Cykl turnieju (6 etapów)

Wyobraź sobie, że klient właśnie wysłał wiadomość "chcę zarezerwować na sobotę rano". Co się dzieje między "otrzymaniem" a odpowiedzią agenta?

Etap 1 — Ingest (pracownik brzegowy, <ms)

Wiadomość z WhatsApp dociera za pośrednictwem webhooka Meta bezpośrednio do pracownika Cloudflare w punkcie obecności (PoP) najbliższym geograficznie. W Brazylii oznacza to São Paulo lub Rio, opóźnienie w sieci <0ms.

Pracownik wykonuje trzy rzeczy:

1. Weryfikuje podpis webhooka (HMAC wobec tajemnicy WABA).
2. Identyfikuje dzierżawcę na podstawie numeru telefonu odbiorcy (multi-tenant przez to_number).
3. Normalizuje payload — dźwięk zamienia się w transkrypcję, obraz w opis, lokalizację w {lat,lng}, tekst pozostaje takim samym.

Na końcu etapu 1 masz obiekt {dzierżawca_id, konwersacja_id, wiadomość_użytkownika} gotowy do następnego kroku.

• Historia ostatnich rozmów (ostatnie N rozmów istotnych).
• Długo terminująca pamięć klienta (preferencje, historia zakupów, notatki).
• Stan agenta (postać, włączone umiejętności, zasady).

Wszystko pochodzi z D1 (rozmieszczony SQLite Cloudflare). D1 zastępuje tradycyjny Postgres/Mongo — bez serwera bazy danych do utrzymania, dostęp w kilkanaście milisekund od robota, wieloosobowy przez tenant_id.

Kluczowa informacja: nie ładowujemy całej rozmowy w prompt. Manager Pamięci v2 OpenClaw (opisany w naszej dokumentacji wewnętrznej) wybiera tylko rozmowy istotne dla obecnego rozmowy (ostatnie N + N istotne semantycznie). To utrzymuje koszt tokenów przewidywalny nawet w rozmowach przekraczających 100 rozmów.

Etap 3 — Wybór umiejętności (polityka silnika, ~20ms)

Każdy agent ma zestaw umiejętności dostępnych — funkcji, które może wywołać. Przykłady: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Dana wiadomość "quero marcar pra sábado de manhã", polityka silnika filtruje:

• Umiejętności kompatybilne z zidentyfikowaną intencją (zapisanie).
• Umiejętności dozwolone w obecnym etapie rozmowy (nie każda umiejętność jest dostępna w każdym etapie).
• Umiejętności, które tenant włączył (kalendarz pojawia się tylko wtedy, gdy tenant zintegrował go).

W końcu masz mały zestaw umiejętności przekazany do modelu — nie 50 możliwych, tylko 4, które są tutaj sensowne. To drastycznie zmniejsza szansę, że model wywoła umiejętność niepoprawną.

Etap 4 — Decyzja (LLM call, 400-1200ms)

Teraz model wchodzi w grę. OpenClaw wywołuje jedną z najnowszych granicznych LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurowalna przez tenanta) z:

• System prompt = postać agenta + zasady + dostępne umiejętności.
• Historia = wybrane rozmowy w etapie 2.
• Wiadomość użytkownika = obecną wiadomość rozmowy.

Model odpowiada jedną z dwóch rzeczy:

• Ostateczna odpowiedź (tekst bezpośrednio do klienta).
• Tool call (żądanie wykonania określonej umiejętności z parametrami).

W przykładzie "quero marcar pra sábado de manhã", model typowo zwraca:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Etap 5 — Wykonanie z ograniczeniami (zmienna, ~100-500ms)

Umiejętność nie wykonuje się w modelu. Wykonuje się w kodzie naszym, który:

...

1. Weryfikacja parametrów (data_range ma poprawny format? spełnia on zasady dzierżawcy?).
2. Sprawdzenie uprawnień (ten agent ma prawo do zapytania o ten kalendarz?).
3. Wykonanie wywołania (API Google Calendar w tym przypadku).
4. Powrót wyników strukturyzowanych do modelu.

Dlaczego to jest ważne? Ponieważ model nigdy nie generuje wyników. Jeśli kalendarz zwróci [10h, 11h], to jest dokładnie to, co zostanie przesłane w następnym wywołaniu. Jeśli umowa nie powiedzie się, model wie, że nie powiedzie się. Zero ryzyka, że agent "stworzy" godzinę 9, kiedy nie ma.

W przypadkach dotyczących wrażliwych informacji (cena, termin, imię klienta), pipeline wymusza tool call — nie pozwala modelowi odpowiedzieć na podstawie własnego "wiedzy". To eliminuje najczęstsze przypadki alucynacji w agentach handlowych.

Etap 6 — Odpowiedź i persistencja (~50ms)

Po otrzymaniu wyników umowy, model wykonuje drugie wywołanie — teraz do formowania ostatecznej odpowiedzi dla klienta. Na przykład:

"Mam sobotę o 10 i 11. Którą preferujesz?"

W międzyczasie, worker:

1. Wyśle odpowiedź z powrotem przez API WhatsApp.
2. Zapisze pełny turnus (użytkownik + asystent + wywołania narzędzi + czas trwania) w D1.
3. Zaktualizuje pamięć długoterminową jeśli turnus wygenerował nowy fakt (np. "klient preferuje sobotę").
4. Wyemituje zdarzenie obserwowalności (metryka opóźnienia, koszt tokenów, szybkość skalowania).

Wszystko to działa w paralele. Persistencja nie blokuje wysłania odpowiedzi — klient nie czeka na D1.

---

Gdzie jest obrona przed alucynacją

Agent, który alucynuje w produkcji, szybko traci zaufanie. OpenClaw ma 4 linie obrony:

1. Źródło prawdy wymuszone. Dane faktyczne (cena, godzina, imię) zawsze pochodzą z umowy, nigdy z modelu samodzielnego.
2. Podwójna weryfikacja danych wrażliwych. Zamówienie jest potwierdzane z klientem przed zapisaniem. Płatność jest potwierdzana przed wydaniem dostępu.
3. Wyraźne reguły negatywne. Osobowość każdego agenta zawiera "nie wynajmuj nigdy X, Y, Z" — model przestrzega.
4. Fallback do człowieka. Gdy żadna umowa nie pokrywa pytania, agent mówi "pozwól mi sprawdzić z zespołem" i otwiera bilet — nie strzela.

W audytach, które przeprowadziliśmy w ciągu ostatnich 6 miesięcy (prawdziwe rozmowy przeglądane ręcznie), stężenie alucynacji faktycznej wyniosło poniżej 0,3% turnusów — i niemal wszystkie przypadki były spowodowane konfiguracją (dzierżawca zapomniał włączyć relevantną umowę), a nie błędem modelu.

Dobrej aranżacja jest niewidoczna dopóki nie zobaczysz faktury. Oto przykład: każdy ruch generuje 1-2 wywołań LLM + lookups w D1, co daje typowy koszt rozmowy pełnej (10-15 ruchów) w wysokości: