Jak Działa Konwersacyjny Agent AI od Środka

Jak Działa Konwersacyjny Agent AI od Środka (Architektura OpenClaw)

Jak działa konwersacyjny agent AI w praktyce, tura po turze? Ten post otwiera czarną skrzynkę OpenClaw: od momentu, gdy wiadomość klienta trafia na WhatsApp, aż po tekst, który agent pisze w odpowiedzi. Będzie technicznie. Warto przeczytać, jeśli decydujesz o architekturze produktu, jeśli zamierzasz kupić rozwiązanie i chcesz ocenić je dogłębnie, albo jeśli po prostu lubisz wiedzieć, co dzieje się za kulisami rozmowy.

TL;DR: każda tura przechodzi przez 6 etapów — ingest, rozwiązanie kontekstu, wybór skills, decyzja o następnej akcji, wykonanie z guard-rails, utrwalenie pamięci. Cały cykl działa w <2 sekundy na edge Cloudflare, bez stałego serwera.

---

Dlaczego architektura ma znaczenie

Konwersacyjny agent, który wydaje się działać na demo, ale psuje się na produkcji, zazwyczaj ma jeden z tych 4 problemów:

1. Wysoka latencja — klient czeka 8 sekund na odpowiedź, rozmowa umiera.
2. Niekontrolowane halucynacje — agent wymyśla cenę, godziny, politykę.
3. Utracony kontekst — klient wraca po 2 dniach, a agent „zapomina" wszystko.
4. Niekontrolowane koszty — każda długa rozmowa wypełnia prompt i płacisz fortunę za tokeny.

Wszystkie 4 to wybory architektoniczne, nie ograniczenia modelu. OpenClaw został zbudowany, aby unikać wszystkich 4 — a drogą do zrozumienia jest przyjrzenie się cyklowi jednej tury.

---

Cykl jednej tury (6 etapów)

Wyobraź sobie, że klient właśnie wysłał wiadomość "quero marcar pra sábado de manhã". Co dzieje się między „received" a odpowiedzią agenta?

Etap 1 — Ingest (edge worker, <50ms)

Wiadomość z WhatsApp trafia przez webhook Meta bezpośrednio do Cloudflare Worker w najbliższym geograficznie punkcie obecności (PoP). W Brazylii oznacza to São Paulo lub Rio, latencja sieciowa < 20ms.

Worker wykonuje trzy rzeczy:

1. Waliduje sygnaturę webhooka (HMAC względem sekretu WABA).
2. Identyfikuje tenanta po numerze telefonu odbiorcy (multi-tenant po to_number).
3. Normalizuje payload — audio zamienia na transkrypcję, obraz na opis, lokalizacja na {lat,lng}, tekst pozostaje bez zmian.

Na końcu etapu 1 masz obiekt {tenant_id, conversation_id, user_message} gotowy do następnego kroku.

Etap 2 — Rozwiązanie kontekstu (D1 + KV, ~80ms)

Agent potrzebuje 3 elementów kontekstu przed podjęciem decyzji:

• Ostatnia historia rozmowy (ostatnie N istotnych tur).
• Pamięć długoterminowa klienta (preferencje, historia zakupów, notatki).
• Stan agenta (persona, włączone skille, reguły).

Wszystko pochodzi z D1 (rozproszonego SQLite od Cloudflare). D1 zastępuje tradycyjnego Postgres/Mongo — bez serwera bazy danych do utrzymywania, dostęp w kilka ms z workera, multi-tenant po tenant_id.

Kluczowy punkt: nie ładujemy całej rozmowy do promptu. Memory Manager v2 z OpenClaw (opisany w naszej dokumentacji wewnętrznej) wybiera tylko tury istotne dla bieżącej tury (ostatnie N + N o wysokiej trafności semantycznej). To utrzymuje przewidywalny koszt tokenów nawet w rozmowach liczących 100+ tur.

Etap 3 — Wybór skilli (policy engine, ~20ms)

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

Dla wiadomości "quero marcar pra sábado de manhã" policy engine filtruje:

• Skille kompatybilne z wykrytą intencją (umawianie).
• Skille dozwolone na tym etapie rozmowy (nie każdy skill jest dostępny przez cały czas).
• Skille, które ten tenant włączył (kalendarz pojawia się tylko jeśli tenant go zintegrował).

Na końcu masz mały podzbiór skilli przekazany do modelu — nie 50 możliwych, tylko 4, które mają tu sens. To drastycznie zmniejsza szansę, że model wywoła niewłaściwy skill.

Etap 4 — Decyzja (wywołanie LLM, 400-1200ms)

Teraz wchodzi model. OpenClaw wykonuje pojedyncze wywołanie do frontierowego LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurowalne per tenant) z:

• System prompt = persona agenta + reguły + dostępne skille.
• History = tury wybrane w etapie 2.
• User message = wiadomość z bieżącej tury.

Model odpowiada jedną z dwóch rzeczy:

• Odpowiedź końcowa (tekst bezpośrednio do klienta).
• Tool call (żądanie wykonania konkretnego skilla 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 guard-railami (zmienne, ~100-500ms)

Skill nie działa w modelu. Działa w naszym kodzie, który:

1. Waliduje parametry (date_range ma poprawny format? mieści się w regułach tenanta?).
2. Sprawdza uprawnienia (czy ten agent ma prawo odpytywać ten kalendarz?).
3. Wykonuje wywołanie (Google Calendar API w tym przypadku).
4. Zwraca ustrukturyzowany wynik do modelu.

Dlaczego to ma znaczenie? Ponieważ model nigdy nie fabrykuje wyniku. Jeśli kalendarz zwróci [10h, 11h], dokładnie to trafia do następnego wywołania. Jeśli skill zawiedzie, model wie, że zawiódł. Zero ryzyka, że agent „wymyśli", że jest termin o 9h, gdy go nie ma.

W przypadkach obejmujących wrażliwe informacje (cena, termin, nazwa klienta), pipeline wymusza tool call — nie pozwala modelowi odpowiadać z własnej „wiedzy". To eliminuje najczęstszą klasę halucynacji w agentach komercyjnych.

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

Mając wynik skilla, model wykonuje drugie wywołanie — tym razem aby sformułować końcową odpowiedź dla klienta. Np.:

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

Równolegle worker:

1. Wysyła wiadomość z powrotem przez API WhatsApp.
2. Persystuje pełną turę (user + assistant + tool calls + czas trwania) w D1.
3. Aktualizuje pamięć długoterminową, jeśli tura wygenerowała nowy fakt (np.: „klient preferuje sobotę").
4. Emituje zdarzenie obserwowalności (metryka latencji, koszt tokenów, wskaźnik eskalacji).

Wszystko to działa równolegle. Persystencja nie blokuje wysyłki wiadomości — klient nie czeka na D1.

---

Gdzie jest obrona przed halucynacją

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

1. Wymuszone źródło prawdy. Dane faktyczne (cena, godzina, nazwa) zawsze pochodzą ze skilla, nigdy z samego modelu.
2. Podwójna weryfikacja danych wrażliwych. Rezerwacja jest potwierdzana z klientem przed zapisaniem. Płatność jest potwierdzana przed udostępnieniem dostępu.
3. Jawne reguły negatywne. Persona każdego agenta zawiera „nigdy nie wymyślaj X, Y, Z" — model się stosuje.
4. Fallback do człowieka. Gdy żaden skill nie obejmuje pytania, agent mówi "pozwól, że sprawdzę z zespołem" i otwiera ticket — nie zgaduje.

W audytach, które przeprowadziliśmy w ciągu ostatnich 6 miesięcy (rzeczywiste rozmowy przeglądane ręcznie), wskaźnik halucynacji faktycznych wyniósł poniżej 0,3% tur — i prawie wszystkie przypadki wynikały z konfiguracji (tenant zapomniał włączyć odpowiedni skill), a nie z błędu modelu.

---

Koszt na rozmowę

Dobra architektura jest niewidoczna, dopóki nie spojrzysz na fakturę. Biorąc pod uwagę, że każda tura wykonuje 1-2 wywołania LLM + zapytania do D1, typowy koszt pełnej konwersacji (10-15 tur) wynosi: