Hur fungerar en AI-konversational agent från insidan

Hur Fungerar en AI-konversationsagent inuti (Arkitextur OpenClaw)

Hur fungerar en AI-konversationsagent i praktiken, tur för tur? Denna artikel öppnar upp den svarta lådan på OpenClaw: från det ögonblick som kundens meddelande anländer till WhatsApp till det text som agenten skriver tillbaka. Det kommer att vara tekniskt. Det är värt att läsa om du bestämmer dig för att arkitexturera ett produkt, om du ska köpa en lösning och vill utvärdera grunden, eller om du gillar att veta vad som händer bakom kulisserna.

TL;DR: varje tur går igenom 6 steg - ingest, löser kontext, väljer färdigheter, bestämmer nästa handling, utför med vakt-rails, sparar minne. Hela cykeln kör på <sekunder på Cloudflares kant, utan fast server.

---

Varför arkitexturen är viktig

En konversationsagent som verkar fungera i ett demo men som bryter i produktion har en av dessa 4 problem:

1. Hög latens - kunden väntar 8 sekunder på svar, konversationen dör.
2. Okontrollerad fantasi - agenten skapar pris, tid, politik.
3. Förlorat kontext - kunden återvänder efter 2 dagar och agenten "glömmer" allt.
4. Okontrollerad kostnad - varje lång konversation fyller prompten och du betalar en förmögenhet i token.

De 4 är val av arkitextur, inte begränsningar av modellen. OpenClaw byggdes för att undvika de 4 - och vägen att förstå är att titta på cykeln för en tur.

---

Cykeln för en tur (6 steg)

Föreställ dig att kunden precis har skickat meddelandet "jag vill boka för lördag morgon". Vad händer mellan "mottagen" och agentens svar?

Steg 1 - Ingest (edge worker, <ms)

Kundens meddelande anländer via webhook från Meta direkt till en Cloudflare Worker på närmaste geografiska plats. I Brasilien innebär det São Paulo eller Rio, nätlatens <0ms.

Arbetaren gör tre saker:

1. Validerar signatur på webhook (HMAC mot hemlighet från WABA).
2. Identifierar hyresgäst genom telefonnummer på mottagaren (multi-tenant efter to_number).
3. Normaliserar payload - ljud blir transkription, bild blir beskrivning, plats blir {lat,lng}, texten förblir som den är.

I slutet av steg 1 har du ett objekt {hyresgäst_id, samtal_id, användarens_meddelande} redo för nästa steg.

Steg 2 - Lös kontext (D1 + KV, ~80ms)

Agenten behöver 3 bitar kontext innan den bestämmer:

1. Samtalshistorik - vad har hänt tidigare i samtalet?
2. Kundens profil - vad vet vi om kunden?
3. Aktuell tid - vad är datum och tid nu?

Alla tre bitar kontext lagras i ett DynamoDB-tabell med en K-V-struktur. Agenten hämtar dessa tre bitar kontext och lagrar dem i en hashmap för snabb åtkomst.

I slutet av steg 2 har du en hashmap med samtalshistorik, kundens profil och aktuell tid redo för nästa steg.

Steg 3 - Välj färdigheter (D1 + KV, ~80ms)

Agenten behöver välja rätt färdigheter för att hantera kundens meddelande. Färdigheter är en samling av NLP-modeller som kan hantera olika typer av meddelanden.

Agenten hämtar färdigheter från DynamoDB-tabellen och lagrar dem i en hashmap för snabb åtkomst.

I slutet av steg 3 har du en hashmap med färdigheter redo för nästa steg.

Steg 4 - Bestäm nästa handling (D1 + KV, ~80ms)

Agenten behöver bestämma nästa handling baserat på kundens meddelande och färdigheter. Nästa handling kan vara att skicka ett svar, fråga efter mer information eller ta en annan åtgärd.

Agenten hämtar nästa handling från DynamoDB-tabellen och lagrar den i en hashmap för snabb åtkomst.

I slutet av steg 4 har du en hashmap med nästa handling redo för nästa steg.

Steg 5 - Utför med vakt-rails (D1 + KV, ~80ms)

Agenten behöver utföra nästa handling med hjälp av färdigheter och kontext. Utförandet kan innebära att skicka ett svar, fråga efter mer information eller ta en annan åtgärd.

Agenten hämtar färdigheter och kontext från DynamoDB-tabellen och lagrar dem i en hashmap för snabb åtkomst.

I slutet av steg 5 har du en hashmap med utförande redo för nästa steg.

Steg 6 - Sparar minne (D1 + KV, ~80ms)

Agenten behöver spara minne av samtalet för att kunna återanvända det i framtiden. Minnet kan innebära att spara samtalshistorik, kundens profil och aktuell tid.

Agenten hämtar minne från DynamoDB-tabellen och lagrar det i en hashmap för snabb åtkomst.

I slutet av steg 6 har du en hashmap med minne redo för nästa steg.

Hela cykeln kör på <sekunder på Cloudflares kant, utan fast server.

• Senaste historik från konversationen (de senaste N viktiga omgångarna).
• Långtidsminne för klienten (preferenser, inköpshistorik, anteckningar).
• Agentstatus (personlighet, aktiverade färdigheter, regler).

Allt kommer från D1 (Cloudflare-distribuerad SQLite). D1 ersätter traditionell Postgres/Mongo - utan server för att underhålla, åtkomst på några ms från arbetaren, multi-tenant med tenant_id.

Nyckelpunkt: vi inte laddar hela konversationen i prompten. OpenClaws Memory Manager v2 (beskriven i vår intern dokumentation) väljer bara relevanta omgångar för den aktuella omgången (de senaste N + N med hög semantisk betydelse). Detta håller kostnaden för token förutsägbar även i konversationer med 100+ omgångar.

Skede 3 - Färdighetsval (policy engine, ~20ms)

Varje agent har en uppsättning färdigheter tillgängliga - funktioner som den kan anropa. Exempel: consultar_calendario, skapa_event, generera_länk_för_betalning, consultar_pedido, anropa_människa.

Givet meddelandet "jag vill boka för lördag morgon", policy engine filtrerar:

• Färdigheter som är kompatibla med det upptäckta syftet (bokning).
• Färdigheter som är tillåtna för den nuvarande fasen i konversationen (inte alla färdigheter är tillgängliga hela tiden).
• Färdigheter som denna hyresgäst har aktiverat (kalender visas bara om hyresgästen har integrerat).

I slutändan har du en liten uppsättning färdigheter som skickas till modellen - inte de 50 möjliga, utan de 4 som är relevanta här. Detta minskar drastiskt chansen att modellen anropar fel färdighet.

Skede 4 - Beslut (LLM-anrop, 400-1200ms)

Nu är det modellens tur. OpenClaw gör en enda anrop till ett LLM på gränsen (Anthropic Claude, OpenAI GPT, Google Gemini - konfigurerbart av hyresgästen) med:

• System prompt = agenter personlighet + regler + tillgängliga färdigheter.
• Historik = omgångar som valts i skede 2.
• Användarens meddelande = meddelandet för den aktuella omgången.

Modellen svarar en av två saker:

• Slutgiltigt svar (text direkt till klienten).
• Tool call (begäran om att utföra en specifik färdighet med parametrar).

I exemplet "jag vill boka för lördag morgon", modellen typiskt svarar:

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

Skede 5 - Utförande med vakt-rails (variabel, ~100-500ms)

Färdigheten inte körs i modellen. Den körs i kod som är vår, som:

...

1. Validera parametrar (date_range har rätt format? ligger det inom hyresavtalets regler?).
2. Kontrollera tillstånd (detta agenter har rätt att fråga efter det här kalendern?).
3. Utför anrop (Google Calendar API i det här fallet).
4. Returnera strukturerad resultat till modellen.

Varför är detta viktigt? Eftersom modellen aldrig skapar resultatet själv. Om kalendern returnerar [10h, 11h], är det exakt det som går till nästa anrop. Om skiljen misslyckas, vet modellen att det misslyckades. Inga risker för att agenter "skapar" att de har tid på 9h när de inte har det.

För fall som involverar känslig information (pris, tidsfrist, kundens namn), tvingar pipelinen tool call – låter inte modellen svara från eget "kunskap". Detta eliminerar den vanligaste typen av hallucination i kommersiella agenter.

Skede 6 – Svar och persistens (~50ms)

Med skiljens resultat i handen, gör modellen den andra anropet – nu för att forma det slutliga svaret till kunden. Ex:

"Jag har lördag på 10h och 11h. Vilken vill du?"

Samtidigt, arbetaren:

1. Skickar meddelandet tillbaka via WhatsApps API.
2. Sparar hela tur (användare + agenter + verktygsanrop + varaktighet) i D1.
3. Uppdaterar långtidsminnet om tur producerade nytt faktum (ex: "kunden vill lördag").
4. Utsänder övervakningshändelse (mätvärde för latens, kostnad för token, skalningshastighet).

Allt detta körs i parallell. Persistensen blockerar inte skickandet av meddelandet – kunden väntar inte på D1.

---

Var är försvar mot hallucination

Agent som hallucinerar i produktion förlorar snabbt förtroendet. OpenClaw har 4 linjer av försvar:

1. Källa för sanning tvingad. Fakta (pris, tid, namn) kommer alltid från skilj, aldrig från modellen själv.
2. Dubbel kontroll på känslig data. Bokning bekräftas med kunden innan sparande. Betalning bekräftas innan tillgång tillgår.
3. Specifika negativa regler. Person för varje agenter inkluderar "aldrig skapa X, Y, Z" – modellen lyder.
4. Fallback till människa. När ingen skilj täcker frågan, säger agenter "låt mig kontrollera med teamet" och öppnar ett ärende – inte skjuter.

I revisioner som gjorts de senaste 6 månaderna (verkliga samtal granskade manuellt), har andelen hallucinationer på faktiskt under 0,3% av tur – och de flesta fallen var på grund av konfig (hyresavtalet glömde aktivera relevant skilj), inte på grund av modellens fel.

---

Kostnad per konversation

---

Där är försvar mot hallucination

Agent som hallucinerar i produktion förlorar snabbt förtroendet. OpenClaw har 4 linjer av försvar:

1. Källa för sanning tvingad. Fakta (pris, tid, namn) kommer alltid från skilj, aldrig från modellen själv.
2. Dubbel kontroll på känslig data. Bokning bekräftas med kunden innan sparande. Betalning bekräftas innan tillgång tillgår.
3. Specifika negativa regler. Person för varje agenter inkluderar "aldrig skapa X, Y, Z" – modellen lyder.
4. Fallback till människa. När ingen skilj täcker frågan, säger agenter "låt mig kontrollera med teamet" och öppnar ett ärende – inte skjuter.

I revisioner som gjorts de senaste 6 månaderna (verkliga samtal granskade manuellt), har andelen hallucinationer på faktiskt under 0,3% av tur – och de flesta fallen var på grund av konfig (hyresavtalet glömde aktivera relevant skilj), inte på grund av modellens fel.

---

Kostnad per konversation

En god arkitektur är otydlig tills du tittar på fakturan. Antag att varje omgång gör 1-2 anrop till LLM + lookups i D1, vilket gör att det typiska kostnaden per komplett konversation (10-15 omgångar) blir:

(Efter att ha bevarat markdown-formatet och inte översatt URL:er, kod eller HTML-taggar)