Hvordan en Konversationel AI-Agent Fungerer Indefra

Hvordan en Konversationel AI-Agent Fungerer Indvendigt (OpenClaw-Arkitektur)

Hvordan fungerer en konversationel AI-agent i praksis, tur for tur? Dette indlæg åbner den sorte boks i OpenClaw: fra det øjeblik kundens besked ankommer på WhatsApp til den tekst, agenten skriver tilbage. Det bliver teknisk. Det er værd at læse, hvis du beslutter produktarkitektur, hvis du skal købe en løsning og vil evaluere det grundlæggende, eller hvis du bare er nysgerrig efter, hvad der sker bag samtalen.

TL;DR: hver tur gennemgår 6 stadier — ingest, løs kontekst, vælg skills, beslut næste handling, eksekvér med guard-rails, persistér hukommelse. Hele cyklussen kører på <2 sekunder på Cloudflares edge, uden fast server.

---

Hvorfor arkitekturen er vigtig

En konversationel agent, der ser ud til at virke i en demo, men bryder sammen i produktion, har typisk et af disse 4 problemer:

1. Høj latenstid — kunden venter 8 sekunder på svar, samtalen dør.
2. Ukontrolleret hallucination — agenten opfinder pris, tidspunkt, politik.
3. Tabt kontekst — kunden vender tilbage efter 2 dage, og agenten "glemmer" alt.
4. Ukontrollerede omkostninger — hver lang samtale fylder prompten op, og du betaler en formue i tokens.

Alle 4 er arkitekturvalg, ikke modelbegrænsninger. OpenClaw er bygget til at undgå alle 4 — og vejen til at forstå det er at se på cyklussen for en tur.

---

Cyklussen for en tur (6 stadier)

Forestil dig, at kunden lige har sendt beskeden "quero marcar pra sábado de manhã". Hvad sker der mellem "received" og agentens svar?

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

Beskeden fra WhatsApp ankommer via Metas webhook direkte til en Cloudflare Worker på det geografisk nærmeste point of presence (PoP). I Brasilien betyder det São Paulo eller Rio, netværkslatenstid < 20ms.

Workeren gør tre ting:

1. Validerer signaturen på webhooken (HMAC mod WABA-hemmeligheden).
2. Identificerer tenanten via modtagerens telefonnummer (multi-tenant via to_number).
3. Normaliserer payloaden — lyd bliver til transskription, billede bliver til beskrivelse, lokation bliver til {lat,lng}, tekst forbliver som den er.

Ved slutningen af stadie 1 har du et objekt {tenant_id, conversation_id, user_message} klar til næste trin.

Stadie 2 — Løs kontekst (D1 + KV, ~80ms)

Agenten har brug for 3 kontekstdele, før den kan beslutte:

• Nylig historik fra samtalen (sidste N relevante ture).
• Langtidshukommelse om kunden (præferencer, købshistorik, noter).
• Agentens tilstand (persona, aktiverede skills, regler).

Alt kommer fra D1 (Cloudflares distribuerede SQLite). D1 erstatter traditionel Postgres/Mongo — ingen databaseserver at vedligeholde, adgang på få ms fra workeren, multi-tenant via tenant_id.

Nøglepunkt: vi indlæser ikke hele samtalen i prompten. OpenClaws Memory Manager v2 (beskrevet i vores interne dokumentation) udvælger kun de relevante ture for den aktuelle tur (sidste N + N med høj semantisk relevans). Dette holder tokenomkostningerne forudsigelige selv i samtaler med 100+ ture.

Fase 3 — Valg af skills (policy engine, ~20ms)

Hver agent har et sæt tilgængelige skills — funktioner den kan kalde. Eksempler: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Givet beskeden "quero marcar pra sábado de manhã", filtrerer policy engine:

• Skills der er kompatible med den detekterede intention (tidsbestilling).
• Skills der er tilladt i denne fase af samtalen (ikke alle skills er tilgængelige hele tiden).
• Skills som denne tenant har aktiveret (kalender vises kun hvis tenanten har integreret den).

I sidste ende har du et lille undersæt af skills der sendes til modellen — ikke de 50 mulige, kun de 4 der giver mening her. Dette reducerer drastisk chancen for at modellen kalder den forkerte skill.

Fase 4 — Beslutning (LLM-kald, 400-1200ms)

Nu træder modellen ind. OpenClaw foretager et enkelt kald til en frontier-LLM (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurerbar per tenant) med:

• System prompt = agentens persona + regler + tilgængelige skills.
• History = udvalgte ture fra fase 2.
• User message = besked fra den aktuelle tur.

Modellen svarer med en af to ting:

• Endeligt svar (tekst direkte til kunden).
• Tool call (anmodning om at udføre en specifik skill med parametre).

I eksemplet "quero marcar pra sábado de manhã" returnerer modellen typisk:

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

Fase 5 — Udførelse med guard-rails (variabel, ~100-500ms)

Skillen kører ikke i modellen. Den kører i vores egen kode, som:

1. Validerer parametre (har date_range korrekt format? er det inden for tenantens regler?).
2. Tjekker tilladelse (har denne agent ret til at slå op i denne kalender?).
3. Udfører kaldet (Google Calendar API i dette tilfælde).
4. Returnerer struktureret resultat til modellen.

Hvorfor er det vigtigt? Fordi modellen aldrig fabrikerer resultatet. Hvis kalenderen returnerer [10h, 11h], er det præcis det, der sendes videre til næste kald. Hvis skillen fejler, ved modellen, at den fejlede. Nul risiko for, at agenten "opfinder", at der er en tid kl. 9, når der ikke er.

I tilfælde der involverer følsomme oplysninger (pris, frist, kundenavn), tvinger pipelinen tool call — den lader ikke modellen svare ud fra sin egen "viden". Dette eliminerer den mest almindelige klasse af hallucination hos kommercielle agenter.

Stadie 6 — Svar og persistering (~50ms)

Med skillens resultat i hånden foretager modellen det andet kald — nu for at danne det endelige svar til kunden. F.eks.:

"Jeg har lørdag kl. 10 og 11. Hvad foretrækker du?"

Parallelt gør workeren:

1. Sender beskeden tilbage via WhatsApp API'et.
2. Persisterer den komplette tur (user + assistant + tool calls + varighed) i D1.
3. Opdaterer langtidshukommelsen, hvis turen producerede et nyt faktum (f.eks.: "kunden foretrækker lørdag").
4. Udsender observabilitetsevent (latensmetrik, tokenomkostning, eskaleringrate).

Alt dette kører parallelt. Persisteringen blokerer ikke afsendelsen af beskeden — kunden venter ikke på D1.

---

Hvor forsvaret mod hallucination befinder sig

En agent, der hallucinerer i produktion, mister hurtigt tillid. OpenClaw har 4 forsvarslinjer:

1. Tvungen source-of-truth. Faktuelle data (pris, tidspunkt, navn) kommer altid fra en skill, aldrig fra modellen alene.
2. Dobbelt verifikation af følsomme data. Tidsbestilling bekræftes med kunden, før den persisteres. Betaling bekræftes, før adgang frigives.
3. Eksplicitte negative regler. Hver agents persona inkluderer "opfind aldrig X, Y, Z" — modellen adlyder.
4. Fallback til menneske. Når ingen skill dækker spørgsmålet, siger agenten "lad mig tjekke med teamet" og opretter en ticket — den gætter ikke.

I audits vi har foretaget over de seneste 6 måneder (rigtige samtaler gennemgået manuelt), lå den faktuelle hallucinationsrate under 0,3% af turene — og næsten alle tilfælde skyldtes konfiguration (tenant glemte at aktivere relevant skill), ikke modelfejl.

---

Omkostningen per samtale

God arkitektur er usynlig, indtil du ser fakturaen. Givet at hver tur foretager 1-2 LLM-kald + opslag i D1, ligger den typiske pris per komplet samtale (10-15 ture) på: